New ffdshow build (?)

[bob0r]

*red face* for not going to gcc 4.0.3

[ilpippo80]

ProcessExplorer shows that MediaPlayerClassic loaded pdh.dll.
Watching MediaPlayerClassic activity in ProcessMonitor (also available from sysinternals) shows that pdh.dll is successfully found and opened.
Haruiko and others, if you need my ProcessMonitor log just ask!
Btw, I have Italian version of XP.

[Reino]

ffdshow_rev514_20061109_clsid.exe:

-Does one know when ffdshow will be able to play embedded WavPack Audio together with the WavPack Splitter?
-Also does anyone know if ffdshow will ever support quicktime audio such as TWOS,ARAW,etc?
-When trying to enhance the video images with warpsharp an ugly green line always shows up (see image below). Is this supposed to happen?
http://img139.imagevenue.com/loc361/th_34576_ffdshow_warpsharp_123_361lo.JPG (http://img139.imagevenue.com/img.php?image=34576_ffdshow_warpsharp_123_361lo.JPG)

*bump*

[foxyshadis]

Yes, marcfd's awarpsharp is hideously buggy - using luma only mostly works, but chroma modes bug up all the time. Normal warpsharp shouldn't though.

By WavPack w/ WavPack splitter, you mean ffdshow decoding from .wv files, as opposed to inside a video file? Does it currently not work? I don't have anything to test against. Hybrid files definitely won't work though.

As for quicktime audio, we're pretty dependant on 3rd party libraries for that type of thing. If ffmpeg implemented it, we'll add it, or if an easily integratable open source library was found for them.

[G_M_C]

[...]
G_M_C : on the ffdshow video decoder config -> Decoder options -> switch IDCT to auto and see if you still have that problem. You could also play around with Error concealment option and Error resilience.

Thx, i'll give it "a whirl" as they say, on my next project :)

[Reino]

Yes, marcfd's awarpsharp is hideously buggy - using luma only mostly works, but chroma modes bug up all the time. Normal warpsharp shouldn't though.

By WavPack w/ WavPack splitter, you mean ffdshow decoding from .wv files, as opposed to inside a video file? Does it currently not work? I don't have anything to test against. Hybrid files definitely won't work though.

As for quicktime audio, we're pretty dependant on 3rd party libraries for that type of thing. If ffmpeg implemented it, we'll add it, or if an easily integratable open source library was found for them.

Thanks for your answer foxyshadis.
I'm talking about awarpsharp indeed, but it doesn't make any difference how you setup the options that go with it. I have set Chroma Mode to none, Blur Mode to fast 1-pass, Depth to 16, Threshold to 0.5 and Blur to 2, but the green line always apears no matter what.
Let's hope this will be fixed soon.

As for WavPack: I'm talking about hybrid files (like the one mentioned in this thread: SoC_[XviD+WavPack+MP3]-007.mkv). WV-files play perfectly.

I would be great to be able to play quicktime-files without the need of QuickTime Alternative or VLC Media Player.

[LoRd_MuldeR]

Hey, now I can combine ffdshow with Haali Renderer an get an even longer delay :D
(BTW: rev548 didn't change anything on the problem)

[Px]

I still cannot reproduce the delay problem.

To summarize,

The version of pdh.dll does not matter.
When it is delayed, "CPU Load" always shows the error "does not work in vista..." (Is this correct?)

I think the problem is caused by the failure of loading pdh.dll.
If ffdshow try to load windows\system32\pdh.dll and fail, then it serches the environmental variable "PATH". It takes the time.
I'll try explicit full path. But why does loading pdh.dll fail?
It's not connected with pdh.dll, on rev_494 I have delays in bsp on reopen, and both ffdshow and player don't search for this file. Moreover, I installed ffdshow_rev548_20061115_clsid.exe, there is no delay on first launch, on second launch bsp searching for pdh.dll after delay....

[Px]

Yeah, but it is still pixellated on the edges, XviD shows well-defined edges. When the decoding of H264 by ffdshow produces ruff edges, i cant use it for my transcodes ...
Turn on Fast SPP Deblock

[Px]

There is no HDD activity during the delay, it seems to be just sitting and waiting...
Confirms, no other activity during the delay, watched by filemon....

[LoRd_MuldeR]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem :)

// EDIT

But know MPC disappears without error message when I double-click (some) files in Explorer.
Doesn't happen when I open the problematic files via Drag-and-Drop.

