ffdshow tryouts project: Discussion & Development

[Liisachan]

why cant i using ffdshow for RV10 in sony vegas???

or do i need to remove realplayer first??

EDIT
Sorry, I posted an idiotic reply mistaking rv10 with rv40 ^^;
*deletes everything*

Ok, the only I could say is,,, the config dialog says "Real Video (RV10, RV20, incomplete)"--so the support is imcomplete...

[clsid]

Does Sony Vegas use VFW? In that case make sure that you have enabled RV10 in the ffdshow VFW decoder.

[haruhiko_yamagata]

AVIS decoding in DirectShow mode works for me.
In vfw mode, ffdshow fails to connect.:confused:
In vfw mode it works now. My setting was broken (AVI Decompressor was disabled).
@zambelli: could you upload samples (with the script and original file)?

[KoD]

embeeding asm in C programs on x64 architecture machines is different than on x86. Explanations in MSDN. Not to mention 64 bit in Linux is different than 64 bit in Windows (int is also 64 bit while on Windows no), so don't ever expect for any 64 bit code developed on a Linux machine (like libavcodec is) to be easily ported to 64 bits on Windows, unless it was designed to be. I doubt that Linux developers really care about porting it to Windows though, not to mention fast bit operations may not be ported unless rewritten specifically.

[HowlerX]

Was wondering why I couldn't get h.264 mov trailer to decode with megui. Took me almost two hours to figure out that I had left "Use ffdshow only in:" active but did not have megui in the list. :(

Suggestion: Please add megui.exe to list of programs allowed.

... I should really be sleeping...

[Dr Pizza]

embeeding asm in C programs on x64 architecture machines is different than on x86. Explanations in MSDN.
Right, no inline asm in x64. But that's probably not a problem, because VC++'s inline asm syntax was different from gcc/g++'s anyway, so I wouldn't expect much or any inline asm to be used at all; nasm or yasm syntax is far closer to portable.

Not to mention 64 bit in Linux is different than 64 bit in Windows (int is also 64 bit while on Windows no), so don't ever expect for any 64 bit code developed on a Linux machine (like libavcodec is) to be easily ported to 64 bits on Windows, unless it was designed to be.
I think most of this kind of code uses typedefs anyway so the different 64-bit models shouldn't make a difference. Stuff like the H.264 decoder already has 64-bit asm with Windows-specific code paths, it just doesn't work properly.

[haruhiko_yamagata]

Was wondering why I couldn't get h.264 mov trailer to decode with megui. Took me almost two hours to figure out that I had left "Use ffdshow only in:" active but did not have megui in the list. :(

Suggestion: Please add megui.exe to list of programs allowed.

... I should really be sleeping...
Thank you. Added at rev 1048. Please open the dialog (pressing edit button) and reset the list.

[ONjA]

Hi! Some long lived bug forced me to register.
ffdshow version: at least any starting from this year, icl9 or generic (clsid build)
Sample: http://chukos.narod.ru/sa2.avi 1.2Mb (DIV3)
Player: mpc/crystal
Setup: Postprocessing on, > fast spp deblock <
How to: While playng video open and close ffdshow's settings window several times. You'll probably see access violation...

Can't determine any dependency on file's properties, but I have quite a lot of such files. Some similars in type do not exploit that.
Normal (not fast) SPP works fine.

[haruhiko_yamagata]

Hi! Some long lived bug forced me to register.
ffdshow version: at least any starting from this year, icl9 or generic (clsid build)
Sample: http://chukos.narod.ru/sa2.avi 1.2Mb (DIV3)
Player: mpc/crystal
Setup: Postprocessing on, > fast spp deblock <
How to: While playng video open and close ffdshow's settings window several times. You'll probably see access violation...

Can't determine any dependency on file's properties, but I have quite a lot of such files. Some similars in type do not exploit that.
Normal (not fast) SPP works fine.
Thank you, but I can't reproduce. Any aditional information such as CPU, OS, extra filter... are wellcome. Which page to open?

[foxyshadis]

There are several x64 players out there that won't use 32-bit codecs. If you take a x64 build of Vista, your Media Center, Movie Maker, and DVD Maker are all 64-bit, so the current 32-bit ffdshow won't work with those applications.

