ffdshow tryouts project: Discussion & Development

[LoRd_MuldeR]

There is a directshow input plugin...

Okay. But unless explicitly stated, we must assume that he doesn't use that input plugin and tried to access ffdshow through its VfW interface...

[squid_80]

There's no other way to open matroska files directly in virtualdub (for now ;)). So the plugin must be on his system.

[ikarad]

what is the difference between beta 6 branch and generic branch? Is it the same or not?

[fastplayer]

what is the difference between beta 6 branch and generic branch? Is it the same or not?
FAQ: What is the difference between official releases and SVN builds? (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#releases)

[haruhiko_yamagata]

OK I've been able to find a sample that has both problems. I can always reproduce them at the same frame:

- With Haali's Splitter:

When seeking to frame 160 --> Garbled frames.
When seeking to frame 163 --> Video stops, and if you do anything else with the player it hangs and you have to kill it with task manager. If only 1 thread is used then it does something strange but doesn't hang.

I can't reproduce with your sample. I'm not sure if the problem is the same as premiere-paff.ts.
The garbling with Haali's splitter and premiere-paff.ts is explained here (http://forum.doom9.org/showthread.php?p=1226434#post1226434).

[Reino]

Could you devs please have a look at FFDShow's theora support?

A_New_Computer--med.ogg (http://polycrystal.org/lego/movies/A_New_Computer--med.ogg) OGG[Theora+Vorbis] - Works okay with FFDShow. (upon time-seeking, the image still hangs for ±3seconds, but this is a splitter issue)

transparency.ogg (http://cdn.novell.com/cached/xglrelease/transparency.ogg) OGG[Theora+Vorbis] - Fails with FFDShow (but also fails with the built-in MPC Video Decoder!)
With MONOGRAM GraphStudio the file-loading takes ± 10seconds, then only the FFDShow Audio Decoder is connected to the MKV Splitter (the FFDShow Video Decoder refuses on connecting manually), and finally refushed to render anything at all. Maybe this is a splitter-issue afterall.

Theora+AAC.mkv (http://www.turboupload.com/files/get/FHxLfZku4k/theoraaac.mkv) MKV[Theora+AAC]- Works okay with the MPC Video Decoder, but the FFDShow Video Decoder refuses to connect to the MKV Splitter, so I guess this not the MKV Splitter to blame. In fact, when I mux both streams of A_New_Computer--med.ogg and transparency.ogg into a MKV-container, both files play perfectly with the MPC Video Decoder (incl. time-seeking!!). Way to go on the MKV Splitter! ;)

[tetsuo55]

I did some RMVB tests with ffdshow as the decoder.
the result is better than i expected, all the samples worked, but the CPU usage is massive when compared to the realmedia decoder.

mplayer scored worse here because some samples got displayed incorrectly

Hope the ffmpeg team can still optimize rv40 decoding

[STaRGaZeR]

I can't reproduce with your sample. I'm not sure if the problem is the same as premiere-paff.ts.
The garbling with Haali's splitter and premiere-paff.ts is explained here (http://forum.doom9.org/showthread.php?p=1226434#post1226434).

It seems to be the same as premiere-paff.ts, here you have a screenshot of what happens after seeking to frame 160 with Haali's splitter (and EVR/EVR Custom):

http://thumbnails8.imagebam.com/2150/88785821499227.gif (http://www.imagebam.com/image/88785821499227)

EDIT: Interesting, this only happens with EVR and EVR Custom. Also the freeze only happens with those renderers. VMR9 and the others are problem free. That's probably why you can't reproduce. Can you confirm?

[ikarad]

FAQ: What is the difference between official releases and SVN builds? (http://ffdshow-tryout.wiki.sourceforge.net/FAQ#releases)

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?

[LoRd_MuldeR]

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?

There is no "official" release of ffdshow ever! It's an OpenSource project and development goes on continuously. Changes are applied every single day.

If you want the latest features and improvements (and if you aren't afraid to face new bugs) go with the latest "SVN" build.
And if you need a more tested (but usually somewhat older) build, you should take the latest "beta" version.

Right now "Beta 6" has just been released. So at the moment there is no noteworthy difference between latest "Beta" and current "SVN" ;)

[tetsuo55]

I just read on Kostya's blog (the guy who made the rv40 and rv30 ffmpeg decoders), that the realvideo decoders can be faster than the binary decoder from real itself

he says

When I switch motion compensation functions from C implementations to optimised H.264 counterparts (they are slightly different so the picture quality gets worse) native decoder becomes faster than binary one by several percents on x86 and even faster on PPC. Conclusion: if you want fast decoding then submit SIMD versions of motion compensation functions.


source:http://codecs.multimedia.cx/

[fastplayer]

thnaks but I didn't see the answer of my question in the faq.
beta 6 is it an official release?
It's as official as it can get:
http://ffdshow-tryout.sourceforge.net/

[Atak_Snajpera]

is there any reason why Cubic interpolation is selected by default instead of YADIF?

[LoRd_MuldeR]

is there any reason why Cubic interpolation is selected by default instead of YADIF?

Because it's a very simple, very fast and artifact-free deinterlacer, maybe?

[oddball]

Using ffdshow_prebeta6_rev2527_20081219.exe

Problem: Selecting '3/2/1 - 6 channel' in the 'Mixer' and encoding 6 channel AAC from a Quicktime video to AC3 output results in no audio whatsoever being sent to the SPDIF out.

Setting to 'Same as input' results in it encoding and outputting AC3 fine, as does changing to 'Quad' and a couple of others in the Mixer drop down options.

[Atak_Snajpera]

Because it's a very simple, very fast and artifact-free deinterlacer, maybe?
and very ugly compared to YADIF. Have you ever seen artifacts in YADIF????

[LoRd_MuldeR]

and very ugly compared to YADIF. Have you ever seen artifacts in YADIF????

At least no "combing" artifacts, as you see them with KernelDeinterlacer now and then.

But CPU usage of Yadif is significant higher then Cubic interpolation. Without deinterlacer CPU usage is ~5%, with cubic interpolation it is ~7%, with Yadif it's ~20% :eek:

[STaRGaZeR]

Have you ever seen artifacts in YADIF????

Yes, and quite a few.

[Atak_Snajpera]

Yes, and quite a few.
show me screenshot

But CPU usage of Yadif is significant higher then Cubic interpolation. Without deinterlacer CPU usage is ~5%, with cubic interpolation it is ~7%, with Yadif it's ~20%
Correct me if i'm wrong but it seems that YADIF is multi-threaded.

.mts (AVCHD ~15 Mbps comcorder footage) Q6600@3Ghz
http://img128.imageshack.us/img128/1517/new1kk8.th.png (http://img128.imageshack.us/my.php?image=new1kk8.png)

[LoRd_MuldeR]

Correct me if i'm wrong but it seems that YADIF is multi-threaded.

So what? Multi-threading doesn't lower the required CPU time at all. It simply helps to distrubue the CPU time over several cores.
Yadif still requires significant more CPU time than a simple deinterlacer, like Cubic interpolation. Especially for 1080i stuff it is very demanding!

And keep in mind: Not any ffdshow user has got an up-to-date multi-core CPU :p

[Atak_Snajpera]

And keep in mind: Not any ffdshow user has got an up-to-date multi-core CPU
If you don't have at least 2 cores you can also forget about playing 1080i footage :)

It simply helps to distrubue the CPU time over several cores.
So what? If I have two or more cores why not to use them?

[LoRd_MuldeR]

If you don't have at least 2 cores you can also forget about playing 1080i footage :)

If you have an old CPU, it will be at high load, even for SD content and even without deinterlacing.

In that case you certainly don't want to use a complex deinterlacer, but a simple one.

The other way around there is no problem though: Using a fast deinterlacer on a fast CPU is okay.

So what? If I have two or more cores why not to use them?

Because you are running other tasks in the background, maybe :rolleyes:

It all comes down to one conclusion:
The default deinterlacer shouldn't be the slowest one available in ffdshow, but a fast and simple one.

In case the user prefers a slower deinterlacer, (s)he can choose one at any time...

[Atak_Snajpera]

Because you are running other tasks in the background
Like what? folding@home :) Come on! When I watch movie I don't care if app running in background gets more or less cpu cycles. All I care is video quality. Besides 2 cores is minimum these days if you haven't noticed that. Video decoding/encoding , even games like Far Cry 2 requires 2 cores (on 1 core game is unplayable - massive drop in fps!)

[haruhiko_yamagata]

It seems to be the same as premiere-paff.ts, here you have a screenshot of what happens after seeking to frame 160 with Haali's splitter (and EVR/EVR Custom):

http://thumbnails8.imagebam.com/2150/88785821499227.gif (http://www.imagebam.com/image/88785821499227)

EDIT: Interesting, this only happens with EVR and EVR Custom. Also the freeze only happens with those renderers. VMR9 and the others are problem free. That's probably why you can't reproduce. Can you confirm?
Interesting, then the timing the renderer calls back 'Run' matters. Still can't reproduce though.

[STaRGaZeR]

show me screenshot

http://thumbnails9.imagebam.com/2154/445a5221532760.gif (http://www.imagebam.com/image/445a5221532760) http://thumbnails5.imagebam.com/2154/a206ee21532761.gif (http://www.imagebam.com/image/a206ee21532761) http://thumbnails9.imagebam.com/2154/7013f821532762.gif (http://www.imagebam.com/image/7013f821532762) http://thumbnails13.imagebam.com/2154/22b25021532765.gif (http://www.imagebam.com/image/22b25021532765)

And the same one with ATI's deinterlacer, just for the lulz:

http://thumbnails6.imagebam.com/2154/264c5921532766.gif (http://www.imagebam.com/image/264c5921532766)

Yadif is the best ffdshow deinterlacer, but it's not perfect. Those 4 screenshots in motion look ugly, I tell you!

Interesting, then the timing the renderer calls back 'Run' matters. Still can't reproduce though.

Not even the freeze?

[LoRd_MuldeR]

What I see on your screenshot doesn't look like a "combing" artifact. It's more the way Yadif interpolates that doesn't look "perfect" here.

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...

[STaRGaZeR]

What I see on your screenshot doesn't look like a "combing" artifact. It's more the way Yadif interpolates that doesn't look "perfect" here.

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...

Since when the word "artifact" as Atak_Snajpera wanted means combing? An artifact is an artifact, and those are artifacts.

[LoRd_MuldeR]

Since when the word "artifact" as Atak_Snajpera wanted means combing? An artifact is an artifact, and those are artifacts.

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
I just wanted to point out that one of the great things about Yadif is that it doesn't let any of these "combing" artifacts slip through. Sure it isn't perfect. But which deinterlacer is? ^^
And I still think "Yadif" and "Greedy 2 Frame" are the most satisfying real-time s/w deinterlacers. At least for medium-compressed "real life" footage...

[Atak_Snajpera]

Sure it isn't perfect. But which deinterlacer is? ^^
looks like ati's deinterlacer :) As long as you don't watch anime you can safely use Yadif.

[STaRGaZeR]

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
I just wanted to point out that one of the great things about Yadif is that it doesn't let any of these "combing" artifacts slip through. Sure it isn't perfect. But which deinterlacer is? ^^
And I still think "Yadif" and "Greedy 2 Frame" are the most satisfying real-time s/w deinterlacers...

And I just wanted to show Atak_Snajpera artifacts when deinterlacing with Yadif. If it removes the combing leaving that sh*t on screen it means that the deinterlacer is not doing its job properly in that concrete scene. The goal of any deinterlacer is to convert the image form interlace to progressive and to get rid of any interlace derived artifacts, that means combing, random white pixels or whatever. AFAIK there are 0 perfect smart deinterlacers. No big deal, just some presets and you're done.

looks like ati's deinterlacer :) As long as you don't watch anime you can safely use Yadif.

Nah, ATI has little problems with F1 footage in small areas (combing) too. But I agree, Yadif is just damn good almost always.

[Leak]

I'm yet to see any "combing" artifacts with Yadif, like you see them with KernelDeint/KernelBob or TDeint here and there...
Not to mention that deinterlacing anime is absolutely the wrong thing to do when fieldmatching and decimation are in order...

np: Kid606 - Umbilical Bullets (Die Soundboy Die)

[Leak]

The reason why we need to deinterlace at all are "combing" artifacts and these also are the most annoying artifacts with the classic adaptive deinterlacers (SmartDeint, KernelDeint, TDeint, etc)
Use KernelBob and turn the threshold down to 0 or just slightly above it. That should eliminate any residual combing, and still look great in motion - just don't take screenshots with those settings.

np: Kid606 - Umbilical Bullets (Die Soundboy Die)

[LoRd_MuldeR]

Use KernelBob and turn the threshold down to 0 or just slightly above it. That should eliminate any residual combing, and still look great in motion - just don't take screenshots with those settings.

KernelBob is a pretty good bobber, but even with threshold as low as 3 it shows ugly combing artifacts from time to time. Also static areas tend to flicker at such low threshold. Therefore I usually prefer Yadif in "Double Framerate" mode. Also Yadif produces more smooth edges, while KernelBob tends to show stairs...

[Anima123]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

[Inventive Software]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

RV40 decoding AFAIK is complete, as it's now fully committed in ffmpeg. RV30 is partially complete and in ffmpeg, but samples are welcome to the codec developer (NOT US!): www.ffmpeg.org

[tetsuo55]

At ffdshow-tryout beta6 - audio decoder configuration - Dolby decoder, what does "Apply Dolby Pro Logic II decoding to all stereo sources" actually mean? It act the same as the switch to activate/deactivate Dolby decoder itself. I'm wondering if it tend to be the switch to bypass Dolby decoder process in case the audio stream is pure stereo as I've requested.

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).

Cheers.

For RV40 see my post here: http://forum.doom9.org/showthread.php?p=1226503#post1226503

[MatMaul]

Also I'd like to know if RV40 decoder is not finished yet. Actually in this stage the playback of rmvb files still jerky and cannot afford the same experience as the Real's binary can. Really hope it can get perfect in the near days (months?).
I get jerky playback with RV40 too.
I don't think it comes from the ffmpeg decoder, the images themself are fine.

sample :
http://samples.mplayerhq.hu/real/VC-RV40/spygames-2MB.rmvb

[tetsuo55]

Anima123, Inventive Software, MatMaul
Read my previous post to see why RV40 performance is sub-optimal
For those who know how to program it even states how to fix the perfomance problems, and even improve perfomance beyond that of real-alternative

[MatMaul]

that's not a performance problem, my cpu is under 30%, and all frames seem to be decoded correctly.

[tetsuo55]

that's not a performance problem, my cpu is under 30%, and all frames seem to be decoded correctly.
Okay interesting.

In my testing of mplayer for windows i had the same jerkeyness andf high cpu usage when compared to mpc+real alternative

Also mplayer had aspect ratio problems.

The problem must be ffmpeg then...

[STaRGaZeR]

Not to mention that deinterlacing anime is absolutely the wrong thing to do when fieldmatching and decimation are in order...

Not suitable for watching hundreds of diffferent videos, with different settings for each one :rolleyes:

[haruhiko_yamagata]

Not even the freeze?No, I can't.
I'm adding workaround for the field matching issue, but it is impossible to recover dropped non ref frames.
I'll send you a test build when I'm ready.

[haruhiko_yamagata]

Not suitable for watching hundreds of diffferent videos, with different settings for each one :rolleyes:
After all, does that video need IVTC rather than deinterlacing?

[haruhiko_yamagata]

I wonder how ffdshow can be effected by V-RAM access. It doesn't access the graphics card directly, it just sends over the decoded frame to the next filter in graph, right? ffdshow (or any DirectShow video decoder) writes to V-RAM directly.
ffdshow calls getBuffer on the downstream. Downstream prepare buffer and give it to ffdshow. If the downstream is a video renderer, it will give V-RAM as buffer.

[fastplayer]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).
Right now, the "Package" category looks like this:


Official ffdshow beta releases
Old beta releases
SVN builds by albain
SVN builds by clsid
SVN builds by xxl


Comments:
1.) "ffdshow beta" is redundant: A beta release is an official release.
2.) Older releases should be put under 1.) in a subgroup "Older releases" or something like that
3.-5.) Any chance we consolidate all 3 into one?