Anybody else with that problem ???

[Blight]

Argh... ignore my previous post, it's not an ffdshow issue.

Keep up the good work.

[LoRd_MuldeR]

When I turn on OSD (and only then), I still get a huge delay plus this:
http://img292.imageshack.us/img292/1936/cpuloadgl2.jpg
(running on WinXP SP-2 as Admin)

[akapuma]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem Confirmed.

Thank you for fixing the problem.

Best regards

akapuma

Edit:
But same problem with CPU-load is on OSD...

[foxyshadis]

As for WavPack: I'm talking about hybrid files (like the one mentioned in this thread: SoC_[XviD+WavPack+MP3]-007.mkv). WV-files play perfectly.
That's ffmpeg's domain; I believe liisachan reported it, but no work's been done on it in the last 4 weeks.

aWarpSharp has no source code, never has. It's a precompiled binary that Milan included. Short of disassembling and rewriting from scratch, like the existing "original ffdshow warpsharp", there's no way to ever fix anything.

[Px]

Hmmmm, uninstalled ffdshow_rev548_20061115_clsid.exe, installed back ffdshow_rev494_20061115_clsid.exe, and delay disappeared.......

[ilpippo80]

FFdshow-Tryouts-20061115-rev551.exe doesn't show the delay problem :)

Confirmed for me too.
no more delay on startup. still delay when turning on osd with cpu load and same message "does not work on vista"...

[clsid]

So it seems that loading phd.dll only from system32 doesn't make a difference. That workaround can then be removed.

Perhaps the following updated version of phd.dll fixes the problem?
http://support.microsoft.com/kb/917022/en-us

[Episode]

There doesn't seem to be any way to download that hotfix :(

[Liisachan]

That's ffmpeg's domain; I believe liisachan reported it, but no work's been done on it in the last 4 weeks.

clsid is the one who reported the problem (http://forum.doom9.org/showthread.php?p=880207#post880207) on September 26, 2006, also saying "Wavpack crashes". Currently, lossy/hybrid Wavpack does not crash, though you get no sound, so I guess it's better than it was. "Normal" lossless Wavpack does play too. The problem is, so-called Wavpack Lossy (lossy wv without wvc) and Wavpack Hybrid (lossy wv with wvc) do not play.

Wavpack is currently v4.3x and v4.4 is on its way, which will be slightly incompatible with 4.3x, so I'd think devs can wait until 4.4 is officially out.

[Egh]

aWarpSharp has no source code, never has. It's a precompiled binary that Milan included. Short of disassembling and rewriting from scratch, like the existing "original ffdshow warpsharp", there's no way to ever fix anything.

Suggestion: then maybe it should be removed completely?

BTW, what are other precompiled binaries used in ffdshow for which source is not available?

Anyhow, anyone who needs specifically awarpsharp, can use avisynth filter, which doesn't produce greenline, at least here.

Also, theoretically one can ask the developer for the source code, so reverse engineering is not the only remaining option ^^

[haruhiko_yamagata]

I gave up using pdh.dll and restored previous version of TcpuUsage.
I thought it was not working, but I was wrong. It was basically OK, some device was necessary for the caller's side. Now it works for multiprocessor system too.

Thank you for many reports and backup.
My binary (http://sourceforge.net/project/showfiles.php?group_id=173941) is available for rev555.

[fastplayer]

Hehe, I'd really like to know why it worked for some and for others not. But as long as it works... :D
Thanks for your persistence on this matter! :)

[LoRd_MuldeR]

I gave up using pdh.dll and restored previous version of TcpuUsage.
I thought it was not working, but I was wrong. It was basically OK, some device was necessary for the caller's side. Now it works for multiprocessor system too.

Thank you for many reports and backup.
My binary (http://sourceforge.net/project/showfiles.php?group_id=173941) is available for rev555.

Thank you! New build works fine, even with OSD and "CPU Load" enabled :)

[G_M_C]

Turn on Fast SPP Deblock

Nothing seems to help as yet. Will keep trying though, by downloading & installing the newest version this weekend and starting again.

But i'm considerating going over to CoreAVC if it works better with my system and AviSynth's DirectShowSource().

But before i do that, i wanted to try out the Open Source possibillities first.

[lasuocera]

Thank you! New build works fine, even with OSD and "CPU Load" enabled :)

It's ok for me too!

[clsid]