I'm just really hoping that this will happen, because I love ffdshow for it's immense flexibility, and I'd like to be able to use an updated 64-bit version of it (celtic_druid's build has some issues with H.264 decoding- artifacts galore).

It'll happen as soon as a developer or willing volunteer gets x64. Until then it's untestable even if it was tweaked to compile; how could we fix any inevitable crashes?

[Dr Pizza]

If someone could provide me with a buildable x64 source tree and suitable files to test it, I could certainly have a look.

[ONjA]

Thank you, but I can't reproduce. Any aditional information such as CPU, OS, extra filter... are wellcome. Which page to open?

Verified on 3 computers:
AXP and Duron (old, no sse, generic) - w2ksp4, no additional codecs\splitters\packs.
AXP under clean ws2003.

Just invoke ffdshow via player's control, i.e. mpc - filters -> ffdshow video decoder, then close, then invoke once more. Or the same via tray control.

[Px]

It'll happen as soon as a developer or willing volunteer gets x64.
I can test such builds in my second os, XP x64

[Leak]

Okay, here's another updated version of my AviSynth filter:

The current installer based on revision 1048 (and previous versions) can be found here (http://leak.no-ip.org/AviSynth/ffdshow/)
Patch is here (https://sourceforge.net/tracker/index.php?func=detail&aid=1676882&group_id=173941&atid=867362)

Changes are that setting 0/1/0 and disabling "Apply Pulldown" should prevent any buffering ahead, just like the old filter. I've also added some code to send an onStop event to the filters when using the DirectShow encoder and encoding finishes, as I need to do some cleaning up if encoding should work more than once in a row.

Note: if you're using ffvfw (the Video for Windows wrapper around ffdshow) for encoding with the AviSynth filter turned on and it is set to buffer ahead you *will* get repeated frames at the beginning of your encode, as VfW *always* expects a compressed frame to come out when it hands an uncompressed frame to a codec - and there's nothing I can do about that.

Encoding using the DirectShow "ffdshow video encoder" works fine, though.

[multiblitz]

I guess this is a bug:

If I use ffdshow (rev 1020) to playback VC-1 (HD-DVD) (using Haali's splitter, AnyDVD and ZP), I get a white picture (pure white screen) if I don't resize the picture. With resize (lanzos), I have a nice picture. But I don't want to resize (1920*1080 is already there...)

BIggest Bug so far: If ffdshow is used in the video-part (does not matter if it is only postprocessing-raw-filter after the original MS VC-1 Codec or directly the ffdshow-VC-1-decoder): Instead of correct speed of 23.976 fps, it recognizes 29.999 fps. So, the video is much faster than the audio which indeed is the case...without ffdshow in the video-chain, with pure MS VC-1, it works, eventhough SPDIF is still somewhat jaggy (core duo 6400 at 3.6 ghz).

[cc979]

with rev1050 and before
can't get ffdshow to be used with virtualdub (us sure it work before) it falls back to opening with xvid

is there something up with the vfw part?

cheers

[clsid]

It works fine here. If you have both installed it is to be expected that Xvid is used instead of ffdshow. VFW doesn't have a merit system afaik.

[skystrife]

I can test such builds in my second os, XP x64

I know nothing about compiling and such, but I would certainly be interested in beta-testing such software. =)

[cc979]

VFW doesn't have a merit system afaik.

i did'nt know about that, cheers

[akupenguin]

Is there really a need for x64 build of ffdshow? I mean, it won't be any faster than normal 32-bit build and x64 is compatible with normal builds.

It would be faster if you didn't have to disable asm. A 64bit build of ffh264 is 15% faster than a 32bit build on linux, entirely due to the extra registers.

Stuff like the H.264 decoder already has 64-bit asm with Windows-specific code paths, it just doesn't work properly.
There is a little 64bit asm (though mostly we just let gcc compile the same asm for 32 and 64bit). But there are no windows-specific codepaths in libavcodec.

[bob0r]

ffdshow_rev1050_20070318_clsid.exe
ffdshow_rev1050_20070319_clsid_sse_icl9.exe

Which build should i put on x264.nl?
And why ICL9? (does it still only benefit on Intel and not AMD?)

[fastplayer]

And why ICL9? (does it still only benefit on Intel and not AMD?)
:readfaq:
ffdshow tryouts FAQ (http://ffdshow-tryout.sourceforge.net/html/en/faq.htm)

[Leak]

:readfaq:
ffdshow tryouts FAQ (http://ffdshow-tryout.sourceforge.net/html/en/faq.htm)
That still doesn't say anything about whether the executable has Intels dain bramaged "if it isn't an Intel CPU perform much worse/don't run" check patched or not...

[foxyshadis]

It's been patched. Current versions of icl just crash when you use AMD, they don't even bother to use the slow route anymore. (At one point VM9 was going to patch them to crash on Intel instead of AMD... ;p)

[haruhiko_yamagata]

Verified on 3 computers:
AXP and Duron (old, no sse, generic) - w2ksp4, no additional codecs\splitters\packs.
AXP under clean ws2003.

Just invoke ffdshow via player's control, i.e. mpc - filters -> ffdshow video decoder, then close, then invoke once more. Or the same via tray control.
Thank you, now I can reproduce the problem using another computer.

[Dr Pizza]

It would be faster if you didn't have to disable asm. A 64bit build of ffh264 is 15% faster than a 32bit build on linux, entirely due to the extra registers.


There is a little 64bit asm (though mostly we just let gcc compile the same asm for 32 and 64bit). But there are no windows-specific codepaths in libavcodec.

tbh, if there were generic C paths that would do me for the moment. Making sure that the C parts are 64-bit LLP64 clean (god what a stupid model! I sorta understand why MS did it, but it's still annoying; they should have bitten the bullet and gone LP64) would be a good start.

[clsid]

It's been patched. Current versions of icl just crash when you use AMD, they don't even bother to use the slow route anymore. (At one point VM9 was going to patch them to crash on Intel instead of AMD... ;p)
I have patched the genuineintel check in the ICL libraries, so SIMD instructions should work on AMD processors too. Are you sure it crashes on AMD?

[foxyshadis]

I mean, current unpatched icl. Sorry.

[bob0r]

So my question is answered with Beta 2? :thanks:

[ExtraEye]

But of course. Beta 2 is the answer to all questions.

[bob0r]

http://x264.nl/slap.gif

[fastplayer]

@clsid:
Could you add "beta2" to the filename like in the first beta (ffdshow_beta1_20061211_clsid.exe)?

Edit: Thanks! This should help separate it from the nightlies.

[HeadBangeR77]

Hello,
We've been discussing some colour-spaces issues in the ColorMatrix thread, and KillerZero seems to have discovered an interesting thing, that might affect ffdshow decoding.

http://forum.doom9.org/showthread.php?p=972785#post972785

I can't give you more info, since I can't reproduce his findings.

and ...

:thanks:

VERY MUCH for the new beta2! :)

PS. I don't know how the counter works, yet it shows 0 downloads, while at least two people have already downloaded it (me and a friend of mine)...

[akupenguin]

tbh, if there were generic C paths that would do me for the moment. Making sure that the C parts are 64-bit LLP64 clean (god what a stupid model! I sorta understand why MS did it, but it's still annoying; they should have bitten the bullet and gone LP64) would be a good start.

The C parts of libavcodec are definitely LLP64 clean: The only codec that uses (long) at all is the faad wrapper.

[Avish]

I have patched the genuineintel check in the ICL libraries, so SIMD instructions should work on AMD processors too. Are you sure it crashes on AMD? No. It does not crash. I've AMD 64 X2 & Im using ur latest build [ICL9 one] without any problems so far.

[Leak]

No. It does not crash. I've AMD 64 X2 & Im using ur latest build [ICL9 one] without any problems so far.
If it crashed on that CPU something would be really wrong - as all newer AMD CPUs include full SSE2 support (http://en.wikipedia.org/wiki/SSE2#CPUs_supporting_SSE2)...

[foxyshadis]

PS. I don't know how the counter works, yet it shows 0 downloads, while at least two people have already downloaded it (me and a friend of mine)...

It only updates every few hours. They do that on purpose so that all of the early adopters get to feel special, like they're the very first to grab it. That's my theory anyway. ;)

The rest of the colorspace issues raised in that thread are too murky to give me any idea of where the fault might lie. And I can't usually tell the difference between 601 and 709 - mild colorblindness - so I'd never notice anyway.

Want to include leak's patch now? It as good a time as ever.

[HeadBangeR77]

I've been using ICL9 builds for months and it never crashed on me, though I don't have an SSE2-capable CPU (Athlon XP-M).

@ foxyshadis:
Good theory. And you know what, I felt somehow "special" downloading the beta2 and seeing "0" on the counter. :D

As to colours issue with HD - yes, I know it's very vague, and I wasn't able to reproduce it so far. Could be graphic card drivers dependent, instead of ffdshow.

[fastplayer]

PS. I don't know how the counter works, yet it shows 0 downloads, while at least two people have already downloaded it (me and a friend of mine)...
Then the sourceforge servers would do nothing else besides generating pages after every single download where only the counter changed. Unnecessary traffic and CPU load IMO...

[Leak]

PS. I don't know how the counter works, yet it shows 0 downloads, while at least two people have already downloaded it (me and a friend of mine)...
You can click on that "0" to get to the download statistics page for that file - there you'll find the up-to-date download count. ;)

[cc979]

did some quick tests with ffdshow using gcc.4.2.0 pre-release

cc-gcc-4.0.4, and haali splitter v1.7.100.18
tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)

rev1058 - gcc 4.0.4 and gcc 4.2.0 on ffmpeg,mplayer,libmpeg2 - using mmx only
null: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.9, dfps: 75.3
vmr9: 8s, kernel: 1s, total: 9s, real: 10s, fps: 68.7, dfps: 59.9
ovrl: 8s, kernel: 0s, total: 8s, real: 8s, fps: 76.9, dfps: 73.8

rev1058 - all gcc 4.0.4 - mmx only
null: 8s, kernel: 0s, total: 8s, real: 8s, fps: 77.1, dfps: 74.5
vmr9: 8s, kernel: 0s, total: 9s, real: 11s, fps: 67.2, dfps: 57.8
ovrl: 8s, kernel: 0s, total: 9s, real: 9s, fps: 72.7, dfps: 70.8

rev1041
using o4 mmx
null: 9s, kernel: 0s, total: 9s, real: 9s, fps: 71.2, dfps: 67.7
vmr9: 9s, kernel: 0s, total: 10s, real: 11s, fps: 64.4, dfps: 54.9
ovrl: 9s, kernel: 0s, total: 9s, real: 9s, fps: 69.5, dfps: 66.9

using o4 sse1
null: 9s, kernel: 0s, total: 9s, real: 9s, fps: 70.9, dfps: 68.5
vmr9: 9s, kernel: 0s, total: 10s, real: 11s, fps: 63.3, dfps: 54.7
ovrl: 9s, kernel: 0s, total: 9s, real: 9s, fps: 69.8, dfps: 67.0

looks like a improvement me

[_xxl]

@albain
http://img144.imagevenue.com/loc427/th_85485_Capture_122_427lo.jpg (http://img144.imagevenue.com/img.php?image=85485_Capture_122_427lo.jpg)
You have by mistake commited some errors.

[KoD]

cc979, you do realize that's a very short sample and that you'd have to repeat the measurement at least three times in each case to assure that it's consistent.

[zambelli]

In vfw mode it works now. My setting was broken (AVI Decompressor was disabled).
@zambelli: could you upload samples (with the script and original file)?
This is a very strange bug. I generated two .avs scripts, both with same dimensions, pixel type and framerate. The only difference between them is that one reads from ImageSource(), while the other generates ColorBars(). The scripts play exactly the same in DirectShow. Yet, when I create AVIS files from them, those play differently in DirectShow.

When I drop them into GraphEdit:
ColorBars AVIS uses the DirectShow ffdshow decoder and plays back correctly. ImageSource AVIS uses the VfW Ffdshow decoder (AVI Decompressor is inserted) and throws a "Graph can't play" error on playback.

You can download samples from here: http://www.citizeninsomniac.com/download/AVIS.7z

Confirmed on tryouts build 1029. Avisynth version is 2.57.

When YV12 decoding is enabled only in VfW mode and YV12 video is played through DirectShow, the image gets mirrored
This apparently only happens when Ffdshow VfW is set to handle YV12 and renders to VMR7. It forces conversion to YUY2 and mirrors the image. If VMR9 is selected, then it forces a conversion to RGB32 but displays it correctly.

I also noticed different behavior for YV12 AVI playback versus YV12 Avisynth playback. The former always forced RGB32 conversion, while the latter seemed to prefer YUY2 ouput.
When YV12 decoding is enabled in both DShow and VfW, YV12 video is always converted to YUY2 when rendered to VMR (i.e. GraphEdit playback).
Most likely related to the behavior above... The major difference between this one and the VfW behavior is that this one always renders to YUY2, with both VMR7 and VMR9.

Interestingly enough, this YV12 issue only seems to affect rendering. When I connected Ffdshow decoder to the input of the WMV9 encoder in GraphEdit, it passed YV12 to the encoder without any problem.

[haruhiko_yamagata]

This is a very strange bug. I generated two .avs scripts, both with same dimensions, pixel type and framerate. The only difference between them is that one reads from ImageSource(), while the other generates ColorBars(). The scripts play exactly the same in DirectShow. Yet, when I create AVIS files from them, those play differently in DirectShow.

When I drop them into GraphEdit:
ColorBars AVIS uses the DirectShow ffdshow decoder and plays back correctly. ImageSource AVIS uses the VfW Ffdshow decoder (AVI Decompressor is inserted) and throws a "Graph can't play" error on playback.

You can download samples from here: http://www.citizeninsomniac.com/download/AVIS.7z

Confirmed on tryouts build 1029. Avisynth version is 2.57.

It seems to be the "path". Double clicking the AVI file launches MPC and plays, but druging a file to MPC's window does not work unless the working directory is configured. I'll look into it further.

[KillerZero]

I used latest beta (rev 1054) and it renders YV12 in MPC if set to VMR7 (windowed). No conversion to YUY2.
When set to VMR7 renderless it output YUY2, but if I disable all output options except YV12 in output tab, it outputs YV12. Maybe just format selection is wrong?

BTW is conversion of interlaced YV12 --> YUY2 correct? It seems little worse than when playing with mplayer -vf ilpack,scale (I have to use scale, because mplayer crashes with YUY2 output for some reason)

[SealTooGreat]

With:
ffdshow_rev1050_20070319_clsid_sse_icl9.exe
ffdshow_beta2a_20070322_clsid.exe
ffdshow_beta2_20070319_clsid.exe
.... using MPC+Haali splitter, I can't watch my anamorphic encodes(it doesn't stretch to correct AR) and also there's some green line in right border.
Using same ffdshow video presets I don't have that issue with:
ffdshow_beta1_20061211_clsid.exe
Any idea why?!

[fastplayer]

@Devs:
Should the download links (in changelog and tryouts homepage) be updated to the new beta2a build?

[KillerZero]

Would be possible to make ffdshow specify DXVA_NominalRange_Wide
and if specified in stream DXVA_VideoTransferMatrix and DXVA_VideoPrimaries?
I think it should solve problems with WMR modes and that Rec601/Rec709 issue, so SD MPEG2 files with Rec709 colorimetry would play correctly without upsampling to HD.
http://msdn2.microsoft.com/en-us/library/ms796493.aspx

[Leak]

To Haruhiko or whoever has a better understanding of MPEG2 decoding:

If I'm using ffdshow to decode DVDs I've noticed that the only events getting fired from the DVD Navigator are BeginFlush/EndFlush, but the video decoder pin doesn't handle those, so I don't think libmpeg2 or anything else is actually waiting for a keyframe after seeking - that might explain why there's still quite some macroblocking going on when seeking around on a DVD.

Incidentally, that also prevents my filter from just dropping the remaining buffered frames and makes it process them, which is quite wasteful - should we perhaps add an onFlush() method (like the existing onStop and onSeek) to TimgFilter(s) that gets called on BeginFlush(), or should we at least call onSeek() in that case?