How about something like this (proposal #1)?

Official releases

<link to the latest and greatest release>
Older releases

...
...


SVN builds

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



Or better (proposal #2):

ffdshow

<link to the latest and greatest release>
Older releases

...
...


ffdshow (unstable)

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



The advantage of the latter approach is that the "Release" category would carry actual version resp. revision numbers which is more conventional and less confusing than what we have now.

What would top this all off is, if all filenames would follow a consistent and descriptive pattern:

Official releases: ffdshow-<version>-<opt>.exe
SVN builds: ffdshow-SVN-<revision>-<opt>.exe

Placeholder:

<version> - An actual version number. Even a mix of 1.0.<revision> would be an improvement... To denote that it's an actual beta, <opt> could be used like for example: ffdshow-1.0.2527-beta.exe.
<revision> - The SVN revision number. Optionally with "rev" as a prefix. Example for an ICL10 build: ffdshow-SVN-2527-ICL10.exe.
Alternatively, "SVN" could be replaced by "unstable" if proposal #2 is used.
<opt> - For official releases optional (until we get stable 64-bit releases). For generic 32-bit SVN builds it can be omitted otherwise flags should be used - like we do now - that indicate what type of SVN build it is (ICL10, MT, 64-bit etc.).

Any other additional information like builder and date should be added to the file properties.

What do you think?

[STaRGaZeR]

No, I can't.
I'm adding workaround for the field matching issue, but it is impossible to recover dropped non ref frames.
I'll send you a test build when I'm ready.

OK, but I'll be around one week away from my computer. I'll test when I came back. On a side note I had the crash once with VMR9 renderless today.

After all, does that video need IVTC rather than deinterlacing?

No, this one is not hard telecined, simple IVTC would not work.

[tetsuo55]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).
Right now, the "Package" category looks like this:


Official ffdshow beta releases
Old beta releases
SVN builds by albain
SVN builds by clsid
SVN builds by xxl


Comments:
1.) "ffdshow beta" is redundant: A beta release is an official release.
2.) Older releases should be put under 1.) in a subgroup "Older releases" or something like that
3.-5.) Any chance we consolidate all 3 into one?

