ffdshow tryouts project: Discussion & Development

[pitch.fr]

from what I understood, as long as your CPU supports SSE ICL10 compiled builds will be faster.

I wish I found this out a while ago, actually :rolleyes:

I guess they make generic builds for old ass CPU's...

[fastplayer]

I wish I found this out a while ago, actually :rolleyes:

I guess they make generic builds for old ass CPU's...
Read the FAQ... :rolleyes:

[Shinigami-Sama]

from what I understood, as long as your CPU supports SSE ICL10 compiled builds will be faster.

I wish I found this out a while ago, actually :rolleyes:

I guess they make generic builds for old ass CPU's...

its just after marc=pentium2 theres not that much gain
like 0.2% and thats within the range of error....

[pitch.fr]

Read the FAQ... :rolleyes:

I did, actually :rolleyes:

but I always thought that this FAQ was outdated, and that all the available builds were ICL10 already..

on a 3.3Ghz Q6600 with extensive audio/video post-processing(96HQ resampling, spline resize, sharpening, rgb32 conversion, MT avisynth) on HD content, the difference is VERY MUCH noticeable :)

I guess noone knows how to get nice and clean deinterlacing on 29.97 DVD content ?

[clsid]

libavcodec is always compiled with GCC so the decoding speed is pretty much identical for all our builds. ICL is only beneficial for some of the a/v postprocessing filters. Most people don't use those, so for them there is no noticable difference between builds.

[Octo-puss]

Maybe I can post my question here. What's being used for decoding mp3 if disabled in FFD?

[fastplayer]

Maybe I can post my question here. What's being used for decoding mp3 if disabled in FFD?
Either your media player's- or OS-integrated MP3 decoder.

[Octo-puss]

Hmm considering general crappiness of XP, I guess FFD will be better choice :)

[pitch.fr]

try Gabest's MP3 decoder.
huge soundstage, very clear audio, IEEEE float output.

it doesn't get any better than that, I think it's by far the best mp3 decoder(I tried Shibatch, MAD, Franhofer, foobar, etc..)

there's some MPC HC versions with standalone .ax filters ;)

[Liisachan]

Hmm considering general crappiness of XP, I guess FFD will be better choice :)
Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.

