ffdshow tryouts project: Discussion & Development

[MatLz]

Unless you mean the difference between ICL10 and ICL11 builds, then the difference between MSVC2008 and ICL11 with resizing+deband+HQRGB32 is ~=15%. Which reminds me I have to finish that benchmark at some point. :) But you can find some previous results by searching this thread.Nope, I only meant the pure decoding speed compared to regular builds, with no filtering.
So am I wrong ?

[clsid]

For pure decoding all builds give the same performance because GCC is used as compiler for libavcodec.dll

[MatLz]

For pure decoding all builds give the same performance because GCC is used as compiler for libavcodec.dllThanks for this precision.
In fact, the only 'filtering' I use is the 'gamma-contrast-brightness...', so can it be the cause of the small speed gain I noticed ?

[clsid]

That filtering is done using the GPU, so it does not affect performance. You need to do benchmarks to see if there are actual differences.

[Sebastiii]

@SamuriHL : I thought that both mkv/mpeg splitters acted the same way.
So MPC M2TS splitter + PGS => ok but one should wait for the first parsed gub
MPC MKV splitter + PGS => not detected

But Haali still suffer from HD audio splitting, no ?

And do you have any news concerning audio dropouts with radeons 5xxx series ?
Thanks

Hi,

Casimir666 has added support for MPC Matroska Splitter for PGS sub today :)

Thanks to him :)
And it's working great :)
Seb.

[gametiger]

Sorry if this has been discussed already, but I just couldn't find anything useful.

I'm using the ffdshow DXVA video decoder for all my DXVA compliant files, but I also have a few H.264 encodes that aren't DXVA compliant (too many reference frames). So I thought I could use the "normal" software ffdshow video decoder for these, i.e. only use the DXVA decoder for files it's going to support. Is it possible to (automatically) do this?

I'm using the latest MPC-HC and ffdshow builds. CPU is a Core 2 Duo E8400, ATI HD5750 graphics. Thanks!

[clsid]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.

[pankov]

clsid,
am I correct to read your words that if the stream is not DXVA compliant the building of the graph will fail and then the player will have to select another decoder?
If that's the case this is very inconvenient because for example if one (like I do) uses ZoomPlayer's "Smart Play" functionality and have configured FFDShow DXVA decoder for H264 when the building of the graph fails an error message will appear and then the default directshow graph creation will kick in. In most cases this default graph will be a mess ... at least not what the user wants. As we all know most if not all computers have more than one filter for each format and also most of us have configured ffdshow raw decoding both for audio and for video but use it only in certain cases. All this usually leads to 2-3 decoders in both the video and audio chains and this is never good.
So isn't it possible to add an option in the ffdshow DXVA decoder to fallback to the defaul ffdshow decoder when the stream is not DXVA compliant?

[clsid]

The graph won't fail. The decoder will simply deny the connection. Then DirectShow will try inserting the next available decoder into the graph (which usually is the regular ffdshow decoder).

[STaRGaZeR]

There has been a lot of talk about ATI cards being able to decode 5.1 streams, and I keep seeing files that crash the driver, play with artifacts or simply BSOD, like this one. It's 4.1 compliant in everything except resolution, so it's actually 5.0. MPC reverts to software decoding, but ffdshow uses DXVA and the driver crashes. Play it a second time and you'll get a BSOD.

http://www.megaupload.com/?d=QH4TWGBO (35MB)

[pankov]

well, if the decoder denies the connection this means that ZoomPlayer will fail to build the graph with the preconfigured decoders and will fallback to the default directshow graph building.
I tried the following:
1. disabled the H264 DXVA codec in ffdshow DXVA configuraiton.
2. configured ffdshow DXVA decoder as the prefered H264 decoder
3. played a H264 file and got the following warning
Could not find a suitable Decoder for "[Source File: Smart Play Graph].Video"

SubTypes:
{31435641-0000-0010-8000-00AA00389B71}
and then the following error