@ G_M_C: did you perhaps enable any of the "skip deblocking ..." options in ffdshow? Those lower the visual quality (and increase performance).

[Jeremy Duncan]

The download links at sourceforge are down.

http://superbwest.dl.sf.net/sourceforge/ffdshow-tryout/ffdshow_rev555_20061116_Q.exe

[_xxl]

Try this:
http://switch.dl.sourceforge.net/sourceforge/ffdshow-tryout/ffdshow_rev555_20061116_Q.exe
http://switch.dl.sourceforge.net/sourceforge/ffdshow-tryout/FFdshow-Tryouts-20061116-rev555.exe

[Jeremy Duncan]

Those links work. Thanks. :)

Edit.
http://prdownloads.sourceforge.net/sourceforge/ffdshow-tryout/ffdshow_rev551_20061115_clsid.exe

"Could not read file.

Go back. /home/ftp/pub/sourceforge//s/so/sourceforge/ffdshow-tryout/ffdshow_rev551_20061115_clsid.exe
Nov 16, 2006 10:33"

[LoRd_MuldeR]

you should use rev555, not rev551

[Jeremy Duncan]

you should use rev555, not rev551

I am. drevil_xxl linked to clsid_551 and the link didn't work.

[clsid]

Fresh builds (regular and icl9) are now on sourceforge. Rev557.

[F_L_C]

clsid has rev557 at sf now. I have an Athlon XP 2400 mobile and have always used the generic build because clsid seems to usually update that build first. Should I stick w/ them or use the generic build ICL 9.1 below those?

[LoRd_MuldeR]

Fresh builds (regular and icl9) are now on sourceforge. Rev557.

:thanks:

[Inventive Software]

Any chance of a mammoth SVN changelog? :D

[Egh]

Any chance of a mammoth SVN changelog? :D

what's wrong with http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ? :)

Though actually most of the revisions have very vague description and it's hard to understand w/o looking in the code itself what actually was corrected :)

[Inventive Software]

what's wrong with http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ? :)

Though actually most of the revisions have very vague description and it's hard to understand w/o looking in the code itself what actually was corrected :)

Because I know zilch about SVN, so it's easier for me to ask. ;) I'll bookmark that and keep a sharp eye, so I'll know what's going on.

[Egh]

clsid has rev557 at sf now. I have an Athlon XP 2400 mobile and have always used the generic build because clsid seems to usually update that build first. Should I stick w/ them or use the generic build ICL 9.1 below those?

As a rule you need to test on your particular system what's faster.
Generally speaking the difference is minimal.

Comparison:
(system is 3800+ A64 overclocked to 2.7Ghz, NVidia 7600GS overclocked). Output samples are disabled for the test, colorspace output -- YV12.

Input file -- 1280*720 h264 high-profile, encoded with nearly maximum possible quality settings.

Null renderer performance:

FFDShow from 4th Oct Generic
User: 18s, kernel: 0s, total: 18s, real: 19s, fps: 63.9, dfps: 62.6
ffdshow 557 generic
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 69.3, dfps: 68.3
ffdshow 557 ICL9
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 68.6, dfps: 67.3


VMR9 performance:

FFDShow from 4th Oct Generic
User: 19s, kernel: 1s, total: 20s, real: 23s, fps: 58.4, dfps: 50.0
ffdshow 557 generic
User: 18s, kernel: 1s, total: 19s, real: 22s, fps: 61.7, dfps: 52.8
ffdshow 557 ICL9
User: 17s, kernel: 1s, total: 18s, real: 22s, fps: 63.8, dfps: 52.4


So ffdshow does decode h264 faster now than even a month ago, though actual speed increase is about 5%. Unfortunately still seriously below CoreAVC performance ...

ICL9 here (i.e. on this system, as I told above the results might actually vary on different boxes) not really much faster than generic, in fact ICL9 is somewhat slower.

@ Inventive Software:
Because I know zilch about SVN, so it's easier for me to ask. I'll bookmark that and keep a sharp eye, so I'll know what's going on. Not that I much follow source code itself, but that svn revisions log I bookmarked ages ago :)

[clsid]

The ICL9 build can be useful if you make use of the processing filters in ffdshow. For pure decoding speed it makes no difference as Egh showed.

[SeeMoreDigital]

Wow guys....

I've just installed "ffdshow_rev551_20061115_clsid.exe" and have to say playback of MPEG-4 AVC (even MBAFF and PAFF) is much improved...

