ffdshow tryouts project: Discussion & Development

[clsid]

If you drag and drop h.264 video in Graphstudio - does you have FFDshow DXVA video decoder + EVR (VMR9) chain by default?
The merit of EVR (VMR9) needs to be changed first.
I have located the bug, but I don't know why it crashes or how to fix it yet. If anyone want to give it a try, look here for details:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/TvideoCodecLibavcodecDxva.h?r1=4177&r2=4176&pathrev=4177

[Eliminateur]

Hi10p plays fine here in GraphStudio x64.
What is the crashing module?
Does x86 version crash as well?

no idea which is the crashing module, how do i find out?.

haven't tested with x32 at all, and i've played hi10p but small sizes (under 1GB) and it doesn't crash, it only happened with these 5 big movies (smallest one 2.6GB)

[hoborg]

I have located the bug, but I don't know why it crashes or how to fix it yet. If anyone want to give it a try, look here for details:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/TvideoCodecLibavcodecDxva.h?r1=4177&r2=4176&pathrev=4177
:thanks:

[egur]

When compiling ICL12 version it always fail on IntelQuickSyncDecoder project, since rev.4150.
Here's the error log:

I'll fix it ASAP. Had some setup problems with ICL12, so I didn't check the compilation so far...

[DigitalDeviant]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1Y

[haruhiko_yamagata]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1Y
Crash confirmed.:thanks:

[Snowknight26]

Sample file needed.

x264.x64.exe --qp 0 -o output.mkv --output-csp rgb input.mkv
http://stfcc.org/misc/H.264 High 4.4.4 Predictive RGB.mkv

[clsid]

no idea which is the crashing module, how do i find out?.

haven't tested with x32 at all, and i've played hi10p but small sizes (under 1GB) and it doesn't crash, it only happened with these 5 big movies (smallest one 2.6GB)
You can find the crash module name in the error dialog of the crash.
Please test x86 because MPC-HC x64 tends to be buggy.
When does the crash occur? Right at the start, or after a while during playback.
Next time provide all essential information in you initial bug report. That saves everyone from wasting time.

[alexins]

egur, in the file QuickSyncExports.cpp use of incorrect parameters "define".
define COMPILER_VER "ICL" and define COMPILER_VER "MSVC 2010".

Index: QuickSyncExports.cpp
===================================================================
--- QuickSyncExports.cpp (revision 6)
+++ QuickSyncExports.cpp (working copy)
@@ -41,11 +41,11 @@
# elif __INTEL_COMPILER >= 1000
# define COMPILER "ICL 10"
# else
-# define COMPILER_VER "ICL"
+# define COMPILER "ICL"
# endif
#elif defined(_MSC_VER)
# if _MSC_VER==1600
-# define COMPILER_VER "MSVC 2010"
+# define COMPILER "MSVC 2010"
# elif _MSC_VER==1500
# define COMPILER "MSVC 2008"
# else

[egur]

egur, in the file QuickSyncExports.cpp use of incorrect parameters "define".
define COMPILER_VER "ICL" and define COMPILER_VER "MSVC 2010".


Fixed at revision 4183. Finally got my ICL setup, so this shouldn't happen again. Using the latest ICL ffdshow didn't compile. fixed that too.

[alexins]

egur, now there is a problem, you can't build projects VS2010, the problem is in the IntelQuickSyncDecoder svn rev.6 (QuickSyncExports.cpp).

Here is the contents of the file QuickSyncExports.cpp svn rev.6:

#ifdef __INTEL_COMPILER
# if __INTEL_COMPILER >= 1200
# define COMPILER "ICL 12" It is correct!
# elif __INTEL_COMPILER >= 1100
# define COMPILER "ICL 11" It is correct!
# elif __INTEL_COMPILER >= 1000
# define COMPILER "ICL 10" It is correct!
# else
# define COMPILER_VER "ICL" This is wrong!
# endif
#elif defined(_MSC_VER)
# if _MSC_VER==1600
# define COMPILER_VER "MSVC 2010" This is wrong!
# elif _MSC_VER==1500
# define COMPILER "MSVC 2008" It is correct!
# else
# define COMPILER "MSVC" It is correct!
# endif
#else
# define COMPILER "Unknown and not supported compiler"
#endif