Could not create a Smart Play Graph, will now try a standard graph...
So I as I see it - this is not working for ZoomPlayer users
:(

[dann23]

There has been a lot of talk about ATI cards being able to decode 5.1 streams, and I keep seeing files that crash the driver, play with artifacts or simply BSOD, like this one. It's 4.1 compliant in everything except resolution, so it's actually 5.0. MPC reverts to software decoding, but ffdshow uses DXVA and the driver crashes. Play it a second time and you'll get a BSOD.

http://www.megaupload.com/?d=QH4TWGBO (35MB)

The Ati cards are capable to decode 5.1 streams. I tried to play the sample. It works afters waiting 3 minutes :) but I after it started my monitor entered in sleep mode but audio worked. I think it will be more usefull to report this in Ati forums. This way they will correct in a future driver release. Also I think it's important to specify that ffdshow dxva is playing this file if compatibility mode is set to skip all checks.

[clsid]

Disabling DXVA and then setting it as preferred decoder will obviously fail. Duh. First do things the right way and if it still fails then you should ask the ZoomPlayer developers to handle this kind of situation properly.

[pankov]

clsid,
I was just trying to simulate an non dxva compliant stream playback, because I couldn't quickly find one that isn't. That's the only reason I changed ffdshow's config. Of course I won't leave it this way.
Well I'm not sure it's players responsibility to change decoders depending on the DXVA compliance of the stream. AFAIK there is only one media subtype for both DXVA and non DXVA H264 streams so the player cannot have different configurations for different H264 streams. One more reason that brings me to the same conclusion is that all other DXVA capable decoders fallback to software mode without the need to rebuild the graph or change the decoder. This is true for MPC's Video decoder, Cyberlink's one, DivX's one and I'm pretty sure it's the same with Microsoft's DTV-DVD decoder too.
So I think it's only FFDShow that's making it in different way which is not very convenient for the users.
I'll be glad to be proven wrong here and somebody to show me how to use ffdshow DXVA decoder in Zoomplayer or DVBViewer (another player in which you can configure only one H264 decoder at a time)

[STaRGaZeR]

The Ati cards are capable to decode 5.1 streams. I tried to play the sample. It works afters waiting 3 minutes :) but I after it started my monitor entered in sleep mode but audio worked. I think it will be more usefull to report this in Ati forums. This way they will correct in a future driver release. Also I think it's important to specify that ffdshow dxva is playing this file if compatibility mode is set to skip all checks.

ffdshow r3480 plays this file with compatibility mode set to normal, not skip all checks. So waiting 3 minutes is being capable of decoding it? I'd really like to know what would happen if I make a test encode with this resolution plus 16 ref frames, of course 5.1 compliant ;)
Writing on ATI forums is useless IMO. ATI cards definitely have bad support for high resolution and high number of ref frames. The issue I see here is that this particular file is blocked by MPC, but not by ffdshow. Looking at how it crashes the driver here I'd say MPC is right and ffdshow is not. Also, why MPC blocks it if this card can play 5.1 streams? :p

[dann23]

be patient :) They've just added support for 5.1 streams. Maybe they will fix it. But I don't know why I have to choose skip all checks in ffdshow to play 5.1 streams if my card and my driver support it. I didn't have problems with 5.1 streams until this sample of yours :D
And I believe that wating 3 minutes to play that sample is equal to the blue screen you had.:p because my monitor went black after that yet my computer was working. I could hear the sound. stupid driver:D

[clsid]

clsid,
I was just trying to simulate an non dxva compliant stream playback, because I couldn't quickly find one that isn't. That's the only reason I changed ffdshow's config. Of course I won't leave it this way.
Well I'm not sure it's players responsibility to change decoders depending on the DXVA compliance of the stream. AFAIK there is only one media subtype for both DXVA and non DXVA H264 streams so the player cannot have different configurations for different H264 streams. One more reason that brings me to the same conclusion is that all other DXVA capable decoders fallback to software mode without the need to rebuild the graph or change the decoder. This is true for MPC's Video decoder, Cyberlink's one, DivX's one and I'm pretty sure it's the same with Microsoft's DTV-DVD decoder too.
So I think it's only FFDShow that's making it in different way which is not very convenient for the users.
I'll be glad to be proven wrong here and somebody to show me how to use ffdshow DXVA decoder in Zoomplayer or DVBViewer (another player in which you can configure only one H264 decoder at a time)
If the "preferred" decoder fails, then ZoomPlayer should just pick the next available decoder. If ZoomPlayer shows you an error after trying just one decoder, then that is simply stupid behavior of ZoomPlayer. They can easily fix that flaw.
The behavior of ffdshow is working fine and is intentional to allow fallback to software decoders other than ffdshow. This will not change!