Very well done (and nice set-up GUI install clsid) :)


Cheers all

[haruhiko_yamagata]

4) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly. Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).

I think it's implemented properly.
Please set "Gamma correction" 1.50 and see.

[G_M_C]

@ G_M_C: did you perhaps enable any of the "skip deblocking ..." options in ffdshow? Those lower the visual quality (and increase performance).

Nope, my goal is quality and disabling the "inline-beblocking" stuff in H264 would not be wise ;)

But as i said; I'll be starting again this weekend. It might even be something alse on my system that's bugging.

For instance: i've got a DivX 6.x codec dat want to butt in every time I start a XviD. It then gets disabled, and XviD takes over. This is kinda weard, because i'm shure ive uninstalled DivX 6.x a while ago, so there defenately is something wrong. I might even reformat my whole system, and setup all video-stuff again (but i dread that option, because its so much work; Installing everything from DVD-RB to CCE, authoring stuff AC3-tools Soundforge ... just too much to think about :/ )

[haruhiko_yamagata]

7) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
I can't reproduce this.
Please see if it is the same with other DVDs.
If the first track is 2ch and main track is 6ch, 2ch preset setting is loaded.

[foxyshadis]

Suggestion: then maybe it should be removed completely?

BTW, what are other precompiled binaries used in ffdshow for which source is not available?

Anyhow, anyone who needs specifically awarpsharp, can use avisynth filter, which doesn't produce greenline, at least here.

Also, theoretically one can ask the developer for the source code, so reverse engineering is not the only remaining option ^^

MarcFD's long gone, unfortunately, and was never inclined to release his sources at all. That's his choice, but you might be right about removing it. aWarpSharp is the only one, I believe.

That does give me an idea though, to take a few filters out of the main compiling and have a separate project for them, including just .obj if necessary, because dang, they take forever to build. =p The ones that aren't affected by internal ffdshow changes.

G_M_C, do you have any dregs of codec packs on the system? It might be worth getting radlight filter manager (or zoomplayer's or whatever) and check out where that's coming from.

[clsid]

List of known issues in revision 562:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Levels (ylevels, ylevelsG, ylevelsS, ylevelsC) are not implemented correctly? Details about the correct way can be found here (http://forum.doom9.org/showthread.php?p=897854).
3) WM9 decoder passthrough is missing

Reported but unconfirmed bugs:

4) Automatic preset loading doesn't seems to be working with on "number of channel match" and AC3 audio on DVD (don't know if it happens with AC3 audio in MKV, AVI or not or any other audio format). I use "3;4;5;6" in "number of channel match" so this should load with audio track with more than 2 channels but with an AC3 2 channels track this is also loaded. (reported by thuan)
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". I know that at least some of these encoders do work for others. My system specs: Windows 2000, AMD Athlon Thunderbird. (reported by clsid)
6) Resize filter alters colors. Details (http://forum.doom9.org/showthread.php?p=884778#post884778). (reported by Kador)

Other issues:

7) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). Funny thing however is that the files play without crash if you first play a good file and then play a 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)
8) ffdshow is not compatible with CrystalPlayer.

[G_M_C]

[...]

G_M_C, do you have any dregs of codec packs on the system? It might be worth getting radlight filter manager (or zoomplayer's or whatever) and check out where that's coming from.

Dont really remember, but afaik i've allways tried to avoid any form of Codec-Pack, and have installed codecs sererately (as needed). But its very possible I messed up sometime ;)

But thx for the advice; Ill see if Radlight filtermanager produces usefull results. The most recent version is a couple of years old, but it worth a try :)

[F_L_C]

The ICL9 build can be useful if you make use of the processing filters in ffdshow. For pure decoding speed it makes no difference as Egh showed.

I do use the postprocessing, blur&noise reduction (denoise3D), and resize/aspect filters for xvid/divx AVIs. All right, I'll use the ICL9 builds from now on. And thanks for the numbers Egh.

[_ck_]

For some reason both these new builds totally hose my use of ffvdub within virtualdub. I can load the filter but then virtualdub crashes immediate if I try to move through the video at all.

[haruhiko_yamagata]

For some reason both these new builds totally hose my use of ffvdub within virtualdub. I can load the filter but then virtualdub crashes immediate if I try to move through the video at all.
It works for me. I use VirtualDub 1.6.15.