#ifndef _M_X64
# define ARCH "x86"
#else
# define ARCH "x64"
#endif

IQuickSyncDecoder* __stdcall createQuickSync()
{
return new CQuickSync();
}

void __stdcall destroyQuickSync(IQuickSyncDecoder* p)
{
delete (CQuickSync*)(p);
}

void __stdcall getVersion(char* ver, const char** license)
{
static const char s_Version[] = QS_DEC_VERSION " by Eric Gur. " COMPILER ", " ARCH " (" __DATE__ " " __TIME__ ")";
strcpy_s(ver, 100, s_Version);
*license = "(C) 2011 Intel\xae Corp.";
}

[egur]

I tried compiling ffmpeg myself and ran into a problem (ffdshow rev4183).
I tried both under cmd and mingw shell.
ffdshow crashes when loading ffmeg.dll right after it tries to load pthreadgc2.dll.
Using dependency walker, I saw that the ffmpeg.dll shipped with ffdshow doesn't link to pthreads. instead it's linked to user32.dll.

The FAQ didn't reveal anything. Also din't find an answer in previous posts...

Can anyone help?

Also, build_script.bat refuses to find the InnoSetup executable (default install location). This line causes an error:
'REG QUERY "%U_%\Inno Setup 5_is1" /v "Inno Setup: App Path"2^>Nul^|FIND "REG_"') do (

[egur]

egur, now there is a problem, you can't build projects VS2010, the problem is in the IntelQuickSyncDecoder svn rev.6 (QuickSyncExports.cpp).


One should never commit before a meeting :(
Fixed in rev4184.
alexins, I only noticed one of the issues, the latter will be fixed with other changes.

[clsid]

r4174 crashes when trying to play a lossless H.264 stream encoded with x264, but only when --output-csp (output colorspace) is specified as 'rgb'. 'i420', 'i422', and 'i444' all work correctly.Fixed in r4185.
ffdshow will now reject connection, allowing another filter to do the decoding, such as LAV Video.

@Haruhiko
Is 4:4:4 RGB p8/9/10 input already fully supported? If so, can you make mappings for libav/ffmpeg PIX_FMT_GBRP(9/10)? Then I could enable decoding of these formats.

[clsid]

Eric,
ffdshow (and MPC-HC) require static-pthreads.
Here is a msys/mingw package that will work properly for ffdshow:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=

[egur]

Eric,
ffdshow (and MPC-HC) require static-pthreads.
Here is a msys/mingw package that will work properly for ffdshow:
http://xhmikosr.1f0.de/index.php?folder=dG9vbHM=

Works great. Thanks. Maybe it should be in the build docs...

[nevcairiel]

You should really ditch pthreads and use the w32threads libav has now. :p
Works just great for LAV

[clsid]

There was some mention of it being a bit slower in the MPC topic. Dunno if that is true.

[nevcairiel]

Thats because of MPC-HCs broken version of ffmpeg
... which they take from ffdshow, so you're probably broken as well. :p

[alexins]

Lav+w32threads has a speed of decoding higher than ffdshow+pthreads

[SamuriHL]

I can definitely confirm that on 2 of my machines.

[madshi]

You should really ditch pthreads and use the w32threads libav has now. :p
Works just great for LAV
Is w32threads better than pthreads for ffmpeg?

[nevcairiel]

Is w32threads better than pthreads for ffmpeg?

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.

[clsid]

ffdshow uses w32pthreads as well now. Trivial patch.

[madshi]

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.
Good to know, thx.

[Eliminateur]

You can find the crash module name in the error dialog of the crash.
Please test x86 because MPC-HC x64 tends to be buggy.
When does the crash occur? Right at the start, or after a while during playback.
Next time provide all essential information in you initial bug report. That saves everyone from wasting time.

i'd need to download ffdshow x86 as well as i'm using only x64.

it crashes on open, it doesn't even starts playing it resizes the window and crashes, it doesn't tells me any module, the crash is "mpc-hc has stopped working windows will try to find a solution"

[egur]

It seems to have equal performance and it gets rid of one dependency, thats better in my book.
Rather use native threading then pthreads on windows.

LAV has been using it for a while already (ever since the new w32threads implementation was added in october), and it seems to work just fine.

Out of curiosity, do you know which part of pthreads caused the slowness?
* Thread creation/destruction
* Synchronization objects

BTW, did anyone try replacing malloc by a faster implementation that's more suited for multithreaded apps (e.g. Google's malloc or TBB's malloc)?

[nevcairiel]

Out of curiosity, do you know which part of pthreads caused the slowness?

What slowness?


BTW, did anyone try replacing malloc by a faster implementation that's more suited for multithreaded apps (e.g. Google's malloc or TBB's malloc)?

I did some testing with the "normal" malloc, and as long as you don't start going into the virtual cores of hyper threading, performance is linear when doing excessive multi threaded allocations. (ie. 4x times the work load gets done by 4 cores at the same time then 1 core does 1x the work)
The problem people usually experienced with multi-core and allocations were mostly in the early days of multi-cores on linux. I didnt test there, but i assume its better as well.

[ageback]

I have Intel Parallel Composer 2011 installed and I could compile ICL12 version before.
But now I can't build ICL12 version.
Which Intel Compiler should I install?

[alexins]

ffdshow uses w32pthreads as well now. Trivial patch.
ffdshow 4186 x86, if the use of multithreading in Windows XP (libavcodec), then when playing a video H264, an error occurs and hang-up!

[egur]

What slowness?

What parts of pthread were slower than using win32 API?

I did some testing with the "normal" malloc, and as long as you don't start going into the virtual cores of hyper threading, performance is linear when doing excessive multi threaded allocations. (ie. 4x times the work load gets done by 4 cores at the same time then 1 core does 1x the work)
The problem people usually experienced with multi-core and allocations were mostly in the early days of multi-cores on linux. I didnt test there, but i assume its better as well.
Even in single threaded applications Google and TBB performed much better than libc malloc on Linux about 2 years ago when I benchmarked a large application.
Performance was 3x faster (!) using either malloc replacement. Both replacement used more memory than malloc.
The application (and 3rd party libraries) allocated and deallocated huge amounts of memory (many GB) either directlly or implicitly via various STL containers (and strings). Over time malloc's (original) internal database became very fragmented and malloc/free operations became very slow. One work load caused malloc to return a small buffer after 5 seconds instead of a few micro seconds after running for several minutes.

FFDshow uses large buffers mostly and should work about the same speed. If a lot of STL is used (or boost), it's worth checking it out.

[nevcairiel]

What parts of pthread were slower than using win32 API?

I never said it was slower, i just said its good to get rid of a dependency and use native threading.

[haruhiko_yamagata]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

FWIW, LAV Video Decoder sets this flag correctly.
I think it was delay of soft telecine detection. I have fixed at rev 4178. Please try rev 4185 (4188 doesn't work for me).

[haruhiko_yamagata]

Fixed in r4185.
ffdshow will now reject connection, allowing another filter to do the decoding, such as LAV Video.

@Haruhiko
Is 4:4:4 RGB p8/9/10 input already fully supported? If so, can you make mappings for libav/ffmpeg PIX_FMT_GBRP(9/10)? Then I could enable decoding of these formats.
OK, I'll take a look later.

[haruhiko_yamagata]

I'm getting a lot of crashes on Blu-ray subtitles displaying more than one subtitle on the screen at a time. I've tried in MPC-HC and PotPlayer and with the MPC splitter and LAV filter. It doesn't occur every time but the more multiple lines you have the more it happens. The example below crashes more often than not.

http://www.megaupload.com/?d=24ZO2T1YI have fixed at rev 4189.

[dann23]

I have one problem and a feature request. The problem is with vobsub subtitles in mkv files. After some time they won't appear anymore. This happes after some time, maybe one minute or less.
And the feature request is about Info Tab in ffdshow. Is it possible to make it show the type of subtitles?

[DigitalDeviant]

I have fixed at rev 4189.

Thanks. I'll test it out as soon as a build is available and I have a few minutes.

[Eliminateur]

i'd need to download ffdshow x86 as well as i'm using only x64.

it crashes on open, it doesn't even starts playing it resizes the window and crashes, it doesn't tells me any module, the crash is "mpc-hc has stopped working windows will try to find a solution"

i've updated to 4191 as well and done some tests, the option that makes it crash is setting the primary output colorspace as RGB32 and using the "high quality yv12 to RGB" converter, the exact moment that checkbox is set, the mpchc hang/crashes (no module crash, generic "[program] has stopped working".

and it only happens with BIG hi10p files

[clsid]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

[clsid]

ffdshow 4186 x86, if the use of multithreading in Windows XP (libavcodec), then when playing a video H264, an error occurs and hang-up!Try with a clean build of 4191.

[alexins]

try with a clean build of 4191.

The problem is solved, all works well!
Thank You!

[Eliminateur]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

thanks clsid, indeed must be something about the encode, the chunk has the same effect.
this is the sample: http://www.mediafire.com/?4242856581wdn8b

[gendouhydeist]

There was an error on Commie - UN-GO at Y416 colorspace output.
The instruction at 0x54fb913d referenced memory at 0x0e321000. The memory could not be written.

It was crashing on MadVR, tried also on EVR it doesn't crash but there's no video output.

using latest svn revision of ffdshow on xvidvideo.ru

[hoborg]

Hi.
I have problem to play this video (http://hobring.esero.net/saf/samples/ffdshow_bad_playback.zip) with FFDshow video decoder.
LAV/MPC-HC video decoders working fine.

EDIT:
rev. 4174 is OK
rev. 4183 have broken playback.

[andybkma]

Just upgraded to ffdshow_rev4191_20111221_xvidvideo-ru_x86_icl12 and using the raw video filter to post process I get a thick green border on the right side of the video. I don't have this problem with the previous version I was using which is ffdshow_rev3984_20110922....

[haruhiko_yamagata]

thanks clsid, indeed must be something about the encode, the chunk has the same effect.
this is the sample: http://www.mediafire.com/?4242856581wdn8b
It works fine for me.
I have tested MPC-HC x64, graphstudio64 with RGB32 output, with "High quality YV12 to RGB conversion" checked.
Can anybody else reproduce the crash?

[haruhiko_yamagata]

Just upgraded to ffdshow_rev4191_20111221_xvidvideo-ru_x86_icl12 and using the raw video filter to post process I get a thick green border on the right side of the video. I don't have this problem with the previous version I was using which is ffdshow_rev3984_20110922....
Which decoder is connected to ffdshow's input pin? What is the color space? What are the dimensions?

[haruhiko_yamagata]

There was an error on Commie - UN-GO at Y416 colorspace output.Please write in plain English. I cannot understand "Commie - UN-GO at ".

The instruction at 0x54fb913d referenced memory at 0x0e321000. The memory could not be written.

It was crashing on MadVR, tried also on EVR it doesn't crash but there's no video output.

using latest svn revision of ffdshow on xvidvideo.ru
I can't reproduce.

[SamuelMaki]

I doubt the size is relevant. Those files were probably just encoded differently. The problem seems to be in the colorspace conversion code of ffdshow. Cut a 20MB sample with DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip) and upload it to MediaFire (http://www.mediafire.com). Then Haruhiko should be able to fix it.

Sorry for OT, but I would prefer multiupload... It has free direct download and you can use whatever fileserver you want:) Oh, and it is faster too...
http://www.multiupload.com/

[gendouhydeist]

@haruhiko_yamagata
it's an anime show called UN-GO sub by Commie
you can get the torrent here http://commiesubs.com/un-go-10/