[SamuriHL]

Hi,

Casimir666 has added support for MPC Matroska Splitter for PGS sub today :)

Thanks to him :)
And it's working great :)
Seb.

SERIOUSLY?? Man all the fun happens when I'm on vacation. I came back home just for tonight but I'll have to grab that and give it a quick test before I leave for the rest of the week. Do you have a link?

[Sebastiii]

Hi :)
You can try this :)

Filter MPC Matroska ans MPEG LAST SVN (http://sebinternet.free.fr/mediaportal/2010.06.20-MKVHD.rar)

Enjoy :)
Seb.

[SamuriHL]

Hi :)
You can try this :)

Filter MPC Matroska ans MPEG LAST SVN (http://sebinternet.free.fr/mediaportal/2010.06.20-MKVHD.rar)

Enjoy :)
Seb.

Thanks, Seb! I'll give it a try. Won't get to do much after I leave again in the morning as I'm beaching it up for a week. :D This is great, though, as I can finally drop Haali.

[gametiger]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.
I have a H.264 720p High@5.1 (16(!) ref frames) video that stops playing after 7 seconds (audio stops a few seconds later), isn't this regarded DXVA non compliant?

Also, I noticed some major artefacts with SD (both 4:3 and 16:9) H.264 3.1 w/ 8/9 ref frames material. What's up with that?


Maybe the way I setup my external filters in MPC-HC has something to do with it: I have both the DXVA and the normal ffdshow video decoder set to preferred in the External Filter settings.

I hope someone can help, thanks!

[Sebastiii]

hehe it's works here :) and good vacation to you :)
The next step it to add the full support of EDITION (multi end of movie).
Some issue to fix about DVDSUB i have see on one mkv sample.
And the splitter goes to 100% :)
Seb.

[Snowknight26]

The DXVA decoder checks for compliance and only decodes streams that pass that test. Whatever other decoder you have installed will take care of the rest.

So why does High 4:4:4 Predictive pass?

[clsid]

I have a H.264 720p High@5.1 (16(!) ref frames) video that stops playing after 7 seconds (audio stops a few seconds later), isn't this regarded DXVA non compliant?Cut a sample of that file and post it in the MPC-HC topic. Then the MPC devs can test it. (ffdshow uses the same DXVA code as MPC-HC)
Also, I noticed some major artefacts with SD (both 4:3 and 16:9) H.264 3.1 w/ 8/9 ref frames material. What's up with that?
The SD issue is a bug in the ATI driver.
So why does High 4:4:4 Predictive pass? The DXVA compliance test currently only looks at the number of reference frames. Post problematic files in the MPC-HC discussion topic.

[STaRGaZeR]

be patient :) They've just added support for 5.1 streams. Maybe they will fix it. But I don't know why I have to choose skip all checks in ffdshow to play 5.1 streams if my card and my driver support it. I didn't have problems with 5.1 streams until this sample of yours :D
And I believe that wating 3 minutes to play that sample is equal to the blue screen you had.:p because my monitor went black after that yet my computer was working. I could hear the sound. stupid driver:D

What I don't really like is that after a driver is out saying something like "support for 5.1 H.264 streams blabla" there's a lot of people in the MPC thread saying "ey, I've tested this sample with 16 ref frames and it worked!". Then one dev removes the checks for it, and then a lot of users complain because it really doesn't support 5.1 at all. After that you can read things like "UVD cards can't play it, UVD2 cards can!". This is also not true, and we have the problem again. Anything above 4.1 (and above 10 ref frames or so) has very high chances of not working with DXVA on ATI, and thus software decoding should be used instead.

Can anybody test this sample with Microsoft's decoder?