IIRC libmad is the default mp3 decoder in ffdshow (I don't know why. WHY?), and so you might want to change that option manually.

[Liisachan]

try Gabest's MP3 decoder.
huge soundstage, very clear audio, IEEEE float output. If you mean the one in MPC, that's libmad too. So it may be actually ok, and even excellent, but I can't help but feel it's not safe...

[IgorC]

As many people already know about new AAC decoder http://multimedia.cx/eggs/aac-decoder-is-in/
There is no information about stability but are there some plans to include it to ffdshow in future?
It has better performance than faad.

[Octo-puss]

Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.

IIRC libmad is the default mp3 decoder in ffdshow (I don't know why. WHY?), and so you might want to change that option manually.

Well, there is this mp3lib which I've been using and didn't encounter any problems.

[pitch.fr]

Yeah, maybe that's safer. But there are more than one mp3 decoders in ffdshow itself, and I'd say you might want to use something other than libmad. libmad has not been maintained anymore, more than 4 years or so now, and known as seriously-buggy-but-no-one-fixed-it for some years, with several reports, at least on mplayer (-ac mad). The problems are not about quality, mostly AV-sync related, especially in VBR.
https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/244722

It may be ok in ffdshow (so far no obvious problems have been found in ffdshow-libmad), but the bug is in libmad itself, outdated and not maintained, so it should be safer to use another decoder. Besides, basically you don't get anything by selecting libmad unless your CPU only supports integer math, and not floating.
thanks for the bug report.
I mostly use Gabest MPC's MP3 decoder for music(so A/V sync is irrelevant), and I might have watched a few AVI's with VBR MP3.....they seemed fine to me ?!

I use Reclock and HR, so my movies are under tight supervision :D

I'd guess that Gabest would have seen and fixed such an A/V bug, considering he really knows what he's doing :)

so this bug might either be only MPLAYER-related, Gabest would have fixed it in his DSHOW filter or I didn't encounter the bug yet ?!

I'll run more tests, and compare with ffdshow's built-in MP3 decoders.

[Mangix]

mp3lib is faster. not that it makes a difference...

[Liisachan]

@Octo-puss
@Mangix
Yup, my choice now is mp3lib too. That's mplayer's standard default too. I have no real reason to like it, but I do have a reason to dislike libmad, so relatively...

@pitch.fr
No, this bug is probably in libmad, not in mplayer. If you select another decoder (-ac3 mp3 or -ac3 ffmp3), mplayer is happy with MP3 including VBR. Besides, I was told that madplay (the reference implementation of libmad) has bugs too.

Maybe things are ok on Windows, which uses it's own sync system, just letting libmad decode, not asking it what time it is now. It's just that I really can't trust libmad anymore, now that I know how it's broken on mplayer. I wouldn't make it ffdshow's default mp3 decoder. Many years ago, when I found that ffdshow's default Vorbis decoder was really bad, milan told me that he would still like to keep Tremor in Low Quality Mode for slower CPUs. Maybe libmad is there for the same reason. But I tend to think it shouldn't be the default.

libmad might behave differently than other DirectShow mp3 decoders on Windows if the first mp3 frame is a VBR tag frame ("LAME", "Xing", "Info"), especially a LAME tag frame. libmad is fully VBR-tag-aware. But the difference is like 24 ms, so hard to detect. And actually this part may be related to the bug.

When my friends and I found that mplayer -ac mad didn't like VBR MP3, we first assumed that it just didn't like the hack to put VBR audio in AVI. Some also suggested that packed bvops were bad too. However, like that bug report says, we then noticed libmad didn't like VBR MP3 in (x264+VBR MP3).mp4 .mkv etc. either. So the problem is more fundamental: libmad itself is broken, and you can't blame Nandub's hack or DivX's hack here.

I am under impression that mpalyer's libmad goes crazy especially when you put VBR MP3 *without* the VBR tag (lame -t), but it's not really stable *with* the tag either. LAME tag might be a cool hack for audio-only files, but depending on it is a bad idea for movies, since it exists only as the first mp3 frame and you might edit your movie removing the first part, or dividing it into 2 or more. Or you might concatenate 2 movies, and if each of them has this tag, you end up having the hack padding in the middle of your movie.

[clsid]

I have never noticed any VBR related problems with libmad and I am not aware of any ffdshow users that are. So you are probably right that the bug doesn't manifest itself with DirectShow, or at least not in a noticeable way.

[fastplayer]

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D

[pitch.fr]

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D
well, EVR/VMR are nowhere near as smooth as HR jitter-wise.
yet noone complains, mostly coz they watch movies in 60Hz on crappy flat screens.

so this user base is not too picky when it comes to A/V sync and dropped frames ;)

[thuan]

@pitch.fr: You haven't look at MPC-HC thread, have you?

[pitch.fr]

haha.

no, what is MPC HC again ? :D

well simply put, I play my movies in 24fps in 24Hz with Reclock and HR.

HR offers an extremely low jitter such as 0.01ms :

http://pix.nofrag.com/3/7/2/f9dd4bb16cde2c99452be634e747f.png

MPC in custom EVR/VMR9 is UNABLE to keep up with such a low jitter, let alone not dropping frames for no reason.

MPC is great for watching movies in 60Hz w/o Reclock I guess :D

so if that madlib is giving 24ms delay, I guess no MPC user would notice it anyway.

just for fun, try to play 29.97fps in 89.91Hz....MPC HC in exclusive mode will fail....look at the CTRL+J infos :D

the MPC HC custom renderers are really not tight enough, HR plays 29.97@89.91Hz w/o a itch and with <1ms jitter.

[TheShadowRunner]

hi leeperry, huh pitch.fr...
Still trying all you can to get a stable playback or did you find the holy grail yet?
I just want to react on the EVR/VMR jitter statement. VMR9 is perfectly stable here, not a single dropped frame, ever; a perfect job with Reclock. So don't generalize please.
Later,

TSR

[pitch.fr]

I don't know you TSR, I'm sorry :)

yeah, if you don't find HR smoother than EVR/VMR, I think the problem might be on your display(not all of them offer perfect VSYNC in the first place) ;)

I'm far from being the only one who finds HR a lot smoother than EVR/VMR on HCFR.

HR is as smooth as a cinema projector, I usually suffer from 10ms jitter(a quarter of a frame in 24fps) over a 2H movie w/o a single dropped frame.

HR and Reclock work perfectly fine here, offering the ultimate 24fps goodness :)

try to play 29.97fps@89.91Hz in MPC EVR/VMR, and lemme know how it goes.

