ffdshow tryouts project: Discussion & Development

[Sven75]

Could support for Apple DV (DVCP) files be added to ffdShow? I tried the following file with ffplay.exe from current ffmpeg and it's playing just fine. Also, lavsplitter accepts the file in GraphStudio, but it cannot be rendered from there on, (obviously) because no decoder in my system will support it.

http://www.mediafire.com/?8fwcaxepy3xca4v (Apple_DVCP_small.mov)

If a file is supported by ffmpeg what does it take to make it work with ffdShow? Is it just a matter of adding an additional MediaType or are there substantial differences in the decoder codebase between current ffdShow and current ffmpeg or libav?

[clsid]

It plays when I add support for the FourCC "DVCP" to ffdshow. However, the video stutters. I will not commit this change, since I only want to support things that can be properly played.

[Sven75]

Yes, you are right. Playback is not 100% perfect and I understand and support your point.

So, to fix this, the best will be to upload the file at ffmpeg/libav and file a bug, right?

In the meantime, does anyone know a Windows decoder (beside the source filters which use the QuickTime framework) which supports Apple DVCP?

[Jason Leach]

I have a new problem: When I was playing a Blu-ray, I noticed when I increased the Gamma correction (under Picture Properties) it was as if I'd increased the brightness setting--that is, areas of the image that are pure black become brighter, which should not happen with the gamma setting (it does not in Photoshop or when I use my ATI 4350's gamma control). I verified these areas are true black by using the Print Screen key to make a screenshot and measuring the RGB level with the eyedropper tool in Photoshop. (Actually it was R:0 G:1 B:0, but I adjusted just the R and B independently and the same thing happened.)

1).operating system (OS)

Windows 7 x64

2).ffdshow version, rev, compiler, ansi or unicode

ffdshow tryouts rev3867 May 31 2011 18:45:44 (MSVC 2010, x86, unicode, r)

3).ffdshow settings and used filters, ex:queue, resize, sharpening, noise, levels...

No others active.

4).media player used and settings ex: mpc, media player2, wmplayer...

BSPlayer but the same thing happens in MPC-HC.

5).output colorspaces "YUY2", "YV12", "RGB32", "RGB24"...

RGB32

6).internal/external splitters ex: Haali Media Splitter, Gabest's Splitters...

Haali

7).video renderers ex:Haali renderer, Overlay Mixer, VMR9, VMR7, EVR...

Happens in both DirectDraw, Overlay, and EVR Custom Pres.

8).video/audio samples <10MB

I tested on both a Blu-ray m2ts and an uncompressed AVI with 0-255 levels, so its not the file, but here's a sample just in case:

https://rapidshare.com/files/1669032072/Mr._and_Mrs._Incredible__2011__Trailer_720p.mp4

9).what you were trying to accomplish, the problem you encountered...anything else that could be useful in reproducing that bug.

It should be easy to reproduce--just raise the Gamma correction on a widescreen Blu-ray and you'll see the black bars above and below the image become light, just as if you'd raised the brightness instead.

[clsid]

Yes, you are right. Playback is not 100% perfect and I understand and support your point.

So, to fix this, the best will be to upload the file at ffmpeg/libav and file a bug, right?

In the meantime, does anyone know a Windows decoder (beside the source filters which use the QuickTime framework) which supports Apple DVCP?If the same happens with ffplay, then please report to FFmpeg devs.

VLC plays the file properly here.

[Snowknight26]

FPS1 -> YV12 is broken again. Chroma planes are reversed.

[Thunderbolt8]

is there a ffdshow picture settings which can change contrast for red, green and blue, BUT leaves black levels untouched?

theres such a setting in TMPGEnc encoder (a filter named "contrast (black base)"), but I like to avoid reencoding my video for that and rather have the colour change applied during playback instead.

[clsid]

FPS1 -> YV12 is broken again. Chroma planes are reversed.
Do you perhaps have a small sample?

[Snowknight26]

Do you perhaps have a small sample?

http://stfcc.org/misc/ffplay_fraps_video_stutter_with_audio.avi

[sneaker_ger]

Now that ffmpeg-mt has been merged: is there any difference between choosing libav and ffmpeg-mt? Any advantages/disadvantages?

[clsid]

Libavcodec is still single-threaded for H.264. It uses w32threads instead of pthreads. Last time I tried changing that it crashed, and haven't looked into it deeper yet.

[sneaker_ger]

I see, thx.

[mark0077]

Guys, when using things like avisynth frame interpolation in ffdshow, is it upto ffdshow or avisynth to correctly set the pin out details.

I frame interpolate everything to 50.00fps using avisynth, yet madVR video renderer reports "movie 23.974 fps (says source filter)". ffdshow pin out also says the following, rather than the correct output rate of 50.00 fps


Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}

- Connected to:

CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
Filter: madVR Renderer
Pin: Input

- Connection media type:

Video: YV12 2048x1080 (16:9) 23.97fps

[TheRyuu]

Libavcodec is still single-threaded for H.264. It uses w32threads instead of pthreads. Last time I tried changing that it crashed, and haven't looked into it deeper yet.

Don't use w32threads then.

ffmpeg-mt was merged. There's zero reason to maintain both of them as separate entities in ffdshow.

Also what still needs to get done for 10bit h264 decoding support?

[clsid]

It crashed when using pthreads. But like I have said, I haven't looked into it yet.

For the 10bit stuff, ffdshow needs to be updated to recognize the 9/10/16bit colorspaces of ffmpeg and use swscale to convert them to the standard output colorspaces. Patches are welcome.

[clsid]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

[sneaker_ger]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

Looking good, performance of libav and ffmpeg-mt are identical.

[TheRyuu]

I'm not completly sure but doesn't autostatic in pthreads mean code like this:
--- trunk/src/ffmpeg/DllEntry.c 2011/06/18 11:59:34 3884
+++ trunk/src/ffmpeg/DllEntry.c 2011/06/18 23:43:03 3885
@@ -28,33 +28,37 @@

CRITICAL_SECTION g_csStaticDataLock;

+BOOL pthread_win32_process_attach_np(void);
+BOOL pthread_win32_process_detach_np(void);
+BOOL pthread_win32_thread_attach_np(void);
+BOOL pthread_win32_thread_detach_np(void);
+
// --- standard WIN32 entrypoints --------------------------------------
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
- //static int count=0;
- //char pomS[40];
- switch (dwReason)
- {
- case DLL_PROCESS_ATTACH:
- //count++;
- //snprintf(pomS,40,"ffmpeg: %i %i\n",count,hInstance);OutputDebugString(pomS);
- DisableThreadLibraryCalls(hInstance);
- InitializeCriticalSection( &g_csStaticDataLock );
- break;
- case DLL_PROCESS_DETACH:
- //count--;
- //snprintf(pomS,40,"ffmpeg: %i %i\n",count,hInstance);OutputDebugString(pomS);
- DeleteCriticalSection( &g_csStaticDataLock );
- break;
- }
- return TRUE;
+ switch (dwReason)
+ {
+ case DLL_PROCESS_ATTACH:
+ pthread_win32_process_attach_np();
+ pthread_win32_thread_attach_np();
+ DisableThreadLibraryCalls(hInstance);
+ InitializeCriticalSection( &g_csStaticDataLock );
+ break;
+
+ case DLL_PROCESS_DETACH:
+ pthread_win32_thread_detach_np();
+ pthread_win32_process_detach_np();
+ DeleteCriticalSection( &g_csStaticDataLock );
+ break;
+ }
+ return TRUE;
}

static char av_datetime[]=__DATE__" "__TIME__;
void getVersion(char **version,char **build,char **datetime,const char* *license)
{
- if (version) *version=AV_STRINGIFY(LIBAVCODEC_VERSION)", "COMPILER COMPILER_X64 COMPILER_INFO;
- if (build) *build=AV_STRINGIFY(LIBAVCODEC_BUILD);
- if (datetime) *datetime=av_datetime;
- if (license) *license="";
+ if (version) *version=AV_STRINGIFY(LIBAVCODEC_VERSION)", "COMPILER COMPILER_X64 COMPILER_INFO;
+ if (build) *build=AV_STRINGIFY(LIBAVCODEC_BUILD);
+ if (datetime) *datetime=av_datetime;
+ if (license) *license="";
}