[Snowknight26]

Anything above 4.1 (and above 10 ref frames or so) has very high chances of not working with DXVA on ATI, and thus software decoding should be used instead.

Have any figures to back up that claim?

[Midzuki]

Only now that I'm planning to build a "trashy" 8.1 sound system by using two sound cards at the same time, I perceive there is no "back center" in the Volume tab of the audio decoder/processor. What's up? :confused: :confused: :confused:

[Eliminateur]

@xhmikosr: i've been following your build and wanted to ask you a question, is the x64 build also ICL11?

[ptr727]

Hi, where do I get the debug symbols for ffdshow tryout builds posted on SF?

They do not appear to be posted anywhere, if they are being posted, please point me to them.

Reason I ask is that my player crashes die to ffdsow, and I would like to help fix the problem.

If symbols are not being posted, how can the community help with ffdshow crashes?
E.g. is ffdshow registered with Microsoft WinQual, do the symbols have source server integration, etc.?

Regards
P.

[XhmikosR]

@xhmikosr: i've been following your build and wanted to ask you a question, is the x64 build also ICL11?

No, I get lots of errors when compiling ffdshow x64 with ICL.

Hi, where do I get the debug symbols for ffdshow tryout builds posted on SF?

They do not appear to be posted anywhere, if they are being posted, please point me to them.

Reason I ask is that my player crashes die to ffdsow, and I would like to help fix the problem.

If symbols are not being posted, how can the community help with ffdshow crashes?
E.g. is ffdshow registered with Microsoft WinQual, do the symbols have source server integration, etc.?

Regards
P.

I don't think you'll find any symbols anywhere unless clsid has kept them. Not to mention that the linker option /DEBUG is not enabled for release builds, which should change in my opinion along with the IntDir.

[Dislikeyou]

Has the multithread bug in ffdshow (ffmpeg-mt) been fixed? i mean when u select to use ffmpeg-mt for h264 and have 8 threads it would make garbaged picture..

Thanks!

[madshi]

It is not really a splitter error. If it works with other renderers, then I see no reason why it shouldn't be possible to make it work with the modified EVR renderers. In fact, the pre-beliyaal EVR CP worked ok with VC-1.
FWIW, it definitely is a splitter error. The MPC HC splitter outputs "shuffled" timestamps for VC-1 m2ts files. When using Haali to split the m2ts file, the problem disappears. When remuxing the VC-1 m2ts file to MKV, the problem disappears (regardless of which splitter is used). Some VC-1 decoders seem to reorder the shuffled timestamps, others don't. Some renderers cope with the shuffled timestamps, other don't. The next madVR renderer version will be able to handle the shuffled timestamps, but it's not ideal, because there can be a audio/video sync problem, because it's not possible for the decoder/renderer to know which timestamp belongs to which frame exactly.

[clsid]

Has the multithread bug in ffdshow (ffmpeg-mt) been fixed? i mean when u select to use ffmpeg-mt for h264 and have 8 threads it would make garbaged picture.Does it also happen with 2 or 4 threads? Does it happen with all files, or just some? A sample file would be useful.

[ptr727]

I don't think you'll find any symbols anywhere unless clsid has kept them. Not to mention that the linker option /DEBUG is not enabled for release builds, which should change in my opinion along with the IntDir.

You don't need debug builds to generate symbols, you just need to generate symbols.

It is standard practice to generate PDB's, ideally with source server integration, for release builds, without them, it is very difficult to debug crashes, you need at least a MAP file, with them, it is much simpler.

If PDB's are generated, but not made public, is it expected that testers send the crash dumps to developers?

P.

[XhmikosR]

I never said anything about debug builds. I said about the /DEBUG switch regarding the linker which generates the PDB files. Other than that, see my previous post and you'll see I suggested the same thing about release builds. I cannot give you an answer about PDB files not be released in public.

[ptr727]

I never said anything about debug builds. I said about the /DEBUG switch regarding the linker which generates the PDB files. Other than that, see my previous post and you'll see I suggested the same thing about release builds. I cannot give you an answer about PDB files not be released in public.