but we should drop it anyhow, I can feel clsid is gonna complain that it's OT(which it is ;))

[SBeaver]

I don't know you TSR, I'm sorry :)

yeah, if you don't find HR smoother than EVR/VMR, I think the problem might be on your display(not all of them offer perfect VSYNC in the first place) ;)

I'm far from being the only one who finds HR a lot smoother than EVR/VMR on HCFR.

HR is as smooth as a cinema projector, I usually suffer from 10ms jitter(a quarter of a frame in 24fps) over a 2H movie w/o a single dropped frame.

HR and Reclock work perfectly fine here, offering the ultimate 24fps goodness :)

try to play 29.97fps@89.91Hz in MPC EVR/VMR, and lemme know how it goes.

but we should drop it anyhow, I can feel clsid is gonna complain that it's OT(which it is ;))

I think that could depend on the hardware also.
When I had a regular LCD with 60Hz HR always gave me good results but now when I have a projector it's a lot harder to get perfect tearing-free playback.
My perfect setup is EVR custom with d3d fullscreen (without this I get slowdowns/drops or tearing) and 47,952Hz (23.976*2) using powerstrip.
24Hz was impossible, sometimes it would seem to work but most of the time there was tearing, and with Haali there was always tearing.
Also haali has those ghost lines when rescaling on my Radeon so I wouldn't want to use it anyway.
I'm sure it can be improved though, I used to use haali all the time.

[Liisachan]

With libmad being the default MP3 decoder in ffdshow and MPC, any problem would have been noticed and reported straight away. The user base is way too large and picky to let this go unnoticed :D

I don't think that way. For example, many encoders use LAME without -t, causing bad AV sync and they are still happy about the results. Plus users in general are slow to report a problem even if they notice there are or there may be something wrong. But the conclusion that libmad is ok on Windows is perhaps correct anyway.

[pitch.fr]

I think that could depend on the hardware also.
When I had a regular LCD with 60Hz HR always gave me good results but now when I have a projector it's a lot harder to get perfect tearing-free playback.
My perfect setup is EVR custom with d3d fullscreen (without this I get slowdowns/drops or tearing) and 47,952Hz (23.976*2) using powerstrip.
24Hz was impossible, sometimes it would seem to work but most of the time there was tearing, and with Haali there was always tearing.
Also haali has those ghost lines when rescaling on my Radeon so I wouldn't want to use it anyway.
I'm sure it can be improved though, I used to use haali all the time.
I'd say it comes from your graphic card/motherboard, or possibly some settings in the BIOS or in CCC(is it on the primary device?)

well look at the CTRL+J infos in D3D exclusive mode, it's a jerky party :)

what I really enjoy in HR is that it remains smooth no matter how much post-processing you got running in ffdshow(when ffdshow reaches h264 bitrate peaks, MPC will drop frames more often than you'd think) and the jitter(the interval between each frame) is constant and very low.

when I watch 24fps stuff in MPC+EVR/VMR9 I have the feeling that I'm getting 23.5fps.....but it's the same in other players, you can't except a software only renderer to offer the same jitter as a hardware based coded by one of the main video rendering expert on PC.

like I said HR is like an unstoppable train, it won't take sh*t from anybody :)

to avoid ghost lines when upscaling with HR, you need to upscale in ffdshow instead(in spline if you can) ;)

[ACiD GRiM]

I'm trying to compile the 64 bit version of ffdshow, but i get the following errors:

Error 62 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." ff_vfw
Error 65 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." ff_acm
Error 56 error PRJ0019: A tool returned an error code from "yasm assembling c:\Users\Ben\Desktop\ffdshow-tryout\src\cpuid64.asm" ffdshow


I'm using Visual Studio 2008, and have compiled some other projects before. I'm wondering if I'm missing some libaries from my VC/lib folder, but I'm not sure. Could someone give me some tips

[Tom Keller]

Does anyone knows, why this recorded H.264 stream (http://www.megaupload.com/?d=66YZOX7I) crashes ffdshow after a couple of seconds? It doesn't matter which player i use - i always get a Visual C++ runtime error after 13-16 seconds. But there aren't any problems with CoreAVC or with the Cyberlink H.264 decoder :confused: ...

[pitch.fr]

I'd like to resize in the avisynth filter of ffdshow, but is there a way to enforce the ffdshow OAR ?

the idea would be to resize to spline 1280*720 and keep the OAR..

maybe with ffdshow_dar_x/ffdshow_dar_y ?

it's not very clear :
http://ffdshow-tryout.sourceforge.net/html/en/avisynth.htm

thanks,

[3ngel]

What about developing a Lagarith decoder implementation?

The codec works really well in coding phase and it would benefit from a DirectShow chain decoding (actually is limited by the internal VFW decoder implementation).

I hope you find this interesting and think about it :)

