ffdshow tryouts project: Discussion & Development

[Eliminateur]

Hello,
i've been trying to playback a H264 Hi10P L4.0 file and i get horrible blocking artifacts of quite distinct colour which makes me suspect it isn't supported, will this be supported with Lord's 10 bit patch?

this is the info:
Format/Info : Advanced Video Codec
Format profile : High 10@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 19s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits

[mark0077]

clsid / guys, would you know if ffdshow doesn't set the output pin to the correct fps by design, or if it would be much work to get it to do it correctly. For example if I use yadif, or an avisynth script that changes the fps, ffdshow doesn't indicate this to the next filter / or renderer in the chain.

EDIT: I also notice it effects use cases in ffdshow like

---------------
Input to ffdshow: 25.00fps interlaced content
De-interlacing: ON (yadif - double frame rate) - outputs 50fps
Avisynth Script: (Performs certain actions for Framerate==25fps and other actions for Framerate==50fps, uses ffdshow_source() to get input)
---------------

I find the above Avisynth script will have trouble as it actually thinks the video input its getting is 25.00 fps but its actually getting 50.00fps output from Yadif. Took me a while to figure out what was going wrong in my avisynth script. This was the problem. Again, would you know if this is a bug or by design? Thanks

[clsid]

Probably a bug. Put it on the bugtracker and hope someone comes along to fix it.

[mark0077]

np, done, thx https://sourceforge.net/tracker/?func=detail&aid=3375672&group_id=173941&atid=867360

[VipZ]

clsid, I am not sure if you interested. I made a patch to make ffdshow more modular in filter registration, I extended how DXVA is done to all the other filters. I didn't made changes to the installer, as this is probably more catered to those who make custom installers.

Patch, http://www.mediafire.com/?5i0rhls7cxh8fsi

[Snowknight26]

How would one go about changing the prefered order of colorspaces used when connecting to other filters? If I have YV12 and NV12 checked, FPS1 -> x is converted to YV12 first (causing bad colors) instead of NV12 (normal colors).

[Delerue]

Does anybody knows if there is any progress with MJPB support, since FFMpeg already supports it? This sample can't be opened with just MPC-HC + FFDShow: http://red.cachefly.net/video/milkgirls1080p.mov

[Blight]

bug report:
Users are reporting problems playing some MKV files with H264/AC3 using ffdshow to output to S/PDIF (while other MKV files with apparently the same codecs play just fine).
The problem is that the ffshow audio decoder refuses to connect to the Default DirectSound audio renderer.
When disabling S/PDIF output, the audio renderer connects just fine.

The problem also depends on the splitter used:
If Haali's or MPC's Matroska splitter i used, the audio decoder wont connect.
If I switch to LAV Splitter, the filter connects and the media plays.

Here's the settings I modified to get the filters to connect (with no success):
1. AC3 decoders (liba52 and libavcodec).
2. 'Connect as PCM' enabled/disabled.
3. 'try all formats' and 'try only standard formats'.
4. Enabling 24bit,32bit and 16bit LPCM output (tested LPCM separately from 24bit/32bit).

I've tested this procedure using the latest ffdshow (ffdshow_rev3949_20110725_clsid.exe), latest MPC standalone filters, Haali splitter and LAV Splitter v0.30.
It appears that the ffshow's output pin presents a different format for the problematic files (see screenshot below).
With mkv files that do play (with exactly the same filters), the pin output looks the identical to the pin output when using the LAV Splitter with the problematic MKV files.

Here's a graphedit screenshot showing with some additional information:
http://t.inmatrix.com/ffdshow_ac3bug.png

[nevcairiel]

If i had to guess, i would say the following:

- The MKV headers contain wrong audio information (apparently it names the sample rate 8kHz, instead of 48kHz?).
- Haali and MPC Matroska simply output the informations as they were contained in the container, while LAV Splitter actually checks the stream to get the information (and therefor, figures out that its 48kHz)
- ffdshow uses the information supplied from the input pin to create the output media type.
- DirectSound refuses a connection to a 8kHz sample rate.

Of course, this is just guess-work. Also, not sure if this can be fixed in ffdshow easily, as it really has to rely on the source-filter provided data. Of course there are ways around that, especially when outputting for SPDIF, because the sample rate doesn't matter there.

PS:
I still wonder why people use GraphEdit when GraphStudio is so much nicer to work with. ;)

[Blight]

nevcairiel:
GraphStudio used to be unstable for me, but it was years since I last tested it.
Next screenshot ;)

Since this problem doesn't affect decoded output, only S/PDIF,
Could the fix be to present a 48kHz media-type for S/PDIF connections that have 8kHz listed in the headers?