How about something like this (proposal #1)?

Official releases

<link to the latest and greatest release>
Older releases

...
...


SVN builds

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



Or better (proposal #2):

ffdshow

<link to the latest and greatest release>
Older releases

...
...


ffdshow (unstable)

Generic 32-bit
Generic 64-bit
ICL10 32-bit
MT 32-bit



The advantage of the latter approach is that the "Release" category would carry actual version resp. revision numbers which is more conventional and less confusing than what we have now.

What would top this all off is, if all filenames would follow a consistent and descriptive pattern:

Official releases: ffdshow-<version>-<opt>.exe
SVN builds: ffdshow-SVN-<revision>-<opt>.exe

Placeholder:

<version> - An actual version number. Even a mix of 1.0.<revision> would be an improvement... To denote that it's an actual beta, <opt> could be used like for example: ffdshow-1.0.2527-beta.exe.
<revision> - The SVN revision number. Optionally with "rev" as a prefix. Example for an ICL10 build: ffdshow-SVN-2527-ICL10.exe.
Alternatively, "SVN" could be replaced by "unstable" if proposal #2 is used.
<opt> - For official releases optional (until we get stable 64-bit releases). For generic 32-bit SVN builds it can be omitted otherwise flags should be used - like we do now - that indicate what type of SVN build it is (ICL10, MT, 64-bit etc.).

Any other additional information like builder and date should be added to the file properties.

What do you think?

seconded

[Leak]

No, this one is not hard telecined, simple IVTC would not work.
So what is it then?

Soft telecined? (Which could be IVTCed just the same)
Video only?
24/30FPS mixed?

np: Tocotronic - Meine Freundin Und Ihr Freund (Digital Ist Besser)

[STaRGaZeR]

So what is it then?

As I don't know how to name it, the best is to see it for yourself:

http://www.megaupload.com/?d=TM593MS6 (67MB)

Soft telecined? No.
Video only? No.
24/30FPS mixed? I have several of these and they certainly don't look like this one. 30FPS with parts that look perfect without any filter, parts that need deinterlacing, no repeated fields or frames...

[haruhiko_yamagata]

@all devs and builders

I'd like to propose some changes to the download page on SF.net (https://sourceforge.net/project/showfiles.php?group_id=173941).

I agree. No other projects use builder's name for the name of package. Casual users don't know the name of builders.
But if we want to keep their names written, they can be written in the filenames. It is less confusing than current mess.