[CruNcher]

Does anyone knows, why this recorded H.264 stream (http://www.megaupload.com/?d=66YZOX7I) crashes ffdshow after a couple of seconds? It doesn't matter which player i use - i always get a Visual C++ runtime error after 13-16 seconds. But there aren't any problems with CoreAVC or with the Cyberlink H.264 decoder :confused: ...

Seems to be a generic Libavcodec Decoding Problem also ffplay crashes (picture buffer overflow), mplayer segfaults vlc doesn't but skips alot of the frames anyways ;)

PS: Superdump is doing a Bug Report for the ffmpeg guys on this thx Superdump :)

[clsid]

What about developing a Lagarith decoder implementation?

The codec works really well in coding phase and it would benefit from a DirectShow chain decoding (actually is limited by the internal VFW decoder implementation).

I hope you find this interesting and think about it :)
First of all, ffdshow uses external libraries for decoding. It does not have its own decoder implementations.

Secondly, there are currently zero developers that are actively working on ffdshow. Which means no bug fixes and certainly no new features.

[3ngel]

Oh, i see i didn't know about this situation.

Mine was just an idea.

[Tom Keller]

Seems to be a generic Libavcodec Decoding Problem also ffplay crashes (picture buffer overflow), mplayer segfaults vlc doesn't but skips alot of the frames anyways ;)

PS: Superdump is doing a Bug Report for the ffmpeg guys on this thx Superdump :)
Thanks for your answer. Seems you're right: the ffmpeg based built-in H.264 decoder from mpc-hc crashes too. Hopefully it's possible to fix it...

[lych_necross]

Secondly, there are currently zero developers that are actively working on ffdshow. Which means no bug fixes and certainly no new features.

If that's true, then what why are there new tryout releases about every week? What exactly is being changed to justify a version change from ffdshow-20041012 to ffdshow_rev2079_20080815? :confused:

[_xxl]

Please read:
http://forum.doom9.org/showthread.php?t=120465

[Mercury_22]

