ffdshow tryouts project: Discussion & Development

[VipZ]

I cant seem to be able to compile the latest x64 build anymore

I get the below message when using MSYS_MinGW_GCC_461_x86-x64_Full.7z,
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb00f): undefined reference to `_ff_pb_F8'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb01c): undefined reference to `_ff_pb_3'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb025): undefined reference to `_ff_pb_4'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb090): undefined reference to `_ff_pb_1'
collect2: ld returned 1 exit status
C:\MSYS\mingw\bin\x86_64-w64-mingw32-dllwrap.exe: C:\MSYS\mingw\bin\x86_64-w64-m
ingw32-gcc exited with status 1
make: *** [../../bin/ffmpeg.dll] Error 1

[Hypernova]

Not sure if this is useful but I tried using MPC-HC (3283, MSVC 2010SP1, with ffmpeg by MinGW GCC 4.6.1), which as far as I can tell also use mutithread decoding. There is no lag.

Note: By lag I mean the video lag behind audio.

[clsid]

I have at least two examples of h264 in AVIs that has noticable lag (~500ms). It's quite old anime fansubs, Cyber Formula Double-one by Ayu and Akazukin ChaCha by the group I don't know the name. If you need help to get a hold of that please let me know. Noted that I do notice the lag even in 2 threads (out of 8) though.Cut a sample with DGSplit and upload it for me.

Does the sync difference grow with more threads? It should.

Not sure if this is useful but I tried using MPC-HC (3283, MSVC 2010SP1, with ffmpeg by MinGW GCC 4.6.1), which as far as I can tell also use mutithread decoding. There is no lag. MPC does not have multi-threaded decoding.

[clsid]

I cant seem to be able to compile the latest x64 build anymore
There is a working mingw64 package on the SourceForge page.

[Hypernova]

I don't know if I did any wrong but only the first part seem to playable after splited by DGSplit. Please use the second half where the karaoke appear to see the lag.

http://www.mediafire.com/?9jf19139i6e0uh2

[alexins]

I cant seem to be able to compile the latest x64 build anymore

I get the below message when using MSYS_MinGW_GCC_461_x86-x64_Full.7z,
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb00f): undefined reference to `_ff_pb_F8'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb01c): undefined reference to `_ff_pb_3'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb025): undefined reference to `_ff_pb_4'
../../obj/MinGW64/ffmpeg/libavcodec/x86/vp8dsp.o:libavcodec/x86/vp8dsp.asm:(.tex
t+0xb090): undefined reference to `_ff_pb_1'
collect2: ld returned 1 exit status
C:\MSYS\mingw\bin\x86_64-w64-mingw32-dllwrap.exe: C:\MSYS\mingw\bin\x86_64-w64-m
ingw32-gcc exited with status 1
make: *** [../../bin/ffmpeg.dll] Error 1

Use this patch:

Index: src/ffmpeg/config.h
===================================================================
--- src/ffmpeg/config.h (revision 3919)
+++ src/ffmpeg/config.h (working copy)
@@ -43,8 +43,8 @@
#define ASMALIGN(ZEROBITS) ".p2align " #ZEROBITS "\n\t"

#if ARCH_X86_64
- #define EXTERN_PREFIX "_"
- #define EXTERN_ASM _
+ #define EXTERN_PREFIX ""
+ #define EXTERN_ASM
#else
#define EXTERN_PREFIX "_"
#define EXTERN_ASM _
Index: src/makefile_c.inc
===================================================================
--- src/makefile_c.inc (revision 3919)
+++ src/makefile_c.inc (working copy)
@@ -12,7 +12,7 @@
TARGET_OS=x86_64-w64-mingw32
CFLAGS+=-DWIN64 -D_WIN64 -D__MINGW64__
OPTFLAGS+=-O2 -m64
- YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64 -DPREFIX
+ YASMFLAGS+=-f win64 -m amd64 -DWIN64 -DARCH_X86_64
else
TARGET_OS=i686-w32-mingw32
CFLAGS+=-DWIN32 -D_WIN32 -D__MINGW32__
@@ -21,7 +21,7 @@
endif