[nevcairiel]

I wonder anyway why the sample rate is used for the SPDIF media type - its sample rate is independent of the actual stream sample rate.

[clsid]

A quick and dirty fix could be adding sample rate check in TsampleFormat::createMediaTypeSPDIF. But I don't have the hardware to test. One of the other devs has to fix this.

[blah123]

I dont' know, what this matter is problem with, but I think it has strong connection with ffdshow... I'll call it "sudden artifacts".
I try to encode MPEG-TS AVC/H264 to AVI XviD (recording from DVB, interlaced). I tried MeGUI and StaxRip - these two apps gives the same bug.
This is Win7 x64 and installed: ffdshow x86 (based on libvacodec), Haali, LAV x86&64, XviD.
Like I've written - this is interlaced DVB-T recording, so I use "Linear blending" deinterlacing in ffdshow. After re-encoding and playing AVI or using the option from StaxRip to preview in deafult system player, sudden artifacts appear very often in it, sometimes in 1 minute.

You can see them here (3 frames in a row, the second with macroblocs):

http://i.imgur.com/X3ARv.jpg (http://imgur.com/X3ARv) http://i.imgur.com/DisG5.jpg (http://imgur.com/DisG5) http://i.imgur.com/9ZuAu.jpg (http://imgur.com/9ZuAu)

These artifacts aren't always in the same frames, but they change their positions. After I re-open the file, artifacts are in different frames.
I don't know, how to resolve this problem.

Couple of details about this MPEG: it hasn't WSS (resolution: simple 720x576), but it's 16:9 letterbox - so I needed to crop letterboxes, and then put in 16/9 LanczosResize (624x352).

[jmone]

That is not because of the integration. A recent fix in the FFmpeg/Libav code is the cause of this performance regression. One of the devs has been notified, so hopefully the situation can be improved.

FYI, It is not just interlaced material my AVC/264 1080/50p stuff also stutters now even on an i7-920 (same with LAVVideo)

[nevcairiel]

FYI, It is not just interlaced material my AVC/264 1080/50p stuff also stutters now even on an i7-920 (same with LAVVideo)

I can play 1080p/60 high-bitrate material just fine on my i7-2600k. Granted, its faster then a 920, but still, the "birds" killer sample, or the CrowdRun 2160p sample are the most complex H264 clips i really know, and they play fluently. Maybe i should benchmark them.

There must be some other factor involved that is hidden somewhere.
Did someone ever link a clip that very obviously shows the performance problem?

[jmone]

Here is a sample AVC 1080/50p file that used to without ffdshow breaking a sweat with ffmpeg-mt, now it is all dropped frames with madVR (OK on EVR) as the queues are never full. http://www.megaupload.com/?d=7JIIQC7C

[nevcairiel]

I just benchmarked that sample, and it topped out at around 80fps, which really isn't fast. In comparison, the very complex high-bitrate Birds sample still runs at around 340fps.

[jmone]

Thanks nevcairiel - I'm not sure what that all means (is more better or worse?) - I have never had issues with it prior and it really is not taxing. All I know is if I use a current version of FFDSHOW then madVR drops frames, roll back to V3882 (13 June) and it plays fine! Looking at the CPU Thread Graph - there is also a big difference in what cores are being used.

EDIT: Should also say no probs with CUVID on a Q6600 PC.

[nevcairiel]

It looks like something in that video causes it to not multi-thread properly.
I know which change caused it, but not sure if reverting it is safe.

[jmone]

OK I went back and tried various builds:
- Last Good = ffdshow_rev3892_20110620_clsid
- First Broken = ffdshow_rev3904_20110623_clsid

I did not change any config settings between the two. 100% repeatable on my rig but please let me know if there are any other FFDSHOW settings to try though both these builds are post the ffmpeg-MT merge.

[jmone]

It looks like something in that video causes it to not multi-thread properly.
I know which change caused it, but not sure if reverting it is safe.