Apologies, misinterpreted.

[STaRGaZeR]

Have any figures to back up that claim?

The sample I posted before, all the complaints each time MPC devs change something in the compatibility code, all the x264 encoded videos that give me black screen, crash the driver or simply BSOD, etc.

[clsid]

The main MPC-HC discussion topic is too unorganized to deal with this properly.
Perhaps you or anyone else that is having lots of DXVA problems could take the initiative to open a new topic to discuss those problems.
The main task of the topic starter would be to keep the first post updated with the information posted in the topic. So it requires a bit of effort.
It should also contain a few (problematic) samples that people can use for testing. As the topic progresses, any useful samples posted could be added to the first post. For each sample a mediainfo log should be included (or perhaps just the relevant parts: reference frames, resolution, level).

People who test the files should provide as much details as possible like:
- Name of sample tested
- Result: artifacts/crash/bsod/plays fine/something else
- Graphics card brand and model number
- Driver version
- Windows version
- The splitter that was used (if relevant)

If enough people post test results, then we should be able to improve the compatibility check.

[Snowknight26]

The sample I posted before, all the complaints each time MPC devs change something in the compatibility code, all the x264 encoded videos that give me black screen, crash the driver or simply BSOD, etc.

Ah, so it only affects you, not 'DXVA on ATI' like you said, which is a blanket statement.

[STaRGaZeR]

The main MPC-HC discussion topic is too unorganized to deal with this properly.
Perhaps you or anyone else that is having lots of DXVA problems could take the initiative to open a new topic to discuss those problems.
The main task of the topic starter would be to keep the first post updated with the information posted in the topic. So it requires a bit of effort.
It should also contain a few (problematic) samples that people can use for testing. As the topic progresses, any useful samples posted could be added to the first post. For each sample a mediainfo log should be included (or perhaps just the relevant parts: reference frames, resolution, level).

People who test the files should provide as much details as possible like:
- Name of sample tested
- Result: artifacts/crash/bsod/plays fine/something else
- Graphics card brand and model number
- Driver version
- Windows version
- The splitter that was used (if relevant)

If enough people post test results, then we should be able to improve the compatibility check.

I don't use DXVA very often, just after some relevant updates, or to test some samples, so I can't really be of any help with this. That's how I discovered this one, I asked myself: "Would this play with DXVA? I think it won't". Boom, BSOD. There's already a thread about this, but it's old and abandoned (http://forum.doom9.org/showthread.php?t=153006). What about resurrecting it?

Ah, so it only affects you, not 'DXVA on ATI' like you said, which is a blanket statement.

No, it isn't. Read some pages from here: http://forum.doom9.org/showthread.php?p=1395672#post1395672, and skip the SD blockiness posts, it has been fixed. The hangs with 16 ref frames material is not fixed. >1080p doesn't work either.

Read dann23 posts again. The sample I posted is 2516x1700 and 5.0 compliant.

Bottom line: 5.1 on ATI is a disaster with ffdshow/MPC. I still want to know if this sample crashes with Microsoft's H.264 decoder, or if anybody has been able to properly play any >1080p video with DXVA on ATI.

[Dislikeyou]

Does it also happen with 2 or 4 threads? Does it happen with all files, or just some? A sample file would be useful.

This is what im talking about:
Image corruption while using ffmpeg-mt with more than 1 thread. (libavcodec and DVXA are also ok)
http://img265.imageshack.us/img265/5303/avatarblurayffmpegmtcor.png

Tested with ffdshow r3370 xxl and r3390 from http://www.xvidvideo.ru

This must be some very old bug because it occurs even in very old revisions as well.

Remuxed BD sample http://www.sendspace.com/file/f9s4te

[dimitrik]

I want to start by apologizing for what might be an off-topic post, however I'm hoping that others might also find it useful as part of a discussion on ffdshow.
Moreover the people in this thread are probably the most qualified on the planet to answer...