Isn't needed anymore since "libav" is built using the gnu linker. I'm only curious because it looks so similar to the (really) old way of doing static pthreads in ffmpeg:
Index: libavcodec/allcodecs.c
===================================================================
--- libavcodec/allcodecs.c (revision 15966)
+++ libavcodec/allcodecs.c (working copy)
@@ -41,6 +41,14 @@
extern AVBitStreamFilter x##_bsf; \
if(ENABLE_##X##_BSF) av_register_bitstream_filter(&x##_bsf); }

+#ifdef PTW32_STATIC_LIB
+static void detach_ptw32(void)
+{
+ pthread_win32_thread_detach_np();
+ pthread_win32_process_detach_np();
+}
+#endif
+
/**
* Register all the codecs, parsers and bitstream filters which were enabled at
* configuration time. If you do not call this function you can select exactly
@@ -59,6 +67,12 @@
return;
initialized = 1;

+#ifdef PTW32_STATIC_LIB
+ pthread_win32_process_attach_np();
+ pthread_win32_thread_attach_np();
+ atexit(detach_ptw32);
+#endif
+
/* video codecs */
REGISTER_DECODER (AASC, aasc);
REGISTER_DECODER (AMV, amv);

You shouldn't need any custom code for pthreads to work.

[jmone]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

Nice Work!

Also Looking good for me and if anything the CPU useage of libav "may" be just slightly better thant ffmpeg-mt (hard to really tell), but it is certainly no worse.

Anyway, are there any benefits now to use ffmpeg-mt over libav? If not are you goint to remove the ffmpeg-mt option?

Thanks
Nathan

Next you will say that libav now supports interlaced VC-1!

[JEEB]

Anyway, are there any benefits now to use ffmpeg-mt over libav? If not are you goint to remove the ffmpeg-mt option?
It was merged, thus the ffmpeg-mt source tree by itself is now pretty much obsolete, if there will be any fixes, they will get into libav/ffmpeg's trunks, not into ffmpeg-mt from now on :) .

Next you will say that libav now supports interlaced VC-1!
Saw people on #libav-devel working on it at least, but this was a while ago.

[VipZ]

Ok, got it working. H.264 decoding is now multi-threaded in libavcodec. Everyone please test.

All seems good here

[clsid]

@TheRyuu
It crashes in ntdll without that custom code. It probably needs it because out pthread lib is a bit old. I will try updating it and see if that code is still needed. Thanks for the hint.

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

@JEEB
Afaik, there is not much active development going on regarding interlaced VC-1. But there is a GSOC project for it, but there has been in past year as well without much results.
http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#VC-1_decoder_missing_features

[VipZ]

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

I have thrown all my previous known issue files at this in x64 as well and haven't had any issues, playback has become much more stable in the last 1-2 months :)

The only issue is but its been around for a while, is that ffdshow doesn't seem to read this info on h264 in MKV when using LAV Spiltter,
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

[roytam1]

@TheRyuu
It crashes in ntdll without that custom code. It probably needs it because out pthread lib is a bit old. I will try updating it and see if that code is still needed. Thanks for the hint.

@all
ffmpeg-mt has been integrated into libavcodec now. So if no problems are reported, ffmpeg-mt can be removed in the near future. Things are looking good so far. Please also test MPEG-1/2, DV, and FFV1, which all use slice-based threading in libavcodec.

@JEEB
Afaik, there is not much active development going on regarding interlaced VC-1. But there is a GSOC project for it, but there has been in past year as well without much results.
http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#VC-1_decoder_missing_features

What about vp3/theora/mpeg4/huffyuv in ffmpeg-mt in the past? Will they have multi threading with new libavcodec?

[upyzl]

sorry to trouble, I've been meaning to ask...

what does splineResize stand for? spline16resize? spline36resize? spline64resize? could I tweak it as LanczosResize(taps)?

[clsid]

What about vp3/theora/mpeg4/huffyuv in ffmpeg-mt in the past? Will they have multi threading with new libavcodec?Those codecs have sync issues when MT is enabled for them. So unless someone figures out a solution for that they won't be multi-threaded.

[Superb]

clsid: did you use the latest winpthreads from http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/winpthreads/ ?

[mandarinka]

sorry to trouble, I've been meaning to ask...

what does splineResize stand for? spline16resize? spline36resize? spline64resize? could I tweak it as LanczosResize(taps)?

Spline resize in ffdshow isn't related to avisynth scalers, it comes from ffmpeg's swscale library. AFAIK it has a different effect from say spline36resize, too.

[clsid]

clsid: did you use the latest winpthreads from http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/winpthreads/ ?
I use this:
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/pthreads/

[VipZ]

I cant seem to compile ffmpeg x64 anymore, had no issue with build 3886

As a reference, I used the below cmd and currently use mingw_gcc_461_v20110506_x86-x64-pre-release.7z from xvidvideo.ru
rd /S /Q obj\MinGW64
cd src\ffmpeg
make 64BIT=yes
cd ..\..
pause

[Wilbert]

Spline resize in ffdshow isn't related to avisynth scalers, it comes from ffmpeg's swscale library.
Perhaps the same as this one: http://forum.doom9.org/showthread.php?p=1356563#post1356563 ?

[clsid]

I cant seem to compile ffmpeg x64 anymore, had no issue with build 3886

As a reference, I used the below cmd and currently use mingw_gcc_461_v20110506_x86-x64-pre-release.7z from xvidvideo.ru
rd /S /Q obj\MinGW64
cd src\ffmpeg
make 64BIT=yes
cd ..\..
pause
This MinGW64 build should work:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20110616.zip/download

[upyzl]

@ mandarinka & Wilbert

Thank you for the reply! I see...

[RealSnoopyDog]

Builds 3886 and 3892 show very bad artefacts when playing back H.264 with the DXVA codec. Build 3882 (and previous) does not have this.

[VipZ]

This MinGW64 build should work:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20110616.zip/download

Thanks :)