This content will become more common as it is footage straight from a Pana HS700 Video Cam (and I presume the new Sony's will also spit out the same as they share the "format").

[makakam]

Guys, I'm having this problem with Dolby True HD bitstream when using ffdshow with mpc-hc. When I play the movie from the beginning everything's fine but whenever I ffwd or shut down the player and want to pick up the movie where I left off the audio is broken, I mean I can't hear anything or there's some cracking noise. How can I fix it? Just to be clear, it's only the case with movies that contain dolby true hd, dts hd is always fine. I use ATI gpu btw. Hope someone can help me out here. Thanks in advance.

[clsid]

Support for decoding H.264 Hi10P has been committed.

The Libav patch that caused the performance regression for certain H.264 files has been reverted.

[jmone]

The Libav patch that caused the performance regression for certain H.264 files has been reverted.

Thanks! - EDIT: I can confirm that the H.264 performance issues have been fixed for me in ffdshow_rev3958_20110731_clsid

[Blight]

clsid:
If you can provide a patched copy that checks the bad s/pdif values, I'll test it and report if the patch works.

[makakam]

Had to help me myself, Lav filters did the job perfectly.

[roytam1]

It seems that ffdshow doesn't support ATRC (Real's ATRAC3 FourCC) and COOK.
ATRC GUID from MPC RealMedia Splitter: {4B4F4F43-0000-0010-8000-00AA00389B71}
ATRC GUID from LAV Splitter: {6B6F6F63-0000-0010-8000-00AA00389B71}

COOK GUID from MPC RealMedia Splitter: {4B4F4F43-0000-0010-8000-00AA00389B71}
COOK GUID from LAV Splitter: {6B6F6F63-0000-0010-8000-00AA00389B71}

[clsid]

Blight, roytam1

Try this test build:
http://www.mediafire.com/download.php?vxq5ud5h6zioeik

[roytam1]

Blight, roytam1

Try this test build:
http://www.mediafire.com/download.php?vxq5ud5h6zioeik

It works for ATRC.
But it not work for cook from LAV Splitter. Sample: http://roy.orz.hm/samples/rv30_chroma_drift.rm

And ffdshow crash with this sample:
http://roy.orz.hm/samples/rv20_cook_640x352_realproducer_plus_8.51.rm

[clsid]

You should use LAV Audio/Video for realmedia. That works better than ffdshow, and it is unlikely that things will get better in ffdshow.

[roytam1]

You should use LAV Audio/Video for realmedia. That works better than ffdshow, and it is unlikely that things will get better in ffdshow.

But the crash should be prevented.

For LAV Audio, as I want to use MPC Audio Renderer which needs integer input, I can't use LAV Audio.

[clsid]

For those who are wondering why Hi10P isn't working with the x64 build. It has been disabled because it crashed.

The crash happens in the golomb code used in the SPS parser. It isn't the first time that this code has been causing problems in x64 builds. It really needs to be replaced with something better.

I tried replacing it with the CByteParser class from LAV Filters, but a simple function call replace didn't work properly (assertion failures in both x86 and x64 build). Need to be analyzed deeper. If anyone else want to give it a go, please do.

[roytam1]

For those who are wondering why Hi10P isn't working with the x64 build. It has been disabled because it crashed.

The crash happens in the golomb code used in the SPS parser. It isn't the first time that this code has been causing problems in x64 builds. It really needs to be replaced with something better.

I tried replacing it with the CByteParser class from LAV Filters, but a simple function call replace didn't work properly (assertion failures in both x86 and x64 build). Need to be analyzed deeper. If anyone else want to give it a go, please do.

r3964 binary tested.
"cook" and "ATRC" is missing in TffDecoder_reg.cpp (i.e. they are not registered to DirectShow framework). I can see only 90 media types (0-89) in ffdshow audio decoder.

And if ffdshow is connected from MPC RealMedia Splitter, the RV30 video is broken (played fine with LAV Splitter).
ffdshow crash when RV10/RV20 video stream is fed, regardless from LAV Splitter or MPC RealMedia Splitter.

[clsid]

ffdshow uses a "catch all" mediatypes. So everything listed there is optional and has not direct functional purpose. Since there is a maximum on the total amount of mediatypes, just the most common ones are listed.

Add the realvideo issue to the bugtracker.

[Blight]

clsid:
The patch works, the problematic file that previously exposed 8khz now exposes a proper 48khz output and connects to the audio renderer with no issues.

[Blight]

clsid:
Please let me know 'official' which build contains the patch.

[Blight]

Bug report:
The latest ffdshow build behaves badly when using Haali as an MP4 splitter for H.264 video.

If Haali's 'use custom media type for H.264' setting is enabled, Haali exposes the following on it's output pin:
Major Type: Video - Sub Type: UnKnown {31564343-0000-0010-8000-00AA00389B71} Format: MPEGStreams CCV1 1280X720, 24 bits
This results in a black video screen (the filters connect with no issues).

If I disable Haali's 'use custom media type for H.264' setting, Haali exposes the following on it's output pin:
Major Type: Video - Sub Type: UnKnown {31435641-0000-0010-8000-00AA00389B71} Format: MPEGStreams avc1 1280X720, 24 bits
And the video plays just fine.