I have been wondering what is the effect of CPU cache on ffdshow performance (e.g. between Athlon II & Phenom II CPU's).

I have never found any clear info except generic stuff like "more is better":rolleyes: and "intel is better than AMD" (possibly due to the SSE2 units?). But cache is something you can pay more for, so knowing if it's worth it seems useful.

Again I apologize if the post is OT and thank you for any opinions offered.

[clsid]

In general more CPU cache gives better performance. But it is just one of the many factors that play a role in the performance of a CPU. So you better just look at a CPU benchmark to compare different CPUs. You can find lots of such benchmarks on hardware sites.

[clsid]

This is what im talking about:
If I can remember correctly fixing that specific problem would require using FFmpeg's H.264 parser in ffdshow.
We need a volunteer to do that.

[dimitrik]

Sadly the hardware sites concentrate much too much on 3D games benchmarks and too little on multimedia performance - it is taken as a given (wrongly so IMO).

Still this is helpful info. Thank you!

[Midzuki]

Plus 10 points for the old school reference!
Thanks for the 10 points.
Even though I'm not sure about your meaning for "old school reference"...

Anyway, "labels" are not very important,
especially if/when they can mislead us.
Stubbornness is bad, and it doesn't care at all if the source-code refers to a web-browser or to a DirectShow decoder. :(

[pankov]

Guys,
since svn build 2067 of MPC's splitter the problem with some H264 streams in TS container is fixed I found a problem in FFDShow ... or it could be still in the splitter - you know better.
If I try to play the sample I used to report the problem of the splitter here
http://forum.doom9.org/showthread.php?p=1410473#post1410473
and use ffdshow as H264 decoder I only get black screen with audio.
If I use CoreAVC or Microsoft DTV-DVD Decoder everything is fine.
Am I doing something wrong or it's really a bug in ffdshow?

[pankov]

and two more problems when using the sample from my previous post and ffdshow:
1. If I add the ffdshow Video Decoder filter as a postprocessor after Microsoft DTV-DVD Decoder I get black and white picture. There is no problem if I add it after CoreAVC but then again if I don't add it after Microsoft's decoder I have coloer
Ideas???
2. If I add the ffdshow raw video filter as a postprocessor after any other filter I get
---------------------------
Zoom Player
---------------------------
Access violation at address 58793E56 in module 'ffdshow.ax'. Read of address 00000504.
---------------------------
OK
---------------------------

What am I doing wrong?

[jeremy33]

This is what im talking about:

If I can remember correctly fixing that specific problem would require using FFmpeg's H.264 parser in ffdshow.
We need a volunteer to do that.

If you remux the sample to mkv there is no probleme with multi threads in ffdshow

[magic144]

Is anybody (else) still seeing sys-tray FFv icon right-click induced crashes (I know this has been reported here on a couple of occasions in the recent past). I have been getting these regularly for several weeks' worth of the latest revisions.

It never used to happen, and it only seems to happen with some content - though not WMV for some reason - using the regular (NOT DXVA) decoder filter. The DXVA filter's video sys-tray icon is fine.

Manually creating a graph and playing the same file using GraphStudio - seems to work OK too. I am using Zoom Player MAX 7.1a5.
Is there any particular data-set I can provide here that would help point to the cause? The M$oft crash window always points to ffdshow.ax as the 'fault module' - here is a typical output:-

Problem signature:
Problem Event Name: APPCRASH
Application Name: zplayer.exe
Application Version: 7.0.0.0
Application Timestamp: 2a425e19
Fault Module Name: ffdshow.ax
Fault Module Version: 1.1.3476.0
Fault Module Timestamp: 4c179977
Exception Code: c00000fd
Exception Offset: 0004c344
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 4105
Additional Information 1: c6b1
Additional Information 2: c6b143c661515d69d4d8c4d358f23b56
Additional Information 3: 73ae
Additional Information 4: 73aedc52574d1a2c0c1aadf1d653516b

----

I should point out that at least one op on the ZP forum does not see the same failure mode, however they do report that rather than a crash, 'nothing' sometimes happens when right-clicking the video tray icon for them.

For me, the crash has been observed on 3 separate Windows-7 32-bit Home Premium platforms, including one fresh (clean) Win7 install with no 3rd party apps, right after having installed latest ffdshow + Haali + ZP.