Since now (http://forum.doom9.org/showthread.php?p=1177473#post1177473) FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. can we hope for E-AC-3 DECODING TOO ? ! :helpful: :thanks:

[clsid]

If that's true, then what why are there new tryout releases about every week?Lately, changes are mostly insignificant updates. Like importing updates from FFmpeg project.What exactly is being changed to justify a version change from ffdshow-20041012 to ffdshow_rev2079_20080815?An enormous amount of improvements have been made to ffdshow in the past years. When I made a comment about a lack of developers, I was talking about the current situation.

can we hope for E-AC-3 DECODING TOO Only if someone volunteers to take up the task.

[jmartinr]

I'd like to resize in the avisynth filter of ffdshow, but is there a way to enforce the ffdshow OAR ?

the idea would be to resize to spline 1280*720 and keep the OAR..

maybe with ffdshow_dar_x/ffdshow_dar_y ?

it's not very clear :
http://ffdshow-tryout.sourceforge.net/html/en/avisynth.htm

thanks,

I use the following script in ffdshow to tinker with the OAR, and to crop off anything that's outside a 16/9 window. I have a small TV-set and have no use for this superwide stuff. It should not be very hard to do what you want.

#ffdshow_setDAR(16,9)
#ffdshow_setDAR(4,3)
#ffdshow_setSAR(12,11)
#wanted dar x
wx=16
#wanted dar y
wy=9
maxwidth=round(last.height*float(ffdshow_sar_y)*wx/ffdshow_sar_x/wy)
maxwidth=maxwidth-(maxwidth%16)
maxwidth=min(last.width,maxwidth)
crop((last.width-maxwidth)/2,0,maxwidth,0)

[lych_necross]

Lately, changes are mostly insignificant updates. Like importing updates from FFmpeg project.An enormous amount of improvements have been made to ffdshow in the past years. When I made a comment about a lack of developers, I was talking about the current situation.

Okay, thanks clsid. Hopefully sometime soon more people will decide to actively develop it soon (I would like to see new features).

[Joniii]

I just installed Vista x64 (SP1) and i'm having severe problems with FFDShow.

Every HD movie I play stutters alot and is unwatchable with x64 builds of FFDShow. I'm using MPC-HC x64 matroska & mpeg splitters for .mkv and Blu-ray .m2ts. It happens in all content (VC-1, H.264 and MPEG-2).

If I disable for example MPEG-2 in FFDShow so that Default Microsoft MPEG-2 codec is used, all MPEG-2 Blu-rays plays smoothly.

I had no problems with Vista x86 & FFDShow. I have the same problem also with MPC-HC and it's internal splitters.

[_xxl]

x64 builds are slow because libmpeg2 is compiled from plain C only.

Which Cpu do you have?

[Joniii]

x64 builds are slow because libmpeg2 is compiled from plain C only.

Which Cpu do you have?

Core 2 Duo 6400.

MPC-HC MpegSplitter.ax (x64)

MPC-HC x64 or WMP11 x64 (x64 FFDShow VC-1, H.264 & MPEG-2)
-Unwatchable VC-1, H.264 & MPEG-2 Blu-rays.

MPC-HC x64 or WMP11 x64 (x64 MPCVideoDec.ax VC-1, H.264)
-Unwatchable VC-1 and H.264 Blu-rays.

It seems strange because those both scenarios work like a dream in Vista x86.

[Leak]

It seems strange because those both scenarios work like a dream in Vista x86.
Like clsid said, there is no optimized 64-bit code for the decoders, so they *WILL* be slow.

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

[Joniii]

I tried this with Vista x64:

MPC-HC MpegSplitter.ax (x86)

MPC-HC x86 or WMP11 x86 (x86 FFDShow VC-1, H.264 & MPEG-2)
-Everything works like a dream.

[Joniii]

Like clsid said, there is no optimized 64-bit code for the decoders, so they *WILL* be slow.

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

Oh, I didn't know about that.

It's just that I watch TV/Movies with my Media Center computer. VMC comes only as 64-bit in Vista x64 and can't use 32-bit WMP11 or 32-bit codecs.

I guess I'll have to install 32-bit Vista then.

[Jong]

Hi everyone.

I have a problem with output settings when using profiles.

If I set one of my profiles to RGB it seems that all profiles do RGB conversion, even if set correctly for YV12.

I have profiles/presets for "SD", "720p" and "1080p" (defined by horizontal resolution). I need to do RGB conversion on SD titles so I can force use of the BT.601 colorspace for upscaled SD material. However, it is a complete waste of cycles to do RGB conversion in software for native HD material and the processing power required actually prevents me doing any other post-processing. ffdshow appears to allow different profiles to use different output colorspaces but it does not seem to work. RGB conversion is done on all once I set it in my SD profile. I do not know why the SD profile seems to take priority, except maybe because it was the first of the profiles to be created. Or maybe it is just that RGB is used if ANY profile is set ot RGB. The RGB Conversion tab DOES work correctly, so at leat I can use BT.709 for HD and BT.601 for SD.

Does anyone have any idea why this is happening and how to resolve it?

Thanks.

[clsid]

Actually, the 64-bit builds DO contain optimizations. At least when libavcodec is build with GCC, which I use for my 64-bit builds. Libmpeg2 on the other hand, as xxl said, does not use the assembly optimizations, and therefore can be slow.

But the slowness issues with 64-bit builds seem to have another cause. Possibly related to colorspace (conversion). Two known workarounds:
1) Enable NV12 colorspace in ffdshow options. Might only work for ATI cards (need confirmation on that). You might also need to disable YV12 (not sure, need confirmation as well).
2) Enable OSD. (Dunno why this makes a difference. Anyone have an idea why? Does it trigger a colorspace conversion?)

[Reimar]

Use a 32-bit media player and the 32-bit version of ffdshow instead; it's not as if video decoding would actually need the extra address space a 64-bit app has...

No, but since we are talking about x86 they very much can use the extra 8 registers and SSE/SSE2 being mandatory that x86_64 provides in addition to 64 bit address space (which to be pedantic is currently "only" 40/48 bit anyway).
Also since libavcodec and at least MPlayer's libmpeg2 work fine in 64 bit builds, I'd expect it should take an interested developer with a 64 bit system not too long to fix the issue. Now how to find such a developer is a different point...

[_xxl]

MPlayer's libmpeg2 work fine in 64 bit builds
Win64 is not the same with ARCH_X86_64. The same issue is with x264 encoder. No Win64.