I have tried the 4.7.0 pre release from xvidvideo.ru before (mingw_gcc_470_v20110507_x86-x64-pre-release.7z) with the same issue and also crashed on a few h264 video's on build 3886 and before, so I assume the build you posted is much more stable now?

I will test this build tonight, if this is the same version you used, I did some testing and had no h264 crashing on me, but I did forget which file crashed for me, maybe I should do a test build and test this.

[Sven75]

Playback of the following file is broken if I use the current LAVFilters and ffdshow. It plays but the video image remains completely grey:

http://www.mediafire.com/?1nr37wujo5g8c65 (cvid in mov container)

However, it does work if I use the MS AVI decompressor. Also, it works with ffdShow, if I use LAVFilter versions <= 0.26-31 (a change in avformat-53.dll broke the compatiblity with ffdShow).

So, it's either a problem with ffdShow or LAVFilter (I also posted it at the LAV thread).

Of course, I can use MS AVI decompressor for it just fine, but maybe it is a problem affecting other formats as well and someone cares to have a look and solve the underlying problem.

[Mr VacBob]

Those codecs have sync issues when MT is enabled for them. So unless someone figures out a solution for that they won't be multi-threaded.

That must be a wrapper issue. vp3 and huffyuv are well behaved. It's possible that mpeg4 (with packed B-frames) isn't.

[clsid]

That must be a wrapper issue. vp3 and huffyuv are well behaved. It's possible that mpeg4 (with packed B-frames) isn't.
Any idea what might be wrong? The sync difference seems to be proportional to the number of threads.

[clsid]

Thanks :)

I have tried the 4.7.0 pre release from xvidvideo.ru before (mingw_gcc_470_v20110507_x86-x64-pre-release.7z) with the same issue and also crashed on a few h264 video's on build 3886 and before, so I assume the build you posted is much more stable now?

I will test this build tonight, if this is the same version you used, I did some testing and had no h264 crashing on me, but I did forget which file crashed for me, maybe I should do a test build and test this.Older versions from MinGW64 project should also work. TDM's build probably as well.

I used the exact same mingw64 build and no crashes have been reported so far, so things are looking good.

[Reimar]

Any idea what might be wrong? The sync difference seems to be proportional to the number of threads.

Frame multithreading creates a delay. Since vp3 and huffyuv do not use B-frames those wrappers probably aren't prepared to handle a decoding delay.
I guess you'll either have to pass the timestamps through properly (I think the requires using the most recent decode API) or just delay them by the (I think) has_b_frames value.

[clsid]

I know that threading causes a delay, but I can't find any code that does things differently for H.264 in that regard. ffdshow seems to use reordered_opaque for the timestamp handling. I am also not really familiar with the parts of the ffdshow code involved in this, so I doubt I can fix it. These formats can easily be decoded even on old CPUs, so I don't consider multi-threading to be important for them. If anyone wants it, submit a working patch.

[roozhou]

Frame multithreading creates a delay.
Is this delay caused by ffmpeg-mt or the current framework of ffdshow?

[pwimmer]

I would like to control the ffdshow Audio Decoder from my application, specifically I would like to turn the tray icon off and disable the mixer.

While

IffdshowBase :: putParam(IDFF_trayIcon, 0)

works as expected

IffdshowBase :: putParam(IDFF_isMixer, 0)

does not.

What is the correct way to change the filter settings temporarily (only for my application)? Do I have to init/create/set a profile for the second call to work? It would be preferred if my application uses the default settings, so that config changes done by the user do not affect my application.

[clsid]

Builds 3886 and 3892 show very bad artefacts when playing back H.264 with the DXVA codec. Build 3882 (and previous) does not have this.
I have one M2TS file that shows this problem. I haven't pinpointed the cause yet.

[Reimar]

Is this delay caused by ffmpeg-mt or the current framework of ffdshow?

It is a direct result of the _concept_ frame-multithreading itself. You obviously can't decode multiple frames in parallel unless you have the data for all these frames.
So if you want to decode n frames in parallel your decoded frame output has to lag behind about n frames from the encoded frame input.

[fastplayer]

@clsid:
You've renamed the ICL10 directory to "...(old)". This means you won't offer ICL builds anymore, right?

[clsid]

Yes, it is unlikely there will be any new ICL10 builds. I currently only have MSV2010 installed on my new PC.

[fastplayer]

OK, thanks. I've jumped the gun and already removed the ICL10 reference from the homepage.

[xv]

Current ffdshow crashes on H.264 4:4:4 files (included ffmpeg has decoding support), sample file: http://www.mediafire.com/?s28158q8rwq2ob8
Here is a x264 build to encode 4:4:4: http://forum.doom9.org/showthread.php?p=1509669#post1509669 (You need AviSynth 2.6, older versions don´t support YV24 colorspace)

[clsid]

Same situation as with H.264 10-bit, it requires support for additional colorspaces in ffdshow.