CFLAGS+=-mdll -mthreads -pipe
-OPTFLAGS+=-fno-common -fno-tree-vectorize
+OPTFLAGS+=-fno-common
CPPFLAGS+=-fno-rtti
OUTPUTFLAG=-MMD -o\

@@ -30,7 +30,7 @@
YASMFLAGS+=-g cv8
else
CFLAGS+=-DNDEBUG -UDEBUG
- OPTFLAGS+=-fomit-frame-pointer
+# OPTFLAGS+=-fomit-frame-pointer (with GCC4.6.x - 4.7.x it is not used.)
LDFLAGS+=-s
endif

And also, in the folder \bin\lib_x64 put the file libpthreadGC2.a (libpthreadGC2 x64 generic cvs.20110403). (http://www.mediafire.com/?rtpyqzyqrcdd5ck)

[Atak_Snajpera]

I'm not the one who create the file, so it's not really a choice on my part.
Wouldn't be easier to just remux from stupid avi to modern mkv/mp4???

[roozhou]

Wouldn't be easier to just remux from stupid avi to modern mkv/mp4???
Some DV also produce AVC in AVI. Actually AVC in AVI is just AnnexB in AVI. If the decoder cannot correctly handle AVC in AVI, it cannot handle AnnexB stream either.

[clsid]

And also, in the folder \bin\lib_x64 put the file libpthreadGC2.a (libpthreadGC2 x64 generic cvs.20110403). (http://www.mediafire.com/?rtpyqzyqrcdd5ck)I will test this to see if this results in a stable x64 build. Can you make a build x86/x64 for latest cvs?

Edit: can you test this file with x64 build:
http://www.zshare.net/video/92250008bfd03cce/
It crashes for me with new pthreads, but not with old. But might also be GCC bug.

Edit2: Build made with GCC 4.5.2 does not crash. So it looks like a bug in newer versions of GCC.

[robpdotcom]

I'd like to use ffdshow video for W7MC recordings (.wtv files) inside MPC-HC, but it will not connect. Should I open a ticket for this?

[Atak_Snajpera]

I'd like to use ffdshow video for W7MC recordings (.wtv files) inside MPC-HC, but it will not connect. Should I open a ticket for this?
Convert to .dvr-ms format. (Right click) or to .ts (http://experts.windows.com/frms/windows_entertainment_and_connected_home/f/49/t/95712.aspx)

[Boulder]

When encoding an RGB source in VDub using ffdshow's HuffYUV and YV12 colorspace, how does ffdshow perform the colorspace conversion? Is it similar to ConverttoYV12 (using the same matrix, Rec601) in Avisynth?

[VipZ]

@ alexins

Thanks for the help :)

@clsid

That video you mentioned to be crashing, on my builds it isn't crashing which is the build I am currently using, Rev 3916 built with mingw_gcc_461_v20110623_x86-x64-pre-release.7z from xvidvideo.ru

[hoborg]

Hi.
There seems to be a problem with FFDshow DXVA decoder when removing from graph - it will cause Graphstudio (and other software) to crash.

It is easy to reproduce - just open any DXVA compatible video in graphstudio then try to remove FFDShow DXVA decoder from graph - Graphstudio will crash.

This doesn't happend with normal FFDshow video decoder (and other DXVA decoders like PDVD).

[clsid]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

[hoborg]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

VMR9 on XP and EVR on Win7.

I changed default renderer on my OS, so Graphstudio use EVR by default on my Win7.

[Midzuki]

In the "Version Details" window (r3919):
ff_kernelDeint.dll Not found
:confused:

Also: the MJPG VfW decoder swaps the channels U and V :(

[clsid]

Do you have a sample? I only have one mjpeg in avi file and that gives correct colors in VirtualDub.

It is easy to adjust colorspace in VirtualDub. Video -> Color Depth.

[zummi]

Hi Gurus :)

Quick question: I'm having trouble with my PGS subtitles. They always appear in the *upper left* corner of my screen. I've tried playing with the subtitles settings in ffdshow, and I'm able to change font size etc...but the placement won't change. Have I completely overlooked something basic here...?

I'm running the latest version of ffdshow of course. Thanks :)

[andybkma]

Greetings, just a quick question. Is ffdshow supposed to be able to decode all wmv content without any problems? Cuz I have many .wmv vids (mostly WMV3/9) for which I only get a grey screen when selecting libavcodec for WMV3/9 and a green screen when I select wmv9 (the vids play fine if I use the internal windows wmv decoder). It doesn't matter which renderer I use, the resulting blocky green & grey screens still occur making the vid unwatchable. This has been going on for as long as I have been using ffdshow (7+ years) and even the most recent builds within the past week still have the same problem. Was just wondering if there is something I can do to finally fix this problem...

Thanks for any tips/guidance...

[hoborg]

I am unable to reproduce. I can delete the filter without problems in GraphStudio. Which renderer are you using? Here it ffdshow DXVA only works if manually inserted in combination with EVR.

So you was not able to reproduce it?

This is how it can be reproduced (Vista/Win7):

Start Graphstudio, look for EVR renderer, then change merit to max.
Restart PC
Open any DXVA compatible video in graphstudio, graph will be now builded using FFDshow DXVA decoder + EVR renderer (instead of video renderer).
Try to remove FFDshow DXVA decoder from graph (click on ffdshow dxva decoder and hit delete key).
Graphstudio will crash.

[clsid]

Greetings, just a quick question. Is ffdshow supposed to be able to decode all wmv content without any problems? Cuz I have many .wmv vids (mostly WMV3/9) for which I only get a grey screen when selecting libavcodec for WMV3/9 and a green screen when I select wmv9 (the vids play fine if I use the internal windows wmv decoder). It doesn't matter which renderer I use, the resulting blocky green & grey screens still occur making the vid unwatchable. This has been going on for as long as I have been using ffdshow (7+ years) and even the most recent builds within the past week still have the same problem. Was just wondering if there is something I can do to finally fix this problem...

Thanks for any tips/guidance...
Please post a sample file that gives you this problem, so that we can test it.

[clsid]

Hi Gurus :)

Quick question: I'm having trouble with my PGS subtitles. They always appear in the *upper left* corner of my screen. I've tried playing with the subtitles settings in ffdshow, and I'm able to change font size etc...but the placement won't change. Have I completely overlooked something basic here...?

I'm running the latest version of ffdshow of course. Thanks :)PGS support may be buggy and it is unlikely that it will get fixed if no additional developers join the project.
Try the internal subtitle renderer of MPC instead.

[clsid]

So you was not able to reproduce it?Can´t reproduce. Can´t fix. Sorry. Maybe someone else can.

[Midzuki]

Please ignore the apparent "anomaly" in the MJPEG decoder --- it "magically" disappeared after I (re-)installed ReClock :eek: :confused: Yep, the rootkits are getting more and more evil, their "residual symptoms" are completely "absurd", but they do exist and happen anyway. :( :( :(

[zummi]

PGS support may be buggy and it is unlikely that it will get fixed if no additional developers join the project.
Try the internal subtitle renderer of MPC instead.

Thanks. I'm running Windows Media Player (within Win MCE) for higher WAF :P So I guess I'm screwed :p

Thanks anyway :)

[andybkma]

Please post a sample file that gives you this problem, so that we can test it.

Thanks so much... I have pm'd you.

Andy

[clsid]

@zummi
DirectVobSub has the same capapbilities as the internal subtitle renderer of MPC.

@andybkma
This is a splitter problem. It does not work properly with the standard MS splitter. The files play properly when forcing LAV Splitter as the source filter. Here is a Registry tweak for that:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.wmv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

[wOxxOm]

is it known that AVC/m2ts terribly lags with newer builds?
Older builds still work correctly in the same environment.

builds pre-3892: OK
builds post-3904: FAIL

[clsid]

You are the first to mention such problems.

What exactly do you mean with lag? A sync delay? Stuttering?
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Does it only happen with M2TS? MKV and MP4 are fine?

[wOxxOm]

ehm, have you tried playing avc in m2ts container?
lags will be seen at once, e.g. video plays at half the speed, total desync, etc.
all options are set to defaults

this issue is confirmed by 3 users btw.

[dwild]

Does the problem go away if you adjust the number of decoding threads in the decoder options?
Nothing changes.


Does it only happen with M2TS? MKV and MP4 are fine?
Every file that requires more than one cpu core to decode.
Looks like threading problem.
Quad-core cpu utilisation (same m2ts file):
builds 3904-3925 - 25-30%, lags.
build 3892 and earlier - 40%, no lags.

[clsid]

I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.

Please point to a sample file I should test.

Also try builds in between 3892 and 3904.

[dwild]

I have a fast CPU. CPU usage is below 10% here when playing 1080p H.264 in TS. No lag at all.
It's an i7, I guess?

Please point to a sample file I should test.
From previous quote - that doesn't matter. It's every .m2ts file.

Also try builds in between 3892 and 3904.
Sorry, but I'm seeing only those two on your site, nothing in-between.

[wOxxOm]

@clsid: any BD will do, however I sent you a 15s sample via pm (look at fps in MPC's Statistics pane)

p.s. also you should use a utility to slowdown speed of your CPU for testing purposes, or wait! there's a neat trick - rightclick a player process in Windows' TaskManager, select Affinity and set it to only 1 core. This way you'll be able to spot any problems at once.

and btw, you're not using DXVA, are you?

[clsid]

BD playback is smooth here. Even with a single thread. No DXVA.

Here are two other builds:
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3894-x86-x64.html
http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3897-x86-x64.html

[dwild]

Here are two other builds:
...
They both lag.
So it was introduced in 3893 or 3894.

[JEEB]

I have to agree that there seems to be a performance regression or a synchronization regression around revision 3888 or so with H.264 that comes up mostly with blu-ray streams (mpeg-ts, splitter doesn't seem to matter). Haven't done specific testing, but when building things on the 26th of June trunk HEAD seemed to already have the regression, and revision 3887 seemed to be alright (the libavcodec multithreading used in both cases). This seems to have been reported at the Japanese 2ch board as well (example (http://hibari.2ch.net/test/read.cgi/software/1299337855/549)).

Other than with just plain eyes, the difference can be seen by looking at the green and red lines on MPC-HC's stats output. 3887 and before might have had some sudden rises in the synch difference or whatever it shows, but with a revision affected by this regression the rises would be MUCH bigger. As the effects of this regression are seemingly overall smaller with newer CPUs (I'm on a 2.26GHz Penryn C2D), I would guess that the difference would be visible via this kind of output in case of no visible stutter.

Will try to build and test revision-by-revision later on.

MSVS2010 SP1, GCC 4.5.3

[clsid]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5

[JEEB]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5
Re-built with that commit reverted, and it unfortunately was still stuttering all around the place.

Edit: the libavcodec/h264.c change, that is.
Edit2: I take my words back, same problem came up with mplayer2, and reverting that commit fixed it in there. Uploading a sample for BBB now.

[PetitDragon]

You are the first to mention such problems.

What exactly do you mean with lag? A sync delay? Stuttering?
Does the problem go away if you adjust the number of decoding threads in the decoder options?
Does it only happen with M2TS? MKV and MP4 are fine?

Hi clsid,

I mentioned the similar problem at 25th June.:) (http://forum.doom9.org/showthread.php?p=1510105#post1510105)

[ikarad]

3893 seems the most likely candidate. I suspect it might be this change:
http://git.libav.org/?p=libav.git;a=commitdiff;h=ea6331f8bbaf3343faec6ffe77a6218a016a3af5

How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.


Moreover i don't know if anybody works on sub renderer (which is still buggued) today but this problem is not yet corrected
https://sourceforge.net/tracker/index.php?func=detail&aid=3186705&group_id=173941&atid=867360

[hoborg]

Can´t reproduce. Can´t fix. Sorry. Maybe someone else can.

Too bad :(
But here is video (http://www.youtube.com/watch?v=KZreMRTsuXk) what happening.
Tested h.264 in mp4/m2ts/mkv container - all of them crash Graphstudio when deleting FFDshow DXVA decoder from graph.
No problem with FFDshow video decoder - tested on xvid AVI.

[clsid]

How to decide to make a release candidate even when important bugs are still present?
By curiosity I would like to know.There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.

[ikarad]

There isn't any RC.

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.

I don't know what bug you told but I speak about sub renderer bugs (bug that I post the link above: here https://sourceforge.net/tracker/index.php?func=detail&aid=3186705&group_id=173941&atid=867360).

If you speak about ffdshow-mt, I never have bugs with ffdshow-mt since one or two year with blu-ray movies or anime in h264 (I stop at version 3614 (I only test briefly the next versions then I don't know if the next versions are buggued with ffdshow-mt).

[JEEB]

The 'bug' you are referring to may not even be an actual bug. The cause has yet to be confirmed, but it possible that the performance regression is an unfortunate side-effect of a correct change. Better to have correct and slightly slower decoding than fast and buggy. And before people start whining with 'old faster version worked fine for me' comments. STFU until the cause is known.
Basically the cause was a fix to the threading code that could produce incorrect results with H.264 streams having slices:
// packets can sometimes contain multiple PPS/SPS
// e.g. two PAFF field pictures in one packet, or a demuxer which splits NALs strangely
// if so, when frame threading we can't start the next thread until we've read all of them
Cases NAL_IDR_SLICE and NAL_SLICE were added to it, to take sliced streams into mention (basically more stuff is done with slice-having streams [blu-ray specs mandate all level 4.1 blu-ray streams to have slices, f.ex.] before threads can continue/be started). Which is a valid fix.

Now, of course I have no idea if this fix actually touches us, as in -- is it needed in our use case of ffdshow-tryouts (probably is), but BBB answered my calls right away, and I gave him out a ~420MB sample that might help him develop something that not only fixes the borked cases, but also does less damage towards decoding capabilities with frame-based multithreading (slice-based multithreading is unaffected, as is single-threaded decoding).

[clsid]

You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?

Using slice-based threading on streams without slices will of course give crappy performance, so if we would ever use it it must be done conditionally.

Who is BBB btw?

[JEEB]

You can enable slice-based threading by modifying "ffcodecs.h". I did a quick test and it gives similar performance here for a BR sample. Slice was even marginally faster than frame-based. Can you test on your PC if slice-based balances the load better?Will see in a momento... or tomorrow (today) after I get some sleep. Been a rather hectic weekend.

Who is BBB btw?Ronald S. Bultje's nickname on IRC, as I don't use the mailing list much (read: at all).

[ikarad]

I don't know where I can post this thing but Ihave noticed that in the versions from xvidvideo.ru (icl12 and mvsc2010), deband filter doesn't work since several months. With versions from ffdshow site deband filter works well.

[andybkma]

@andybkma
This is a splitter problem. It does not work properly with the standard MS splitter. The files play properly when forcing LAV Splitter as the source filter. Here is a Registry tweak for that:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Media Type\Extensions\.wmv]
"Source Filter"="{B98D13E7-55DB-4385-A33D-09FD1BA26338}"

Ah, thanks for your kind response and advice, clisd. So ummm... just curious as to why ffdshow won't work properly with the standard MS Splitter for those vids? Were the vids encoded improperly by their makers or something like that? Unfortunately setting the LAV Splitter to split all my wmv content is a no go solution but is nice to know all the same :)