Here's a sample video:
http://www.youtube.com/watch?v=J1UFnUdX_xw
You'll need to stream-rip the 720p version for testing, I used the 'FlashGot' Firefox Addon to do this by starting to play the 720p video on youtube and then right-clicking the Flashgot icon and selecting the MP4 file.

And here's a link to an MOV (1.2gb) file that crashes ffdshow after a few seconds where it displays a partially decoded image with lots of artifacts:
http://games.on.net/file/42753/Fry_Cry_3_E3_2011_Demo_Walkthrough_Trailer

[clsid]

SPDIF patch has already been committed.

[clsid]

I have played the first minute of FC3_demo.mov and there were no problems when using LAV Splitter and ffdshow.

Please try some older versions for the other problem. It used to work.

[Blight]

clsid:
The 'bug' is, ffdshow going haywire with the {31564343-0000-0010-8000-00AA00389B71} H.264 sub-type.

The problem is specific to ffdshow receiving the "{31564343-0000-0010-8000-00AA00389B71}" sub-type from Haali (I'm not aware of another splitter that uses this sub-type and I believe this sub-type is used specifically for CoreAVC compatibility).
LAV Splitter doesn't expose this sub-type, it exposes the "{31435641-0000-0010-8000-00AA00389B71}" sub-type which works.

And you can instantly see something is wrong when playing the samples I linked as either you don't get any image (youtube sample) or ffdshow crashes (linked sample).

P.S.
Thanks for the S/PDIF patch.

[nevcairiel]

Haali uses this subtype so WMP does not use its own decoder and instead uses CoreAVC - its another truly ugly hack, copyright CoreCodec.

Regarding ffdshow, i believe it just needs to be added to the list of subtypes in TvideoCodecLibavcodec.cpp on line 366
I did not try it, but it would make sense.

[clsid]

Fixed.

Does LAV Video already support the CCV1 fourcc?

[Blight]

clsid:
Can you post a new build to SF? I'd like to test it and inform my users.

[nevcairiel]

Does LAV Video already support the CCV1 fourcc?

It should, yes. I did however not test.

[Budtz]

Hey all

I think that sharpening is one of the best features of ffdshow. However im not sure wicth one is best of the different sharpening methods. only the first few are explained. Im now using swscale.

Are they listed by quality and cpu-intensity or just random?

Any1 know anything about this or has a link somewhere. I have not been able to find a guide to sharpening.

thx

[Blight]

bug report:
In build 3966, the FFDShow subtitle filter (the separate filter) is completely broken.
It's enough to just connect the filters in graphedit and press play and it crashes (even if i disable the "Subtitle" checkbox in the subtitle filter property page).
At times, a split second before the crash, graphedit throws this an "The graph could not change states" 0x80040209 error.

Here's what I eliminated:
1. Tried both EVR and Haali as the video renderer.
2. Tried both LAV, Haali and the microsoft AVI Splitter as the source filter.
3. Tried both AVI and MKV as the source material (both with external SRT subs).
4. Tried ffdshow, MPC and the Microsoft video decoders.

Here's the crash data:

Problem signature:
Problem Event Name: APPCRASH
Application Name: graphedt.exe
Application Version: 10.0.0.0
Application Timestamp: 4a5bcc05
Fault Module Name: ffdshow.ax
Fault Module Version: 1.1.3966.0
Fault Module Timestamp: 4e4197eb
Exception Code: c0000005
Exception Offset: 0002e9fc
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 1d32
Additional Information 2: 1d32409995138d855a2b9bb446ccc159
Additional Information 3: 591c
Additional Information 4: 591c8f267d7c87f1375dd28c7ce78903


P.S.
1. Using the FFDShow video decoder itself as the subtitle renderer does work.
2. Using DirectVobSub as the subtitle renderer works (the sub files are valid).

[Blight]

bug report update:
With the help of Mitko on my forum, we managed to track down the crash to a specific ffdshow setting:
On the output page, if the "Set interlaced flag in output media type" is enabled, it crashes.

There's actually two issues:
1. If "Set interlaced flag in output media type" is enabled on the ffdshow subtitle filter and a non-ffshow video decoder is used.
2. If "Set interlaced flag in output media type" is enabled on either the ffdshow video decoder or the ffdshow subtitle filter if they are both used in the same graph.

[clsid]

The purpose of that option is to simply pass on any interlaced flags from input to output. That is correct and should give no problems. There is probably a bug somewhere that causes a null pointer dereferencing in the subtitle filter case. I will have a look at it when I have some time.

[clsid]

Please narrow down the revision in which it got broken.

[Blight]

clsid:
Are you referring to my report?