New ffdshow build (?)

[Liisachan]

Yet another flavor :D

ffdshow-20060423_gcc4.1_speed.exe (http://www.paehl.com/open_source/?FFDSHOW)





Hm, I'm just not happy with these SSE and SSE2 builds

I kind of regret updating now. I remember having a build from Feb 6, 2006 ICL9 unicode. Is there somewhere I can get the latest ICL9 build?
That -mt- patch is not for stability. There are many builds recently, I know about 15 builds for rev.2523. What are you looking for. According to celtic_druid, "Infact MSVC8 seems to be the most stable (talking about ffdshow.ax). ICL I guess would be ok for most of the plugins. Then you have an MSVC8/ICL/gcc build though." If what you are looking for is ffdshow-20060203-icc-sse or ffdshow-20060202-icc-sse2 i put them here (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/).

[JarrettH]

The one CLSID posted works pretty good actually.

SVN: 2006-04-20 (rev. 2523)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/18585145/ffdshow-svn2523-20060420.exe.html)

I noticed using Live TV the SSE and SSE2 builds were definitely not as fast as what I had been using and looked a bit more aliased in places. Does ICL9 mean it could have been SSE/SSE2? It didn't specifically say in About ffdshow.

Ah it must have been Feb 3rd then ;)
You are so kind for uploading that for me!!:D

[haruhiko_yamagata]

Thank you very much, bob0r. They works nicely on my computer.
Originally Posted by multiblitz
Same setting with the ffdshow-20060423-gcc4[1].0.3-sse2-mt-x264.nl.exe version:

One CPU at 90-95%, the other at 35-40%; total at 65-75%, so some MT haopens; Stuttering is much worse that in Milan's version of 20051129, every 5 secs.
Hello, multiblitz. I will investigate. This may take several days. Thank you.

[haruhiko_yamagata]

Hello, LoRd_MuldeR.
Originally Posted by LoRd_MuldeR
Question:

Does the MT patch effect multi CPU systems only?
Can I expect any improvements for my single CPU too?
Or could the MT patch even lower performance for a single CPU?
MT patch is not supposed to affect performance on single CPU. You can not expect any improvements for single CPU. MT patch check CPU count (just read from memory) and this is some overload. But this can be ignored.

In regard to bugs, there is room for them. The critical session, m_csReceive, is locked at different timing.

Video is running more fluid, but still not very well. Audio/Video is now in sync, but I get heavy "clicking" sounds all the time. So I'm not sure what is better...

CPU usage with *new* build (single CPU):

Thank you for detailed report.
I have no idea why.
Strange CPU usage curve with up and down. Does that occur on other builds without MT patch?

To investigate this, I would like to know

the application and its version ( and How to get)
how to get Superman trailer
the setting of ffdshow and application.

[haruhiko_yamagata]

I found a multithreading related bug.
It crashes Zoom Player!!

Confession : I have not tested with Zoom Player.

[foxyshadis]

I'm pretty sure the cpu curve is caused by avisynth. When I enable limitedsharpen on mine, cpu usage is ~70%, but occasionally dips to zero for a second or two and freezes, before resuming. Other ffdshow-specific maniplations (such as resize, subtitles, etc) don't show that behavior whether they use 20% or 80% total cpu.

Rawr, vsfilter crashes on here but ffdshow refuses to show the first line of softsubs, so I'm all out of luck for subs. ;_;

[LoRd_MuldeR]

Hello, LoRd_MuldeR.

To investigate this, I would like to know

the application and its version ( and How to get)
how to get Superman trailer
the setting of ffdshow and application.

Thanks for info. But does MT patch do any harm on single CPU or is it just without any effect and I can use the new builds with no risk?

The application is "Media Player Classic" with output set to "VMR7 (Windowed)". This setting seems to give best results on my machine. I use latest build from Celtic Druid. And I have *no* filters enabled in ffdshow at all. Excpet I did some testing with resize-filter: Downsizing to 640x384 (Fast Bi-Linear filter) seems to improve performance a little compared to full resolution of 1920x1088, but of course image quality suffers and it still does not play good...

You can download that trailer right here:
http://jfl1974.free.fr/upload/superman.mp4

[haruhiko_yamagata]

Originally Posted by LoRd_MuldeR
Thanks for info. But does MT patch do any harm on single CPU or is it just without any effect and I can use the new builds with no risk?

There is some risk even if you use single CPU. Just relatively safe.

Thanks for the detail. I'm downloading superman.

[LoRd_MuldeR]

There is some risk even if you use single CPU. Just relatively safe.

Thanks for the detail. I'm downloading superman.

So I hope there will be some new(!) builds *without* MT patch available...

[multiblitz]

It would be great if the most used filters in ffdshow would have separate threads, i my case this would be:

- (maybe de-interlace)
- Denoise 3d in HQ-Mode
- Lanszos Resizing at 4 tap+ and Lanszos Sharpening
- Sharpening with Unsharp-Mask

and this in combination with VMR9+zoomplayer. It would be simply wonderful if MT allows us to have this quality (ideally with limitesharpening / avisynth) in RGB32 at 1080p, which is today totally unfeasible (BTW, my x2 3800 runs at 2450 mhz)

[Egh]

So I hope there will be some new(!) builds *without* MT patch available...

Exactly. Especially taking into account that two new revisions were made to SVN already since 2524.

And kuroshu builds with patches are rather buggy, even casual sse1 build. In my case, for instance, b0b0rs build plays mpeg files ok, but kuroshu build with same settings doesn't do that properly. Both are same revision and both are sse1 only.

So for single CPU systems I would still like to get not patched builds :P

[clsid]

SVN: 2006-04-24 (rev. 2526)
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, mplayer.dll, kerneldeint.dll)
Minimum CPU requirement: MMX
Download: click here (http://rapidshare.de/files/18838575/ffdshow-svn2526-20060424.exe.html)

[Liisachan]

Thanks clsid!!!

@Egh
following the svn version is one thing, experimenting with mt is another. Each has its own value.

[Liisachan]

celtic_druid returns!

ffdshow-rev2526-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2526-SSE2.exe)

[asasadad_1]

clsid's ffdshow build always works well on my machine(especially in libmpeg2).:thanks:

i cann't install celtic_druid's new ffdshow build (when register ffdshow.ax, there is error).

[videomixer9]

the main trick is not using gcc 4.x :O

[celtic_druid]

I used ICL9 for libmpeg2.

Build is unicode and requires SSE2. Other than that it should work.

[LoRd_MuldeR]

I used ICL9 for libmpeg2.

Build is unicode and requires SSE2. Other than that it should work.

Too sad I don't have no SEE2 support :mad:

[celtic_druid]

For about €100 you should be able to get a Sempron 3000+ and a cheap MB. So basically just sacrifice a night of drinking and you can have SSE2. No idea what Sempron's are like at video though esp. socket 754 ones. Probably not worth it.

[asasadad_1]

http://img246.imageshack.us/img246/9563/snap17ca.jpg
yes,my cpu support sse2,xp sp2

[Liisachan]

celtic's one installed on Win2k but doesn't install for me on winxp, with Runtime Error R6034 (http://ffdshow.faireal.net/tmp/r6034.png).

Normal (svn2526 clsid) vs. mt (20060423-sse-mt-x264.nl)

YES! mt does work, more or less. For a testing purpose, I used something I've never used:
- Postprocessing (Presets mplayer)
- Resize to 640x480 to 800x600 Lanczos
And this is what I almost always use:
- output colorspace RGB32, hq conv

Player is MPC celtic_druid Rev 604, VMR-9 Renderless, subpic buffer disabled. Tested on Prescott 3.4 GHz HT enabled, Windows XP SP2

http://ffdshow.faireal.net/tmp/ffdshowmt.png

EDIT: I captured Task Manager at a random time while playing the same file (I should have done that at the exactly same timing but I didn't...) So "Normal" and "mt" can't be compared side by side, but we can roughly conclude that mt is working, i.e. one of the two (shown as the left pane) is nearly equal to 0% with the normal version, but significantly non-zero with the mt version.

[celtic_druid]

Problem with manifest files again. Win2k doesn't care about them so it installs. XP I don't know. I tried with name='Microsoft.VC80.CRT' and it still won't load the runtime library.

[videomixer9]

I WANT TOO BUILD! all the newest freaky stuff, still generic build though... o_O

ffdshow-rv2526.exe: click here (http://rapidshare.de/files/18859754/ffdshow-rv2526.exe.html) or here (http://www.megaupload.com/de/?d=HZDO6OF7)

[LotharZ]

@videomixer9

libmpeg2 no works with your new build, even disabling SSE2.
Running now with your "ffdshow-20060408_msvc8_gcc41_sse" smoothly.

@celtic_druid

And yours cant be installed under Win2003, error with Visual C++ libraries.

[videomixer9]

bummer ... updated links to hopefully fixed version ...

http://www.megaupload.com/de/?d=HZDO6OF7
http://rapidshare.de/files/18859754/ffdshow-rv2526.exe.html

[LotharZ]

Problem solved, everything works perfectly.

thx

[Rash]

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

[Liisachan]

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.
This is going to be reality (http://sourceforge.net/tracker/index.php?func=detail&aid=1468239&group_id=53761&atid=471492). When asked to use the high-quality mode of Tremor, milan replied:


I'd like to leave tremor as it is as fast but not so high-quality
option for those with slower computers and make libavcodec
the default decoder for vorbis.
Do you or others have vorbis samples which aren't decoded
correctly with libavcodec vorbis decoder? I'd like to fix
them if there are any before making libavcodec vorbis
decoder the default.


Would lavc for vorbis decoding be 100% ok already? Afaik, yes, but does anyone know anything?

[celtic_druid]

I made lavc default for my installer. Just a pitty that it only works under win2k due to the manifest/dependancy problem. Now that I think about it I think I had the same problem with 64bit builds under X64.

[clsid]

Decoding audio doesn't use much cpu power in general. So I think high-quality is the best option, even for slow computers.

Btw, is high accuracy equivalent to the 32-bit mode of CoreVorbis?

[Liisachan]

That's what I suggested, but what milan says makes sense too (for really slow CPU). Tremor vs. libavcodec vs. CoreVorbis etc etc...that's a really difficult question, like "Which MP3 decoder is the best?" I have a vague impression that CoreVorbis is the best, but without proof. As for Tremor low vs high, I have a solid ABX proof.

I asked the same question in HA.org and it looks like no one got any problem with lavc.
http://www.hydrogenaudio.org/forums/index.php?showtopic=43983
Only, I was asked "why writing another independent Vorbis decoder in libavcodec, possibly buggy, when there is already proper one delivered by Xiph...?" which I cannot answer for sure. I thought maybe ffmpeg devs needed to make it GPL, not using a BSD-style license of libvorbis...but that's just a random guess. I could say "maybe because they hate xiph" but saying that in HA.org would be a bad idea, i guess.

[Yong]

ffdshow libavcodec-vorbis decoder have problem decoding 6-channels Ogg vorbis file.

[videomixer9]

ffdshow rev. 2527

requires: a CPU, with SSE preferably
compilers: GCC 4.1.1 + MSVC 8
specials: hopefully high accuracy tremor, maybe libavcodec default vorbis decoder
links: here (http://rapidshare.de/files/18909341/ffdshow-rv2527.exe.html) and here (http://www.megaupload.com/de/?d=B69NO8JR)

[Egh]

ffdshow rev. 2527


I downloaded the one from megaupload.


Error while registering ffdshow
Is shown during the installation.

I got Win XP SP2. b0b0r version (svn2523 iirc) is still nice.

I think is it actually installers code problem? :O

[foxyshadis]

Oh right, I need to report a bug in the mt builds. Seeking is screwy - it sometimes works, and sometimes just quits decoding video after the seeked-to frame. Maybe it has to do with landing on the wrong type of frame. It won't even restart at the next I-frame, I waited to make sure. Normal builds always seek just fine.

[Liisachan]

ffdshow libavcodec-vorbis decoder have problem decoding 6-channels Ogg vorbis file. I can't test it since my system is just stereo. Are you sure? and is Tremor OK with that? do you happen to know would libvorbis ok with 6-chan vorbis?

[Liisachan]

I think libavcodec does have problems with 6ch vorbis, and Tremor works better in this case.

Can anyone confirm?
Sample: xvid+6ch_vorbis.ogm (http://ffdshow.faireal.net/tmp/xvid+6ch_vorbis.ogm) 2.5MB

-Edit-
This is what I'm hearing. (channel 1 Front Left)
tremor_FL.wav (http://ffdshow.faireal.net/tmp/tremor_FL.wav) at least decent
lavc_FL.wav (http://ffdshow.faireal.net/tmp/lavc_FL.wav) "bubbly" artifacts

[celtic_druid]

Looks like a problem with the manifest again. Had the same problem with MPC. XP didn't like MSVC8's autogenerated manifest file. Remove it or replace it and it would run. MPC doesn't require Microsoft.VC80.CRT though. Haven't figured that one out yet.

Anyone got a MSVC8 built ffdshow.ax to register?

edit:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="ffdshow.ax" type="win32" />
<description>WindowsExecutable</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>


That works. If you have MSVC2005 you can just open the ax and replace the manifest. External manifests are ignored when registering, so they won't help.

I'll put a new build up later.

[videomixer9]

I downloaded the one from megaupload.

Is shown during the installation.

I got Win XP SP2. b0b0r version (svn2523 iirc) is still nice.

I think is it actually installers code problem? :O

Install VC8 runtime libs! get vcredist_x86.exe from MS site. Last time had the same with people that were all missing the runtime libs.
http://faux.warwickcompsoc.co.uk/vcredist/vcredist_x86.exe

[videomixer9]

ffdshow rev. 2529

requires: a CPU, with SSE preferably
compilers: GCC 4.1.1 + MSVC 8 (ffdshow.ax)
specials: high accuracy tremor
tested: yes, working
links: here (http://rapidshare.de/files/18954480/ffdshow-rv2529.exe.html) or here (http://www.megaupload.com/de/?d=ZVPYYON9) (identical files just other hoster)

needs MSVC8 runtime libs, otherwise fails registering!!!

[LoRd_MuldeR]

ffdshow rev. 2529

requires: a CPU, with SSE preferably
compilers: GCC 4.1.1 + MSVC 8 (ffdshow.ax)
specials: high accuracy tremor
tested: yes, working
links: here (http://rapidshare.de/files/18954480/ffdshow-rv2529.exe.html) or here (http://www.megaupload.com/de/?d=ZVPYYON9) (identical files just other hoster)

needs MSVC8 runtime libs, otherwise fails registering!!!

Here is one problem I found:
If I play WMV content, go to the ffdshow controls and switch to the "Info" page, then MPC just crahes and disappears without error message...

[celtic_druid]

WMV1 is working fine here, including the info page.
I did a SSE build this time to. Although I haven't tested it. Should install fine now though.

[videomixer9]

I don't use ffdshow for WMV usually, especially not WMV3. I have no real clue why it crashes except gcc messing it up. I wouldn't recommend ffdshow for WMV3 in any case though. I'll look into that for the next build, though I need to acquire an WMV video for that first as I usually avoid those. Guess I have to do my own somehow as WMV1/2 is not really used anymore since quite some time, if the crash is produced by WMV3 then I skip on this as WMV3 and ffdshow is stupid game, it works then it maybe doesn't and so on, even depends on the encoding settings and more :O

Another story about these runtime libs for MSVC 2005 (v8), the runtime libs should have external manifests so just getting dlls isn't enough usually.

[Liisachan]

lavc+vorbis6ch=buggy is confirmed by the 3rd party too.
vorbis 6ch = problematic on ffmepg too so probably it's not just ffdshow's pb but the pb is in lavc vorbis.c itself.
Thank you very much Yong, for this critical report :) Without you things might be foobared without knowing that problem.

Anyway celtic_druid's new builds:
- ffdshow-rev2529-SSE.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2529-SSE.exe)
- ffdshow-rev2529-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2529-SSE2.exe)

Let's hope they will install on XP :)

changelog (http://ffdshow.faireal.net/bakaupdates.php)

[LoRd_MuldeR]

WMV1 is working fine here, including the info page.
I did a SSE build this time to. Although I haven't tested it. Should install fine now though.

Approved. Thanks for the SSE build :D

However it still crahes on the "Info" page during WMV playback.
That's not a big problem, because I avoid WMV too.
But sometimes I get WMV files and since ffdshow supports it, why not use it then?
The fewer M$ filters we need, the better :cool:

[Liisachan]

celtic's SSE & SSE2 now both install on XP for me.
that mt patch is not included, or if it is, it's not working for me this time.
no other obvious things so far.

[celtic_druid]

No mt patch in either build. WMV containing what? I only tested WMV1.

Who uses 5.1 vorbis anyway?

[LoRd_MuldeR]

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

I just noticed that it helps a lot to change AAC decoder from "libfaad2" to "realaac". At least the heavy "clicking" sounds are gone and audio is okay now. A/V sync is also pretty much okay. Only video is still stuttering...

[LoRd_MuldeR]

No mt patch in either build. WMV containing what? I only tested WMV1.

WMV3 only I think. Problem is there with *all* WMV3 files I tested. With some WMV1 file I tested there's no problem.

But: The only problem is the "Info" page in ffdshow controls. Playback itself works fine for me...

[thuan]

LoRd_MuldeR you're probably playing a WMV3 file with ffdshow WMV3 codec enable by hand in the registry. I have the same problem when I do it, but then again WMV3 is not offically supported, and if I'm right ffdshow just load Microsoft decoder to do it anyway, so there's no point in enabling it.
BTW it doesn't crash with ffshow WMV3 decode with MPC here just Zoom crashes.

[LoRd_MuldeR]

if I'm right ffdshow just load Microsoft decoder to do it anyway, so there's no point in enabling it.

Oh really ???

[videomixer9]

prolly, the libav decoder for WMV3 is in vc9.c and this doesn't come with ffdshow's version of libav, however it's based on the vc-1 reference decoder afaik and not recommended to be used anyways, hence you're better of using ms filter directly, comes with windows anyways.

[LoRd_MuldeR]

prolly, the libav decoder for WMV3 is in vc9.c and this doesn't come with ffdshow's version of libav, however it's based on the vc-1 reference decoder afaik and not recommended to be used anyways, hence you're better of using ms filter directly, comes with windows anyways.

okay :mad:

[haruhiko_yamagata]

Originally Posted by foxyshadis
Oh right, I need to report a bug in the mt builds. Seeking is screwy - it sometimes works, and sometimes just quits decoding video after the seeked-to frame. Maybe it has to do with landing on the wrong type of frame. It won't even restart at the next I-frame, I waited to make sure. Normal builds always seek just fine.

:thanks: I tested seek bar of MPC and Windows Media Player 10. It worked.
Because Zoom Player crashes without showing any frame,
I think I must test more applications.
Please tell me what application do you use.

I'm trying to debug, though it is hard ^^;

[Egh]

Milan actually started responding to the entries on the ffdshow bugtracker, so I guess some old bugs are going to be corrected soon :approved:

Important info for gcc builders from Milan Cutka:

Date: 2006-04-25 08:54
Sender: milan_cutkaProject Admin
Logged In: YES
user_id=547197

I'm afraid the problems with GCC 4.1.0 aren't caused by ffdshow source code but by GCC 4.1 bug (or at least by build for MinGW). I'm almost certain there is nothing I could do to fix it. I compared assembly output of GCC 4.0 and 4.1 and those generated by GCC 4.1 are missing underscores in mangled symbol names (such as _ZN11CBaseFilter15QueryVendorInfoEPPw) in the parts of code where those symbols should be defined. So for now only GCC 4.0.3 is supported - if you'd find a problem compiling ffdshow using this compiler, report it to me. I promise I'll respond quickly.
I also hope GCC 4.1 gets fixed.

[Liisachan]

Who uses 5.1 vorbis anyway? Not me, but Yong. He/She uses it and that's why he/she could report that. But what's more important is, now its clear that vorbis decoder in LAVC is buggy, and it's possible that the decoding quality for normal 2ch vorbis is not perfect. which matches my vague impression that CoreVorbis is the safest/best DS Vorbis decoder too.

[Egh]

Not me, but Yong. He/She uses it and that's why he/she could report that. But what's more important is, now its clear that vorbis decoder in LAVC is buggy, and it's possible that the decoding quality for normal 2ch vorbis is not perfect. which matches my vague impression that CoreVorbis is the safest/best DS Vorbis decoder too.

AFAIK the 6ch vorbis per se is buggy. I mean that most people do not recommend to use it at all at this moment. Some even promised to correct that and do proper 6ch vorbis... A year ago already :P

[Liisachan]

oh, I see. you mean that fishy org?
um, but then again, BeLight has an option to directly convert AC3 5.1 to Vorbis 5.1, so I guess there are a few ppl who want to do that. I would use AC3 as it is if I needed 5.1 tho. Or maybe AAC? But I don't own 5.1 sound system, so...

[foxyshadis]

5.1 vorbis only isn't recommended because it has no channel coupling logic, so even vorbis backers point people to aac for that right now. There's no quality bugs (with the reference decoder), just that it's a lot larger than it has to be for any given quality.

haruhiko, I'll give wmp a try, but I've been using zoom player and mpc to test with. Also, haali's splitter. I've only done testing with mpeg4 (asp/avc) and mpeg1 so far. But, I can't get it to happen now, after shutting windows down for the night, so I guess it was something else! Weird.

[Shirokuu]

Risking going slightly off topic with the next question, but i have for months - maybe years already - an issue with using FFDSHOW combined with the Haali splitter and TMPEGenc. For some reason it happens with any FFDSHOW build since about a year ago so i guess it's not FFDSHOW related perse. Maybe somebody happens to know a workaround?

When feeding TMPEGEnc a matroska file with multiple audio tracks and one or more subtitles tracks, the subs don't get displayed. FFDSHOW feeds TMPEGenc with video and audio and Haali takes care of parsing the subtitles embedded in the MKV. With regular playback through the core player, BSP or MPC the subs DO appear.

A workaround would be to use MKVExtract to extract the embedded to a SRT file, and using FFDSHOW itself to parse the subtitles from the SRT. Of course TMPEG displays the subtitles this way, but TMPEG becomes instable when converting the MKV to for instance a DVD compliant MPEG2 stream. And on top of that two Haali splitters icons appear in the system tray. Strangely on normal playback using any player of your choice the regular amount of icons appears, namely one.

Both on my regular PC with the old 2004 stable FFDSHOW build, Haali 1.5 and TMPEG 2.0 and on my laptop with the latest FFDSHOW, Haali 1.6 and TMPEG Xpress 3.0 this behaviour occurs.

[celtic_druid]

TMPGEnc's dshow input is somewhat buggy and I believe mkv is officially not supported. So if it works at all, I guess you should be happy.

[Shirokuu]

MKV is indeed not officially supported so i have no real reason to complain of course. But I hoped to get MKV's working by using the VFAPI dshow input ability offered by TMPGEnc. I guess i have to take the long route: splitting a MKV into seperate streams with MKVExtract and feeding TMPGEnc the audio, video and subtitle streams manually through FFDSHOW.

[issa]

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe (http://rapidshare.de/files/19025631/ffdshow-20060426-icc-rev2531-unicode.exe.html)

[foxyshadis]

Shirokuu, you can probably just extract the subtitles and use vsfilter to put them on the movie as hardsubs (at least, I'm pretty sure vfapi allows using vdub plugins on the source, if not, there's always avisynth). No need to separate it all and then try to line it back up again. If you want softsubs, you need them external to convert to vobsubs anyway. (Assuming dvd, not mpeg-1.)

[videomixer9]

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe (http://rapidshare.de/files/19025631/ffdshow-20060426-icc-rev2531-unicode.exe.html)

i did any build in unicode so far, i think it's not even worth mentioning anymore as it is naturally to use unicode if available. Besides that it seems that ICL still does a better job on libmpeg2 e.g. but only marginal sadly. The .ax file seems to be no different with any compiler still hm.

[Liisachan]

5.1 vorbis only isn't recommended because it has no channel coupling logic, I can see your point very well. The audio part of the above sample is like 500Kbps, but the original AC3 is 384kbps, this is totally meaningless except for a testing purpose.
What you mean by "no channel coupling logic" is, it's not taking advantage of channel-correlations, such as in "mid-side coding"? (I'm not sure about those technical terms, but I mean, "does it compress each chan independently when chans are sharing a lot of similar data?")


@Shirokuu
If I have time I'll do more investigating, but I reckon... what you are trying to do is essentially like this?
If so, it's not TMpgEnc, but VSFilter doesn't like it. Maybe. Not 100% sure because this is my 1st time to try 2 connect graph this way.

http://ffdshow.faireal.net/tmp/vs2avimux.png

[Shirokuu]

Liisachan, that IS exactly what I was trying to do. Thanks for trying to reproduce the problem. You would reckon it would make no difference in a real player or in TMPGEnc, but it does. Is there a way around VSFilter that I could try?

[Liisachan]

This is not ffdshow-related, but here's what I would do.

First do this:
mkvinfo in.mkv

check fps, and the track number of sub you want.
...
| + Default duration: 41.708ms (23.976 fps for a video track)
...
| + Track number: 5
...
| + Codec ID: S_TEXT/UTF8
| + Language: eng

now, do this:
mkvextract tracks in.mkv -c WINDOWS-1252 5:WinLatin.srt

-c is for charset. if omitted, the result is UTF-8 (in that case you might need to re-save the .srt in UTF-16 or something)
5 is the track number

Make my.avs which looks like....

LoadPlugin("path\to\VSFilter.dll")
DirectShowSource( "in.mkv", fps=23.976 )
## Or, + AssumeFPS
# DirectShowSource( "in.mkv", fps=23.976 ).AssumeFPS( 24000, 1001, false )
## If upside down do
# FlipVertical()
TextSub( "WinLatin.srt" )

Open my.avs by MPC to check if it's ok. If it's ok, load my.avs to TmpgEnc.
The above won't take more than 1 minute or so.

EDIT: If it's dual-audio, maybe you need to demux the audio to handle it separately. AssumeFPS is technically needed because ((float)23.976) is not equal to = 23976/1000 nor = 24000/1001 in binary. If it's 25.000fps. not needed at all.

[foxyshadis]

I can see your point very well. The audio part of the above sample is like 500Kbps, but the original AC3 is 384kbps, this is totally meaningless except for a testing purpose.
What you mean by "no channel coupling logic" is, it's not taking advantage of channel-correlations, such as in "mid-side coding"? (I'm not sure about those technical terms, but I mean, "does it compress each chan independently when chans are sharing a lot of similar data?")
Yep, that's exactly the problem. 5.1 mixing is more complex than stereo coupling, I understand, but same idea. It's been on the todo list, but I guess no one's been available to do it in a while (most of the development outside aoyumi's tweaks seems to concentrate on speex and theora now).

[videomixer9]

ffdshow rev. 2532

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://rapidshare.de/files/19057679/ffdshow-rev2532.exe.html) or here (http://www.megaupload.com/de/?d=E6EGBBNQ) or here (http://www.filepoint.de/download/2841-dl-ffdshow-rev2532_exe) (no nagging)(2.93 MB)

[namchik]

Wow! It seems that latest SSE2 build by celtic_druid doesn't crash when libmpeg2 used :cool:

[videomixer9]

ffdshow rev. 2533

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://rapidshare.de/files/19084161/ffdshow-rev2533.exe.html) or here (http://www.megaupload.com/de/?d=IZD51S29)

changes: VMR9 color controls

[issa]

SVN 2533 icl 9 with gcc 4.1.1 unicode build,

URL: RapidShare (http://rapidshare.de/files/19102971/ffdshow-rev.2533-20060428-icc.exe.html) or MegaUpload (http://www.megaupload.com/?d=0VVWDA4C) [no sse & sse2 require]
URL: RapidShare (http://rapidshare.de/files/19105309/ffdshow-rev.2533-20060428-icc-intel.exe.html) or MegaUpload (http://www.megaupload.com/?d=QSPWCRAA) [sse2 intel cpu require]

[namchik]

issa
sse2 intel cpu require
is it for intel cpus only? I'm asking coz i have AMD 64...
and does it crash when libmpeg2 is used for decodeing mpeg2?

[issa]

issa

is it for intel cpus only? I'm asking coz i have AMD 64...
and does it crash when libmpeg2 is used for decodeing mpeg2?

Use the [no sse & sse2 require] version, it will use sse & sse2 when you have it.
The [no sse & sse2 require] compiled with CFLAGS "-QaxKW",
the [sse2 intel cpu reqire] compiled with CFLAGS "-QxN" & "-msse2 -mfpmath=sse".

[JarrettH]

SVN Rev. 2531 icc 9 with gcc 4.1.1 build,

unicode build: ffdshow-20060426-icc-rev2531-unicode.exe

thanks...just the stuff i'm looking for:cool:

where can i see the changes between these various builds?

[Liisachan]

Log (http://ffdshow.faireal.net/bakaupdates.php), more (http://svn.sourceforge.net/viewcvs.cgi/ffdshow?rev=2534&sortby=date&view=rev)

[videomixer9]

ffdshow rev. 2534

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, more experimental gcc switches
download: here (http://www.filepoint.de/download/2870-dl-ffdshow-rev2534_exe) or here (http://rapidshare.de/files/19110555/ffdshow-rev2534.exe.html) or here (http://www.megaupload.com/de/?d=MKML8A61)

[Yama4050242]

@issa
your build can not decode the x264 clip i made long time ago, sample here
http://rapidshare.de/files/19117988/sample.rar.html

[videomixer9]

ffdshow rev. 2535 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, more experimental gcc switches
download: here (http://www.filepoint.de/download/2883-dl-ffdshow-20060428-rev2535_exe) or here (http://rapidshare.de/files/19125295/ffdshow-20060428-rev2535.exe.html) or here (http://www.megaupload.com/de/?d=H9P10Z1M)

changes: vertical and horizontal image flipping

[videomixer9]

ffdshow rev. 2536 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, even more experimental gcc switches
download: here (http://www.filepoint.de/download/2895-dl-ffdshow-20060428-rev2536_exe) or here (http://rapidshare.de/files/19132438/ffdshow-20060428-rev2536.exe.html) or here (http://www.megaupload.com/de/?d=GH3BR3ES) or here (http://bittekeinspam.googlepages.com/ffdshow-20060428-rev2536.exe) (2.90 MB)

changes: DeBand filter

[videomixer9]

ffdshow rev. 2537 x64 tryout build
download here (http://www.filepoint.de/download/2938-dl-ffdshow64-20060428-rev2537_exe)

beware ... SLOWWWW! not milans fault, only mine :O

[LoRd_MuldeR]

ffdshow rev. 2536 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, even more experimental gcc switches
download: here (http://www.filepoint.de/download/2895-dl-ffdshow-20060428-rev2536_exe) or here (http://rapidshare.de/files/19132438/ffdshow-20060428-rev2536.exe.html) or here (http://www.megaupload.com/de/?d=GH3BR3ES) (2.90 MB)

changes: DeBand filter

Hey, why you don't make a small Homepage for your builds? Or at least a pure realese therad where the link is always in the first post (like Shartooth's x264 builds)? Would be much nicer, since this way I could permanently link to that thread...

BTW: What does "DeBand" do ???

[videomixer9]

i don't have a real example of banding on my hand, however you can add nice ghost shadows to people on fine videos with it :p It removes vertical bands that some video sources have, it seems to be an error that occurs mostly for analog input sources through interferences or broken cables afaik.

as for a homepage try this one, remembered I could "abuse" google for this:
http://bittekeinspam.googlepages.com/

[Rash]

Please no spam!:thanks: :D

[bob0r]

I could fully automated ffdshow builds, just like x264, as it also uses svn.
But, i think its better you update ffdshow every few days or revisions numbers, even when Milan farts, its added to the SVN.

Just a though, its a free world, but i am not hosting each revision of ffdshow :cool:

[LoRd_MuldeR]

as for a homepage try this one, remembered I could "abuse" google for this:
http://bittekeinspam.googlepages.com/

Looks good :) I'll link to that one!

[Egh]

I could fully automated ffdshow builds, just like x264, as it also uses svn.
But, i think its better you update ffdshow every few days or revisions numbers, even when Milan farts, its added to the SVN.

Just a though, its a free world, but i am not hosting each revision of ffdshow :cool:

But it would be still nice if you did weekly builds :) More than a week passed since your last one... :P

[foxyshadis]

Personally, I'm only updating MT builds, so that alone is why I appreciate bob0r's contribution. ;)

[videomixer9]

ffdshow rev. 2538 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-rev2538.exe)

changes: minor msvc bugfixes by milan, I use this to try some more funny tweaks, this time some for caching.

[videomixer9]

ffdshow rev. 2538 MULTITHREADED VERSION

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-mt-rev2538.exe)

the patch is note exactly made for this revision so it's a unknown to me if it works.

[LoRd_MuldeR]

ffdshow rev. 2538 MULTITHREADED VERSION

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-mt-rev2538.exe)

the patch is note exactly made for this revision so it's a unknown to me if it works.

Seems to works here without problems. No Multi-CPU though...

[videomixer9]

means you got no Dual-Core processor? well okay i don't have one either and the build works for me too, just wonder if it really does it's work on dualcores. Patching app threw some errors but seemed to have applied most things except for the outdated patching of .nsis2 file.

One reason I don't like external patches is that they tend to not fit anymore with even some trivial code changes here and there and need extra updates. I seriously hope milan does something about this soon.

[foxyshadis]

Well, I don't have time to in-depth test it now, but it works fine during normal viewing, no crashing and burning or anything.

[haruhiko_yamagata]

I seriously hope milan does something about this soon.

Thank you very much. But I think I have to fix at least the major bug with Zoom Player(maybe concern to other applications) before accepted.

[MatMaul]

ffdshow rev. 2538 (unicode as always)

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060429-rev2538.exe)

changes: minor msvc bugfixes by milan, I use this to try some more funny tweaks, this time some for caching.

Can you also activate high accuracy for libmad please ?
You can find the diff patch for activate accuracy mode for libmad here (http://kurosu.free.fr/ffdshow-update.tar.bz2) (made by kurosu (http://kurosu.free.fr/ffdshow)).

[videomixer9]

indeed, seems like this patch vanished after I had it applied and fiddled around a bit. Doing a new build now with 2539 revision and libmad patched too. The multithreading seems to give no harm in performance on single cpu so I'll keep it, if anyone thinks this isn't the case inform me please. As for a bug with ZoomPlayer ... dunno about that but it seems to work fine here as far as I can see, if anyone gets errors with this patch I'll also do an patchless version.

ffdshow rev. 2539

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, multithreading by haruhiko_yamagata
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060430-mt-rev2539.exe)

Also I did a real test with a multithreaded and a non-multithreaded version on my Athlon XP 3000+ with a regular MPEG4 video.

ffdshow MT
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4
ffdshow non-MT
User: 90s, kernel: 0s, total: 90s, real: 96s, fps: 374.5, dfps: 350.0

it seems that it also gain a bit of performance with single CPU systems. Repeated this a few times and it always ended up similar.

[MatMaul]

coool thanks

[MatMaul]

I have a problem with your multithreaded buids : when I play a video (I don't know if it appears with all my videos, I have test with only 2 videos) and I navigate on the video in MPC, after 5-6 seeking I obtain an error :

http://www.mezimages.com/image/matmaul/miniature/mini_error.PNG (http://www.mezimages.com/agrandir_membre.php?na=matmaul&fi=/error.PNG)

I obtain this error with your 2 last mt buids (fdshow-20060430-mt-rev2539.exe and ffdshow-20060429-mt-rev2538.exe) but I don't have any problems with your last non-mt build (ffdshow-20060429-rev2538.exe)

[videomixer9]

your cpu type, os and mpc version and evtl. haali version would be interesting. So far I didn't hear from anyone else of problems with the mt patch with single core, so I'm kinda curious and maybe it also has something in common with those ZP crashes haruhiko reported before. I'll build another version without the mt patch. Also interesting would be if the problem also occures with bobors mt builds.

ffdshow rev. 2539

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060430-rev2539.exe)

[MatMaul]

Pentium M Dothan
Windows XP SP2
MPC 6.4.9.0 FR
I use internal MPC Splitter for the problematics videos (avi files).

I test mt bobor build and I report.

[clsid]

For those who might want to do some benchmarking on the different builds, Haali's TimeCodec (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool is quite useful. (you also need to install Haali Media Splitter)

[MatMaul]

same problem with ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe and ffdshow-20060423-gcc4.0.3-sse2-mt-x264.nl.exe
no problem with ffdshow-20060420-gcc4.0.3-sse2-x264.nl.exe

[videomixer9]

Hm tested with skipping around a bit with gabest avi splitter with the rev604 mpc by celtic_druid and couldn't reproduce the problem. Maybe I try the older "stable" release of MPC. Otherwise this is a myth to me, might be a fault that only occurs on Pentium M or only your specific config, odd how multithreading does this as it's a quite common technique in any software so it must be a specific error with this one ...

[MatMaul]

My problem isn't reproducible for me too...
It does not appear all the time, I must restart the video 3-4 times and a lot of seek to reproduce the problem.
The problem appears often after a change in the ffdshow configuration when a movie is launched, ever when I seek.

I can't reproduce the problem in ZP and WMP.

[videomixer9]

Ah ... hm ... I had such problems in the past with anything in MPC, I dunno why it appears but in randomly appears sometimes in MPC and then doesn't. Also I happen to have random crashes with MPC while watching DVDs when I select something in the menu. So it looks like it's actually something with MPC if it's not reproducable with ZP and WMP ... :/

[MatMaul]

I think the problem is MPC+mt build, because I have no problem with your build ffdshow-20060430-rev2539.exe

[videomixer9]

well I guess the way the filters are loaded they'll belong to the MPC process and there might be an interference with the threads of MPC itself, or maybe only with the french trans of MPC *hehehe* however as I cannot reproduce the problem I cannot do any further debugging of it so it'll be upto haruhiko, milan or gabest.

[MatMaul]

same problem with MPC 6.4.9.0 EN and MPC rev604

[videomixer9]

okay I reproduced an error when I turn on one of the filters in ffdshow I never use usually :p MPC crashed then with the MT build, the other one didn't. Playback or search didn't crash except the usual thing if you manage to search a file to a dozen places within a second it always got overworked, at sane search speed never a problem, so seeking in a file I dunno about.

The problem with the filter occurs on any player though. Seems to be a problem with the mt code though.

To reproduce it e.g. enable Resize & Aspect Filter in ffdshow controls while the video plays, then dechecked it right after you enabled it and it will crash. This is something haruhiko_yamagata has to check up on. Doesn't seem to happen with any video neccessarily so you might have to try several. Also notice some of the settings for this filter section are still applied without the filter being enabled.

Seems like the MT doesn't like size changes of video that much. Nothing wrong with seeking still.

Nothing wrong with seeking still. Besides I wonder why someone would seek around like mad and change ffdshow config all the time. o_O Also does it happen only with special filters enabled or e.g. postprocessor or swscaler on or with anything? I usually don't use any filters as postprocessor is crappy, the rest of the filters for sucky video that i have none of and my graphic card upscale perfectly fine. So I wouldn't have notice any errors with them without any report.

So my current guess is you fiddle around with resize & aspect filters ...

[foxyshadis]

Ah, this could explain why I experienced seeking problems of my own (audio would play but not video), but no crashes or permanent hangs, while using resize filter. Thanks for testing, I know I'm not insane now!

[videomixer9]

haruhiko changed the resizing part of libmplayer that ffdshow uses. The other part that was changed is in the .ax file itself. It may be possible that the .ax file still sends a picture to the video renderer in the resolution before it was changed, but propagates another resolution already which gets the player confused and either hang up the video renderer or crash the player. Just a wild guess. However the resizing was one major point for haruhiko (should I use -san or -kun to be not that rude? :p) to do this so this is bit annoying.

However, it doesn't neccessarily happen all the time, plenty of times nothing wrong happens here.

[Egh]

I havent' been using MT version on a single AthlonXP cpu for much time so far, but I pretty much *always* use ffdshow lanczos resizing and I didn't experience any seeking or crashing problems. I have last CD's build of MPC.

Suggestion: try to play with output options. E.G. I always use forced RGB32 output. Maybe problems are with other settings?

[Liisachan]

@videomixer9
lol, -kun is a no-no. That'd make you sound his/her boss. If you'd like to add a honorific, -san would be always gender-neutral and safer. OR: haru or haru-chan, like Alex for Alexandra

Seeking like a mad is not practical but could be a good way to find a hidden bug. Enabling/disabling the resizing filter while playing the video is a bit too much, but basically the same thing.

[Liisachan]

@videomixer9
You changed the filename rev2539-2.exe to rev2539.exe? Could you please try not to change the URL unless really needed? As I sometimes re-post the link to another place...

PS what I said about -kun might be wrong. but I can tell for sure that generally -san is much safer.

[multiblitz]

Has anyone an explanation why the NON-Milan-builds (comparing for example Milan's 20051129-version with the latest MT-version) need in sum more CPU-Power for the same thing ? As I use a X2 3800 at 2450 mhz, could it be that the AMD-optimization is missing (read somewhere that most people use the Intel-compilers which make INtel-CPUs look better)?

[videomixer9]

Did you do a real test or just watch taskmanager for a bit, try to test it with timeCodec e.g. Since the last milan build there were I think two changes with libavcodec and both should've improved mpeg4 performance really. Most people btw. don't use Intel compiler, bobor doesn't use it, kurosu doesn't use, clsid didn't use it on his last build, I don't either, only issa did.

Intel Compiler can automatically adjust optimizations and if you don't patch it ICL8/9 have a GenuineIntel check, if that one fails, does on AMD CPUs e.g., then it uses a generic tree that runs on any CPU.

-kun is more a friendly you, while -san is a more distanced you (german I'd make it Du vs. Sie), If he'd be my master I could call him -sama or -dono while -dono sounds more like he's a samurai even though it's still okay to use nowadays, or I could call him -sensei but I'm not his pupil in anything and he's not a doctor either :p (ah the joy of watching anime and japanese drama for too long)

Btw. the resizing problem didn't occur now while testing that much, seems to apply only to certain videos. I didn't find any pattern in those yet though.

Sorry for the re-renaming, but I did that cause I had it linked elsewhere already too where I couldn't edit the link afterwards.

[Liisachan]

Well, in anime, the background is often young people's school life, in that case what you said is roughly true, altho it depends on many other things--both your age/gender and the age/gender of the person you speak to matter. Believe me, at least in forums or mailing lists in Japanese language, you'd use -san (or sometimes -shi) in a situation like this.

[haruhiko_yamagata]

So far I didn't hear from anyone else of problems with the mt patch with single core, so I'm kinda curious and maybe it also has something in common with those ZP crashes haruhiko reported before.
Yes, my wishful thinking is that some of the symptoms reported have same cause as you pointed. I can't reproduce seeking problem till now. And I hope that is fixed when I have fixed the bug with Zoom Player. I'm working on Zoom Player though it has not been progressing over the past few days.

However the resizing was one major point for haruhiko
This is just an aside.
Three months ago, when I started to work around ffdshow, I just wanted to see upscaled DVD without frame drops. First I thought multithreading of swscaler would make this come true. I implemented it to see a result just bit better.
Next I checked what was most time consuming and found video renderer was. Though video renderer was out of ffdshow, I guessed calling it on other thread would do multithreading. So I changed ffdshow.ax.
The result was satisfactory, but I needed more than three CPU. Against my will, I had to keep the lid on mt of swscaler. On dual-core system mt of swscaler is not used frequently.
I don't think mt of swscaler is not much buggy. I guess most bugs are related to mt of ffdshow.ax

should I use -san or -kun to be not that rude?
I read good talk of you and Liisachan with :D . Anyway I don't need any honorific. Just call me haruhiko. That sounds nice.

[haruhiko_yamagata]

I have a problem with your multithreaded buids : when I play a video (I don't know if it appears with all my videos, I have test with only 2 videos) and I navigate on the video in MPC, after 5-6 seeking I obtain an error :

Now I confirmed seek problem with MPC and mt, though it doesn't crash. Video is not updating for seconds after seek. I'll try to debug. Thank you.

[foxyshadis]

Just curious, but is there any benefit to multithreading other areas of ffdshow, such as decoding or avisynth? I'm sure avisynth could benefit when enabled, it usually makes things slooooow. ;) I guess making every filter a thread would lead to lots of unnecessary memory copies, though.

Glad to have it now, though, it works great 99% of the time. Good luck, debugging threads is pretty tricky.

[videomixer9]

libavcodec already does multithreaded encoding, also with ffdshow. I think that patching libavcodec for multithreaded decoding would be the easiest. libavcodec has the capabilities as it e.g. can already multithread mpeg1/2 decoding.

Via ffdshow you can also already make libavcodec spawn several threads but it doesn't use them yet for decoding work and I think it's still a bit tricky to do this properly considering you have to interact with all the different frame types to decode. I guess milan will wait for ffmpeg people to implement this, all he has to do then is to set the amount of threads via a libav call like it already does for mpeg1/2, that's a one line patch :O.

[dk75]

I've had ZoomPlayer crashed with ffdshow MT bobors mod when used resizing filter. It's always when doing settings in ffdshow while playing or when closing ZP down while playing.
Thought i've never used resizing filter before so i can't compare it to nonMT version of ffdshow.

[dk75]

ups! forget to mention that i have AthlonXP only so not a HT or MT capable machine.
But, this MT ffdshow was only newest bobor compilation avilable, so no choice.

[zilexa]

zilexa, it doesn't define what hand-optimizations are used; those still go through a cpu-checking process and use whatever you have no matter what build you run. (..)

ok so if I understand correctly, just to be sure, I could even use the Athlon64 build from http://kurosu.free.fr/ffdshow for all Athlon processors (XP and 64) and even Pentium processors (but for Prescott it would lack support for SSE3)?
I made an unattended Windows OEM cd with ffdshow ofcourse, I install it on several PC's with Pentium and AMD cpu's. Thats why I ask..

[videomixer9]

SSE3 optimizations were just recently added to ffmpeg and aren't in ffdshow yet, the rest of the code should be also free of any SSE3 optimizations. Only problem that might appear with builds for SSE3 is that by some miracles gcc did some working autovectorizations for SSE3 or replaced calls to SSE units with ones specific to SSE3. I don't remember if SSE3 even had some register call changes compared to SSE2 but iirc SSE3 is merely a plain slight performance upgrade to SSE2.

SSE2 builds would probably crash on regular Athlon/Athlon XP and non-SSE2 Pentium as there are actual changes in SSE2 to SSE and there is actually some code that will automatically assume presence of SSE2 if set at compile time. That's mostly what the specific optimized versions do, they override checks and automatically assume the presence of a certain instruction set. This saves you some comparisions at runtime, but those are really minor though e.g. mplayer team recommends setting optimizations while compiling already either. A problem in the past with this often occured with ffdshow or VLC e.g. in the past, often with liba52 and libdts that had SSE2 switches enabled at compiletime and assumed it's presence.

The only proper autovectorization that makes stuff really require a certain instruction set are the builds done with ICL, however ICL can also do those with a runtime detection enabled if you specify all supported instructions sets at compile time, e.g. /QaxNWPKB. The binaries will be larger but run on any CPU, you can of course favor smaller size and recompile for each processor type.

GCC devs are working on autovectorization, but it is buggy, and I think that kurosu also dropped using it. Checking the notes GCC outputs with -ftree-vectorizer-verbose enabled you can also see that GCC still doesn't even nearly optimize as much as ICL does. For the decoding part all this doesn't matter much anyways, only matters for the performance of some filters (not the colorspace conversions either cause those are in libmplayer and handoptimized too and with runtime cpu detection).

[dk75]

whoa... i've had this infamous "can't register ffdshow.ax" error during instalation.
On both videomixer9 GCC 4.1.1 and Paehl GCC 4.1.0 versions.
So, it's time to comeback to bob0r's GCC 4.0.3 - but it's only SVN2524... :(

[kurt]

@dk75: did you try it again after a restart? sometimes I get the same error...

[videomixer9]

seems people don't want to read, it needs MSVC8 runtime libs!

http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en

If it's not that then I have no idea except for lack of user rights which isn't usually the case as most bakas work as admins all the time. If ffdshow.ax is already used it cannot overwrite it and fails at that stage already. Just try and register it by hand and it'll prolly throw a more useful error message at you.

[Egh]

If it's not that then I have no idea except for lack of user rights which isn't usually the case as most bakas work as admins all the time. If ffdshow.ax is already used it cannot overwrite it and fails at that stage already. Just try and register it by hand and it'll prolly throw a more useful error message at you.

If it says "Fail to register" then it's lack of dlls. If the ffdshow.ax is still used (b0rked videoplayer copy in memory e.t.c.) then the message is different (with classical "Abort, Retry, Ignore"). In the latter case kill all remaining videoplayer copies in memory if there're any, and then if still not working, kill explorer.exe :P That usually helps.

[haruhiko_yamagata]

I'm almost dead lock in my debug^^; I'm doing this for diversion.

Okay, did some testing with that "super high resolution" Superman trailer (x264). With the previous ffdshow build the video was stutterting extremely. Sometimes no new frame for several seconds. And audio/video was completely out of sync.
I can't explain why, but milan's ffdshow-20051115.exe is best to play Superman trailer on my PC. AFAIK any newer version is not as good as 1115 to see Superman.

Dammit! The superman trailer pwned my computer! It is an Athlon 64 3200+ with a GeForce 6800GT. Where are you guys running this video?

Do you mean you can't see Superman? Some version(s) of MPC fails. I update MPC to see Superman.

[videomixer9]

If it says "Fail to register" then it's lack of dlls. If the ffdshow.ax is still used (b0rked videoplayer copy in memory e.t.c.) then the message is different (with classical "Abort, Retry, Ignore"). In the latter case kill all remaining videoplayer copies in memory if there're any, and then if still not working, kill explorer.exe :P That usually helps.

I explained exactly that and then you explain it to me ... very clever. You call it lack of dlls and I specified which dlls aren't present ... duh. I also explained that if the ffdshow.ax is already in use that it will fail overwriting but not registering. Am I that hard to understand? bleh.

[issa]

Rev 2539 Build,

Compiler: GCC 4.1.1 only
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/19499233/ffdshow-2539-gcc-sse2-20060603.exe.html) or MegaUpload (http://www.megaupload.com/?d=8YYJAQ42)

Compiler: GCC 4.1.1 only
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/19499670/ffdshow-2539-gcc-sse-20060603.exe.html) or MegaUpload (http://www.megaupload.com/?d=XNT4YYYH)

Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19504995/ffdshow-2539-icc-sse-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=VMDHTWKL)

Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE2 (Intel CPU only)
Download: RapidShare (http://rapidshare.de/files/19504656/ffdshow-2539-icc-intel-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=JZT2D77K)

[videomixer9]

I wonder when Intel will finally release ICL 9.1 (which was announced for end of april) as the current one doesn't integrate into MSVC 2005 and milan changed all the makefiles to 64bit compilation for ICL already and you have to clean that out. And newest Platform SDK doesn't work too well with it either.

Btw. that Superman trailer runs better on current ffdshow here, the h264 part was a bit improved since then ... however still to slow so I stick to CoreAVC for h264.

[breez]

Rev 2539 Build,
Compiler: ICC 9.0.30 (msvcr 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19504995/ffdshow-2539-icc-sse-20060503.exe.html) or MegaUpload (http://www.megaupload.com/?d=VMDHTWKL)

Any ideas how to get this build working? I get 'exception occured while trying to run "ffdshow.ax,configure"' message when trying to open config dialog (it installed fine).

This http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en is installed. Windows XP SP2. Athlon XP.

[dillee1]

Tested videomixer9's mt-rev2539 with some hdtv mpeg2 and mpeg4 clip on a dual p3 1G.
Graphedit never reports more than 54% CPU usage. No difference in compare with single threaded builds. Btw vlc use ~95% CPU when playing those clips.

[videomixer9]

set the number of threads to two in the ffdshow configuration, actually mpeg2 decoding is multithreaded since ages.

[dk75]

@dk75: did you try it again after a restart? sometimes I get the same error...
Yes, feew times. It's always refused to install. After one of this i've instantly installed bob0r 2523 GCC4.0.3 version without problems.

[haruhiko_yamagata]

Btw. that Superman trailer runs better on current ffdshow here, the h264 part was a bit improved since then ... however still to slow so I stick to CoreAVC for h264.

Ok, current ffdshow runs better on faster machines. On my P4HT/G450, 1115 is better. I've tested current version on Athlon 64 x2 4400+, it's OK.
I know milan is working very hard on h264, I didn't like to say that. and in practice P4HT/G450 is too slow to enjoy HD movie whatever the version is. But I'm just curious about the strange CPU usage curve. It appears after 1115.

[haruhiko_yamagata]

bug fix: Crash on default setting of Zoom Player, old
renderer of MPC, etc.

Certain video renderer cannot run on child thread. It
includes the default renderer of Windows 2000 or older,
the default of Zoom Player(Overlay Mixer, Standard
Renderer), "Old Renderer" of MPC, etc. In this case,
multithreading around video renderer is avoided and Resize
is processed on multithread.

knouwn bug: Seek problem is not fixed yet. Mainly on DX50?
It sometimes crashes after seek.

http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

Ok, current ffdshow runs better on faster machines. On my P4HT/G450, 1115 is better. I've tested current version on Athlon 64 x2 4400+, it's OK.
I know milan is working very hard on h264, I didn't like to say that. and in practice P4HT/G450 is too slow to enjoy HD movie whatever the version is. But I'm just curious about the strange CPU usage curve. It appears after 1115.

milan doesn't work at all on h264 as milan isn't affiliated with ffmpeg project afaik. decoders are just taken from the ffmpeg project, that's why multithreading in ffdshow itself may even be the wrong attempt, as I said before libavcodec is already prepared for multithreading as e.g. it can do so for mpeg1/2 already since quite some time, MPEG4 and others are missing but libavcodec has interfaces to set amount of threads. On the encoding part MPEG4/h264 should also have multithreading support already though. The strange behaviours are prolly cause of changes to framedropping so the audio/video sync isn't lost.

The video renderer is just something ffdshow connects to and which must be multithreaded by MS, to take off load for HD playback it's needed to multithread the decoding process itself, which is a bit more complicated, but is doable as CoreAVC/Ateme and other decoders show.

Also consider the video memory needed and acceleration features, a G450 might have problems keeping up to the rest of your PC and HD video renderers, and if you're trying with VMR9 it's hopeless anyways on that card I'd say.

[haruhiko_yamagata]

decoders are just taken from the ffmpeg project, that's why multithreading in ffdshow itself may even be the wrong attempt, as I said before libavcodec is already prepared for multithreading as e.g. it can do so for mpeg1/2 already since quite some time, MPEG4 and others are missing but libavcodec has interfaces to set amount of threads.
Yes, my way of multithreading conflicts multithreading of decoders on dual core CPU. So let's hope we'll have multi-core CPU. I should add dialog for setting. Then user can select which way of multithreading.

The video renderer is just something ffdshow connects to and which must be multithreaded by MS, to take off load for HD playback it's needed to multithread the decoding process itself, which is a bit more complicated, but is doable as CoreAVC/Ateme and other decoders show.

I mentioned the Superman trailer, but my main purpose is to see upscaled DVD. In this setting decoding DVD doesn't take CPU time long.
The video renderer depends much on video card, so I doubt if multithreading of video renderer would be effective.
There are many scenarios. Heavy decoder+light renderer, the opposite, etc. Best way of multithreading differ case by case.

Also consider the video memory needed and acceleration features, a G450 might have problems keeping up to the rest of your PC and HD video renderers, and if you're trying with VMR9 it's hopeless anyways on that card I'd say.

G450 is for developing environment. I see movie with Athlon 64 x2 4400+/Radeon 9600XT. 9600XT is a bit out of date, so it needs help of multithreading. No frame drop with Superman trailer.

[videomixer9]

And I'll keep wondering why people are so hot for software resizers when their video hardware has inbuilt resizing that works pretty well most of the time while preserving most details.

The problem with multithreading just a specific filter is that the filter has to wait for the decoder to do it's work, and then kick in when decoding is already done. Problem with this is that your workload is spread unequally if you just throw random work at some threads and reuse them immediatly after they are done with their work, there is a real high chance then that only one thread is doing most of the work, as the video decoder is decoding for realtime playback and doesn't deliver content as fast as the filter could do it's work. Without specific CPU selection it can now happen that the free other core we have doesn't get much of the work as the threads are more probable to land on the processing list for the first core again, as the decoder won't start with the next frame before the filter is done. Of course this also has to do with the OS handling it.

From my peeks at your code it seems that just a random thread is generated and executed on a CPU the OS decides it should use. It should be like that you create a worker thread per CPU that you assign to a specific core and then spread the work that should be done to those worker threads equally, or even better by checking the status of those threads and assign the one on the lesser used core to more work.

This doesn't solve the issue that you still only get video data from an upstream that gives you only frame per frame as it's supposed to be outputted to a video renderer, to be more effective you'd need to get the decoder to do work ahead of time and still keep audio sync. You could then resize a few frames ahead and spread the workload more effective.

As ffdshow is currently, I think that it waits with decoding the next frame till the one before actually wandered all the way to the videorenderer. The frame gets decoded, after that the CPU is all free for filtering, then the next frame is decoder and filtered and so on. As you see there is a timegap the decoder could already decode a new frame while resizing is done and another thread could resize the this frame already just to throw it at the videorenderer right after the one before.

Problem is, decoder and filters need to properly sync on this work.

As for dillee1, VLC should have multithreaded decoding hacked around the codecs, so this should explain why MT is effective while these multithread patches by haruhiko are just really interesting for resize filter users.

btw. added 2541 compile that has Aud-X support, dunno if anybody really uses that, forgot to add the dll to the installer, maybe next time ...

milan official added the patch by haruhiko, new build coming soon.

[haruhiko_yamagata]

Well, it's ideal, but too difficult for me. To make things compact so that I can be responsible for it is important, I think.

[videomixer9]

ffdshow rev. 2544

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060504-rev2544.exe)

Multithreading patch by Haruhiko Yamagata is now officially part of ffdshow. Also new is Aud-X support, audxlib.dll comes with installer, get sure to read the license here (http://bittekeinspam.googlepages.com/AudX_licence.pdf).

[issa]

Any ideas how to get this build working? I get 'exception occured while trying to run "ffdshow.ax,configure"' message when trying to open config dialog (it installed fine).

This http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en is installed. Windows XP SP2. Athlon XP.

I try it on my notebook, it didn't crash... I will recheck the build and upload the build again.

[clsid]

I get a crash whenever I try to change the resizing settings during playback :(
If I pause first, then the crash will occur immediately after playback is resumed.
It happens 9/10 times.

(rev 2544)

[videomixer9]

oddly that's what happened for me earlier too, however it suddenly just disappeared as a problem. All I remember doing inbetween was uninstalling ffdshow and reset settings to default ... not that it sounds like that's related.

[LoRd_MuldeR]

Here it *sometimes* crashes when I switch from "Specify aspect ratio" to "Specify size" during playback. MPC just closes without error message. Keeping at "Specify size" and typing in different sizes, it will work okay and no problem at all. (Latest Videomixer build).

[dillee1]

Tried 2 thread setting with mpeg2 clip. CPU usage goes to ~60% (1 thread = 54%). More threads don't further increase CPU usage. mpeg4 doesn't seems to be affected by MT at all.

"VLC should have multithreaded decoding hacked around the codecs, so this should explain why MT is effective"

vlc doesn't use directshow at all, so it is not restricted by frame-per-frame architecture in directshow. It might schedule a whole gop to each worker thread if it wish. It's can communicate internally to sync A/V as well.

"while these multithread patches by haruhiko are just really interesting for resize filter users."
10% speedup is better than nothing:-)

[clsid]

resize crashes are been fixed in latest revision

[haruhiko_yamagata]

resize crashes are been fixed in latest revision
Not only comminting the patch, he added dialog for setting and fixed my bug. Thank you, milan!

[foxyshadis]

So basically ffdshow needs to be re-engineered to do multithreading all the way through, presumably by pre-buffering several frames of audio or video data (which can decide how to best parallelize that part), decoupling the filtering engine from the decoding engine and feeding into a worker thread per core like vm9 says, then having a pool at the renderer that ensures frame order and timing are correct. Shouldn't be too hard... for server engineers. ;) I wish I knew more about implementing threading, I'd love to work on it. I'm curious how much of that structure is already done.

Until then, having portions of it multithreaded is still better than nothing, though.

[issa]

Rev. 2545 build,

Compiler ICC 9.0.30 (msvcrt 8 included) + GCC 4.1.1
CPU extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19652727/ffdshow-2545-icc-sse-20060505.exe.html) or MegaUpload (http://www.megaupload.com/?d=5537E1BA)

How many people still want to try pure GCC 4.1.1 build?

[videomixer9]

So basically ffdshow needs to be re-engineered to do multithreading all the way through, presumably by pre-buffering several frames of audio or video data (which can decide how to best parallelize that part), decoupling the filtering engine from the decoding engine and feeding into a worker thread per core like vm9 says, then having a pool at the renderer that ensures frame order and timing are correct. Shouldn't be too hard... for server engineers. ;) I wish I knew more about implementing threading, I'd love to work on it. I'm curious how much of that structure is already done.

Until then, having portions of it multithreaded is still better than nothing, though.

ffmpeg will add MPEG4 and other multithreaded for sure. Then ffdshow can just set an amount of threads to be used for decoding and libavcodec will do effective video decoding multithreading. ffdshow's filtering is another case, but most filters aren't that cpu heavy anyways, and for some the original devs will prolly also do something about it.

[foxyshadis]

I'm beginning to think people are intentionally agitating videomixer.... You could just read the last page.

http://forum.doom9.org/showthread.php?p=822612#post822612

[MatMaul]

Same problem (crash of MPC after seeking) with rev 2544.
I stay on rev 2539.

[videomixer9]

there is this nifty insurgent thing on the CCCP website, maybe try that and post the results of the log somewhere. If that problem is persistent than it may have to do with something else on your system that conflicts with MPC and ffdshow ...

http://www.cccp-project.net/downloadi.php

you can post result on nopaste.info or similar for better overview.

ffdshow rev. 2546

requires: SSE
compilers: GCC 4.1.1 + MSVC 8
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060509-rev2546.exe)

changes: edge emulation for deBand - works only when processing full frame

[MatMaul]

I don't think it's a filter problem because when I render the file with mpc the filter chain seems to be normal :
AVI MPC source -> ffdshow MPEG4 decoder -> video renderer

log file of CCCP (http://www.nopaste.info/index.php)

[MatMaul]

The uninstaller doesn't remove audxlib.def and audxlib.dll.

[asasadad_1]

lpcm decoding crashes in ffdshow rev. 2546(by videomixer9)

[videomixer9]

hehe is there any directshow filter available you didn't install? :O Well if the filters used are really only those. There are some evil things in that list but they usually don't interfere with avi playback. Btw. are those crashes really produced by video rendering? Try to disable sound output and seek around, dunno which audio filters you use but they may also be the culprit.

did lpcm still work in 2545, if yes then I wonder how it got broken ... need to check that but don't have any lpcm ... guess I try search the forum for some sample.

Ah dammit forget to add the delete command in the uninstall section, thx MatMaul. reuploaded the version with hopefully fixed uninstalling.

[MatMaul]

if it's an audio problem, ffdshow is also the problem because it decode the audio of those files with ffdshow :p
I have removed the audio of a file and same problem......
I think it's a problem of the couple ffdshow mt patch-MPC...

EDIT : same crash with last rev of mpc (rev609 compiled by CelticDruid)

[asasadad_1]

hehe is there any directshow filter available you didn't install? :O Well if the filters used are really only those. There are some evil things in that list but they usually don't interfere with avi playback. Btw. are those crashes really produced by video rendering? Try to disable sound output and seek around, dunno which audio filters you use but they may also be the culprit.

did lpcm still work in 2545, if yes then I wonder how it got broken ... need to check that but don't have any lpcm ... guess I try search the forum for some sample.

Ah dammit forget to add the delete command in the uninstall section, thx MatMaul
here is a sample:http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/lpcm.vob

[LoRd_MuldeR]

here is a sample:http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/lpcm.vob

I can reproduce the problem with that sample. If I enaable LPCM support in ffdshow I get only noise. Otherwise it's fine...

[videomixer9]

hm I tried an example from here:
http://forum.doom9.org/showthread.php?p=603581#post603581

and it works fine. o_O that mplayer sample I only get noise too.

[MatMaul]

anyone have a pentium M dothan and can try to reproduce my bug ?

[asasadad_1]

hm I tried an example from here:
http://forum.doom9.org/showthread.php?p=603581#post603581

and it works fine. o_O that mplayer sample I only get noise too.
that mplayer sample is ok via ffdshow-rv2526 by you:)

[videomixer9]

lpcm doesn't work with issa build either here, though it either constantly peeps or you hear nothing, there were several changes since that revision on the file decoding lpcm. milan might have broke it unintentionally. From looking a bit around ... could it be 64bit CPU users don't have this problem? are you guys using 64bit CPUs, I'm not. Just an idea I got from the code changes ...

Other than that, it first appears as a problem in rev2544 for me ... I didn't do 42 and 43 builds. Inbetween there was some quicktime audio stuff added that changed some audio decoding stuff, I guess I'll try and revert those files affect in that patch and try if the error still occurs.

May also be related to floating point code generation ...

edit: the sample is 24bit lpcm? older builds says so, newest one only detects standard lpcm and may thus decode it as 16bit resulting in the noise. I hardcoded the 24bit part and then it works ... but that's not a real solution hehe.

[sleepking]

Same problem (crash of MPC after seeking) with rev 2544.
I stay on rev 2539.



The same problem,and ffdshow audio decoder-->codercs-->uncomperessed "all supported" don't work on my computer.

[issa]

Rev. 2546 build,

Compiler: ICC 9.0.30 (msvcrt 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19739749/ffdshow-2546-icc-sse-20060506.exe.html) or MegaUpload (http://www.megaupload.com/?d=FZCJ1D0O)

Temporary fix LPCM problem by assume 16bit PCM when fail to detect the stream type.

[max-holz]

Rev. 2546 build,

Compiler: ICC 9.0.30 (msvcrt 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19739749/ffdshow-2546-icc-sse-20060506.exe.html) or MegaUpload (http://www.megaupload.com/?d=FZCJ1D0O)

Temporary fix LPCM problem by assume 16bit PCM when fail to detect the stream type.

Where is link for SSE2 build?

[videomixer9]

the binaries automatically select the available SIMDs and use the one according to your CPUs capabilities. Code is generated for both SSE and SSE2 with ICL and embedded into the same binary. So the link to SSE and SSE2 version is the same ...

[MatMaul]

@ videomixer9 :I see on your website :
applied patches : runtime cpu detection, advanced gcc optimizations makefile patch
what are these patch ?
Can you publish them please ?
I actually try to make my own build and I'm interested by these patchs.
thanks !

[Adub]

Videomixer, are you going to make some builds with sse2 optimizations? That would be great man!

[videomixer9]

just use the build from issa, I won't do SSE2 builds.

[issa]

Rev 2546 Build version 2,

Compiler: ICC 9.0.30 (msvcrt 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/19816562/ffdshow-2546-icc-sse-20060507.exe.html) or MegaUpload (http://www.megaupload.com/?d=M8CGQY9T)

Temporary try to fix LPCM problem by using the old detecting code when new code fail to detect the stream. I think milan still working on the new detecting code.

[haruhiko_yamagata]

I apologize for lacking consideration for ffmpeg project/libavcodec.
Please forget the prior version of document and words about Superman trailer.
I am really sorry for it.

To 2546 updated document.
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[MatMaul]

@ videomixer9 :I see on your website :
applied patches : runtime cpu detection, advanced gcc optimizations makefile patch
what are these patch ?
Can you publish them please ?
I actually try to make my own build and I'm interested by these patchs.
thanks !

Up, thanks !

[_xxl]

ffdshow-20060508-2546.exe Intel 9.0.30
http://rapidshare.de/files/19931630/ffdshow-20060508-2546.exe.html

[Liisachan]

ffdshow-rev2546-SSE2.exe (http://ffdshow.faireal.net/mirror/ffdshow/ffdshow-rev2546-SSE2.exe)

3826010 Bytes
2006-05-08 13:14:20 UTC

[celtic_druid]

Not 100% rev2546. I added the multichannel vorbis patch from ffmpeg so 5.1 vorbis should sound fine now when decoded by libavcodec. Tested ok here.

[Liisachan]

Wow, I'll test it now.

EDIT
YES! That problem has been fixed in this new build.
In case someone needs a sample to test: xvid+6ch_vorbis.ogm (http://ffdshow.faireal.net/tmp/xvid+6ch_vorbis.ogm)

I was wondering why you made yet another one when there are already many builds lately, but now I know the reason. You're aggressively creative, which i'm really appreciating.

[videomixer9]

Hm, I also applied the patch and updated my latest build to use it. I usually don't check ffmpeg mailing lists so I missed it ...

[asasadad_1]

some lpcm decoding seems didn't work in ffdshow-rev2546-SSE2(by celtic_druid ).
here (http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/Fever.vob) is a sample.
ffdshow-svn2523-20060420(by clsid) is ok.

[issa]

some lpcm decoding seems didn't work in ffdshow-rev2546-SSE2(by celtic_druid ).
here (http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/Fever.vob) is a sample.
ffdshow-svn2523-20060420(by clsid) is ok.

I think the lpcm detect code in svn had not finished yet, if you need lpcm decoding, try my build on http://forum.doom9.org/showthread.php?p=824440#post824440.

[_xxl]

http://rapidshare.de/files/20008336/ffdshow-20060509-2546.exe.html
http://rapidshare.de/files/20034853/gcc.jpg.html
http://rapidshare.de/files/20034897/icl.jpg.html

[Lemonzest]

using videomixer9's builds, latest one and wma2 has stopped working, it is recognised but just muted/no sound have to disable libavcodec in the options and let windows decode it. i made a new test file and its the same.

[videomixer9]

works fine for me with a sample I got off mplayer ftp as I don't have such trash on my hd anymore :p there are some aggresive gcc optimizations enabled that may break stuff randomly, I usually test them only for aac/ac3/dts sound though as those are the usual things that break with them.

[Lemonzest]

i just did a quick encode with wma2 audio, and have to disable "WMA 8/9" Audio in the codec part of the audio decoder, for it to play, windows explorer says the audio is "Windows Media Audio 2" and in the info panel of the audio decoder it says "libavcodec wmav2" just no sound :(

http://lemonzest.tastyspleen.net/Temp.avi

[Kostarum Rex Persia]

Can someone tell me why build 2546 doesn't support fourCC IV50( Indeo 5.11 codec).

I can't play Indeo 5.11 files at all, can someone make a patch for decoding this stuff?

[foxyshadis]

I've never seen IV50 or IV40/41 in ffdshow, you've always had to go to ligos's website to get the codecs. As the decoders aren't present in lavc at all, it would take a lot more than a quick patch to get it in.

http://www.free-codecs.com/download/Intel_Codec_Installer.htm

[Lemonzest]

videomixer9, just got your new build and no idea what you did but wma v2 now plays fine :D Thanks.

[3dsnar]

I have posted this request through sourceforge,
but I would like to know what other users think about such approach
(I think this is the least confusing and possibly the most stable apprach)

-------------------------------------------------------------
Currently Aud-X MP3 5.1 is available as one of the mp3 decoding libraries.

My request is:

1) Please, add new format: Aud-X MP3 5.1 to the format list.
The user will be able to chose audxlib or disable the format.

---- If Aud-X MP3 5.1 is selected:
audxlib.dll would be used ONLY for Aud-X streams.
For regular MP3 streams other mp3 decoder would be used (selected with the MP3 format drop list)

---- if not selected, audxlib.dll would not be used.

2) Please add description to "info & debug"
about the mp3 5.1 stream (if it is such).

-------------------------------------------------------------

Please share your thoughts within this forum,
but also here:
http://sourceforge.net/tracker/index...61&atid=471492

[videomixer9]

ffdshow rev. 2546 ICL9.1

minimum requirement: SSE
compilers: GCC 4.1.1 + ICL 9.1.022
specials: high accuracy tremor, high accuracy libmad, runtime cpu detection, libavcodec 6ch vorbis fix
download: here (http://bittekeinspam.googlepages.com/ffdshow-20060511-rev2546-icl91.exe)

I thought it was time to try and get things on ICL maybe, test it and find out if it works better for you. It uses autovectorization and auto-parallelization (automatic optimization for dualcore). Raw decoding performance shouldn't be very much better as libavcodec is still gcc compiled, but some filters built into ffdshow.ax should work better. Compile time for this is very long so I don't know if I do any built with ICL 9.1 from now on. I prolly release another built with some other settings later.

[celtic_druid]

Parts of libavcodec can be built with ICL9 to. Yeah, compiling ffdshow with ICL does take ages.

[videomixer9]

libavcodec ICL 9.1 fails on missing links for some things that I'm trying to figure out to get it compiled with it, interesting is the auto-parallelization part. Seems to have something to do with dsputil ...

[LoRd_MuldeR]

Are ICL builds okay for AMD CPU's too or is it recommended to use GCC builds on my AthlonXP ???
Will do some testing myself too...

[videomixer9]

From my expierence upto now ICL isn't really usefull for main ffdshow part. I had better results making up performance by using more optimization for libavcodec on gcc. Also mostly totally stupid stuff is autovectorized or parallelized, e.g. dolby decoder or mixer.

Would be nice to have timecodec results, for me the icl build is not a bit better for just decoding, must be cause all needed operations are optimized anyways, and the rest of the code not being that bad. Considering ICL needs almost a half hour and MSVC 2005 only like 2-3 mins ... not even talking about stuff like kerneldeint which throws out of memory after a while here ...

And yes better not use it on AMD the libs aren't patched and I think it still is nazi against AMD, but rather than applying a patch I think I'd stick to MSVC compiler as it performs well enough that way. If it'd patch any libs I'd also only patch them now to check for AuthenticAMD so Intel people may cry, got sick of that company.

[LoRd_MuldeR]

I've just noticed that there's a big difference between RGB and YUV output. With YUV output (ffdshow default setting) it looks "mealy". If I uncheck YUV modes and force RGB output, the colors look *much* better. So it's a great improvement for image quality. Any explanation why it's that way?

Sample: YUV (http://mulder.dummwiedeutsch.de/etc/mpc_yuv.png) <-> RGB (http://mulder.dummwiedeutsch.de/etc/mpc_rgb.png)

[Isochroma]

Your video card doesn't do hardware colorspace conversion properly. In this case, make sure to uncheck all the YUV output formats. Also while you're there, check "High Quality colorspace conversion". If you're using the registered version of CoreAVC for AVC decoding, then select the output colorspace as either RGB24 or RGB32 in the decoder window. And if you happen to be using the XviD decoder filter, set the output colorspace also to RGB24 or RGB32.

My FX5200 and GeForce MX400 don't do it right either. Others have reported this issue; it seems to effect mostly Nvidia cards.

[Romario]

What about IV50, and IV40/41 fourCC support in future FFDSHOW builds.

Can someone make stable patch, so I can watch IV50(Indeo Codec 5.11) video on my computer?

Or, how I can directly contact Milan Cutka via email. If someone knows his email, send it via Private Message to me. Thank you.

[Liisachan]

@LoRd_MuldeR
possibly nVidia's known problem--uh not a problem but it's by design.

to let nVidia+YUV+overlay work as 0-255:
...Example (NVidia ForceWare 78.01 WHQL)...
- Color Correction -> Apply color changes to: "Overlay" / Brightness "120%" / Contrast "101%"
- Video Overlay Settings -> Hue "0" / Saturation "102%"

Still, I'm one of RGB24/32 lovers too, actually.
RGB is slightly better than YUV, even if colorspace is ok, that's my experience; perhaps it's just that my hw is baka.

@Romario
http://sourceforge.net/tracker/?atid=471492&group_id=53761&func=browse

[thuan]

About new vm9's icl9.1 build, it's faster on my computer (AMD T-bred 1.5GHz). Here's the results with timecodec:new icl9.1 r2546
User: 52s, kernel: 0s, total: 52s, real: 53s, fps:70.2 dfps: 69.6
r2546 vm9's normal build
User: 64s, kernel: 0s, total: 65s, real: 65s, fps:56.8 dfps: 56.2 File tested: first 2 mins of Maison Ikkoku - 93 [TD].avi. Output colorspace YV12. The file is pretty old (use DIV3) so for acceptable quality when watching I use mplayer PP with Accurate deblocking and no automatic quality control, denoise3d hq and xsharpen. I also use those settings for the benchmark above.

Just normal decoding there's not much difference like vm9's comment.

[videomixer9]

hm ... the denoise3d and xsharpen must been the better working stuff there. Looks like it got some pros for filter users so I guess I do icl builds at least once in a while ...

[foxyshadis]

A quick test, comparing videomixer's icl and gcc builds, on my SSE3 core duo...

avc, no resize
ffdshow icl9 ~ User: 48s, kernel: 0s, total: 49s, real: 50s, fps: 156.5, dfps: 152.8
ffdshow gcc ~ User: 48s, kernel: 0s, total: 49s, real: 51s, fps: 157.6, dfps: 151.3
coreavc 1.0b ~ User: 6s, kernel: 0s, total: 6s, real: 21s, fps: 1118.6, dfps: 359.9

asp, resize, pp
ffdshow icl9 ~ User: 37s, kernel: 0s, total: 38s, real: 47s, fps: 198.2, dfps: 161.2
ffdshow gcc ~ User: 37s, kernel: 0s, total: 38s, real: 46s, fps: 196.5, dfps: 162.6

asp, resize, pp, deband, warpsharp
ffdshow icl9 ~ User: 132s, kernel: 1s, total: 133s, real: 143s, fps: 56.8, dfps: 52.6
ffdshow gcc ~ User: 136s, kernel: 1s, total: 137s, real: 149s, fps: 55.2, dfps: 50.7

I guess the filters I use just don't benefit, probably because they're already at least SSE. Of course, the lavc decoding doesn't at all. And coreavc is still waaay faster than lavc. (I still don't use it though, I like ffdshow's filters too much.) And the results were a bit variable between runs, so I tried to keep system use to a minimum.

OT, it'd be nice is sharpen and warpsharp dialogs were combined sometime.

[o2xygen]

with mplayer post and accurate deblock at automatic quality control. VMR9 RENDERER
My cpu is a Pentium III 1ghz SSE. all tests were carried out at the same environment.
sample
Video: DivX 5 512x384 23.98fps 1537Kbps [Video 0]
Audio: MPEG Audio Layer 3 48000Hz stereo 128Kbps [Audio 1]


bob0r build
ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.8, dfps: 76.6

Celtic Druid build
ffdshow-rev2529-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 14s, fps: 107.7, dfps: 73.6

issa builds
ffdshow-2539-gcc-sse-20060603.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.6, dfps: 73.4
ffdshow-2546-icc-sse-20060506.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.0, dfps: 72.5

dirk paehl build
ffdshow-20060423_gcc4.1_speed.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.0, dfps: 75.8
ffdshow-svn_2536_gcc.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 77.4

videomixer9 builds
ffdshow-20060505-rev2546.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 104.7, dfps: 77.8
ffdshow-rev2533.exe
User: 9s, kernel: 0s, total: 9s, real: 13s, fps: 109.7, dfps: 77.9

[Reino]

videomixer9, at the moment I'm using your release posted here (http://forum.doom9.org/showthread.php?p=823871#post823871).
Could it be possible you (or someone else?) changed something on the libfaad2?
When I try to play this (http://www.megaupload.com/?d=8HUIR042) MPG[AVC1+AAC]-file, sound is really distorted with libfaad2 somehow (with realaac everything if fine...)
This wasn't an issue with previous FFDShow releases.

[videomixer9]

yeah that compile has a problem and I replaced it with something else iirc cause libfaad2 was borked by gcc and it's vectorizer that was applied to it. please replace it. These distortions happen if the floating point code is broken.

hm best dfps in o2xygen's test :p

[LoRd_MuldeR]

Your video card doesn't do hardware colorspace conversion properly. In this case, make sure to uncheck all the YUV output formats. Also while you're there, check "High Quality colorspace conversion".

Done!

possibly nVidia's known problem--uh not a problem but it's by design.

Can't be nVidia's Problem, because I have ATI graphics card (Redeon 9800 Pro) ^^
But as long as RGB gives much better quality, I'll just disable YUV and be happy :)

[_xxl]

http://www.intel.com/cd/ids/developer/asmo-na/eng/257129.htm

[Liisachan]

Software-side RGB *will* guarantee a good result, but not for free--it costs much CPU time. For a "heavy" codec like SNOW, Dirac, software-side RGB might be a bit difficult, especially when softsubbed. Other than CPU cost (in other words, you won't make most of the HW accelerators), there's nothing wrong in it. I use ffdshow-side RGB myself too. I even set Codec | Raw Video = All YUV so that any non-ffdshow-supported codec like RG40 VP7 will be RGB'ed too thru ffdshow.

But I thought that problem (YV16-235 in HQ Overlay) was only in nVidia drivers' default. It's news to me that the similar can happen more generally. Thanks for that report, LoRd_MuldeR :)

[MatMaul]

I have compiled pure GCC builds without the mt patch.
See here for more informations (http://matmaul.googlepages.com/)
Thanks to videomixer9, his google page is my model.
@ videomixer9 : If you don't want I use text of your page, just send me a PM or tell that here.

[bob0r]

Wow, Sourceforge SVN is already fucked again, after 400 retries i finally got 2546 source.

Ill be doing SSE and SSE2 builds for x264.nl

Both builds are done, but there is a huge problem.
ffdshow DTS decoding is horrible, sound get very loud and all messy, my reciever even decided to turn itself off.

So ffdshow-2546-gcc4.0.3-sse-x264.nl.exe and ffdshow-2546-gcc4.0.3-sse2-x264.nl.exe are now fully automated aswell (only manual compile as not every revision will be online)

I hope Milan can fix this horrible bug asap!
( http://sourceforge.net/tracker/index.php?func=detail&aid=1487390&group_id=53761&atid=471489 )

I advice anyone NOT to play DTS files using the
latest revision until this issue is resolved, it Can
blow up your audio system.

[videomixer9]

btw. is there any way to get icl to compile tomsmocomp and kerneldeint in sane timespans that is not hours or days? i gave up on libmplayer and libavcodec with icl, both perform horrible compiled with it. resizing gets awful slow with libmplayer compiled with icl.

btw. nothing blown up here with 2546 and DTS ... :p must be a compiler error.

I'll have a typical testing file and that one boosted up to some nice record values for me ...

todays icl build ...
User: 79s, kernel: 0s, total: 80s, real: 83s, fps: 422.9, dfps: 405.1
vs my mt-2539 build which had only:
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4

on the same file ... I'm amazed. gotta go back to tweak some more ...

Also, does any x64 processor have SSE3? Next build for x64 I'd like to just use SSE3 as default target.

[Egh]

I'll have a typical testing file and that one boosted up to some nice record values for me ...

todays icl build ...
User: 79s, kernel: 0s, total: 80s, real: 83s, fps: 422.9, dfps: 405.1
vs my mt-2539 build which had only:
User: 87s, kernel: 0s, total: 87s, real: 95s, fps: 387.2, dfps: 356.4

on the same file ... I'm amazed. gotta go back to tweak some more ...

Also, does any x64 processor have SSE3? Next build for x64 I'd like to just use SSE3 as default target.

Wow :approved: It seems we really have record holder now. Even on my athlon XP 1800+ I noticed faster seeking in video (that's 720p XVid and some filters enabled).

As for SSE3. You're not quite right.
Older A64 models do NOT support SSE3. Clawhammer&Newcastle&Winchester models dont' have it. SSE3 was introduced into A64 range only in Venice&SanDiego cores.

[videomixer9]

ah damn ... I only checked some pricelists and saw SSE3 listed everywhere, so I assumed every 64bit modell has it.

[Egh]

Software-side RGB *will* guarantee a good result, but not for free--it costs much CPU time. For a "heavy" codec like SNOW, Dirac, software-side RGB might be a bit difficult, especially when softsubbed. Other than CPU cost (in other words, you won't make most of the HW accelerators), there's nothing wrong in it. I use ffdshow-side RGB myself too. I even set Codec | Raw Video = All YUV so that any non-ffdshow-supported codec like RG40 VP7 will be RGB'ed too thru ffdshow.

But I thought that problem (YV16-235 in HQ Overlay) was only in nVidia drivers' default. It's news to me that the similar can happen more generally. Thanks for that report, LoRd_MuldeR :)

First, it's not only NVidia problem. Second that correction you told is only approximate iirc, not true conversion.

It's very easy though to convert if you have Avisynt installed. Add "ColorYUV(levels="TV->PC")" line into avs section in ffdshow and enjoy :)

Since RGB conversion actually takes into account that source signal is within TV range (and RGB is always full range) enabling only RGB output in ffdshow fixes the problem. If you don't do "high quality conversion" you don't actually loose much on CPU %.

And of course, simplest way to emulate conversion w/o changing colorspace would be to enable ffdshow filter Levels :P Use 16-235 as input and full range as output. Thus you can restore colors w/o RGB output :P

[Liisachan]

@Egh
Yeah, what I actually meant was: VMR9 Renderless RGB vs. Overlay YUV. The difference of CPU cost is significant, but like you said, YUV->RGB is not the slow part.

There is no 'only-one' formula to convert YUV to RGB, so the phrase "true conversion" doesn't make much sense. Avisynth uses one of the common algos--the Rec.601 matrix coeffs--by default, but that's not the only one, either. On the other hand, this conversion is float calc lossily cast to int, so like you said, everyhing is more or less just approximate, not losslessly reversible.

Personally, I do love ffdshow's RGB24/32 output (hq conv), I too feel that software-side rgb is higher-quality too, altho I've never tried double-blind tests :P

[Egh]

@Egh
There is no 'only-one' formula to convert YUV to RGB, so the phrase "true conversion" doesn't make much sense. Avisynth uses one of the common algos--the Rec.601 matrix coeffs--by default, but that's not the only one, either. On the other hand, this conversion is float calc lossily cast to int, so like you said, everyhing is more or less just approximate, not losslessly reversible.



I meant that altering brightness/constrast etc is not actually a true conversion. That wasnt' releated to YV12<->RGB. For the *true* conversion from TV to PC range in software you either have to use avisynth or ffdshow "Levels" filter (making input as 16-235 there).

P.S. Concerning coefficients -- Rec.601 and Rec.709 are both possible in AVS. I wonder which one ffshow actually uses :P

[dk75]

I advice anyone NOT to play DTS files using the
latest revision until this issue is resolved, it Can
blow up your audio system.[/B]
Rest assured. No one will use these new builds... cause it's nowhere to find.

[haruhiko_yamagata]

To 2546 bug fix. Seek problem.

http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[flanger216]

Videomixer9: when I try to install your latest x64 build, I get the error, "Error while registering ffdshow.ax" . 32-bit builds install fine.

[issa]

Rev 2546 build using ICC 9.1,

Compiler: ICC 9.1.22 (msvcrt 8 included) + GCC 4.1.1
CPU Extension: SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20323670/ffdshow-2546-icc-sse-20060513.exe.html) or MegaUpload (http://www.megaupload.com/?d=JFVWJJU2)

Please try it and see if there is a speed improvment.

[bob0r]

...

btw. nothing blown up here with 2546 and DTS ... :p must be a compiler error.

...


Ya probably, only my compiler did not change, ffdshow source did, so indeed something is broken.



Another issue: Am i the only one with ffdshow SVN checkout issues????

I get errors like there:
A ffdshow\src\ffmpeg\libavcodec\i386\dsputil_svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
mmx_avg.h

A ffdshow\src\dialog\CmaskingSKAL.h
A svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)
ffdshow\src\dialog\Cin.h
A ffdshow\src\dialog\Cvolume.h

And then it does not complete the checkout, i have to run it a few times so it gets completed.
Only then i see "Checked out revision 2546.", but not the first time.
(i use svn co https://svn.sourceforge.net/svnroot/ffdshow/trunk ffdshow)

(could possibly be the cause of the DTS error aswell, though i don't think so)

[haruhiko_yamagata]

Multithreading of swscaler handles "Resize", "Sharpen/swscaler" and "Blur & NR/swscaler gaussian blur". As reported here, when two of them is checked and one try to uncheck one while playing, older mt versions crash. This patch includes bug fix for it.
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

Videomixer9: when I try to install your latest x64 build, I get the error, "Error while registering ffdshow.ax" . 32-bit builds install fine.

msvcrt for x64 is not included in the x64 build, get the special x64 runtime libs. As the installer would also install it on a 32bit system I didn't include it so that noone can break stuff. Also of course ffdshow64 only installs properly on Win64, it's not for 64bit processors running 32bit version of Windows.

http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B (x64 VC Runtimes)

SVN checkout works like a charm here, sf.net never had less problems for me. DTS lib is version 0.0.2 or so since ages, I would be surprised to see any real changes there and the other audio handling stuff seems fine.

[o2xygen]

all with mplayer post and accurate deblock, auto Quality.control- VMR9 RENDERER
CPU= 1Ghz PIII SSE
Sample
Video: DivX 5 512x384 23.98fps 1537Kbps [Video 0]
Audio: MPEG Audio Layer 3 48000Hz stereo 128Kbps [Audio 1]


BOB0R BUILDS
ffdshow-20060423-gcc4.0.3-sse-mt-x264.nl.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.8, dfps: 76.6


CELTIC DRUID BUILDS
ffdshow-rev2529-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 14s, fps: 107.7, dfps: 73.6


ISSA BUILDS
ffdshow-2539-gcc-sse-20060603.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.6, dfps: 73.4

ffdshow-2546-icc-sse-20060506.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 104.0, dfps: 72.5

ffdshow-2546-icc-sse-20060513.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 80.1


DIRK PAEHL BUILDS
ffdshow-20060423_gcc4.1_speed.exe
User: 9s, kernel: 0s, total: 10s, real: 14s, fps: 106.0, dfps: 75.8

ffdshow-svn_2536_gcc.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.7, dfps: 77.4


VIDEOMIXER9 BUILDS
ffdshow-rev2533.exe
User: 9s, kernel: 0s, total: 9s, real: 12s, fps: 108.1, dfps: 83.6

ffdshow-20060509-rev2546.exe
User: 9s, kernel: 0s, total: 10s, real: 12s, fps: 106.8, dfps: 83.1

ffdshow-20060512-rev2546-icl91.exe
User: 9s, kernel: 0s, total: 10s, real: 13s, fps: 106.9, dfps: 81.9


MATMAUL BUILDS
ffdshow-20060512-rev2546-SSE.exe
User: 9s, kernel: 0s, total: 9s, real: 13s, fps: 108.0, dfps: 81.2
Videomixer's builds are still the fastest
issa's latest ICL build gained much speed than the previous one
Matmaul's build seems fast as well

[MatMaul]

ffdshow rev. 2546

requires: SSE or SSE2
compilers: pure GCC (4.0.3+4.1.1)
specials: high accuracy tremor, high accuracy libmad, libavcodec 6ch vorbis fix, mt bugfix
download: SSE (http://matmaul.googlepages.com/ffdshow-20060513-rev2546-mt_bugfix-SSE.exe), SSE2 (http://matmaul.googlepages.com/ffdshow-20060513-rev2546-mt_bugfix-SSE2.exe)
more informations here (http://matmaul.googlepages.com/)

Thanks haruhiko_yamagata, your patch works great, I can now seek in my video.

[bob0r]

@videomixer9

Can you do a full compile with only gcc 4.0.3 then?
Also can you please pack up and put 2546 source online somewhere?

(or anyone else for that matter)

Edit:
@videomixer9
http://forum.doom9.org/showthread.php?p=827091#post827091
That build has fucked up DTS audio as well, meaning its most likely ffdshow SOURCE and CPU dependant.

So forget the above compile and put online requests, i already filed this as bug report, lets just wait what the answer is.

Also i will test 2543 first, it's possible this issue was introduced with revision 2544.

If only i could get the sources......:
cd Subversion\bin
svn co -r 2543 https://svn.sourceforge.net/svnroot/ffdshow/trunk ffdshow

svn: REPORT request failed on '/svnroot/ffdshow/!svn/vcc/default'
svn: REPORT of '/svnroot/ffdshow/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.sourceforge.net)

PFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Thank god the SVN system allows 100x checkout untill all files are completed :P (or svn up for that matter)

[videomixer9]

My build has fine DTS sound, your soundsystem is broken. Same with your SVN client :p The real broken thing is only LPCM.

sources ... http://bittekeinspam.googlepages.com/rev2546.7z

[flanger216]

msvcrt for x64 is not included in the x64 build, get the special x64 runtime libs. As the installer would also install it on a 32bit system I didn't include it so that noone can break stuff. Also of course ffdshow64 only installs properly on Win64, it's not for 64bit processors running 32bit version of Windows.

http://www.microsoft.com/downloads/details.aspx?FamilyId=90548130-4468-4BBC-9673-D6ACABD5D13B (x64 VC Runtimes)

Yeah, I tried that, but still no joy... here's my installation log, if it helps:

Output folder: D:\Program Files\ffdshow
Extract: ffdshow.ax... 100%
Extract: libavcodec.dll... 100%
Extract: TomsMoComp_ff.dll... 100%
Extract: libmplayer.dll... 100%
Extract: libmpeg2_ff.dll... 100%
Extract: ff_liba52.dll... 100%
Extract: ff_wmv9.dll... 100%
Extract: ff_tremor.dll... 100%
Extract: ff_theora.dll... 100%
Extract: ff_libmad.dll... 100%
Extract: ff_libdts.dll... 100%
Extract: ff_libfaad2.dll... 100%
Extract: ff_realaac.dll... 100%
Extract: ff_samplerate.dll... 100%
Extract: ff_unrar.dll... 100%
Extract: ff_x264.dll... 100%
Extract: ff_kernelDeint.dll... 100%
Extract: audxlib.dll... 100%
Extract: audxlib.def... 100%
Extract: msvcr80.dll... 100%
Extract: Microsoft.VC80.CRT.manifest... 100%
Could not load: D:\Program Files\ffdshow\ffdshow.ax

Again, don't worry about it too much; the 32-bit builds work great, and I doubt the x64 compiles really make much difference. I just wanted to finally test something legitimately 64-bit on my new XP64 install :)

[flanger216]

Here's a brainstorm...

Win64 has two 'program files' directories: 'C:\program files' for x64 applications and 'C:\program files (x86)' for x86 applications. When I try to install the x64 version of ffdshow, the installer defaults to 'C:\program files (x86),' so Windows erroneously thinks it's a 32-bit application instead of 64-bit. So, when the installer tries to register ffdshow.ax, perhaps it's trying to use the 32-bit version of regsvr32.exe instead of the 64-bit version? I checked, and there are in fact two versions in two seperate directories (c:\windows\system32 and \syswow64).

Sorry... probably talking out my ass here, but I know xp64 isn't all the widespread around here, so hopefully it'll help.

[videomixer9]

the crt is in it? uh ... maybe delete it then. I dunno, does Win64 also use regsvr32 to register? maybe try register it manually. If a binary is 64bit or 32bit shouldn't be detected on the directory but via the file header. If you register it manually it should complain about why it cannot be loaded or shows a crash e.g. so e.g. do regsvr32 c:\program files\ffdshow\ffdshow.ax (or is it regsvr64 on win64?) so maybe try regsvr64 c:\program files\ffdshow\ffdshow.ax

Also, you do have an SSE3 capable CPU? (e.g. Athlon 64 Clawhammer&Newcastle&Winchester don't have it as reported by Egh)

because not so many people have win64 this responses are my only clue if the builds work so your report is very welcome.

[bob0r]

My build has fine DTS sound, your soundsystem is broken. Same with your SVN client :p The real broken thing is only LPCM.

sources ... http://bittekeinspam.googlepages.com/rev2546.7z

Not when its CPU related!
Like i said ffdshow-20060420-gcc4.0.3-sse-x264.nl.exe does have fine DTS audio.
Ill try find out from which revision DTS audio goes wrong.

2543 is still broken too.

My SVN client is not broken, as it does the same on 3 other Computers aswell.

Most likely some SF SVN setting that is wrong, because AMS-IX usually knows best :)

[videomixer9]

Well I cannot reproduce that problem on any of my PCs with any of my DTS movies. That's a P4, P3 and Athlon XP. Perfect sound coming out of my 5.1 system hooked up via creatives propiertary multichannel pcm cable. You got any broken sample? preferably not dts in wave *hate*

Though thinking about it, did you test a file where dts is in wave and it just decodes it as regular 2ch PCM which usually sounds like plain distorted noise ...

[bob0r]

Well I cannot reproduce that problem on any of my PCs with any of my DTS movies. That's a P4, P3 and Athlon XP. Perfect sound coming out of my 5.1 system hooked up via creatives propiertary multichannel pcm cable. You got any broken sample? preferably not dts in wave *hate*

Though thinking about it, did you test a file where dts is in wave and it just decodes it as regular 2ch PCM which usually sounds like plain distorted noise ...

http://mirror05.x264.nl/public/x264.dts.sample.mkv

Please can you put an sample online too, then we should know enough.

[clsid]

Here's a brainstorm...

Win64 has two 'program files' directories: 'C:\program files' for x64 applications and 'C:\program files (x86)' for x86 applications. When I try to install the x64 version of ffdshow, the installer defaults to 'C:\program files (x86),' so Windows erroneously thinks it's a 32-bit application instead of 64-bit. So, when the installer tries to register ffdshow.ax, perhaps it's trying to use the 32-bit version of regsvr32.exe instead of the 64-bit version? I checked, and there are in fact two versions in two seperate directories (c:\windows\system32 and \syswow64).

Sorry... probably talking out my ass here, but I know xp64 isn't all the widespread around here, so hopefully it'll help.
Since the installer is 32-bit, Windows will indeed think the stuff in it is also 32-bit.

You could try moving the files to the 64-bit program files folder and manually registering ffdshow.ax with regsvr64.exe

[videomixer9]

afaik there isn't an nsis that produces special x64 installers so i'm kinda wondering how to get that stuff solved then ... hm.

That dts track in that sample is indeed broken and total overdrive. Hm need to cut part of some mkv, need to get tools first so may take a bit.

Okay some part of Howl with non-broken dts. fear superior japanese dvd. http://rapidshare.de/files/20377932/dts_sample.avc.mkv.html

[bob0r]

@videomixer9

r2524 | milan_cutka | 2006-04-22 17:02:19 +0200 (Sat, 22 Apr 2006) | 2 lines

merged changes from Dscaler5 libdts


Seems there lies the problem.

(ironicly 1 revision after the build i put on x264.nl :p)

[videomixer9]

great ... so milan broke dts and lpcm, wonder what's next :p I merged back parse.c from proper libdts and reuploaded my build with a libdts that actually works for that example too.

So this (http://bittekeinspam.googlepages.com/ffdshow-20060513-rev2546-icl91.exe) build now has the mt fixes and fresh from svn checked out libdca (libdts) plus the vorbis fix ... milan really needs to get back fixing lol.

[Skelsgard]

I´m having trouble downloading builds on googlepages. The download suddenly stop at bout 1.7 Mbs and reports "Download completed", but of course the .exe is broken. It´s happening with bobor´s and vm9´s builds. Yet vcredist_x86 and audxlib.dll download properly. Anybody having this problem?

[thuan]

Happen here too, but if you use a download manager then it went fine.

[Skelsgard]

I´ll try that, thnx, man :).

[flanger216]

the crt is in it? uh ... maybe delete it then. I dunno, does Win64 also use regsvr32 to register? maybe try register it manually. If a binary is 64bit or 32bit shouldn't be detected on the directory but via the file header. If you register it manually it should complain about why it cannot be loaded or shows a crash e.g. so e.g. do regsvr32 c:\program files\ffdshow\ffdshow.ax (or is it regsvr64 on win64?) so maybe try regsvr64 c:\program files\ffdshow\ffdshow.ax

Also, you do have an SSE3 capable CPU? (e.g. Athlon 64 Clawhammer&Newcastle&Winchester don't have it as reported by Egh)

because not so many people have win64 this responses are my only clue if the builds work so your report is very welcome.

There's a 32-bit version of regsvr32 in 'c:\windows\system32' and a 64-bit version in '\sysWOW64,' which, unfortunately, is also called regsvr32 . You think they could've at least changed the name of the executable, but I guess that's why I don't work at Microsoft.

Anyway, I'm away from my comp now, but tomorrow night I'll try cracking open the installer and registering ffdshow.ax myself. I do have a SSE3-capable Athlon64, so hopefully it should work, and then I'll report on whether it actually runs better.

[zambelli]

I'm experiencing a strange problem with ffdshow when transcoding videos to a Windows Mobile device using WMP10's sync feature.

I used to have the 12-21-05 x264.nl build installed and everything worked peachy. Then I upgraded to the 4-20-06 x264.nl build and suddenly all the transcoded videos (in: XviD, out: WMV9) started coming out upside down and mirrored. Whaaa? OK, I figured something was wrong with the new build, so I reverted back to 12-21-05 - and all my transcoded videos are still coming out flipped and mirrored.

Things I know:
1) Playback of the same XviD videos works fine in WMP10 and MPC. Even playback through VfW in VirtualDub works fine.
2) Encoding in standalone WME9 works fine - the videos transcode correct side up.
3) Ffdshow is definitely being used during WMP's transcoding process. I can see the ffdshow tray icon show up and the info shows the XviD video being decoded.

So my conclusion is that something is different in my Ffdshow configuration this time around. What could cause the video to be flipped and mirrored on decode just for this one graph? My ffdshow video config is pretty standard. No postprocessing features are checked - it's pretty much the default install config, really.

Any ideas or similar experiences?

[zambelli]

I'm experiencing a strange problem with ffdshow when transcoding videos to a Windows Mobile device using WMP10's sync feature.
OK, I've discovered the solution to my problem in the meantime. :) Rather than deleting the original post, I'll just post the solution here to help anyone else who runs into the same issue:

Apparently "Allow output format changes during playback" in the Output tab was the culprit. If checked, the image somehow gets flipped and mirrored during decode. I'm not sure why this is happening only in a transcoding graph (one where the output is not a renderer) though. If left in the default "indeterminate" state, the problem goes away and the image is decoded correctly. That sounds like a bug.

[Link00y]

Hi,

first of all: your ffdShow builds are great!

it was already mentioned once here.. I checked all your versions to find out that since ffdshow-20060504-rev2544 "decoding" uncompressed audio is impossible, making the ffdShow audio processor totally unusable. I downgraded to ffdshow-20060503-rev2541 and things work again - actually I'd like to have audio processing so that even for none supported codecs or codecs supported by the player itself (like MPC with its MPEG audio decoders) can still be upmixed (using the mixer feature) to 5.1 (Speaker configuration: 3/2+LFE) as ffdShow does that much better than my own sound card driver (Sound Blaster Audigy).

And if you accept: one minor request (but really: IT HAS TIME); the Mixer is a great feature in my eyes however I also often get Mono videos with 1/0 audio.. the 3/2 upsampling matrix does in fact nothing for these streams; I'd like to have a more advanced custom matrix system where I cannot simply type in settings for the input configuration I currently listen to but for all input types (in fact the best request name would be "Custom output speakers configuration")

Thank you,

Link00y

[haruhiko_yamagata]

Hi,

first of all: your ffdShow builds are great!

it was already mentioned once here.. I checked all your versions to find out that since ffdshow-20060504-rev2544 "decoding" uncompressed audio is impossible, making the ffdShow audio processor totally unusable. I downgraded to ffdshow-20060503-rev2541 and things work again - actually I'd like to have audio processing so that even for none supported codecs or codecs supported by the player itself (like MPC with its MPEG audio decoders) can still be upmixed (using the mixer feature) to 5.1 (Speaker configuration: 3/2+LFE) as ffdShow does that much better than my own sound card driver (Sound Blaster Audigy).

It happens on my machine too. It seems to be since rev2522.

[foxyshadis]

Good news haruhiko! The deadlocks when filtering with avisynth from before are also gone, thanks to your fix!

Bad news videomixer. aWarpSharp filter trashes the U chroma plane on the latest build. :( This happens if chroma is set to "downsampled" or "independent". Has anything changed since your last build? wait, nm, it happens in all recent builds, bizarre. It also seems to eat even more cpu than limitedsharpen, so I'll probably use that instead.

[LoRd_MuldeR]

I´m having trouble downloading builds on googlepages. The download suddenly stop at bout 1.7 Mbs and reports "Download completed", but of course the .exe is broken. It´s happening with bobor´s and vm9´s builds. Yet vcredist_x86 and audxlib.dll download properly. Anybody having this problem?

Yeah, here to. Needed to use FDM (http://www.freedownloadmanager.org/) for downlaod. Then it worked fine.

[videomixer9]

I dunno what's the problem with googlepages, could download thing myself just fine, maybe they got some probs due to magic running out of capacities like google likes it or they throttle on purpose. It happens with bob0r's builds too? then it's sth. else :p

aWarpSharp is kinda broken, I dunno what that is, and iirc it is broken with downsample etc. for longer time now, if you disable those it's fine though. MatMaul build e.g. it doesn't even work at all. issa build has the same problem as mine. But besides that I notice on some movie that it has a watermark that shows up using this, heh :P

PCM processing seems to be broken on some part, but I don't want to enforce e.g. 16bit processing cause all others would be broken then and I personally like 24bit :O That problem should be common in most builds.

[Liisachan]

I can't reproduce the "googlepages" pb either. Download is fast and uninterrupted here (i.e. even resume is neededless)
Thanks for your great works btw :)

[Skelsgard]

aWarpSharp is kinda broken, I dunno what that is, and iirc it is broken with downsample etc. for longer time now, if you disable those it's fine though. MatMaul build e.g. it doesn't even work at all. issa build has the same problem as mine. But besides that I notice on some movie that it has a watermark that shows up using this, heh :P
Don´t know if u´re answering to my posting, but with "the .exe" i meant the installer, not any of the program´s utilities.

Downloading it with no problem with FDM :).

[videomixer9]

If you had read the rest of the posts you'd known for who that is, doh.

besides at Link00y, milan is the programmer of this so ask him for features, besides you can swap channels already with ffdshow, and I don't know if the mixer doesn't work for mono audio, I don't have anything from the ages when mono was still used.

Besides you also misunderstood Creative's CMSS features, Stereo Surround doesn't mean pseudo-5.1 sound but it just mirrors the stereo signal to the back and mixes two channels together for the center. For music etc. this is imo better as pseudo-5.1 is mostly lousy and way too much audio on the center channel.

Besides you can automatically load a specific preset based on the number of channels in the input, the input type etc. already. Just create a new preset and set the matrix how you want it and select an fitting autoload condition.

btw. someone requested my gcc params earlier:
-march=athlon-xp -mtune=athlon-xp -mmmx -msse -mfpmath=sse,387 -fforce-addr -ftree-loop-linear -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-loop-ivcanon -funsafe-loop-optimizations -ftree-loop-im -ffast-math -fprefetch-loop-arrays -fmerge-all-constants -falign-functions=64 -falign-jumps=4 -falign-loops=4 -O3 -fomit-frame-pointer -finline-functions -finline

:p works properly on other too even though it has athlon, but I bet it runs better on athlon thx to this :P

[foxyshadis]

XP just means it's made for midsize L1/L2 caches and short pipelines, like P3/Core, pretty much the exact opposite of older P4 but should perform fine on other processors without broken architectures.

[videomixer9]

yeah Athlons have way larger L1 caches than most of their Intel companions, 8kb vs. 64kb, that's the most significant thing. Another point many Intel models are bad with is the old 387 FPU modell that is used combined with sse.

btw. if you want to use optimized parameters better skip using GCCs loop unroller. Horrible crap, in fact GCC is imo still one of the worst compilers if you compare MSVC, ICL and GCC. Well of course it's a open and free compiler unlike the other two.

[foxyshadis]

videomixer, can you enable 7z on the installer if it's available? I rar'd up the file to email to a friend, just to wrap it, and lo, it was 2 megs smaller.

[celtic_druid]

!ifndef COMPRESSION
!define COMPRESSION lzma
!endif

Should get lzma by default.

[videomixer9]

The compression used for my installers is lzma solid. The installer should contain like 17.3 MB of stuff and is only 4.1 MB, I doubt you got it really down another 2 MB that easily.

[foxyshadis]

Wait, I'm stupid, I was looking at the wrong field. Ngg, never mind.

[Liisachan]

Agreed

2006-05-15 12:01 4,353,629 ffdshow-20060513-rev2546-icl91.7z
2006-05-15 12:00 4,300,562 ffdshow-20060513-rev2546-icl91.exe
2006-05-15 12:01 4,300,660 ffdshow-20060513-rev2546-icl91.rar


This installer looks cool but unfortunately this version doesn't work for me. Just trying 2 open a normal AVI via any DS player causes crashing. VfW encoding app can't even start either. Is this supposed to work only for HT or some special CPUs?

[videomixer9]

Only works with SSE, welly ou prolly have that, other than that no special requirements. The automatic parallelization code ICL produces seems to not work on some funny processors, it does on AMD Athlon XP/64 just fine as it seems. And anything except for libmplayer and libavcodec is compiled with ICL. Well as stated it could be that it doesn't work on some Intel processors maybe, function alignment is optimized for 64kb L1 cache, most Pentiums only got 8.

As stated on the website I don't care even one bit if it works on Intel CPUs :P If you got one of those I'm afraid that I cannot help you.

[Liisachan]

Yep, it's Prescott. And it's ok if it's a compiler-side pb. I just wanted to confirm that problem was not in ffdshow itself. I'll just use another build. Thanks anyway even if your build doesn't mix well with my CPU. :)

[videomixer9]

Now I'd rather expected older Intels to have problems, especially the code generated by ICL I wouldn't expect Intels to crash it, though whoever buys Intel should be punished :p would be nice to find out how it breaks so that I can break it even more for all Intel CPUs :p

Usually reclock output nice crash infos incl. the part of ffdshow that really crashed or if it were e.g. runtime libs as usually crash dialogs show up ffdshow.ax as the culprit.

Besides this I might skip a bit on ffdshow building, currently no changes anyways and other than that my need for the filters in it is very low and I got a neat other decoder to test by someone.

[_xxl]

libavcodec.dll can be compiled with
Microsoft.Visual.Studio.2005 + INTEL 9.1 + GCC 4.0.2!

[videomixer9]

I'd rather have the _mm_flags unresolved fixed to compile it all with ICL. Also must be a miracle that a linker puts together that mix. Odd enough e.g. my x64 has a fully ICL compiled libavcodec.dll, only win32 makes probs.

full ICL compile always ends with these linker errors:
vp3.obj : error LNK2001: unresolved external symbol _mm_flags
mpegvideo.obj : error LNK2019: unresolved external symbol _mm_flags referenced in function _get_vissual_weight
ratecontrol.obj : error LNK2001: unresolved external symbol _mm_flags
utils.obj : error LNK2001: unresolved external symbol _mm_flags
vcr1.obj : error LNK2001: unresolved external symbol _mm_flags
h263dec.obj : error LNK2001: unresolved external symbol _mm_flags
huffyuv.obj : error LNK2001: unresolved external symbol _mm_flags
mjpeg.obj : error LNK2001: unresolved external symbol _mm_flags
mpeg12.obj : error LNK2001: unresolved external symbol _mm_flags
asv1.obj : error LNK2001: unresolved external symbol _mm_flags
dv.obj : error LNK2001: unresolved external symbol _mm_flags
faandct.obj : error LNK2001: unresolved external symbol _mm_flags
ffv1.obj : error LNK2001: unresolved external symbol _mm_flags
dsputil.obj : error LNK2019: unresolved external symbol _dsputil_init_mmx referenced in function _dsputil_init
mpegvideo.obj : error LNK2019: unresolved external symbol _MPV_common_init_mmx referenced in function _DCT_common_init

oddly enough mm_flags isn't even referenced in all those files. The other function properly compiled but are missing in the object files.

[foxyshadis]

From dsputil.h, which all those files include...

extern int mm_flags;

which should be defined in dsputil_mmx.obj. Is that file not getting linked? _dsputil_init_mmx should be in there too. _MPV_common_init_mmx should be in mpegvideo_mmx.obj.

[_xxl]

ffdshow-20060516
http://rapidshare.de/files/20613041/ffdshow-20060516.exe.html

[haruhiko_yamagata]

So basically ffdshow needs to be re-engineered to do multithreading all the way through, presumably by pre-buffering several frames of audio or video data (which can decide how to best parallelize that part), decoupling the filtering engine from the decoding engine and feeding into a worker thread per core like vm9 says, then having a pool at the renderer that ensures frame order and timing are correct. Shouldn't be too hard... for server engineers. ;) I wish I knew more about implementing threading, I'd love to work on it. I'm curious how much of that structure is already done.

Until then, having portions of it multithreaded is still better than nothing, though.
Now I've cleaned up my debug queue, I'm begining to think of your request. Having a queue of samples just before sent to downstream would improve sporadic frame drops. Though I'm far from server engineer and I'm not sure if I can make it.
Thank you for your request. Sorry to respond late.

I updated my patch. Minor bug fix.
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

patches for patches would be nice, the most recent one needs almost all stuff restored or produces funny results otherwise like double passages of code.

Whatever, this (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build includes those changes.

[flanger216]

I installed Celtic's x64 build, but when I try to play a movie, Zoomplayer reports that it is "unable to create the ffdshow filter;" in other words, I get a graph error for the video and audio ffdshow filters.

So the question is: in order to use 64-bit ffdshow, does one have to use a 64-bit media player?

[celtic_druid]

Yes. You can have both 32bit and 64bit versions installed at once though. I actually tested the 64bit version in Graphedit64. Are there any 64bit media players?

The other thing is that I didn't add any FourCC selection type options, so you need to configure ffdshow after installing.

Some other notes:

Apparently Inno Setup's browse for file feature doesn't work in x64 mode, so VDub's plugin gets installed to ffdshow's directory. If you want to use it, copy it over.
The AVISynth plugin and AVISynth VfW support is disabled unless there is a HKLM\Software\AVISynth key with the plugin path. Installing via the .inf doesn't add this.

[Lemonzest]

videomixer9, now your builds are done with ICL9.1 have the intel cpu only checks been removed? so it runs full speed with sse/sse2 etc on AMD's CPU's?

[videomixer9]

It's not using automatic detection but forced one, so it should be fine without any patches, though it might not. I don't know of any patches for 9.1 though. Does it also use checks if you use /QxN e.g. ? I read that it doesn't. Btw. this SSE thing is getting redicolous, 9.1 should also already come with SSE4 support ... teh ... hail the codebloat.

The /Qax checks weren't removed, it seems Intel still wants to hide that their processors are crap and fear their own compiler producing dozen times superior code on AMD. An easy thing is to boycott Intel on the processor part and also companies like Dell which get bribed for using their crap.

[Paul Oblomov]

I'm having biig problem with almost all builds I've tried - when playing apple HD trailers (1080i) I got sudden CPU usage drop. For ex. it plays smooth for 30 sec and CPU usage 80-90% and suddenly it drops to 15-20-30%, totaly slowing down decoding :( Seeking 5 seconds back is enough to make it "eat well" again... for 10 seconds. :( Any ideas ?

P.S.
A64 3200 with AMD latest driver + 2gb ram + x800pro + win2k3 sp1
+
haali splitter + xvid + divx + x264 + any ffdshow + zoom player 4.51 and 5 pr.6

ffdshow-20060513-rev2546-mt_bugfix-SSE2.exe

And the next one - some AAC streams makes ffdshow's faad or realaac kinda hiss. It reports 96Khz (audigy2 zs). CoreAAC works like a sharm.

[videomixer9]

GCC optimizations MatMaul uses on his builds breaks libfaad and maybe realaac too.

The drop issue is simply that your PC seems to be to slow. CPU usage isn't constant for decoding, on various parts that make use of certain codec features it might need more processing power. If ffdshow is overloaded it usually does this stalling to kick in at a later point again. Weird effect but also the case here with things that overwork my CPU. You might wanna try VMR7 output, usually the fastest.

Only thing that solved this for me was using CoreAVC ;)

[Paul Oblomov]

Slow ?! Damn :( I remember NASA trailers - played smooth. but not with ffdshow :(

[videomixer9]

well dunno, here at least xmen 3 hd trailer in 1080p plays fine (well barely okay) with ffdshow. might be something else on your setup that maybe slows down the playback, or maybe try another build. And I got an Athlon XP 3000+ only.

[MatMaul]

GCC optimizations MatMaul uses on his builds breaks libfaad and maybe realaac too.

Can you tell to me what optimizations breaks libfaad and realaac please ?thanks!

[videomixer9]

If you only use the switches mentioned on your page I'd guess that it's fast-math that break it. You might need to apply different CFLAGS to libfaad and realaac. The loop unroller might be the culprit though too, it depends on the version of GCC. GCCs loop unroller mostly seems to suck anyways. Also note that you can only break parts of libavcodec with specific flags, e.g. the vorbis decoder in libavcodec easily breaks without other parts being affected.

[issa]

It's not using automatic detection but forced one, so it should be fine without any patches, though it might not. I don't know of any patches for 9.1 though. Does it also use checks if you use /QxN e.g. ? I read that it doesn't. Btw. this SSE thing is getting redicolous, 9.1 should also already come with SSE4 support ... teh ... hail the codebloat.

The /Qax checks weren't removed, it seems Intel still wants to hide that their processors are crap and fear their own compiler producing dozen times superior code on AMD. An easy thing is to boycott Intel on the processor part and also companies like Dell which get bribed for using their crap.

ICL will product CPU ID check when you use optimize flag other then K or W. It will check your CPU ID to ensure it is Intel CPU, otherwise it will quit the code immediately. It also true on the Qx flag. The ICL check depend on CPU ID, not the CPU Extension.

[Paul Oblomov]

AXP 3000 ?!?! WOW
I've got twice more powerfull CPU... Damn!
There's smth strange with my system :( X-men 3 1080p - 10seconds -- fine. Then - slow as hell. Tried CoreAVC - the same sh*t.

[MatMaul]

for libfaad and realaac I use the last snapshot of gcc 4.1.1.
for my next builds I disable the loop unroller.

[videomixer9]

Well better try it before if it's really the culprit, doesn't take to long to do a compiling test, faad and realaac compile in 30 secs or so.

Athlon 64 3200+ twice as powerful? heh. 64bit doesn't mean it has twice the speed, an X2 would be a different thing but libavcodec doesn't do multithreading for h264 yet properly. Try to check for weird filters in your system and e.g. check filter graphs for anything weird being active or your player not using proper acceleration.

[videomixer9]

ICL will product CPU ID check when you use optimize flag other then K or W. It will check your CPU ID to ensure it is Intel CPU, otherwise it will quit the code immediately. It also true on the Qx flag. The ICL check depend on CPU ID, not the CPU Extension.

So any easy patch for ICL 9.1 libs there?

[LoRd_MuldeR]

I get extreme CPU usage when I enable KernelDeinterlacer with your latest builds. I even can't used it for real-time playback on my AthlonXP 2800, because I get too high CPU usage and A/V dysnc plus stuttering. With TomsMoComp it works fine! And remember I used KernelDeinterlacer in ffdshow some time ago with "normal" CPU usage. This makes me think there's something wrong with KernelDeinterlacer code in latest builds. Maybe it's ICL specific problem?

[videomixer9]

maybe, kerneldeint regularly get icl into new dimensions of memory usage.

I'll update the latest builds with a new kerneldeint. Dunno what it was but should work fine now probably. Must've been ICL being out of memory again before. This (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build should have a fine kerneldeint now.

[LoRd_MuldeR]

maybe, kerneldeint regularly get icl into new dimensions of memory usage.

I'll update the latest builds with a new kerneldeint. Dunno what it was but should work fine now probably. Must've been ICL being out of memory again before. This (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build should have a fine kerneldeint now.

Damn, you are fast! That fixed the problem perfectly :)

[clsid]

So any easy patch for ICL 9.1 libs there?
You can do it rather easily with a hex editor. Just search for 'genu', 'inei' and 'ntel'. Then replace 3d47656e75, 3d696e6549 and 3d6e74656c with a900000000.

[videomixer9]

nice, that's easy, nicely obscured :p

[MatMaul]

Well better try it before if it's really the culprit, doesn't take to long to do a compiling test, faad and realaac compile in 30 secs or so.

Athlon 64 3200+ twice as powerful? heh. 64bit doesn't mean it has twice the speed, an X2 would be a different thing but libavcodec doesn't do multithreading for h264 yet properly. Try to check for weird filters in your system and e.g. check filter graphs for anything weird being active or your player not using proper acceleration.
The problem is I don't have any problem to decode aac file with faad and my pentium M with my last builds (SSE and SSE2 builds work on my pc).

@Paul Oblomov : Can you try my last build please (20060517)?

[Egh]

This build should have a fine kerneldeint now.

Yet it seems new build crases on MP3 if mp3lib is used on Athlon XP here.

[Paul Oblomov]

videomixer9
K8 faster that K7. Linear x2 boost.

MatMaul
The same sh*t :( I'm switching back to CoreAAC.

BTW - videomixer9 latest build does the same sound. Since I don't know if there's anything like frame editor for aac, I can rip this track of and share, so you can find a solution.

edit
Extracted it out. Winamp plays well ;) 58Mb
Size: 61644528 bytes
Format: AAC
MPEG-2 LC-AAC
Sample Rate: 48000
SBR: Not Present
Channels: 6 Mode: 5.1
Bitrate: VBR

edit once again
Cutted with hexworkshop ~2mb
http://rapidshare.de/files/20812918/Track21.rar.html

[issa]

Rev. 2546 pure GCC 4.1.1 testing build,

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20817522/ffdshow-2546-gcc-sse2-20060519.exe.html) (updated)

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20818308/ffdshow-2546-gcc-sse-20060519.exe.html)

I am trying a different optimize flags to see if there is any speedup on pure GCC build.

Compiler: ICL 9.1.22 (msvcrt 8 included + patched intel lib) + GCC 4.1.1
CPU Extension: SSE2 (Compiled with -QxN -QaxP)
Download: RapidShare (http://rapidshare.de/files/20824815/ffdshow-2546-icc-sse2-20060519.exe.html)

People have AMD CPU with SSE2, please help me to test if the patched work, since I don't have AMD CPU.

[Paul Oblomov]

I found a problem with my HDTV speed! Seems like my NTFS partition where those trailers placed is f**king fragmented OR bad mft table. Maybe old or whatever. Recopying to just another folder - and all them played nice and sweet!!! :D Really weird! So it's not my "slow" PC or whatever nor ffdshow! Sorry, for the inconvinience :(

[JarrettH]

Admittedly, issa's builds are the only ones that don't crash when I use my image settings (live tv, divx/xvid, DVD). I don't know what's different about them, but they consistently work for me. Using rev2546 ICL9 SSE

[videomixer9]

Yet it seems new build crases on MP3 if mp3lib is used on Athlon XP here.

Yeah I broke it with GCC but libmad is usually set as default for my installer and I just hate mp3lib so much :p The sound libs in libmplayer are just way to easy breakable. Cannot optimize the video part without the crappy audio codecs breaking all the time. I usually benchmark it for video on my system and am happy if it's very fast, not a filterfreak and not a fan of audiocodecs in libmplayer.

Okay now I'm seriously pissed off by this, got no fucking clue which of the switches breaks mp3lib since removing most of them didn't help a bit. Gotta love this.

[Livesms]

Rev. 2546 pure GCC 4.1.1 testing build,

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20817522/ffdshow-2546-gcc-sse2-20060519.exe.html) (updated)

Compiler: GCC 4.1.1 (All files builded by GCC 4.1.1)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20818308/ffdshow-2546-gcc-sse-20060519.exe.html)

I am trying a different optimize flags to see if there is any speedup on pure GCC build.

Compiler: ICL 9.1.22 (msvcrt 8 included + patched intel lib) + GCC 4.1.1
CPU Extension: SSE2 (Compiled with -QxN -QaxP)
Download: RapidShare (http://rapidshare.de/files/20824815/ffdshow-2546-icc-sse2-20060519.exe.html)

People have AMD CPU with SSE2, please help me to test if the patched work, since I don't have AMD CPU.

I've got AMD Sempron 3000+ x64 (SSE2 SSE3) - and in hour or two I'll tell you result.

[videomixer9]

wow I finally found what broke mp3lib. If nothing breaks again I stop fiddling around with GCC params too much now. Thanks for the report again. But I just love fiddling around with GCC params to try and squeeze out some more performance on decoding for my box :P

other than that i'd be interested if the patched lib really works though I'd prolly use the combination of QxK and QaxN

The thing with libavcodec compiling and why it didnt fail on x64 target with ICL was btw. very easy after I remembered that usually ffmpeg gets configured before compiling, on x64 HAVE_MMX is undefined and thus handcoded MMX stuff won't be compiled, if I remove it from config.h it of course works then. Though, this prolly means that if you change it when doing x64 compiles it will be slower than most other compiles, it seriously slower without the handcoded MMX stuff.

[issa]

wow I finally found what broke mp3lib. If nothing breaks again I stop fiddling around with GCC params too much now. Thanks for the report again. But I just love fiddling around with GCC params to try and squeeze out some more performance on decoding for my box :P

other than that i'd be interested if the patched lib really works though I'd prolly use the combination of QxK and QaxN

The thing with libavcodec compiling and why it didnt fail on x64 target with ICL was btw. very easy after I remembered that usually ffmpeg gets configured before compiling, on x64 HAVE_MMX is undefined and thus handcoded MMX stuff won't be compiled, if I remove it from config.h it of course works then. Though, this prolly means that if you change it when doing x64 compiles it will be slower than most other compiles, it seriously slower without the handcoded MMX stuff.

Which gcc flags break the mp3lib?

[videomixer9]

doubt you use it but it was -fforce-addr. I originally added this after reading that it may be useful on gentoo forums, obviously not that useful with mp3lib.

Another tip, try the resize filter if you use aggressive optimizations, it may produce weird blocky video with some switches. Other thing is libfaad, it will produce weird sound if you use too aggressive optimizations. In libavcodec the vorbis decoder may break.

Yeah I broke a lot of stuff already :p

[issa]

doubt you use it but it was -fforce-addr. I originally added this after reading that it may be useful on gentoo forums, obviously not that useful with mp3lib.

me too... maybe it's not good on windows.

[Egh]

Yeah I broke a lot of stuff already :p

Not that I use libmp3 much but still was worth reporting :)

Now it seems to work.

BTW, I think some MPEG-1 playback was b0rked as well in previous build, don't remember whenever it was libavc or libmpeg2 responsible (was reproducibly crashing with one of these).

Now that file seems to work OK>

[videomixer9]

Probably due to the same reason, I used that flag for some time. libmpeg2 is now ICL which produces pretty reliable code, so I guess it may have been libavcodec, per default the installer will enable libmpeg2 if you enable it on install.

[MatMaul]

Finally I have problem with libfaad2 too on my pc, the file of Paul Oblomov sounds crap with ANY builds : I tried to compile libfaad2 without optimizations flags with 2 gcc versions (4.0.3 4.1.1), that don't work
and that don't work also with the last build of videomixer9 (ffdshow-20060519-rev2546-icl91.exe), the last celtic druid build.
This sample works great with the internal aac mpc decoder

[videomixer9]

it indeed has problems with both realaac and libfaad ... it works fine in winamp e.g. this must have to do with the code.

Well e.g. this is fucked up http://www.mplayerhq.hu/MPlayer/samples/A-codecs/AAC/faad2-fail.mkv too ... guess I lookup mplayer archives for a fix before posting a bug report or try to acquire some other versions of the code that already has the real entrypoints needed for ffdshow.

used a dll from rarewares.org and it has the same problems, so the error must be somewhere in the ffdshow code.

[dk75]

clsid svn2546 MSVC71/GCC345 and no problem with this faad2-fail.mkv when using realaac, libfaad2 or CoreAAC.
But you should download "[Shinsen-Subs] Ergo Proxy - 06 [H264 AAC].mkv".
It have AAC/MPEG2/SBR-LC audio stream that crash libfaad2 on this clsid build and report audio to be 6ch 96kHz (it is 6ch 48kHz) and playback in slowmotion with CoreAAC (build upon faad2) or with mplayer.
But encodes of earlier episodes with AAC/MPEG2/SBR-LC audio stream plays fine.

[videomixer9]

The example was fucked up before but now it plays back fine too, must've been some sideeffect or I mixed it up with another example, hm. It's an older failure thing too, ah whatever. Will try the shinsen release.

Try to enable 32bit output mode with the shinsen release, works for me then oddly, otherwise it's just silent, it shows bitrate etc. though properly and all other infos. CoreAAC doesn't work either, it sometimes has some sound, MPC internal AAC decoding is also mostly just silent.

[Paul Oblomov]

I'm a BuG Man ;)

[Bathrone]

ffdshow-20060519-rev2546-icl91.exe - Crashing on explorer.exe from libavcodec.dll since installing WMP 11 BETA each time Im playing back avi's containing xvid video.

[foxyshadis]

maybe, kerneldeint regularly get icl into new dimensions of memory usage.

I'll update the latest builds with a new kerneldeint. Dunno what it was but should work fine now probably. Must've been ICL being out of memory again before. This (http://bittekeinspam.googlepages.com/ffdshow-20060518-rev2546-icl91.exe) build should have a fine kerneldeint now.
64bit build? 3dnow? o.O Everything's crashing from trying to execute prefectw now (a 3DNow!/x64 instruction). Anything change lately?

Last version to work correctly is 20060513, as far as I can tell. Which is bizarre, because I'm sure I was using 5/17. Huh, guess not.

[issa]

Rev. 2546 GCC OPTIMIZE FLAGS test build, -fforce-addr removed;

Compiler: GCC 4.1.1 (All files build by GCC)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20908228/ffdshow-2546-gcc-sse-20060520.exe.html)

Compiler: GCC 4.1.1 (All Files build by GCC)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20908884/ffdshow-2546-gcc-sse2-20060520.exe.html)

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20908693/ffdshow-2546-icc-sse-20060520.exe.html)

Please someone help me to test if the optimzie flags help to improve speed, and also if it break any part of ffdshow.

[videomixer9]

Sounds like the ffdshow-20060519-rev2546-icl91.exe build actually got some 3dnow instructions in it, if it does I don't really care as I give shit about Intel processors, I won't fix that :p KernelDeint crashing from 3dnow would be odd though cause ICL doesn't generate 3Dnow code.

And Xvid and WMP11 beta runs fine here so I bet you got an Intel too.

[Episode]

Ahem.. still there's no need to be extremely rude for those who do use intel processors.. and please try to keep your language clean :D

[videomixer9]

Your fault buying processor from a company that needs to rig tests to win, use stupid cpuid checks instead of trying to built a decent FPU unit which is specially useful for this kind of thing.

Intel buyers mostly fell for the stupid marketing of a big company that cannot get around the fact that their processor designs cannot compete fairly against others.

You see their fear of AMD and others everywhere, e.g. with 3DNow! units, in certain cases using them kicks Intels ass so much that they will buy up any tester trying to use special 3dnow! code. Intel's old style 387 FPU even sucks so much that most people tell you to stay away from using it nowadays ... kinda sad for a company fussing all about their new processors coming soon that will suck again but win rigged tests in integer competition but horribly lose in most FPU tests while costing twice the money.

[foxyshadis]

Well yes, that's why I mentioned that it was a 3dnow instruction; it's a core duo. At least label current builds non-intel. Oh well. (lol @ using ICL to generate amd-only code, even if it is GCC or inline that does it.)

The instruction is during the lavc initialization, so anything using it is affected, no matter what filters.

It's also an official amd64 instruction now though, which is why I wonder if it didn't get accidentally compiled as a 64-bit build. (Not supported on em64t, oddly. Then again, an SSE instruction does the same thing. Could be a preprocessor define on the new deint update that bases its value on the march.)

btw, did you update with kerneldeint, or leakkerneldeint?

Edit: AMD's architecture is still only slightly less broken than Intel's current, from the high view. Yes, its native x64 functions better and it has a better memory controller, but it's as stuck with the legacy crap as Intel is, and even transitioning to 64 only drops some of the problems. Comparitively, power and solaris are significantly better architectures, although you end up with the exorborant cost (and ibm's recent mis-development of power, leaving other companies to do its job better). Altivec has shown to be stronger than any of the x86 simd extensions, when given a good compiler or asm guru.

[videomixer9]

3dnow! and 3dnow!ext should be the same in 64bit and 32bit only processors from AMD. It works all fine on my Athlon-XP. I didn't update with anything external.

Altivec as superior tech made me wonder the most about Apple changing to Intel, must've been enough money involved besides IBM being to slow on delivering new versions, though xbox360 makes you wonder about that too. Problem is x86 to some other tech is a hard change to do, even though I think that MS e.g. could magically come out with a Windows for PowerPC and others as they got such versions in the past already, Linux e.g. supporting other tech anyways.

However AMD does way better standard x86 design, their 64bit clou included. Their regular FPU is way better.

[Alante]

I don't get it,...why didn't he fixed "Error while registering FFDshow.ax" I have their latest build FFDshow 2006.05.13 rev2546,..:(

[LoRd_MuldeR]

I don't get it,...why didn't he fixed "Error while registering FFDshow.ax" I have their latest build FFDshow 2006.05.13 rev2546,..:(

Reading the instructions might help :rolleyes:

vcredist_x86.exe (runtime libs needed for these builds to work)

[Bathrone]

While I appreciate your efforts Videomixer9, I think the builds should be labelled as AMD only if thats the way it is.

Yes, Im using an old Northwood P4.

If your going to not address this problem it will leave a gap for all Intel users to find other builds with the same performance and patches.

[issa]

If I remember right, Intel build a faster FPU unit then AMD.
However, on recent AMD CPU, ie 64bit CPU, it have the fastest vectorize unit. Therefore, using SSE2 for FP operation on AMD 64bit CPU should be faster than using FP operation.
Just for information, using SSE2 for FP in GCC, ie -msse2 -mfpmath=sse, will product code pass "Kahan's Floating Point Test".
MSVC, ICC produce code that not pass all the "Kahan's Floating Point Test" when turn on optimize flag, ie -O1 -O2 -Ox.
MSVC produce code pass all "Kahan's Floating Point Test" when turn off optimize flag or turn on optimize flag with "-arch:SSE2".
Intel compiler will produce code pass all "Kahan's Floating Point Test" when turn on "-Op" flag.

[bitcore]

I agree with Bathrone, I too use an intel in my primary computer. At the time, I built this for low power consumption to go in a car, now it's my primary machine. My laptop is an intel chip and with most all laptops you have no choice what chip goes in it.

I too am a firm believer in AMD as the best price per preformance chip maker, my main server has an old 1800+ in it for example, but not all computers use an AMD chip. I see no reason to start a chip war with FFDShow builds, if you want the builds to be AMD only, label them as such so people who have an intel chip who don't care or who own a mixed goup of computers wont run into headaches like I did....

The 5/05 build that I got from free-codecs.com crashed my machine and locked it up with a garbled display. I lost work when that happened and it pissed me off. Just letting you know.

[Bathrone]

For those with Intel cpu's, the work Issa is doing is top notch. Im using his following build:

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2

Great stuff Issa, all works mate

[foxyshadis]

The 5/05 build that I got from free-codecs.com crashed my machine and locked it up with a garbled display. I lost work when that happened and it pissed me off. Just letting you know.
Do you have up-to-date video drivers? Or Win98? A codec or even a media player should never be able to take down 2k/xp like that, unless perhaps it was set on realtime priority, but even that wouldn't matter for a straight crash.

[videomixer9]

He just made up that crash anyways to try and pressurize me cause he was so stupid to buy an Intel processor :p Though I'd also maybe recommend Intel user issa's build, he seems to also optimize nicely, not like I'm in a war to gain as much users of my build as possible.

[Livesms]

Rev. 2546 GCC OPTIMIZE FLAGS test build, -fforce-addr removed;

Compiler: GCC 4.1.1 (All files build by GCC)
CPU Extension: SSE
Download: RapidShare (http://rapidshare.de/files/20908228/ffdshow-2546-gcc-sse-20060520.exe.html)

Compiler: GCC 4.1.1 (All Files build by GCC)
CPU Extension: SSE2
Download: RapidShare (http://rapidshare.de/files/20908884/ffdshow-2546-gcc-sse2-20060520.exe.html)

Compiler: ICC 9.1.22 (msvcrt 8 included /w patched intel lib) + GCC 4.1.1
CPU Extension SSE or SSE2
Download: RapidShare (http://rapidshare.de/files/20908693/ffdshow-2546-icc-sse-20060520.exe.html)

Please someone help me to test if the optimzie flags help to improve speed, and also if it break any part of ffdshow.

Nothing of this are'nt working on my WinXP SP2

I cant play no video - "Error - like codec not installed".

[breez]

Aspect ratio setting in 'resize & aspect' seems to be in effect always even if the 'resize & aspect' isn't enabled. Is this a bug or desired behavior? Using a rev 2546 compile (by who? can't remember).

[videomixer9]

a bug that's in ffdshow since longer already iirc, it's not always like that but appears under some random conditions.

[Episode]

He just made up that crash anyways to try and pressurize me cause he was so stupid to buy an Intel processor :p

Now could you please stop this. You have absolutely no right to call anyone stupid because of their choice of processor, everyone has a freedom to do what ever they want with their money.

I did notice that smiley on the end of that sentence, but it really didn't feel like a joke since you are just making people with Intel processors very unhappy with those comments.

Just label your builds with AMD only tag and everything will be fine again, don't use this thread to start another Intel vs. AMD war.

Thanks.

[issa]

Nothing of this are'nt working on my WinXP SP2

I cant play no video - "Error - like codec not installed".

Did your CPU support SSE at least?
If so, I assume uninstall the previous ffdshow before install the
new one. Sometime we need to reboot the system after uninstall
the ffdshow because the ffdshow.ax still lock by the system in
some resone that I don't know. Please try reboot your system
after uninstall the old ffdshow before install a new one if you
find an error message that said cannot write the file ffdshow.ax
or msvcr8.dll.

[videomixer9]

Intel whiners edition - here (http://bittekeinspam.googlepages.com/ffdshow-20060521-rev2546-icl91.exe) (yeah I have pity for crybabies and they may have fallen for intel rigged tests after all, poor creatures)

And after all which company started e.g. with loser behaviour like cpuid checks ...

[Nic]

@videomixer9: Keep your posts polite and cut out the swearing or you'll be striked.

@all: Enough about Intel & AMD now. Keep thread on topic, or it will be closed and offenders striked.

@Episode: Good posts. Thanks for trying to keep the peace.

-Nic

[obieobieobie]

Thank you, Nic.

[Lemonzest]

whats diffrent in the whiners edition?

[videomixer9]

It may run on Intel processors if ICL didn't break things on it's part again like it did before with auto parallelization which runs independant from any checks but crashed on Intel processors but worked fine on all others. If a current build runs fine no need for any updates. h264 you lose upto 2-3fps on high profile 720p decoding with this build just by changing from AMD to Intel profile @ Athlon XP 3000+ e.g.

[bob0r]

@videomixer9

Can you explain to me how i can fix DTS audio for the latest ffdshow revision?

I want to host a SSE and SSE2 on my page and i am tired of waiting for Milan :p

(also any other needed fixes/patches if possible please)

[videomixer9]

I didn't do much but replace the sources with the one from the libdca project on videolan.org found at svn://svn.videolan.org/libdca/trunk/libdts.

It may actually be a step back but at least that code properly works on anything I tested.

In parse.c at the very end you find a function named getVersion added to the code, copy that function and recopy it to the parse.c of the checked out code that you use to overwrite the code of libdts in ffdshow source tree.

I didn't really analyse what is broken, probably just removing the changes from with the dscaler merge would've been enough.

However, here (http://bittekeinspam.googlepages.com/dts.patch) is a patch you can apply to the libdts dir.

Only other patch is 6ch vorbis thing here (http://bittekeinspam.googlepages.com/ffdshow_vorbis6ch.patch), accuracy patch from kurosu here (http://bittekeinspam.googlepages.com/ffdshow_accuracy.diff), updated multithreading patch is on sf.net (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491). GCC params are everyones own buisness though current one for me is here (http://bittekeinspam.googlepages.com/ffdshow_gccoptimization.diff) and runtime cpudetect just a preprocessor added which doesn't do much anyways. No clue on the LPCM problem.

[Avish]

Just out of curiousity I did this small comparision:

No PP & no other filters are on,
VMR9 Renderer,
CPU= 1.91Ghz Athlon XP 2600+

Sample
Video: DivX5 656x480 29.97fps 1005Kbps [Video 0]

Results:
Milan's ffdshow-20041012-sse:
User: 11s, kernel: 11s, total: 23s, real: 29s, fps: 85.8, dfps: 67.9

VM9's ffdshow-20060519-rev2546-icl91:
User: 11s, kernel: 11s, total: 23s, real: 29s, fps: 86.7, dfps: 67.4

Issa's ffdshow-2546-gcc-sse-20060520:
User: 11s, kernel: 11s, total: 23s, real: 30s, fps: 85.7, dfps: 65.6
Interesting results!!

[bob0r]

@videomixer9

Thanks! It worked.

ffdshow-2546-gcc4.0.3-sse-x264.nl.exe
ffdshow-2546-gcc4.0.3-sse2-x264.nl.exe

are now both hosted on x264.nl.

For now i'll do updates manually, as ffdshow development is not changing that much that i can't keep up.

[_xxl]

http://rapidshare.de/files/21101285/ffdshow-20060522.exe.html

[videomixer9]

Just out of curiousity I did this small comparision:
[...]
Interesting results!!

SHOCKING! I was so shocked I fiddled a bit around and got ready a 1337 speed edition! (mirror (http://www.filepoint.de/download/4711-dl-ffdshow-20060522-rev2546-sp33d1337edition_exe), mirror (http://www.load.to/?d=cVLr1pW1Tg))

If this here (http://bittekeinspam.googlepages.com/ffdshow-20060522-rev2546-sp33d1337edition.exe) is slower than the previous builds I'm going to cry!

milan 20041012-sse
User: 80s, kernel: 0s, total: 81s, real: 90s, fps: 433.3, dfps: 389.4
milan 20051129
User: 77s, kernel: 0s, total: 77s, real: 86s, fps: 453.7, dfps: 407.9
my own 20060519 amd:
User: 74s, kernel: 1s, total: 75s, real: 83s, fps: 466.3, dfps: 422.3
sp33dedition v2 :p
User: 73s, kernel: 1s, total: 74s, real: 81s, fps: 471.2, dfps: 430.8

puh ... save. slight glitch in the first try.

[Egh]

SHOCKING! I was so shocked I fiddled a bit around and got ready a 1337 speed edition!

If this here (http://bittekeinspam.googlepages.com/ffdshow-20060522-rev2546-sp33d1337edition.exe) is slower than the previous builds I'm going to cry!




The bandwidth limit for this site has been exceeded.


I guess you need a better hosting or prooly mirroring releases on rapidshare or whatever :)

I can open the main page but attempt to download any binary atm leads to that nasty message.

[Kostarum Rex Persia]

I guess you need a better hosting or prooly mirroring releases on rapidshare or whatever :)

I can open the main page but attempt to download any binary atm leads to that nasty message.

Yes, you are right, same massage shows to me.

Not rapidshare, please:scared: Use megaupload or mytemdir, videomixer9.

[Avish]

No PP & No Filters used,
VMR9 Renderer,
CPU= 1.91Ghz Athlon XP 2600+,

Sample Video: DivX 5 720x560 25.00fps 1151Kbps

Results:
Milan's ffdshow-20041012-sse:
User: 8s, kernel: 9s, total: 17s, real: 19s, fps: 55.8, dfps: 50.8

VM9's sp33dedition:
User: 7s, kernel: 10s, total: 17s, real: 19s, fps: 57.4, dfps: 51.5
BTW VM9, how do u get such high fps? Can u please post all the related specs?

OK. Me too got high fps when I used smaller resolution video sample. XVID 352x208 25.00fps 1564Kbps.

User: 1s, kernel: 0s, total: 1s, real: 5s, fps: 446.9, dfps: 143.0So now it leavs dfps... can anyone explain?

[videomixer9]

I use null renderer cause I don't want to test how fast Microsoft renderers are, besides they always end up framelimited here, the test video is xvid 640x352 23.98fps. It's a 24 min thing though and I use this lower res to have more gap in fps to not get into having too less difference to see if just something was suddenly active in the background.

Stupid google, but porbably too many warez turds used it again, eh?

[Avish]

I use null renderer cause I don't want to test how fast Microsoft renderers are, besides they always end up framelimited here, the test video is 640x352 23.98fps. Stupid google, but porbably too many warez turds used it again, eh?OK, that explains it.

Another thing I wanted to ask u is that with Milan's build I get this http://img90.imageshack.us/my.php?image=sbuild4ic.jpg
And with ur builds I get this http://img90.imageshack.us/my.php?image=sbuild1bk.jpg
Look at the buttons, slider bars, drop down arrow etc. See the difference? What's causing it? & What should be done to fix it?

Strange! When I open it through MPC, all the buttons are skinned nicely, but when I open it through Start->ffdshow->video decoder configuration, all the buttons are flat again.

[videomixer9]

I removed the external manifest from the installer as one should be embeded, however that one makes the styles go old style somehow. guess I should include it again or adjust the included one as it seems there is some adjustments to be made to make it look new style. Just copy the external manifest and it should look styled again. You don't need to uninstall other builds when installing another btw.

[Avish]

I removed the external manifest from the installer as one should be embeded, however that one makes the styles go old style somehow. guess I should include it again or adjust the included one as it seems there is some adjustments to be made to make it look new style. Just copy the external manifest and it should look styled again. You don't need to uninstall other builds when installing another btw.ffdshow folder already have one "Microsoft.VC80.CRT.manifest", anyway I copied one from another folder & put it in ffdshow folder. Now should I name it "ffdshow.ax.manifest" to work properly?

OK. renaming it "ffdshow.ax.manifest" works fine. All is skinned nicely.

Hmmm. It isn't working when VFW configuration is opened.

OK. Prob solved. First I installed older build which workd OK, then I installed your build over it & now everything is skinned properly.

Thanks.:)

[videomixer9]

I meant ffdshow.ax.manifest and not renaming the microsoft runtime manifest, well you got it anyways now :p The manifest seems to include some infos about the common dialog controls to be used, with this info missing it uses another version it seems which results in no skinning, next builds I'll include the original manifest again, though this isn't really a major issue, but the manifest isn't large anyways.

[Avish]

I meant ffdshow.ax.manifest and not renaming the microsoft runtime manifest, well you got it anyways now :p The manifest seems to include some infos about the common dialog controls to be used, with this info missing it uses another version it seems which results in no skinning, next builds I'll include the original manifest again, though this isn't really a major issue, but the manifest isn't large anyways.When I said "I copied one from another folder" I meant copied another manifest file [I copied mplyarec.ext.menifest] & renamed that one. Not the one u are mentioning!:p & It almost worked! But not for VFW configuration, so I tried "double install method" mentioned in my previous post & It worked fine.:D

[videomixer9]

clsid svn2546 MSVC71/GCC345 and no problem with this faad2-fail.mkv when using realaac, libfaad2 or CoreAAC.
But you should download "[Shinsen-Subs] Ergo Proxy - 06 [H264 AAC].mkv".
It have AAC/MPEG2/SBR-LC audio stream that crash libfaad2 on this clsid build and report audio to be 6ch 96kHz (it is 6ch 48kHz) and playback in slowmotion with CoreAAC (build upon faad2) or with mplayer.
But encodes of earlier episodes with AAC/MPEG2/SBR-LC audio stream plays fine.

btw. this AAC issues for me seemed to be only due to reclock being at work here, it worked fine after I got rid of reclock. However newest CoreAAC build got it's problems however. My newest build has update libfaad2 sources and plays it fine, though older seem to work too. Problem seems to be with other things that cannot handle the 96khz audio.

[LoRd_MuldeR]

I found a problem with multi-channel AAC audio, for example in that Superman trailer. With "libfaad2" I only get strange noise, while "realaac" works fine. However "libfaad2" works fine with my audio files (stereo). Tested with latest build, but noticed before...

[videomixer9]

No problem with it here.

[LoRd_MuldeR]

No problem with it here.

strange :confused:

[Avish]

I found a problem with multi-channel AAC audio, for example in that Superman trailer. With "libfaad2" I only get strange noise, while "realaac" works fine. However "libfaad2" works fine with my audio files (stereo). Tested with latest build, but noticed before...Same here, I get noise even with stereo AACs. "realaac" workes fine with both.

BTW, nothing can play that file smoothly on my machine.:rolleyes:

[videomixer9]

heh, works all fine here and i found no sample with any error. anything coming out properly out of my audigy2 zs

[LoRd_MuldeR]

Try this sample:
http://jfl1974.free.fr/upload/superman.mp4

[videomixer9]

I did try it and there's perfect 5.1 sound coming out. Anything correct except for the video stuttering around a bit ...

[LoRd_MuldeR]

I did try it and there's perfect 5.1 sound coming out. Anything correct except for the video stuttering around a bit ...

No matter what I do, doesn't work...

[videomixer9]

does it generally not work with any build or decoder or only my ffdshow build, however as I cannot reproduce a problem I cannot fix it.

[Avish]

No matter what I do, doesn't work...This is strange :confused: I tried it in GraphEdit & sound is coming out perfectly with "libfaad2".

[LoRd_MuldeR]

This is strange :confused: I tried it in GraphEdit & sound is coming out perfectly with "libfaad2".

Approved :scared:


//EDIT

Works in Graph Edit and mplayer2.exe. Only MPC seems to be effected. Any ideas?
Any ideas ?!?

[Avish]

Approved :scared:Well, it seems like MPC problem to me, cause even WMP is producin' 5.1 sound using "libfaad2".

[videomixer9]

dunno, I'm using MPC rev611 and it works fine, maybe try chose some other audio renderer.

[Avish]

Approved :scared:


//EDIT

Works in Graph Edit and mplayer2.exe. Only MPC seems to be effected. Any ideas?
Any ideas ?!?I'm using WMP10. Don't know whats with MPC, I tried changing splitter to haali, I tried disabling internal audio switcher, but nothing works.

[LoRd_MuldeR]

dunno, I'm using MPC rev611 and it works fine, maybe try chose some other audio renderer.

I use same rev. tried all audio-related options. no change...

[Avish]

dunno, I'm using MPC rev611 and it works fine, maybe try chose some other audio renderer.That too doesn't work. :( Using same rev.

[LoRd_MuldeR]

Maybe some MPC bug that should be reported to Gabest?

[Avish]

Maybe some MPC bug that should be reported to Gabest?I thought so too, but everything is working fine with VM9. & What are we gonna report? We don't even know the problem. ;)

[videomixer9]

what about the pin info?

directsound pin is for me like this

- Connected to:

CLSID: {0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
Filter: ffdshow Audio Decoder
Pin: Out

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Audio

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0





and ffdshow audio for me:

- Connected to:

CLSID: {79376820-07D0-11CF-A24D-0020AFD79767}
Filter: Default DirectSound Device
Pin: Audio Input pin (rendered)

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Set as the current media type

- Enumerated media type 1:

Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: MEDIASUBTYPE_None {E436EB8E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 230400
cbFormat: 0

[LoRd_MuldeR]

ffdshow audio:

- Connected to:

CLSID: {79376820-07D0-11CF-A24D-0020AFD79767}
Filter: Default DirectSound Device
Pin: Audio Input pin (rendered)

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Set as the current media type

- Enumerated media type 1:

Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: MEDIASUBTYPE_None {E436EB8E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 230400
cbFormat: 0


DirectSound Device:

- Connected to:

CLSID: {0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
Filter: ffdshow Audio Decoder
Pin: Out

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Audio

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0

[videomixer9]

doesn't look like there's anything different there.

[Avish]

ffdshow audio:
- Connected to:

CLSID: {18C16B08-6497-420E-AD14-22D21C2CEAB7}
Filter: Audio Switcher
Pin: superman.mp4 / GPAC ISO Audio Handler

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Set as the current media type

- Enumerated media type 1:

Unknown

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Stream {E436EB83-524F-11CE-9F53-0020AF0BA770}
subtype: MEDIASUBTYPE_None {E436EB8E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_None {0F6417D6-C318-11D0-A43F-00A0C9223196}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 230400
cbFormat: 0

directsound:
- Connected to:

CLSID: {18C16B08-6497-420E-AD14-22D21C2CEAB7}
Filter: Audio Switcher
Pin: Out

- Connection media type:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 4608Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 576000
nBlockAlign: 12
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 ca 08 00 0c 00 10 00 þÿ..€»...Ê......
0010: 16 00 10 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71 €..ª.8›q

- Enumerated media type 0:

Audio

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 0
Hope I've posted the correct ones!!:D

Well, my filter "Audio Switcher" is different than u two...

[videomixer9]

btw. which splitters do you use ... with haali splitter the audio switcher is e.g. not really needed anyways if you don't want to remap channels. Does it always say GPAC Iso Audio Handler? hm ...

[Avish]

btw. which splitters do you use ... with haali splitter the audio switcher is e.g. not really needed anyways if you don't want to remap channels. Does it always say GPAC Iso Audio Handler? hm ...I use internal mp4 splitter. & I think that GPAC thing is always there, even with the video, like this: Video: MPEG4 Video (H264) 1920x1088 [GPAC ISO Video Handler]
Audio: AAC 24000Hz 6ch 161Kbps [GPAC ISO Audio Handler]What is that BTW?

[LoRd_MuldeR]

I use internal mp4 splitter.

I tried both, internal and Haali spöitter. With and without internal audio switcher.

[Avish]

I tried both, internal and Haali spöitter. With and without internal audio switcher.Your O in "spoitter" has two spots above it, making it look like human face. How come?

[videomixer9]

ö is a regular german letter like ä and ü, and it's right next to the l on the german keyboard.

[Avish]

ö is a regular german letter like ä and ü, and it's right next to the l on the german keyboard.Oh ok. I thought its my browser's "doing" ;) cause when I tried changing encoding method to Unicode, it lookd like this "sp?er".

[Kostarum Rex Persia]

@ videomixer9

I used your Intel ICL9 builds before, but on my Athlon XP, ICL9 builds refuse to work.

Can ICL 9.1 builds work on AMD?

[videomixer9]

First the libs are patched and second is that there is no reason ICL builds wouldn't work, only problem begins with automatic use of features like SSE2. ICL builds should work on any CPU, especially on Athlon XP as I got an Athlon XP myself. Besides I only did ICL9.1 builds, I never released any with some older version.

[Paul Oblomov]

Guyz, sorry, it maybe sounds kinda off top, but dunno where too ask here else. Maybe some of 'ya know program, which can switch output channels ? For ex. u need it to be played movie in headphones, but game sound must pass through speakers. Kx drivers (i'm using audigy 2 zs) can do such things. Maybe you know how to do that without chaging drivers ? Thx ;)

[celtic_druid]

Use your onboard sound for one, your SB for the other.

[videomixer9]

You want to do play both at the same time? If not just use an easy cable splitter which makes one connector into two, as often as you want when using analog output, too often may degrade quality or produce signal loss though :p

kX drivers kinda annoy me due to lack of EAX for gaming.

[Paul Oblomov]

Heh...
Well - I just need to swap channels by pressing button.

[videomixer9]

Wonder what you swap there, I use 5.1 sound all the time as noones annoyed by loud sound here so swapping some audio channels would be a stupid thing to do besides it using digital out, and gaming and watching a movie the same time, heh ... and EAX makes a difference to traditional D3D Sound for many games.

[Paul Oblomov]

I don't use 5.1 all the time, because it's stupid thing to do, in case if you're playing CSS... So any sujestions ?

[Kostarum Rex Persia]

First the libs are patched and second is that there is no reason ICL builds wouldn't work, only problem begins with automatic use of features like SSE2. ICL builds should work on any CPU, especially on Athlon XP as I got an Athlon XP myself. Besides I only did ICL9.1 builds, I never released any with some older version.

So, you saying that I have to manually disable SSE2 support from video decoder option in FFDSHOW?

Why you don't compile GCC 4.2 builds yet?

[videomixer9]

no you don't need to manually disable anything, it's just that ICL begins with checks from SSE2 on, SSE alone isn't affected. As said it works fine on Athlon XP without problems for a bunch of people incl. me.

Someone provides me with GCC cause I'm to lazy to compile and error all the time myself and GCC 4.2 wasn't under it yet as it seems to be less stable then the GCC 4.1.1 release I currently use.

[Isochroma]

Regarding the LPCM issue, I have a DVD with LPCM audio, and even though I've unchecked LPCM from the supported codecs in ffdshow, it still loads (raw formats are also unchecked). MPC's internal LPCM transform filter (decoder?) is enabled, but it doesn't seem to be loading. No audio plays, and during playback the Info & debug section of ffdshow shows nothing. Any ideas?

[videomixer9]

unchecked ... you mean you set it to disabled under codecs. Well, I had this issue before too, but now somehow nero audio decoder kicks in. If I block it manually, the MPC internal LPCM decoder refuses to work, though it may be that it doesn't support 20 and 24bit lpcm. So it maybe that it still finds ffdshow audio as fallback solution.

If anyone needs a sample try here: http://www.mplayerhq.hu/MPlayer/samples/MPEG-VOB/LPCM/

lpcm.vob doesn't work for me with MPC, Fever.vob e.g. does.

20/24 bit seems to be not supported as I guess from this codepassage:
*pDataOut = (float)(short)((pDataIn[0]<<8)|pDataIn[1]) / 0x8000; // FIXME: care about 20/24 bps too

After some thinking about the changes on ffdshow since rev2539 where it still worked I'll try fix the issue.

[videomixer9]

LPCM fixed edition: here (http://rapidshare.de/files/21290197/ffdshow-20060524-rev2546.exe.html) or here (http://www.filepoint.de/download/4936-dl-ffdshow-20060524-rev2546_exe)

(may change it again cause the current one kinda breaks TWOS support, milan kinda fucked up when adding twos support, if you wanna try twos get an sample here (http://www.mplayerhq.hu/MPlayer/samples/A-codecs/twos/))

[Isochroma]

Thanks, it works!

However, when LPCM is unchecked from the list of supported codecs, ffdshow still loads and by doing so, prevents MPC's internal decoder from working. In this case, nothing is decoded. Perhaps this is an issue with MPC?

[videomixer9]

No clue, I'd put it under random directshow effect. I doubt MPC as it works here okay, it may be ffdshow forgetting about dropping to accept those connections. MPC only if you'd set ffdshow as special filter. If I disable ffdshow LPCM here MPC doesn't use it anymore, with Nero blocked it's just silent then for 20/24bit lpcm as MPC doesn't support 20/24 bit LPCM.

[Isochroma]

New problem: I just made an AVI with WAV audio, but MPC closes instantly when I try to play it, regardless of whether LPCM is checked or not in supported codecs. With the audio track stripped off, it plays fine. When ffdshow is uninstalled, it plays fine with MPC's builtin PCM decoder.

Here is a sample (http://chromasubs.com/Misc/PCM.avi) AVI (1.7 MB)

OK, some weirdness... I just reinstalled ffdshow with LPCM enabled, and now it works fine. No crashes on either wav audio or LPCM. However, one problem remains: even if LPCM and raw are unchecked, ffdshow still loads when a DVD with LPCM track is loaded in MPC, and suppresses the builtin decoder, resulting in no audio.

[videomixer9]

so why not just use ffdshow as decoder, obviously no real need to use MPC internal one? PCM audio is just some bitshifts anyways. Dunno what's broken on your system there but here it's working without problems, disable it in ffdshow audio and MPC decoder is used, otherwise ffdshow and fine.

[bob0r]

GCC 4.1.1 is released.
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.1.1/

Did someone compile all ffdshow files with gcc 4.1.0 before? If so, what modifications are needed?

[_xxl]

http://rapidshare.de/files/21336643/ffdshow-20060525.exe.html
http://www.mytempdir.com/690253
http://www.megaupload.com/?d=14E5SLWL
http://www.sendspace.com/file/t72z6q
ffdshow-20060525-rev2546
Applied patches:
high accuracy libmad decoder,high accuracy tremor vorbis decoder,libavcodec proper vorbis 6ch and LPCM,libdts,libfaad2 fixes.
libmplayer.dll and libavcodec.dll are ICL9+GCC3.4.2.

[shon3i]

@videomixer9 and other uploaders please use www.mytempdir.com instead rapid and filepoint because are both same shit, and what is lastest build some link thanks

[videomixer9]

just finally get a better isp. :p mytempdir has neither a nifty uploadbar, nor does it save any stats and it only holds file for 21 days max, short said it sucks. filepoint offers me stats, direct downloads and doesn't have any limits I know of, if your ISP got too many kiddies that get you banned everywhere it's sth. they should bother with.

[sleepking]

@videomixer9 and other uploaders please use www.mytempdir.com instead rapid and filepoint because are both same shit, and what is lastest build some link thanks

i like google,because there i can use download tools. the others link use IE are too slow.

[breez]

It seems that all 2546 builds compiled with ICL9 randomly crash when seeking video (on my Athlon XP). Pure GCC builds work fine.

[shon3i]

just finally get a better isp. :p mytempdir has neither a nifty uploadbar, nor does it save any stats and it only holds file for 21 days max, short said it sucks. filepoint offers me stats, direct downloads and doesn't have any limits I know of, if your ISP got too many kiddies that get you banned everywhere it's sth. they should bother with.
Use then SendSpace, Megaupload etc.. or find some server like x264.nl, ask bob0r for mirror. About isp, i told you milion times i can't use different isp and many ppl's, so yo get different uploader.

@drevil_xxl Thank you

[_xxl]

It seems that all 2546 builds compiled with ICL9 randomly crash when seeking video (on my Athlon XP). Pure GCC builds work fine.
libmplayer.dll and libavcodec.dll are ICL9?

[videomixer9]

as i can never reproduce any of those people's problem with my athlon xp i'd say it's their systems. Also not helpful when people don't mention the exact builds they tested and which players and versions, especially as we all seem to apply patches now, one more one less and also use different settings. My expierence tells me that "all" doesn't mean all at all.

e.g. last cause that made skipping go wrong was the multithreading patch which is now available in other updated variants.

@shon3i tell me the country with that kind of sucking isp as the only payable one, i'd like to ban it on my other sites ;o

and hm, final gcc 4.1.1 out, need to get some update then I guess. I think it's kinda stupid that original MinGW project doesn't release any new ones anymore though. 4.1.x branch and 4.2.x branch don't seem to be that bad anymore as 4.x was on some points. kurosu should have some compiling fixes for gcc 4.1.x I think, dunno if those are sufficient, just scroll down to bottom of his page and download the pack there.

[MatMaul]

http://rapidshare.de/files/21336643/ffdshow-20060525.exe.html
http://www.mytempdir.com/690253
http://www.megaupload.com/?d=14E5SLWL
http://www.sendspace.com/file/t72z6q
ffdshow-20060525-rev2546
Applied patches:
high accuracy libmad decoder,high accuracy tremor vorbis decoder,libavcodec proper vorbis 6ch and LPCM,libdts,libfaad2 fixes.
libmplayer.dll and libavcodec.dll are ICL9+GCC3.4.2.

Can you publish your libfaad2 and libdts fixes please?

[shon3i]

@shon3i tell me the country with that kind of sucking isp as the only payable one, i'd like to ban it on my other sites ;oSure, europe ;)

[videomixer9]

that's not a country

[haruhiko_yamagata]

Output queue seems to be effective. Max 35% frame rate improvement! I'll test further before release.

I hope this one line patch would fix Umcompressed
audio connection.
http://sourceforge.net/tracker/index.php?func=detail&aid=1495022&group_id=53761&atid=471491

[videomixer9]

gotta hate sf maintenance ... always when you don't want it.

[shon3i]

that's not a country
it's beacuse if you ban this contry or this isp, you are ban half of EU.

btw thanks for mytempdir mirror, i must ask some question i see some vesion was support WMV 3/9 and WMA 9 pro, or i predict something

[videomixer9]

sounds like bullshit, germany (82 mio ppl) nor france (60 mio. ppl) nor scandinavia (over 20 mio. ppl) has an ISP which sucks that much, nor italy (58 mio. ppl) or spain (43 mio. ppl) and portugal (10 mio. ppl). Austria or Poland doesn't have forced proxies either, swiss neither. So it must be some major unimportant country. Obviously it's just you having that funny proxy forced.

T-Online, Free.fr, Wanadoo, Chello and Tiscali and Telefonica are prolly the largest ISPs and none of them got this.

I used mytempdir before your bitching but I won't use it again :p

[shon3i]

I used mytempdir before your bitching but I won't use it again You choice, but you make big mistake of course.

[videomixer9]

Well your ISP cannot be that big, so I doubt that, obviously it's no major ISP and you're not wanting to tell any names even more suspicious so you're probably just the regular whiner, as long as everyone from all major countries can download I don't have any problems, don't care about the other shitty small countries, especially not suckers in the EU like Greece. Must be the super secret nowdays which isp you use.

Mine is Congster, basically using the same infrastructure as T-Online uses. Monthly Traffic around 320 GB and flatrate without the DSL part costs 4.99€.

[bond]

videomixer9, you have been asked for cooling down by nic already...

[videomixer9]

I just wanna know about this mysterious ISP I never heard of, I cannot help but think that it's some made up thing as I don't know any major ISP with forced proxies in europe. So it sounds fake to me. Besides I'm really interested in ISP stuff, wanna know all the weird ISPs around the world. shon3i only seems to want to provoke and get his will, as he doesn't name anything it's whining to me.

[TheShadowRunner]

Kurosu, a new build from you would be greatly appreciated ;)
See you,

TSR

[MacAddict]

No need for the constant swearing. Given that I do appreciate your efforts on the new builds :-)

[Egh]

germany (82 mio ppl) nor france (60 mio. ppl) nor scandinavia (over 20 mio. ppl) has an ISP which sucks that much, nor italy (58 mio. ppl) or spain (43 mio. ppl) and portugal (10 mio. ppl).
:p

Amongst big EU member states you forgot the UK :) Here you can easily get 8mbps download w/o any traffic limits (like I have) and I don't have any difficulties downloading from either of the mirrors you put your builds on.

The ones complaining about downloads should just provide webhosting themselves :P

As for problems on Athlon XP, I never had any crashes with you recent builds at all while randomly seeking videos.

[foxyshadis]

Output queue seems to be effective. Max 35% frame rate improvement! I'll test further before release.

Wow. I'm glad it works so well, for an offhand suggestion. Does it utilize nearly 100% cpu now?

ps, guys, there's PMs for personal discussions.

[breez]

libmplayer.dll and libavcodec.dll are ICL9?

Yes, at least on your latest compile, but probably also on the other ICL builds I have tried during the past week or two.

[issa]

Off Topic
GCC 4.1.2 svn aka GCC 4.1.1 release.
Alias problem fixed.

Download: MegaUpload (http://www.megaupload.com/?d=2C4IL9XH)

[haruhiko_yamagata]

Wow. I'm glad it works so well, for an offhand suggestion. Does it utilize nearly 100% cpu now?

Thank you.
CPU utilization does not differ much from prior version.

Samples we send video renderer have time stamps. Video renderer blocks untill it is time to render. CPU have to wait, if it is not queued. Output queue utilizes this waste of time.

It can be translated into the following.

To make frame drops zero,
[Not queued] max time of decoding/processing < 1 / (frame rate)
[Ideally queued] avarage time of decoding/processing < 1/ (frame rate)

Video renderer drops frame if the sample arrives late. It means all the time spent to decode and process the sample was wasted. If the samples are queued properly, video renderer doesn't drop frames. That's why frame rate increases without increasing CPU utilization much.

[shon3i]

I founded some bug in this lastest and probably few before versions of ffdshow. This file (http://www.mytempdir.com/698466) splitted from original film encoded a few months before whasn't played with this ffdshow, but with CoreAVC everything is fine. I think when i encode this film current verision of x264 is be something around rev503.

[thuan]

Confirmed, that sample works fine with CoreAVC 0.4alpha, but not with vm9's newest ffdshow.

EDIT: It seems to be a ICL9 problem, clsid's newest build works ok, but his older icl compiled also crash in module ffdshow.ax.

[bennynihon]

Videomixer9...your 32-bit builds work very well for me. Just wondering if you or anyone else has had success with a 64-bit build that can run on winxp x64. thanks.

[celtic_druid]

In my limited testing, my build worked fine. Haven't heard any reports from anyone else though. Other then I think one instance of someone trying to use it in a 32bit app. All my testing was done with the 64bit version of Graphedit.

[shon3i]

Confirmed, that sample works fine with CoreAVC 0.4alpha, but not with vm9's newest ffdshow.

EDIT: It seems to be a ICL9 problem, clsid's newest build works ok, but his older icl compiled also crash in module ffdshow.ax.
So what bild to download and use, please link, i am confused, because many ppl's now comile ffdshow.

[_xxl]

Compilers used:
MSVC71:ffdshow.ax
ICL9+GCC3.4.2:libavcodec.dll & mplayer.dll
ICL9:ff_kerneldeint.dll,ff_liba52.dll,ff_libdts.dll,ff_libfaad2.dll,ff_libmad.dll,ff_realaac.dll
ff_samplerate.dll,ff_theora.dll,ff_tremor.dll,ff_unrar.dll,ff_vfw.dll,ff_wmv9.dll
ff_x264.dll,ffavisynth.dll,flt_ffdshow.dll,libmpeg2_ff.dll,tomsmocomp_ff.dll
mkv bug is fixed.
http://rapidshare.de/files/21676210/ffdshow-20060527.rar.html
http://www.mytempdir.com/699611
http://www.sendspace.com/file/3572sf

[sillKotscha]

hi videomixer9,

I'm testing your build ffdshow-20060526-rev2546. As far as I can tell the video part works fine but the audio_aac_decoder is somewhat messed up...

I'm playing apple's ICE AGE2 trailer (HD 720p) (http://www.apple.com/trailers/fox/ice_age_2/trailers.html) - it has 5.1 aac audio. I use ffdshow for direct aac -> AC3 conversion. With milans latest build (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow) I have no problems with the stream and I can hear the sound. With your build I only have a linear stutter... any ideas??

[shon3i]

@drevil_xxl Thanks

[sillKotscha]

sorry, but the same happens with drevil_xxl's build... btw, no matter if I change from libfaad2 to realaac or vice versa...

EDIT: that's the way (http://forum.doom9.org/showpost.php?p=686122&postcount=6) I do the aac -> ac3 conversion...

[cc979]

hi videomixer9,

I'm testing your build ffdshow-20060526-rev2546. As far as I can tell the video part works fine but the audio_aac_decoder is somewhat messed up...

I'm playing apple's ICE AGE2 trailer (HD 720p) (http://www.apple.com/trailers/fox/ice_age_2/trailers.html) - it has 5.1 aac audio. I use ffdshow for direct aac -> AC3 conversion. With milans latest build (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow) I have no problems with the stream and I can hear the sound. With your build I only have a linear stutter... any ideas??

i've just tried hd-720p version with mpc (using mpc's internal aac - unticked downmix to stereo) no problems here ... you did rename it to .mp4

[sillKotscha]

... you did rename it to .mp4

no, I didn't...

(using mpc's internal aac - unticked downmix to stereo)

hmm, but using mpc internal aac decoder isn't really ffdshow related ;-)

[SeeMoreDigital]

hi videomixer9,

I'm testing your build ffdshow-20060526-rev2546. As far as I can tell the video part works fine but the audio_aac_decoder is somewhat messed up... Transcoding 6Ch AAC to 6Ch AC3 using FFdshow's own filters seems to be working fine here!

[sillKotscha]

strange, not for me... I assume you've tested ffdshow-20060526-rev2546 (http://bittekeinspam.googlepages.com/)

if I uninstall this build and reinstall milan's latest (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow) then transcoding works fine but as mentioned not with videomixer9's one/ or drevil_xxl's latest...

[shon3i]

Transcoding 6Ch AAC to 6Ch AC3 using FFdshow's own filters seems to be working fine here!
Wait a second how you encode audio with ffdshow

[sillKotscha]

look 5 posts above

[shon3i]

look 5 posts above
OK i realize that but how you encode in ffdshow, or ffdshow is only to decode aac, and i think then why you not just use FAAD to decode it to wav or stdout, and use ffmpeg to encode to ac3, or use simply BeHappy

[SeeMoreDigital]

Wait a second how you encode audio with ffdshowWe are not "encoding" we are "transcoding".

strange, not for me... I assume you've tested ffdshow-20060526-rev2546 (http://bittekeinspam.googlepages.com/)Yep... it's working for me.

Cheers

[sillKotscha]

OK i realize that but how you encode in ffdshow
there is a difference between encoding and transcoding...

[shon3i]

there is a difference between encoding and transcoding...
Oh yes my mistake.

[sillKotscha]

Yep... it's working for me.Cheers

strange... transcoding 6ch aac to 6ch ac3 won't work for me unless I use milans latest build.

too bad, i'd love to keep up to date with ffdshow dev

[shon3i]

Did you maybe have AC3 Filter or similar filter, because he can disturb qualty because AC3 filter connected with pin which came from ffdshow decoder

Source(AAC)->FFDSHOW(AAC->WAV)->AC3Filter(or some other filter)(WAV)->Encoder

[sillKotscha]

shon3i,

there is no encoding process! nor a wav conversion...

ffdshow is used for pure (realtime) aac->ac3 transcoding. The fact is that it works very well with latest "offical" build by milan but it doesn't work with the above mentioned ones.

and no, I have not ac3filter installed.

I'm a bit lost 'cause for smd it is working and expect for the fact that I uninstall previous build and replace it by latest build I change nothing else... of course I change it back to the one that works for me ;-)

[foxyshadis]

If you guys have different CPUs it could be that just one of the codepaths is broken.

[Isochroma]

Something strange I noticed about VMR's latest build - when configuring the video decoder after clicking the "VFW codec configuration" icon on the start menu, if the Decoder tab is clicked, an entry on the Codecs item appears: "WMV3/9".

However, if the "Video Decoder configuration" icon is clicked, this format doesn't show up in the Codecs list.

[clsid]

Decoding through VFW is not the same as decoding through DirectShow.

[Isochroma]

So you are saying that if I hadn't installed the WM9 VCM codec, that ffdshow could allow me to load WM9 AVIs directly in vdub?

[bond]

So you are saying that if I hadn't installed the WM9 VCM codec, that ffdshow could allow me to load WM9 AVIs directly in vdub?no, ffdshow doesnt support it

[Isochroma]

So what did clsid mean when he said "decoding though vfw is not the same..."? Other than the video encoder, ffdshow is a Directshow only decoder, correct? If it is a VFW decoder also, it would work with vdub...

[bond]

hm it seems ffdshow indeed includes wmv9 decoding (for vfw), so when enabling wmv9 decoding via vfw it should also work in a dshow player

[SeeMoreDigital]

So what did clsid mean when he said "decoding though vfw is not the same..."? Other than the video encoder, ffdshow is a Directshow only decoder, correct? If it is a VFW decoder also, it would work with vdub...What you want to do should be possible with VirtualDub-MPEG-2 v1.6.11... but not with regular builds of VirtualDub.

[Liisachan]

You can open (WMV3).avi via VfW without WMV VCM, if WMV is enabled in ffdshow VfW.

iirc You can (unofficially?) open (WMV3).avi via DS too with ffdshow, but there's no GUI setting for it and you'll need to configure ffdshow with regedit.

[Liisachan]

So what did clsid mean when he said "decoding though vfw is not the same..."?

For instance, just because you can decode (x264) via DirectShow with ffdshow, doesn't mean you can open (x264).avi via VfW. You'd need to enable AVC via VfW separately if you wanted.

Other than the video encoder, ffdshow is a Directshow only decoder, correct? no both DirectShow decoding and VfW decoding are supported, separately.

[shon3i]

iirc You can (unofficially?) open (WMV3).avi via DS too with ffdshow, but there's no GUI setting for it and you'll need to configure ffdshow with regedit.

Interesting and True, i don't know why ffdshow devs hide this?

[breez]

Curiously this one build crashes when entering Info&Debug page in ffdshow while decoding WMV3 (DS). Playback seemed fine.

[Isochroma]

I was today playing with ffdshow's colorspace conversion. Noticed that with yv12 output it uses about half the CPU for HD clips. However, my Nvidia card does incorrect colorspace conversion, so I have to either use software conversion or use "levels" as suggested earlier in the thread.

However, if levels is used, it maps the range 16-235 to 0-255. This means that it clips 0-16 and 235-255 in the source signal, correct? So there would be a quality loss compared to YV12>RGB conversion, I assume?

After comparing them side-by-side, I can see banding in the levels version that is not present in the RGB-converted one. This must be due to the merging of values.

[foxyshadis]

WMV3 was available for selection a few months ago, but it's crazy buggy and glitches up a lot. That's probably why it's hidden. (In particular, it seems to occasionally miss keyframes, so the entire next scene is all messed up. Maybe VC-1 has a secondary keyframe form or something like that.) Of course I haven't tried it in a few months now.

[baribal]

Hi2all.
Q1: I have a crash when i use ffdshow for image processing (crop, deinterlace, etc.) in my tvtuner program. It happens with all 2546 builds not depending of compilation. I had no problems with earlier builds. I'm alone with this problem?
Q2: When i use ffdshow for compression on-the-fly i usually set options: encoder to XVID, FOURCC to XVID, mode to two passes-first pass. When i try to do the second pass of my first pass full video file in the VDub with XVID codec or try to open video.stats in the program "stats analyzer" i have a crash. So i have video.stats file that doesn't compatible with XVID
video.pass file. When i do the second pass with ffdshow codec all is ok but quality of second pass are terrible (huge blocking effect). So can i compress video with ffdshow and get
video.pass format file not the video.stats format?

[cc979]

does normal xvid codec work for you ?

[foxyshadis]

No, xvid and ffdshow's formats are incompatible and unresolvable, unless you were to write a utility to translate between them. You'll just have to run both passes afterward, or set ffdshow's second pass options better (it's pretty difficult to configure, I don't blame you for getting bad results).

What tv tuner program?

[baribal]

does normal xvid codec work for you ?
Yes. But when i use on-the-fly crop, deinterlace etc. in the tvtuner program i have a high CPU load. So i think that ffdshow image processing is more optimized for speed and quality probably than filters in my beholdtv tvtuner program.

[baribal]

You'll just have to run both passes afterward, or set ffdshow's second pass options better.
What tv tuner program?
I use BeholdTV. When i get full quality first pass video file (is it quant 2 or 1 encoding?) is there some quality loss while i'm doing two-pass encoding of it? Or it'll be better to do only second pass of it?

PS And how to tune the second pass in the ffdshow? I usually set only video target size in XVID codec and never have this ffdshow strange blocking artifacts.

[Livesms]

I use BeholdTV. When i get full quality first pass video file (is it quant 2 or 1 encoding?) is there some quality loss while i'm doing two-pass encoding of it? Or it'll be better to do only second pass of it?

PS And how to tune the second pass in the ffdshow? I usually set only video target size in XVID codec and never have this ffdshow strange blocking artifacts.

Can you post your ffdshow build, codec setting, btv&drv version? I'm using BeholdTV 507RDS and interested in realtime high quality capturing.

[baribal]

Can you post your ffdshow build, codec setting, btv&drv version?
ffdshow version 2534. Settings:
Encoder - XVID, Mode - Two pass - fisrt pass, b-frames - 2, croma ME - off, preset motion set precision - Ultra high, preset VHQ mode - mode decision, quantization - H263, Trellis - on.
Image processing: Crop - 4-4-4-4, deinterlace - kernel or tomsmocomp, resize - lanczoz 576:416.
BeholdTV - 4.80, driver - v4000. Frame - 768х576.
CPU: Athlon64 1800Mhz(2520Mhz).

And you have to do second pass in VDub.

[Livesms]

ffdshow version 2534. Settings:
Encoder - XVID, Mode - Two pass - fisrt pass, b-frames - 2, croma ME - off, preset motion set precision - Ultra high, preset VHQ mode - mode decision, quantization - H263, Trellis - on.
Image processing: Crop - 4-4-4-4, deinterlace - kernel or tomsmocomp, resize - lanczoz 576:416.
BeholdTV - 4.80, driver - v4000. Frame - 768х576.
CPU: Athlon64 1800Mhz(2520Mhz).

And you have to do second pass in VDub.

Is it your settings for realtime capture? Seems not...

Two pass - fisrt pass
b-frames - 2
preset motion set precision - Ultra high

Will load your CPU up to 300% in realtime :)

I asked for realtime codec settings

[videomixer9]

Especially the two pass encoding seems odd to me for realtime capturing. The source is kinda gone and not available anymore for the second pass. I still use the freakazoid huffyuv version from ffdshow for realtime captures, wastes space in masses but I can nicely reencode it later without frameloss. 1 TB diskspace isn't that rare nowadays either ...

[baribal]

Two pass - fisrt pass
b-frames - 2
preset motion set precision - Ultra high
Will load your CPU up to 300% in realtime :)


It's my realtime settings. :) Trust me. :)

[baribal]

Especially the two pass encoding seems odd to me for realtime capturing. The source is kinda gone and not available anymore for the second pass.
But i have full quality first pass. It's max quality video that i may get.

[haruhiko_yamagata]

This patch queue samples just before sent to video
renderer and execute video renderer on worker thread.
Compared to rev2546, 10 to 20%(Max 35%) of frame rate
improvement is expected. Single CPU/multithreading is
interesting, though it is not tested.

[Status]
Alpha testing.
Prior version should be more stable.

[Patch]
ffdshow_multithread_060601.patch is PATCH to PATCH.
To rev2546+ffdshow_multithread_060517.patch
http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491

[videomixer9]

Thanks for making it a patch to the patch :thanks:

[Liisachan]

*waiting impatiently*

[videomixer9]

Click here (http://www.fileking.to/download.php?n=r36uAay4jJ) or here (http://www.sebone.de/download.php?file=53a83db3d21c798959a644f6af786980) or here (http://www.filepoint.de/download/5968-dl-ffdshow-20060601-rev2546_exe) or here (http://www.mooload.com/new/file.php?file=files/010606/1149176115/ffdshow-20060601-rev2546.exe)

*waiting-over*

[haruhiko_yamagata]

Thanks for making it a patch to the patch :thanks:

Hello. You are wellcome.
You are fast!

[_xxl]

http://rapidshare.de/files/21944958/ffdshow-20060601.exe.html
http://www.mytempdir.com/707418
http://www.megaupload.com/?d=RX2BPLLE

[LoRd_MuldeR]

Click here (http://www.fileking.to/download.php?n=r36uAay4jJ) or here (http://www.sebone.de/download.php?file=53a83db3d21c798959a644f6af786980) or here (http://www.filepoint.de/download/5968-dl-ffdshow-20060601-rev2546_exe) or here (http://www.mooload.com/new/file.php?file=files/010606/1149176115/ffdshow-20060601-rev2546.exe)

*waiting-over*

Seems to work here.

[Liisachan]

ffdshow-20060601-rev2546.exe
just did a quick test, no obvious pb so far
installer's wmv3 option seemed cool,
wmv3 does play via ds tho being unstable

[videomixer9]

what's more interesting that the broken wmv is if the multithread patch shows it effectiveness :p

On single core on pure benchmarking this doesn't help much, timeCodec results were almost identical at least without the resizing, so I maybe try that next, prolly just using the multiply x2 option.

[cc979]

Yes. But when i use on-the-fly crop, deinterlace etc. in the tvtuner program i have a high CPU load. So i think that ffdshow image processing is more optimized for speed and quality probably than filters in my beholdtv tvtuner program.

you could encode with huffYUV then load it into vdub do you post-processing then encode to xvid

[foxyshadis]

vm9: Try playing a 720p avc file with old/new version. Or any file that drives your cpu near the edge and causes stuttering (toss on a few filters if you have to :p) . If it's way under or way over your cpu's capabilities you won't notice much difference.

I have the perfect set of almost-but-not-quite shows at home, I'll test tonight.

[haruhiko_yamagata]

On single core on pure benchmarking this doesn't help much, timeCodec results were almost identical at least without the resizing, so I maybe try that next, prolly just using the multiply x2 option.
Did you use null video for "pure benchmarking" ?
The patch need video renderer to take effect. With old video renderer it cannot do anything but to add bugs:o . Zoom player's overlay mixer is the old video renderer.
Use overlay mixer, VMR 7/9 and test files with frame rate 17 to 20 with prior version to see the effect.

[thuan]

Test with newest build from vm9 with latest patch from haruhiko_yamagata, here the result from testing on an AMD T-bred 1.5GHz 512MB RAM video renderer Overlaymixer, no filter with first two mins from Shinsen-subs Ergo Proxy ep1 HD.ffdshow-20060601-rev2546:
user: 56s, kernel: 1s, total: 57s, real: 71s, fps: 51, dfps:41.3

ffdshow-20060531-rev2546:
user: 56s, kernel: 6s, total: 63s, real: 77s, fps: 46.7, dfps: 37.9

CoreAVC1.0 pro:
user: 36s, kernel: 6s, total: 42s, real: 57s, fps: 68.6, dfps: 51.6According to the number then CoreAVC is still much faster but with the new ffdshow build I can watch 720p AVC content fine, with the old one it's jerky and lag like hell. Thanks Haruhiko. I wonder why I bought CoreAVC so soon, now I can play what I want okay for free damn.

EDIT: the OP of Ergo Proxy is a little choppy (guess I take back what I said about buying CoreAVC) but now with output queue there's no lag (ffdshow automatic drop frame), I'm happy with it.

[Liisachan]

afaik, CoreAVC is not payware just because they want to make much money, but because they have to pay MPEG license fees.

But I would rather not buy CoreAVC but would make some donation to haruhiko_yamagata or milan. That way I'd feel much, much better even if the money spent would be more.

[videomixer9]

Did you use null video for "pure benchmarking" ?
The patch need video renderer to take effect. With old video renderer it cannot do anything but to add bugs:o . Zoom player's overlay mixer is the old video renderer.
Use overlay mixer, VMR 7/9 and test files with frame rate 17 to 20 with prior version to see the effect.

Oh well I tried a renderer but prolly messed up yesterday, whatever I redid a test this morning with superman.mp4 on VMR7 instead of like before VMR9 and got this

200605031:
User: 89s, kernel: 5s, total: 94s, real: 98s, fps: 23.9, dfps: 22.9
20060601:
User: 89s, kernel: 0s, total: 90s, real: 94s, fps: 24.9, dfps: 23.9

of course it cannot boost the decoder much but noticable is the massive reduction of kernel time used, which is prolly the time the renderer wastes. 1fps overall gain but it appears to be running much smoother, while old version will lag behind sometimes. So even on single CPU this is a nice patch to make the overall video appearance a smoother thing and put load off the video renderer! So everyone get sure to enable output queuing! :thanks:

As far as I think it's not enabled per default, but I guess I make it one, just need to mod the installer again.

[Liisachan]

So everyone get sure to enable output queuing! :thanks:

As far as I think it's not enabled per default, but I guess I make it one, just need to mod the installer again. You mean Miscellaneous | Other controls | Queue output sample? If so, you're right, it's not enabled by def. Are there any possible bad side-effects thinkable by enabling it? I'm kindof curious if this works with VSFilter/MPC's sub pic buffering OR non-buffering (i.e. what if you disable subpic buffering in VS/MPC)...

[haruhiko_yamagata]

afaik, CoreAVC is not payware just because they want to make much money, but because they have to pay MPEG license fees.

But I would rather not buy CoreAVC but would make some donation to haruhiko_yamagata or milan. That way I'd feel much, much better even if the money spent would be more.
Thank you ver much. Apparently milan should be donated, not me. But I'm glad to read your post.

[haruhiko_yamagata]

You mean Miscellaneous | Other controls | Queue output sample? If so, you're right, it's not enabled by def. Are there any possible bad side-effects thinkable by enabling it?
I'm testing single CPU PCs now.
In some cases, frame rate significantly drops when checked.
In some cases, vice versa.

[haruhiko_yamagata]

For better single CPU/multithreading (test).
In some cases, output queue lost performance with the prior revision.
The streaming thread has access to the VRAM buffer,
the video renderer thread has it too.
Nervus VRAM should not be accessed from two threads simultaneously.

This time, THREAD_PRIORITY_ABOVE_NORMAL for video rendering thread.
This will prevent simultaneous access to VRAM from two threads.
This may cause conflict with audio rendering thread.
The side effect would be clicking noise in the audio.
It was not heard in my limited tests.
If it apears, I have another option to test.
Please report.
Bug fix: fixed reconnect to VMR9.
To change resize setting while playing may cause dynamic reconnect.
Prior revision VMR9(non renderless) blacked out after changing resize setting.
Not all the video renderer succeed in reconnect.
[patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491)
ffdshow_multithread_060604.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch

[videomixer9]

Click here (http://ffdshow.drition.net/current.php) to download newest build with ffdshow_multithread_060604.patch :p

[Liisachan]

nice :D

[videomixer9]

cannot help this, but my impression is somewhat funny, during some stupid benchmarks this seemed to be slower, during actual playback and watching taskmanager it doesn't seem to make any real difference ... I had an odd behaviour with dvd playback via ffdshow with the older one, that thing disappeared.

[Avish]

Is it possible to add "auto" option in ffdshow's deinterlacing section? Coz I'm not quiet sure which one to use when. :D

[SeeMoreDigital]

Speaking of de-interlacing....

Does anybody know whether if the libavcodec MPEG-4 decoder filter is able to offer interlaced decoding?


Cheers

[LoRd_MuldeR]

Is it possible to add "auto" option in ffdshow's deinterlacing section? Coz I'm not quiet sure which one to use when. :D

I think you should try KernelDeinterlacer or TomsMoComp

With TomsMoComp I prefer Vertical-Filter enabled plus some Sharpen filter afterwards...

[Avish]

I think you should try KernelDeinterlacer or TomsMoComp

With TomsMoComp I prefer Vertical-Filter enabled plus some Sharpen filter afterwards...Thanks. I'll try them. But still I'd prefer "auto" if it's possible. :D

BTW, what's that "speedup tricks" option for, when I choose libavcodec? What speedup tricks it uses?

[LoRd_MuldeR]

Thanks. I'll try them. But still I'd prefer "auto" if it's possible. :D

BTW, what's that "speedup tricks" option for, when I choose libavcodec? What speedup tricks it uses?

Well, an auto detection for interlaced material would be nice.
So the deinterlace filter could be enabled/disabled automatically.

But which deinterlacer you want to use, is still your choice.
Different people prefer different deinterlacers...
Just try out which looks best for your eyes and use this one ;-)

[mpioner]

Avish
SeeMoreDigital
LoRd_MuldeR
http://sourceforge.net/tracker/index.php?func=detail&aid=1244154&group_id=53761&atid=471492

[Zarxrax]

I have a question regarding FFDshow's audio processing.

I would like to watch some videos at a faster speed. I can add an assumefps() avisynth command on the ffdshow video decoder, and that will change the speed of the video. However, I cant find a way to make a similar change for the audio.

Is this possible with current ffdshow, or does anyone know if ffdshow can have avisynth processing added into the audio decoder?

[Egh]

I would like to watch some videos at a faster speed.

MPC can change video (and audio) playback rate. So I don't think changing video/audio rate is needed inside ffdshow.

[Liisachan]

videomixer9's ffdshow-20060604-rev2546.exe:

If "Queue output samples" is unchecked, you'll get a static picture (video frame) when you pause the video (which is normal).

If "Queue output samples" is ticked, you'll get nothing (blackness) when the video is paused, which is not too nice.

Anyone can reproduce that?
I'm on Windows 2000, MPC rev611 (aka the newest svn), VMR9 Renderless, RGB32.

[videomixer9]

Well for me it doesn't reproduce, maybe only happens on Win2k or using other specific stuff. Is it reproducable using Overlay or VMR7 modes? dunno what's with the kids and VMR9 obsession anyways especially with overlay resize quality being at the level of lanczos4 in many modern cards :devil:

Btw. Gabest's splitter seem to have problems with this patch unlike Haali Media Splitter, so it may be even recommended to use Haali Splitter, also for avi. Gabest's AVI Splitter e.g. just stalls frame displaying. when seeking. The matroska splitter only just falls out of audio sync when seeking sometimes but is fine, same for ogm.

Gabest avi splitter with RGB32 and VMR9 renderless produces a small flickering here. Might be it reproduces the picture that time, and maybe that fails for you and the screen goes black. Haali as AVI Splitter and this doesn't happen.

[Liisachan]

Not reproducable with VMR9 Windowed nor Overlay. It's apparently related with the MPC's internal sub renderer. Don't ask me about VMR7 as it's not officially supported on Win2k. I don't use VMR9 Renderless for resizing quality, but for softsubs. The reason why I use it is unrelated.

[videomixer9]

I actually tried with a subbed file too, so you do use the internal filters, all of them produce the flicker for me? Though it might indeed be related to the sub renderer.

[Zarxrax]

MPC can change video (and audio) playback rate. So I don't think changing video/audio rate is needed inside ffdshow.

If you don't mind my asking, where would I change this in MPC? I have never seen any such options.

[videomixer9]

Menu->Play->Increase Rate or Decrease Rate or just Ctrl+UP or Ctrl+Down

[twist3d]

videomixer9, your latest ffdshow build loads over gig-sized (1024mb) .mkv files for 30-60 seconds before they start to render (at least for me ;)) I first thought that this was a problem with latest mpc or haali's media splitter until I installed latest ffdshow from x264.nl (which starts rendering almost instantly).

[videomixer9]

Queue output samples on or off? It loads instantly here, however it also use automatic array prefetching code, I don't see a reason for this delaying thing this long though. x264 build doesn't have the same patches, especially not the same patchlevel on haruhikos patches ...

Are you using any filter like Reclock, or do you use other resampling? What kind of CPU and OS and output renderer?

[Zarxrax]

Menu->Play->Increase Rate or Decrease Rate or just Ctrl+UP or Ctrl+Down

Oh, that. Well, it only seems to give you two different speeds... one of which is about twice as fast, and the other being about half as fast. Both of these modes seem to work poorly and are pretty much unwatchable for me. So it would be much better to have a fully controllable speed from ffdshow.

[twist3d]

Queue output samples on or off?
no effect on long loading times with this option on or off
Are you using any filter like Reclock, or do you use other resampling? What kind of CPU and OS and output renderer?
no other filters (except if you count haali's one), no resampling or postprocessing of any kind enabled. amd64 3200+, nvidia 6600gt agp, winxp pro sp2 and i've enabled "use overlay mixer" on ffdshow (if that is what you mean with output renderer :D)

[videomixer9]

Output renderer as does your player use VMR7, Overlay Mixer or VMR9, the checkbox in ffdshow doesn't matter much really. It might though give errors if you're not use overlay mixer if the checkbox is checked and not in intermediate state.

I don't see why it would have this load delay. No clue, so as long as there is noone else with this problem it's again the I cannot reproduce it so I cannot fix it problem. Also this really does happen with any player?

[Liisachan]

fyi, I have some huge (>10GB) AVI files and they load instantly with or without that Queue thingy.

[videomixer9]

I wouldn't see any reason why the filesize should matter anyways, it just reads in a certain amount anyways at once and not everything. So also the queueing shouldn't matter really, it works on a small part of the file. So for every file it's basically the same, even if it's 1000 GB it shouldn't matter :p But wasn't 2 GB a limit for avi files or was that just due to old splitters and old shitty filesystem?

I bet on a random other error.

[Liisachan]

But wasn't 2 GB a limit for avi files...? Yes, it was, and it isn't (OpenDML). Incidentally, there's also the 4 GB limit on FAT32 (hence on Win98).

[TheShadowRunner]

hey all, sorry to interfere in your tech talks, but what do you consider to be the latest stable build?
See you,

TSR

[haruhiko_yamagata]

videomixer9's ffdshow-20060604-rev2546.exe:

If "Queue output samples" is unchecked, you'll get a static picture (video frame) when you pause the video (which is normal).

If "Queue output samples" is ticked, you'll get nothing (blackness) when the video is paused, which is not too nice.

Anyone can reproduce that?
I'm on Windows 2000, MPC rev611 (aka the newest svn), VMR9 Renderless, RGB32.
Hello.
I can't reproduce so far. I'm trying MPC/VMR9 renderless, RGB32, files with subtitle. If it is convenient to you, and if the files are not too large, please send me the files.

[Liisachan]

I can reproduce the probelm with any random file.
GRAY.avi (http://ffdshow.faireal.net/tmp/GRAY.avi) 75KB
Queue disabled (http://ffdshow.faireal.net/tmp/gray_no_q.jpg) (you can puase normally)
Queue enabled (http://ffdshow.faireal.net/tmp/gray_q.jpg) (you can NOT puase normally)

Another weird thing. libavcodec in ffdshow is weird with the above sample. If libavcodec is used, MPC reports it as like 10 ~ 16 fps. If xvid in ffdshow is used, or ffdshow is disabled and standalone XviD is used, MPC reports the correct fps, 23.976.
That's not the recent pb, as I can repro it with milan's 20051115. Usually libavcodec works ok with me, but not for the above thing. Can anyone confirm this or is it just me?

[videomixer9]

Might be a way to save CPU power and memory bandwidth, obviously there are no changes in the picture.

[haruhiko_yamagata]

I can reproduce the probelm with any random file.
GRAY.avi (http://ffdshow.faireal.net/tmp/GRAY.avi) 75KB
Queue disabled (http://ffdshow.faireal.net/tmp/gray_no_q.jpg) (you can puase normally)
Queue enabled (http://ffdshow.faireal.net/tmp/gray_q.jpg) (you can NOT puase normally)

Another weird thing. libavcodec in ffdshow is weird with the above sample. If libavcodec is used, MPC reports it as like 10 ~ 16 fps. If xvid in ffdshow is used, or ffdshow is disabled and standalone XviD is used, MPC reports the correct fps, 23.976.
That's not the recent pb, as I can repro it with milan's 20051115. Usually libavcodec works ok with me, but not for the above thing. Can anyone confirm this or is it just me?
Thank you. I'll test furthrer.
As for Gray.avi, I have frame rate reported 16 fps too.

[wyrd]

@Liisachan
I can reproduce the probelm.
but not with or without that Queue output sumple in ffdshow.

MPC VMR9(VMR MIxer mode on) + Queue output check on = OK
MPC VMR9(VMR MIxer mode off) + Queue output check on = NG(blackness)
MPC VMR9(VMR MIxer mode on) + Queue output check off = OK
MPC VMR9(VMR MIxer mode off) + Queue output check off = OK

ok.png (http://tirnanog.fate.jp/tmp/snap/ok.png)
ng.png (http://tirnanog.fate.jp/tmp/snap/ng.png)

my pc env: Pen4(singlecore),RADEON,XPsp2,latest DX9,
at celtic_druid's MPC611,videomixer9's ffdshow

(I don't know framerate probrem.. sorry,)

[videomixer9]

Yeah, this way the problem reproduces here too.

[Liisachan]

ok, we narrowed down the problem: in VMR 9 Renderless:
Queue ticked + Mixer mode unchecked + RGB out = problematic.

- If Queue is not ticked, there's no pb.
- If Mixer mode is ticked, there's no pb.
- If ffdshow's output color space is not rgb, there's no pb either.

hopefully haruhiko can find what is wrong now :)

[haruhiko_yamagata]

Thank you, wyrd. I still can't reproduce the problem, but it would be a nice hint.

[haruhiko_yamagata]

Thank you. I confirmed the problem. Perhaps someting around GetBuffer.

[Livesms]

Can anybody tell which ffdshow build has correct postprocessing by default with H264.

Problem is described here
http://forum.doom9.org/showthread.php?p=819640#post819640

and my quest:

http://forum.doom9.org/showthread.php?p=837917#post837917

[Px]

Oh, that. Well, it only seems to give you two different speeds... one of which is about twice as fast, and the other being about half as fast. Both of these modes seem to work poorly and are pretty much unwatchable for me. So it would be much better to have a fully controllable speed from ffdshow.
Use BSPlayer, it can control speed with 10% step

[DeathTheSheep]

Due to the incredibly nice picture of Haruhi present within it, I hereby declare my pride in using videomixer9's ffdshow build. Upon seeing this scintillating picture, I'm sure you'll all come around to my way of thinking :D

[Zarxrax]

Use BSPlayer, it can control speed with 10% step
Thanks, that was exactly what I needed.

[Liisachan]

@DeathTheSheep
I guess watching that too much is the reason videomixer9 gets suddenly arrogant from time to time :D
I just realized the author of the patch was Haruhiko. lol Is this just coincidence??

[SeeMoreDigital]

Does anybody know whether anybody is working on FFDshow's DVD decoding/parsing: -

http://img60.imageshack.us/img60/3534/ffdshow2vz.png


Cheers

[videomixer9]

works perfectly for me together with mpc, I'm using libmpeg2 though and my build should automatically select libmpeg2 too when you check mpeg1/2 in the installer. Also works in WMP11 fine, only problem is if the resolution is changing e.g. if menu and video differ in that, it sometimes hangs up then, seems to be more a renderer prob than ffdshow though.

btw. if the lame greek guy who stole my website for his codec pack builds reads this please remove the google analytics code, seeing stats of your page in my overview is annoying :p I have nothing against others using my beautiful xhtml code, but I have sth. against keeping the analyticscode :p

[SeeMoreDigital]

When playing DVD's with both MediaPlayer Classic and WMP11 using "only" FFDshow's filters/parsers I see a pumping/surging effect of the video stream...

EDIT: Strike that... libmpeg2 does indeed appear to work okay!


Cheers

[videomixer9]

well it doesn't use any deinterlacing and other processing many dvd decoders apply etc. by default.

[ckjnigel]

At least that's how it was on my father's PC with shared video RAM.
There had been vertical green bar artifacts in some XviD files using VideoMixer9's latest; the DirectX update fixed that.
My 83-year-old father and the 82-year-old girlfriend both especially appreciate the dialogue enhancing "crystality" filter.
Thanks to all involved!

[MatMaul]

I have made a very little patch to modify the behaviour when you use a ratio in the resize properties page : before the patch, ffdshow always apply this formule (aspect ratio = a1/a2) : y=a2*x/a1;x=x
it's good when you use a video with video ar>screen ar (an example (screen 16/10) : 576*240 => 576*360) because it's an upsize
but whith a video with video ar<screen ar (4/3 video) ffdshow does that : 720*576 => 720*450, I think it's not good because it's a downsize => lose of video information
I thing the good resize is : 720*576 => 924*576 (upsize)

My patch modifies ffdshow to do an upsize in all the situtations.

http://sourceforge.net/tracker/index.php?func=detail&aid=1505488&group_id=53761&atid=471491

[SeeMoreDigital]

Hi Matt,

I've performed extensive tests with FFDshow and as far as I'm able to determine the aspect ratio output performs exactly as it should, with MPEG-1, MPEG-2 and MPEG-4 sources containing AR signalling...

Unless you are referring to something else!

[MatMaul]

sorry if I am not clear...
no problem with aspect ratio embedded in mkv for example, this patch is only for people (like me) who use the option "specify aspect ratio" in "resize & aspect" (I use it to resize 4/3 source to 16/10).
the "problem" is, if video ar<screen ar (specified in "specify aspect ratio"), ffdshow downsize the image : I think it's better to upsize (=> the behaviour is good when video ar>screen ar)

[haruhiko_yamagata]

Hi, MatMaul.
It works for me.
Plainly it is better to upsize than to downsize.

[MatMaul]

cool !

[NULUSIOS]

Well I would say that it is better to DOWNsize than UPsize.

You see when you downsize you create less data from a larger data sample, where in upsize you (algorithmicaly) "guess" extra data from a smaller sample. I hope you get my point.

[Sharktooth]

i would say it's better to NOT resize at all...

[Farhad]

Hi,
I am having lot of compilation error issues with ffdshow
source downloaded from SourceForge.net while using
Microsoft VC6++/PlatformSDK while trying to generate
xvid.ax.
Is there an easy way around this problem? Can I use GCC for this--
if so then which version of GCC and where can I get
corresponding make file?

By the way, I was able to use GCC for building libavcodec.dll and libpostproc.dll.

Pointer to ffdshow source code buildable by GCC would also
be appreciated.

Thanks,

Farhad


Yeah ffdshow gcc 4.0.2, ffdshow.ax msvc 7.1, ff_libfaad2.dll msvc 8.0 is what i used (ffdshow-20051102.exe), who knows what msvc 8.0 does with it, thats why i put it there :)

Anyways, only one file left to fix for both gcc and msvc 8.0, ffdshow.ax

Edit:
ffdshow.ax with gcc 4.0.2 was "fixed" by using "make SSE2=no;"
ffdshow.ax with msvc 8.0 almost works, it compiles, only a registering bug left.

[haruhiko_yamagata]

Visual Studio 6 support was dropped (http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php).

To make ffdshow by GCC, first read this (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=From+sources), though it is bit old.

Get GCC from
http://gda.utp.edu.co/~ceniza/GCC-4.0.3/
http://gda.utp.edu.co/~ceniza/GCC-4.1.0/
http://gda.utp.edu.co/~ceniza/GCC-4.1.1/
I recomend GCC-4.0.3 for those firstly try to compile ffdshow, others may recomend newer version though.
I don't know if this (http://sourceforge.net/tracker/index.php?func=detail&aid=1469519&group_id=53761&atid=471489) is fixed.

Get nasm. (http://sourceforge.net/project/showfiles.php?group_id=6208)

Get NSIS. (http://nsis.sourceforge.net/Main_Page)

DirectX SDK and Platform SDK is also needed.

Set environment variables properly.
For example, my environment variables:
CC=gcc
CPLUS_INCLUDE_PATH='C:\mingw\include;(DX9SDK)\Include;(PlatformSDK)\Include'
C_INCLUDE_PATH='C:\mingw\include;(DX9SDK)\Include;(PlatformSDK)\Include'
LIBRARY_PATH='C:\MingW\lib;(DX9SDK)\Lib\x86'

MSYS is recomended. You can complile without MSYS, but "make clean" is not easy without it.

Btw on my environments, MSVC2005 always crushes when it terminates after compiling ffdshow. I have tested two PC, both of them are the same. Does anybody experiencing the crush? Is it related to Japanese version?

[draggoon01]

when i play the hd trailers from apple (rename to avi), i get data excection prevention errors. any way to fix this?

[videomixer9]

so which idiot got you to rename them to avi, which is 100% incompatible with mov whatsoever?

mp4 is based on mov container roughly, so it's basically compatible, so renaming to mp4 usually works without problems, but avi isn't at all compatible.

There is no need to rename them at all, in Zoomplayer and MPC you just need to set quicktime playback to DirectShow instead of Quicktime.

[Liisachan]

A trivial problem.

Rounding of the frame timing to REFERENCE_TIME is not always strict, in OST | Frame timestamps.
Examples in 24000/1001 fps.
Frame 1 (0-based) is reported as 417083-831467, 0.083 416 667 rounded properly.
Frame 29 is reported as 12095416-12512499, off by 1rt, should be 1.251 250 000 exactly
etc etc
666.... sometimes gets 667, sometimes 666, I don't like this kind of looseness.

[haruhiko_yamagata]

A trivial problem.

Rounding of the frame timing to REFERENCE_TIME is not always strict, in OST | Frame timestamps.
Examples in 24000/1001 fps.
Frame 1 (0-based) is reported as 417083-831467, 0.083 416 667 rounded properly.
Frame 29 is reported as 12095416-12512499, off by 1rt, should be 1.251 250 000 exactly
etc etc
666.... sometimes gets 667, sometimes 666, I don't like this kind of looseness.

Hello. I don't fully understand what the numbers mean, but it seems to be too advanced by 1.2ms at frame 29.
Setting time stamps is usually parser's responsibility, ffdshow may change it though.
Which parser filter do you use?
Does it differ when you use different parser?

[Liisachan]

uh, no, it's not a bug report. at least i didn't mean that.
I see this 'problem' everywhere and I'm sure this is nothing new for an excellent coder like you, but some coders naively think that in CFR the current time should be duration-per-frame * frame_number, which is correct only mathematically.

a typical bad example

#define SEC_TO_RT(x) (x)*((float)(1000*1000*10))
char buf[ 1000 ];
int iFrameNumber = 30;
float one_frame = 1001.0f / 24000.0f; // seconds
float time_stamp = one_frame * iFrameNumber; // seconds
sprintf( buf,
"(Real) one_frame = 417083.333333333333\r\n"
"(Float) one_frame = %.12f\r\n"
"(Real) time_stamp = 12512500\r\n"
"(Float) time_stamp = %.12f\r\n",
SEC_TO_RT(one_frame), SEC_TO_RT(time_stamp)
);
MessageBoxA( NULL, buf, "Unit: 100ns", MB_OK );

/* Result:

Unit: 100ns
(Real) one_frame = 417083.333333333333
(Float) one_frame = 417083.315551280980
(Real) time_stamp = 12512500
(Float) time_stamp = 12512499.466538429000
*/

[Farhad]

Thanks Haruhiko for your advice. I found out that the recent
revisions of ffdshow downloaded from SourceForge.net builds
well with VS2005. I have done that and got ffdshow.ax and
a bunch of dlls (e.g., libavcodec.dll. mplayer.dll, etc.). For
installaling the plugin and the codec dlls into my Windows XP,
I registered ffdshow.ax by using command:
regsvr32.exe ffdshow.ax and then placed ffdhow/bin into
windows path to make all the dlls visible to Windows.
Then I tried to playback a Xvid MPEG-4 video
file in .avi format using Windows Media Player 10 (WMP10)
on my XP desktop PC. Unfortunately, only the audio plays
and video is just garbage on WMP10 display/screen!
Just before the audio playback, an error message appears
on WMP10 toolbar saying:
"Connecting....Error downloading codec".
Apparently WMP10 is unaware of the presence of
libavcodecs.....? I further noticed that WMP10 behaves the
same whether I register or deregister ffdshow.ax into XP
registry. This makes me guess that I am perhaps making some
error in the installation procedure of ffdshow.ax and the dlls
generated from the ffdhow build.
Or Could this be a problem of WMP10 on XP itself??
I am confused and would appreciate any help / feedback in
this regard.
Thanks,

Farhad


Visual Studio 6 support was dropped (http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php).

To make ffdshow by GCC, first read this (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=From+sources), though it is bit old.

Get GCC from
http://gda.utp.edu.co/~ceniza/GCC-4.0.3/
http://gda.utp.edu.co/~ceniza/GCC-4.1.0/
http://gda.utp.edu.co/~ceniza/GCC-4.1.1/
I recomend GCC-4.0.3 for those firstly try to compile ffdshow, others may recomend newer version though.
I don't know if this (http://sourceforge.net/tracker/index.php?func=detail&aid=1469519&group_id=53761&atid=471489) is fixed.

Get nasm. (http://sourceforge.net/project/showfiles.php?group_id=6208)

Get NSIS. (http://nsis.sourceforge.net/Main_Page)

DirectX SDK and Platform SDK is also needed.

Set environment variables properly.
For example, my environment variables:
CC=gcc
CPLUS_INCLUDE_PATH='C:\mingw\include;(DX9SDK)\Include;(PlatformSDK)\Include'
C_INCLUDE_PATH='C:\mingw\include;(DX9SDK)\Include;(PlatformSDK)\Include'
LIBRARY_PATH='C:\MingW\lib;(DX9SDK)\Lib\x86'

MSYS is recomended. You can complile without MSYS, but "make clean" is not easy without it.

Btw on my environments, MSVC2005 always crushes when it terminates after compiling ffdshow. I have tested two PC, both of them are the same. Does anybody experiencing the crush? Is it related to Japanese version?

[videomixer9]

Just placing the bin directory into the windows directory is a dumb idea, subdirs are not automatically in the systems PATH variable. Also a file is registered to the location it was when registering, you cannot register a filter and then just move it to some random other location, windows won't find it anymore where it was and decides that it's dead.

Don't build libavcodec and libmplayer with VS. It doesn't use handoptimized MMX code then which is made specially for GCC. It will be way slower this way.

Easiest is to just run ffdshow.nsi with NSIS installer (just right-clicking the nsi file and select compile installer should be fine usually) and make a proper installer for the compiled files, or just keep them where they are and let VS register the .ax file and don't move anything.

Honestly you got a deep lack of knowledge about the OS and other things as it seems ... better fix that first :P There isn't any real gain in compiling ffdshow yourself anyways if you're mostly clueless :O

And yes MSVC 2005 sometimes crashing on exiting after compiling the .ax file.

[Farhad]

Hi,
I was wondering if someone could point me to documentation
on ffdshow that would explain how the code is structured.
Thanks,

Farhad

[Farhad]

The problem was solved by proper installation using NSIS (as suggested by videomixer9). Thanks to your insightful advise, videomixer9. Any suggestion on a proper documentation of ffdshow?
Regards,

Farhad

Just placing the bin directory into the windows directory is a dumb idea, subdirs are not automatically in the systems PATH variable. Also a file is registered to the location it was when registering, you cannot register a filter and then just move it to some random other location, windows won't find it anymore where it was and decides that it's dead.

Don't build libavcodec and libmplayer with VS. It doesn't use handoptimized MMX code then which is made specially for GCC. It will be way slower this way.

Easiest is to just run ffdshow.nsi with NSIS installer (just right-clicking the nsi file and select compile installer should be fine usually) and make a proper installer for the compiled files, or just keep them where they are and let VS register the .ax file and don't move anything.

Honestly you got a deep lack of knowledge about the OS and other things as it seems ... better fix that first :P There isn't any real gain in compiling ffdshow yourself anyways if you're mostly clueless :O

And yes MSVC 2005 sometimes crashing on exiting after compiling the .ax file.

[zilexa]

Can anyone confirm version http://kurosu.free.fr/ffdshow-20060424-13H04-k8.exe
is stable/no bugs reported so far? Trying to figure out fast/good version for a new PC with socket AM2 amd64 3200+ cpu.

[Farhad]

Has anybody tried this?
Thanks,

Farhad

[CruNcher]

http://gda.utp.edu.co/~ceniza/GCC-4.1.1/ <- is it down ?

[therealjoeblow]

Hoping one (or some) of the dev's read this forum from time to time...

It appears that it's impossible to setup the Keys & remote triggers without 2 activation keys (default are ctrl and alt). Would it be possible to allow this? IE, no activation keys, just a single key trigger?

I want to use my ATI remote wonder's 7, 8, 9, and 0 keys to send commands to toggle sharpening, post processing, subtitles, etc, but without getting into the complexities of installing and programming girder, I can't send the activation trigger keys to ffdshow with a single keypad press on the remote. It would be much simpler if the activation keys could just be disabled so that ffdshow just watches for simple single key presses.

And while we're at it, there's no trigger to toggle the DScaler filter - could that be added too please?

Many thanks,

[KikeG]

I don't know if this is already known, but there is a small bug in my Feb-26-2006 build (and I think in other builds too).

The bug is in the displayed coded frame size information in the OSD info when playing mpeg-4 files. The size of I/P/B frames is not in sync with the current frame being shown. I mean, when showing a B-frame, the coded frame size shown is usually much bigger than the one of the previous I or P-frame, so I guess the coded frame size is shown in the wrong order.

[foxyshadis]

I noted this a while back and haven't really had time to look in and investigate. The first problem is the B-frame delay, though; the first size is correct, then x sizes are skipped where x is the delay (1 for b-frames, 2 for b-pyramid) and the rest are all shifted by that much. This affects all containers except avi, bizarrely! You'd expect the opposite, but it looks like someone 'fixed' it for avi at one point by breaking other containers.

It also tends to repeats frame #s wrong a lot with mkv, then make big jumps to cover the gap. Strange.

It used to show B/P in coding, not display order, but I'm glad to see that's apparently been fixed now.

It's a lot easier to analyze OSD by saving it into a file. Quite handy, that.

[KikeG]

Well, it does show wrong sizes in mpeg4 AVIs, I don't know about other containers. OSD saved to a file is wrong too.

I have checked it and I/P/B frame type and quantizer displayed are right, but their frame sizes are wrong.

[LoRd_MuldeR]

I found a bug with ffdshow (latest build from Videomixer9) when playing MEPG4 files and using xvid decoder. The AVI has fourcc "DIVX" and plays fine in both MPlayer and VLC. However in MPC with ffdshow I got a black screen - audio only. Then I changed decoder for "Generic MPEG4" from xivd to libavcodec and when I tried again it worked. Back to xvid and same problem as before. Even tried latest xvidcore.dll from Celtic Druid, but didn't help.

[haruhiko_yamagata]

fixed crash on huffyuv playback.
a bug of multithreading of swscaler.
Refuse loading from blacklist :
Re-installing ffdshow.ax sometimes fails because ffdshow.ax cannot be deleted.
Explorer.exe loads ffdshow.ax and never releases.
That causes annoying error on re-install that one have to log off.
With this patch, ffdshow.ax avoids to be loaded by returning false on DllMain
if the caller is included in BlackList("Don't use ffdshow in:").
aWarpSharp
changed default setting of "Chroma mode"
For better single CPU/multithreading (test).
This time, THREAD_PRIORITY_BELOW_NORMAL for streaming thread, only when it write to V-RAM(Single CPU only).OSD item : Queued samples (joke).

Fixed resource leak : Thanks, hartlerl
http://sourceforge.net/tracker/index.php?func=detail&aid=1386965&group_id=53761&atid=471489.
[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491)
ffdshow_multithread_060625.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch + ...060604.patch
Some of the changes are not related to multithreading, so the patch is supposed to be separated. But it's too complicated, I chosed to merge :D .

[videomixer9]

wow, sunday morning, how dirty. Well whatever, new build incl. the patches available here (http://ffdshow.da.cx).

[LoRd_MuldeR]

whatever, new build incl. the patches available here (http://ffdshow.da.cx).

nope :scared:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

[videomixer9]

that is so typical, you upload one second one wrong file and idiot strikes and loads it ... try again :P Tried some .htaccess setting and it was obviously not allowed on the host ...

[SeeMoreDigital]

As an IE7 beta user I get: -Sorry your browser doesn't properly support XHTML. Please change to a browser with proper XHTML support like Firefox or Opera.

[foxyshadis]

You could try disabling javascript. :p

There still seems to be some problems with huffyuv, it used to play this non-mod16 (676x444) video just fine, now it silently crashes every time. Opens fine in vdub with ffvfw doing the decoding though! (Recompressing it without resize/crop crashes though.)

[videomixer9]

IE7 is an utter piece of shit, it may support some things but it's utterly broken for CSS. Opera and Firefox render correctly, so see what IE7 outputs:
http://xs302.xs.to/xs302/06250/ie7crap.png.xs.jpg (http://xs.to/xs.php?h=xs302&d=06250&f=ie7crap.png)
http://xs302.xs.to/xs302/06250/ie7crap2.png.xs.jpg (http://xs.to/xs.php?h=xs302&d=06250&f=ie7crap2.png)

Neither does it obey the proper padding and margin settings, nor does it clip the thing correctly, it instead takes the width of the first table cell the style applied to and clips text and style differently, so even if you set a width the text is clipped still to the table cell width while the rest isn't. Same effect on the top, clipping is taken from table cell, but the content isn't even anymore in the cell really, padding and margin are applied, but the nice thing is, the left margin get intended by the <ul> tag but the top margin applies incorrectly from the <ul> on level higher, different behaviour on both margins, just awesome. It is amazing IE7 even does this CSS hover popups anyways but the current way it totally unusable and not near any standards.

If you want to see anything correctly get a browser that sends also handles application/xhtml+xml properly, IE doesn't, so it has to stay outside for more than enough other reasons too.

The check is serverside scripted, if your browser doesn't send an Accept: application/xhtml+xml it gets this message, there is not a single line of javascript on the website except for the google analytics code.

[LoRd_MuldeR]

@Videmomixer:
Why you make "no-sse" builds now?

[Egh]

wow, sunday morning, how dirty. Well whatever, new build incl. the patches available here (http://ffdshow.da.cx).

BTW, what happened with WMV3/9 option in the installer? It dissappeared several builds ago :P

[videomixer9]

Too many people seemed to think it's something else than the old crappy support for WMV3 that is in ffdshow since ages. So I removed it again, people may hack registry again if they want it :P

Basically some of the later SSE builds would prolly work on non-SSE too and libavcodec and libmplayer don't use the GCC switches that generate this code anyways, so it's generic as ICL doesn't generate code that needs it really to be there.

[haruhiko_yamagata]

You could try disabling javascript. :p

There still seems to be some problems with huffyuv, it used to play this non-mod16 (676x444) video just fine, now it silently crashes every time. Opens fine in vdub with ffvfw doing the decoding though! (Recompressing it without resize/crop crashes though.)
Thank you for report.
Was prior version OK?
In which module does it crash?
If it is libmplayer.dll, I still have known theoretical bugs that I don't have proper sample to make it crash.

[LoRd_MuldeR]

If you set everything correctly during the installation, you won't have to edit anything ^^

[foxyshadis]

http://neuron2.net/misc/1deint.avi

This is the huffyuv file. It was playable around early may, when I first downloaded it. I don't know if it's just some recent optimization or compiler options.

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

Edit: Ack, I downloaded the wrong ffdshow; the current one plays this file fine. False alarm!

[Egh]

@ haruhiko_yamagata :

Thanks for your participation in ffdshow development btw!

Is it possible to request patch? I've been asking Milan to do that for ages, but still nothing was done.

In the software resizer (which i nearly always use) you need to specify BOTH dimensions (i.e. if i resize to 1024, i need to take DAR into account myself, and put 576 for 16:9 or 768 for 4:3). Since ffdshow itself has access to DAR value, I think it's relatively easy to let user enter only horizontal dimension and calculate vertical target resolution based on the DAR value received. Current behaviour (when user is forced to specify both values) seems to be rather stupid imo.

I think that can be just several lines of code which need to be changed :P

[LoRd_MuldeR]

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

But the build would be a lot "faster" with SSE enabled, eh?

[videomixer9]

ICL actually always takes quite long to compile and honestly for decoding libav is the thing which matters and for resize etc. libmplayer. The rest doesn't seem to profit that much from SSE and SSE2, but maybe someone can show me an example with some major difference in speed.

[haruhiko_yamagata]

http://neuron2.net/misc/1deint.avi

This is the huffyuv file. It was playable around early may, when I first downloaded it. I don't know if it's just some recent optimization or compiler options.

Mulder: Because ICL takes twice as long to compile with sse on? =p (Maybe that's changed though.)

Edit: Ack, I downloaded the wrong ffdshow; the current one plays this file fine. False alarm!
Thank you. My own build played fine.
Videomixer9, I forgot to write "please be sure to re-compile libmplayer.dll".

[videomixer9]

One of my versions before made use of auto-vectorization of GCC which worked fine except that it broke huffyuv, however I had it replaced with a non-vectorized version then, seems the final GCC 4.1.1 has it still unusable too.

[haruhiko_yamagata]

I'm sorry, I downloaded ffdshow-20060621-rev2546.exe carelessly.

ffdshow-20060625-rev2546-icl91-nosse.exe works fine.

[videomixer9]

lots of people downloading wrong things today o_O

[_xxl]

http://www.mplayerhq.hu/design7/news.html
MPEG-1/2/4 and H.264 decoder speedup
skiploopfilter/skipidct/skipframe decoder options for very fast H.264 decoding

[videomixer9]

and i bet it'll look like shit ... speedup I'd call some better optimized code doing everything and not skipping half of the decoding work. Otherwise that release version bases it changes on the last pre7 version which was ancient.

[Liisachan]

ffdshow-20060625-rev2546-icl91-nosse1.exe
"Queue output samples" and Pause don't mix well yet.

- Let's say the video is paused at Frame #1000; then MPC gets Frame #1009 or so, which is off by 9.
- When the video is restarted, it's restarted from #1001 or so, correctly.

VMR9 Renderless. RGB32.

[haruhiko_yamagata]

ffdshow-20060625-rev2546-icl91-nosse1.exe
"Queue output samples" and Pause don't mix well yet.

- Let's say the video is paused at Frame #1000; then MPC gets Frame #1009 or so, which is off by 9.
- When the video is restarted, it's restarted from #1001 or so, correctly.

VMR9 Renderless. RGB32.
It is very difficult.
I'm trying very hard to fix it but still clueless.
I wrote very incomplete patch for MPC, but I wonder if I should post it. It just works, but fails to repaint. VMR9's StretchRect returns error for unknown reason, and blackout. The patch trys not to call Present when StretchRect failed(trys not to show incompleat backbuffer). Not radical at all.

I think the bug(unknown error of StrechRect) may not be ffdshow's nor MPC's. It may be rather VMR9 or deveice driver's. Intel 82865G fails, but some other VGA card works.

[Liisachan]

@haruhiko_yamaga
Well, I guess it's not a big deal. I mean, I can live with it. I just figured I'd let you know thinking it might be a problem easy to fix.
Thanks you very much for your efforts.

[haruhiko_yamagata]

@ haruhiko_yamagata :

Thanks for your participation in ffdshow development btw!

Is it possible to request patch? I've been asking Milan to do that for ages, but still nothing was done.

In the software resizer (which i nearly always use) you need to specify BOTH dimensions (i.e. if i resize to 1024, i need to take DAR into account myself, and put 576 for 16:9 or 768 for 4:3). Since ffdshow itself has access to DAR value, I think it's relatively easy to let user enter only horizontal dimension and calculate vertical target resolution based on the DAR value received. Current behaviour (when user is forced to specify both values) seems to be rather stupid imo.

I think that can be just several lines of code which need to be changed :P
Entering your screen size to "Specify size / New size" and selecting "Keep original aspect ratio" will do nealy what you say as far as you use fullscreen mode, though it may be heavy.
Anyway it's a good idea, I'll try when I have time (perhaps not so easy, it needs a lot of re-engineering).

[Egh]

Entering your screen size to "Specify size / New size" and selecting "Keep original aspect ratio" will do nealy what you say as far as you use fullscreen mode, though it may be heavy.


Well soon this idea will be a year old :P At least counting from the moment I first presented it to Milan.

And your method is not good. It's known for ages, but it leaves THE notorious black bars above and below the actual video frame, which is stupid and CPU waste imo. Turn OSD on, for instance, and see where the text is displayed. Thus in such mode instead of operating only with 1280*720 surface, ffdshow deals with full 1280*1024 (if that's fullscreen resolution used, which is btw standard one for all 19" TFT). And then due to that subs are displayed at a wrong position :P This was known for ages, I think ffdshow sf trackers have prooly 3-4 separate entries related to that (including one mine ^^) over the last year, but Milan seem never was bovvered enough to change that behaviour :P

And of course once I originally made up this idea, others suggested some improvement to it. One which I like was to let the ffdshow automatically get the current fullscreen resolution and resize to that horizontally (if an option is enabled, of course) and take into account DAR, of course.

[foxyshadis]

I don't believe it's a waste of cpu at all - it's a bug in output module, not in the resize itself, as far as I can tell. When I first started using resizing and noticed it happening, I made tests (like turning on heavy noise) and nothing shows in the black area, so it isn't affecting downstream filters, just adding some extra memory copies on the output. (Unless you use VMR9 renderless or Haali's, then it would waste a little gpu in the pixel shaders.) I suspect the output module because I think that's where OSD is rendered.

Screwing up subtitles definitely would be annoying, though.

[Dark Eiri]

Hey guys!
I was wondering... there is a SSE3 build of ffdshow?
In SSE3 capable CPUs, the performance would be how better (in %) with a SSE3 optimized build?

Thanks in advance ^^

[Liisachan]

http://kurosu.free.fr/ffdshow-20060424-13H04-sse3.exe

[foxyshadis]

Depends. Is it an Athlon/Opteron? Virtually no difference over SSE even with full optimization, because SSE2/3 is internally broken into SSE in AMD architectures. On Intel there could be a performance enhancement in certain decoders and filters, but it'd be incredibly dependant on what decoders & filters you use, and most likely employing kassandro to perform the optimization (even ICL isn't a tenth as amazing as he is).

If you just want to compare old SSE vs SSE3 ICL builds of vm9's, I think I found a 1-2% difference for avc video with resizing.

[Dark Eiri]

Depends. Is it an Athlon/Opteron? Virtually no difference over SSE even with full optimization, because SSE2/3 is internally broken into SSE in AMD architectures. On Intel there could be a performance enhancement in certain decoders and filters, but it'd be incredibly dependant on what decoders & filters you use, and most likely employing kassandro to perform the optimization (even ICL isn't a tenth as amazing as he is).

If you just want to compare old SSE vs SSE3 ICL builds of vm9's, I think I found a 1-2% difference for avc video with resizing.

Thank you for all your explanations. You are really helpful ^^
And Yeah, it is an AMD Athlon64. :(

Liisachan: Thank you for the link! I'll try this build anyway. :D

[_xxl]

http://rapidshare.de/files/24249564/ffdshow-20060627.exe.html

[Livesms]

http://rapidshare.de/files/24249564/ffdshow-20060627.exe.html


When somebody will fix bug with PP for H264
Set by default "when decoding H.264 video" and not "when decoding H.264 video and decoder deblocking off".

There is no sense to disable PP at all, but this washed-out picture when "when decoding H.264 video and decoder deblocking off" :sly:

[foxyshadis]

Set it to that and remove the option. Leave it in the registry if anyone needs it but remove the damn useless and misleading option if no one's going to implement detection of when inloop is disabled in the source. </rant>

[Egh]

if no one's going to implement detection of when inloop is disabled in the source. </rant>

Hmm... Does ffdshow fail to detect that inloop is disabled in sauce or what? Seems a bit strange...

[videomixer9]

I brilliantly hate postprocessing in ffdshow so much that if I didn't break anything postprocessing should be disabled when installing per default (milans script has it enabled together with the sound normalization), dunno which idiotic idea drove milan to make this crap on per default. I don't care about the other things as imo anyone who enables postprocessing must be insane anyways :P

[trodas]

Postprocessing MUST be OFF by default. No-one want to see blurry picture when it should not be that blurry. Blocky? Well, that is the source/bitrate/codec problem and compensating it by blurring everything SUXX :(

Futhermore I have strange problems/crashes when trying to play mp4 video with FFD show May 26 2006... :(

It won't even install on my W2k SP2, however when I install older version and just replace the files - all working. Except MP4 files, damn :(


PS. install of the latest version there from the RapidShare works well, however still crash:

BSplayer v1.41.832, Unhandled exception at EIP: 77FCB892
If you click 'Close' application will be terminated.
Please report this info to the author with description what were you doing.
If you have internet connection, it's recommended to send error report, this will help us solve problems faster.
Access violation at address 77FCB892 in module 'ntdll.dll'. Write of address 0000A904
EAccessViolation
Call stack: 00000000,77FCB892,0040482B

[haruhiko_yamagata]

Hello, trodas. Is the crash related to postprocessing?

[trodas]

No, more likely to someone (M$?) stupidity. When I rename the files in question from *.mp4 to *.3gp then all is working now... :scared: ;)

A nice example that years after W98 crashed when one rename mp3 as wav is the problem still there... :(

[videomixer9]

to me this sound more like you got some fucked up filters installed. The blame MS for everything is out amongst non-clueless people :P Better check what's all handling mp4 for you and which things are added as handlers for it in registry etc. I bet you got Nero or whatever kick in there ...

[foxyshadis]

Hmm... Does ffdshow fail to detect that inloop is disabled in sauce or what? Seems a bit strange...
The h.264 PP requires you to manually state whether inloop is enabled or not. In the basic default setting, it's set as if inloop is off. And it has entirely misleading name and values, because it sounds as if it affects inloop deblocking, but that's only set on the main codec config page.

Normal mplayer pp is mostly annoying because it doesn't scale well. Low-to-mid quants will be a blurry mess when high quants are hardly touched at all, and default 100 w/dering is still too high for normal. If deblock were set to 80 and dering to 50 (by modifying the algorithm) it would probably work for the majority of what's watched.

[mpioner]

haruhiko_yamagata
thank you for work
may be you fix CPU load bug in OSD on dual CPU?

[Egh]

The h.264 PP requires you to manually state whether inloop is enabled or not. In the basic default setting, it's set as if inloop is off. And it has entirely misleading name and values, because it sounds as if it affects inloop deblocking, but that's only set on the main codec config page.


Yeah I noticed that H264 deblocking setting doesn't actually affect anything :) Only way to set it is to use those checkboxes at the Codecs page. I guess the combobox at PP page should be completely removed to eliminate confusion.

As for casual, non-inloop PP, that's big BS anyway. If your sauce is bad, it wont' do it really better, if it's good, one doesnt' need to use it anyway :P

What I really recommend as PP is THE deband filter. Banding is very common in anime-style material, and ffdshow filter is superb to remove it. So apart from Debanding and software resizing filters in ffdshow, i hardly use anything at all.

[haruhiko_yamagata]

haruhiko_yamagata
thank you for work
may be you fix CPU load bug in OSD on dual CPU?
Hello, mpioner. It's buggy before mt patch.

Is it nessesary? It may not easy to fix. As far as it exists, it should work properly. Deleting it is easier, but I hesitate to delete something that milan has written. Disable and forget may be better.

[kurt]

after installing videomixer's ffdshow-20060625-rev2546.exe, I got a msvcr80.dll error when using xvid_encraw and megui

http://img230.imageshack.us/img230/1966/image21bb.jpg (http://imageshack.us)

no problems with ffdshow-20060604-rev2546.exe (also from videomixer)

[pdanpdan]

after installing videomixer's ffdshow-20060625-rev2546.exe, I got a msvcr80.dll error when using xvid_encraw and megui

http://img230.imageshack.us/img230/1966/image21bb.jpg (http://imageshack.us)

no problems with ffdshow-20060604-rev2546.exe (also from videomixer)
Delete the ffdshow filter in avisynth plugin directory.

[_xxl]

libx264.dll to decode x264?
It is faster than ffmpeg/libavcodec.
libx264.dll can be used in ffdshow?
http://www.vid-labs.com/products/products.htm
The codec incorporates patent-pending complexity reduction algorithms that adapt to the video clip content and selectively bypass parts of the coding process.

[Egh]

http://www.vid-labs.com/products/products.htm
Fast MPEG4-10 H264 software CODEC!!!


But it's not free source :)

[max-holz]

I want to tell to anybody that the file

ffdshow-20060604-rev2546.exe

was detected tonight by my antivirus as containing the virus
Trojan.Zlob

http://securityresponse.symantec.com/avcenter/venc/data/trojan.zlob.html


BE CAREFUL!

[foxyshadis]

If you look back in the thread to when it was released, you'll see it was a false positive! It was submitted to sites that test against a couple dozen AV engines. Ensure your definitions are up to date, and if they are, dump that worthless symantec trash.

[Liisachan]

There is even this note on every mirror site.

http://ffdshow.faireal.net/

ffdshow-rev2546-SSE2.exe
...
NOTE: Some antivirus software may "detect" a Trojan in this file, which is a false positive (there is no virus in it)...

Just stop and think about it... Most of the ppl around here are geeks, hackers, otaku, geniuses, nuts, aliens, haruhi, whatever. If there really was a virus or trojan in it, they would have found it soon and there wouldve been a huge fuss one hour after the release... don't you think so?

So the bottom line is:

:search:

[foxyshadis]

btw, concerning the h.264 pp debacle, I decided to look a little harder and found that due to a code bug, what's actually happening is that the meanings of each option are reversed. No wonder it makes no sense!


"off": it's always on, "always": disables pp entirely, including for asp, "h264 video": it's always off, "h.264 video without deblocking": it's off when inloop is disabled and on otherwise. Makes sense, eh? The wrong setting obviously doubles up inloop.

I still support setting it to the safest (currently #3) on install, removing the UI, and relegating it to a registry-hack option only.

[clsid]

When PP is off, all four options give me similar dfps.
When PP is on, option #1 and #4 produce higher dfps (almost twice as high) than #2 and #3.

What does "skip deblocking when safe" do? It gives me about 13% better performance. But does it affect visual quality?

[kurt]

Delete the ffdshow filter in avisynth plugin directory.
ok, I deleted ffavisynth.dll and the error message don't appear anymore. thx! :)

[Egh]

What does "skip deblocking when safe" do? It gives me about 13% better performance. But does it affect visual quality?

i think "safe" means you won't see blocks in the picture due to debloking filter being turned off. If completely disable it, then, depending on the sauce inloop filter settings and the bitrate (the lower is the bitrate of the sauce, the higher impact inloop filter actually has on the video quality), some blocks might appear.

On my XP 1800+ "safe deblocking" is actually a very important option, especially for 576p and 720p AVC videos.

[soulstace]

K-lite codec pack always seems to keep up with the latest ffdshow builds.

[_xxl]

http://www.torrentspy.com/torrent/785459/ffdshow_20060703

[foxyshadis]

skip deblocking when safe = deblock only reference frames (i/p-frames mostly). If your source is of questionable quality you'll notice a distinct smooth/blocky pulsing from it, because b-frames won't get deblocked.

clsid, I get the same results and I'm not sure why. I'd like to build ffdshow so I can mess with the pp filter, but I don't want to deal with the hassles right now. ^^;

[haruhiko_yamagata]

I'd like to build ffdshow so I can mess with the pp filter
Good news! It's fun. Let's mess all together.

[therealjoeblow]

videomixer9, your download site appears to be dead:


"ERROR 403
Die angeforderte Seite konnte nicht geladen werden!"

[NULUSIOS]

therealjoeblow indeed - I got online to post the same thing

and it is for some days now... rss also

[foxyshadis]

Oh, and vm9, when you return would you mind making a full patch against svn? That would be a lot easier than integrating almost a dozen small patches. (I don't have them or I'd make it myself.)

[clsid]

ffdshow patches (http://www.mytempdir.com/785874)

[clsid]

Refuse loading from blacklist:
Re-installing ffdshow.ax sometimes fails because ffdshow.ax cannot be deleted.
Explorer.exe loads ffdshow.ax and never releases.
That causes annoying error on re-install that one have to log off.
With this patch, ffdshow.ax avoids to be loaded by returning false on DllMain
if the caller is included in BlackList("Don't use ffdshow in:").
aWarpSharp
changed default setting of "Chroma mode"

Fixed resource leak : Thanks, hartlerl
Could you post a separate patch for these non MT related changes?

OSD item : Queued samples (joke).I think you broke the OSD a bit. Some of the variables (e.g. %ifcc) don't work anymore when you create a custom user-defined OSD string.

[haruhiko_yamagata]

Could you post a separate patch for these non MT related changes?.
I'm sorry. I "choosed" to merge, dropping some merits. Please understand. If you really need it, you can do it yourself.

I think you broke the OSD a bit. Some of the variables (e.g. %ifcc) don't work anymore when you create a custom user-defined OSD string
Thank you. I'll look into it.

[trodas]

videomixer9 - to me this sound more like you got some fucked up filters installed. The blame MS for everything is out amongst non-clueless people :P Better check what's all handling mp4 for you and which things are added as handlers for it in registry etc. I bet you got Nero or whatever kick in there ...

You bet might be accurate, that I had to install the Nero crap with current win (later I will not install it, just use it...) and - what and where to check this?
And if simple file rename fix the problem, who to blame that M$ then? I refuse to be clueless, but your reply won't help me a bit to understand, where the problem is... :o


Guys, stupid question - is the ffdshow-20060627.exe capable of showing a preview of frames in VirtualDub mod or not? Mine refuse... :rolleyes:

And I just wanted to cut out some parts of movie... :rolleyes:

[foxyshadis]

ffdshow vfw gives me no trouble. Troubleshooting is impossible without some kind of error message. (If it's something about "forward reference frame" you just plain can't open that file in any version of vdub.)

The reason it's stupid to blame MS is because they created the framework, but not the buggy/drm'd filters. Nero playback filters take over mp4 even though they'll refuse to play it in applications other than showtime. Removing or demeriting nero splitter and using haali instead is the best way to fix this.

I'm surprised at how many people get mad that things crash or don't automagically work when you feed them wrong extensions or random information. It's nice not to, but it means more development & testing = higher cost & time.

[nfm]

where can I find latest daily build ffdshow source code?

[_xxl]

SVN source code:
https://svn.sourceforge.net/svnroot/ffdshow
FFdshow Patches:
ffdshow patches (http://www.mytempdir.com/785874)

[trodas]

foxyshadis - this is the error message:

http://www.slibe.com/fullimage/a9cb9101-virtual_dub_erro.gif (http://www.slibe.com)

M$ crated framework where one can find next to impossible (w/o hacking with registers impossible, I fear) to fix the stupid problem, so M$ is up to blame.

Now any kind of information how to actually remove (unregistering the splitter should be enought, right?) the Nero sh*t is more that welcome :confused:

[Isochroma]

Did you check that "DIV3" fourcc is checked in the ffdshow "VFW codec configuration" this is different from the "Video decoder configuration" which is for the directshow decoder.

[_xxl]

Did you check that "DIV3" fourcc is checked in the ffdshow "VFW codec configuration" this is different from the "Video decoder configuration" which is for the directshow decoder.
you need VFW codecs: divxc32.dll & divxc32f.dll (system32)
and this registry key:
REGEDIT 4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]
"divxc32.dll"="divx® 4.1.0.3927 (low-motion)"
"divxc32f.dll"="divx® 4.1.0.3927 (fast-motion)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"vidc.div3"="divxc32.dll"
"vidc.div4"="divxc32f.dll"

[foxyshadis]

you need VFW codecs: divxc32.dll & divxc32f.dll (system32)
Don't recommend divx3 codecs, besides being illegal they're buggy as hell, and you're far better off using ffdshow (which has no decoder bugs and compensates for divx3's encoding bugs).

For the other problem, try radlight filter manager.

[Egh]

M$ crated framework where one can find next to impossible (w/o hacking with registers impossible, I fear) to fix the stupid problem, so M$ is up to blame.


rundll32.exe ff_vfw.dll,configureVFW is your friend :P provided, of course, that ffdshow is properly installed and ff_vfw.dll is present in the system.

[_xxl]

http://rapidshare.de/files/25188124/ffdshow-20060707.exe.html

[Liisachan]

@trodas
If the problem is MS-MPEG4v3, and if you are on Windows 2000, you can just intall MPG4DS32 (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/MS-MPEG4v123_win2k.zip); afaik so-called DIVX3 and MS-MPEG4 are the same, except fourCCs. If you are on Windows XP, I guess MS-MPEG4 should play out of the box (not sure).

[akapuma]

Hello,

I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.

Older build's (videomixer9 and other) shows a "current value" above 100%, see attatchment.

The kuroso-builds (20060706 and 20060705) always show 100%.

Best regards

akapuma

[LoRd_MuldeR]

Hello,

I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.

Older build's (videomixer9 and other) shows a "current value" above 100%, see attatchment.

The kuroso-builds (20060706 and 20060705) always show 100%.

Best regards

akapuma

Works fine here :rolleyes:

[akapuma]

Works fine here :rolleyes:Not here. I tested on different systems:

2 x Celeron Prescott with WinXP and sse3-build
1 x Athlon 64 with Win2000 and P3 and k8-build

And with different players: MPC, WMP6.4 and 9, DVBviewerGE

Always same result: old builds works, new builds only without normalization.

Best regards

akapuma

[NULUSIOS]

...and where is videomixer and his builds?

[Liisachan]

I played around with a 120fps video clip a bit, using several different ffdshow builds, including milan's 2005-11, and for this specific sample, vm9's "haruhi" 2006-06-25 is the fastest.
The effects of "queue output samples" are not very clear. Actually disabling it makes rendering faster (very slihglty) in this case, perhaps because no pp is used at all.

This is my current settings:
ffdshow: Output color space RGB32
win2k sp4, dx9 june 2006
MPC: rev611
VMR9 Renderless+VMR9 Mixer mode+YUV mixing
Use texture s... in 3D
Bicubic A=-0.60
Lock back-buffer... NO (unchecked)

I don't know the difference between 3 Bicubic modes, so -0.60 is a random choice; also the Lock back-buffer thing is maybe unrelated or unimportant here; the other settings are so far what I believe is the best for my hw.

[akapuma]

...and where is videomixer and his builds?Latest build from videomixer9 with sse ffdshow-20060625-rev2546.exe

http://rapidshare.de/files/25213866/ffdshow-20060625-rev2546.exe.html

Best regards

akapuma

[haruhiko_yamagata]

Resize setting - automatic vertical size setting
Specify horizontal size and enter 0 as vertical size for Automatic aspect ratio. I don't think the user interface is a good idea. What should it be like?
I'm trying to support the "non-square pixcel", but it depends on video renderer's behavior.

Bug fix
Window media player hangs up when its picture tuning is on and "Queue output samples" is on. Besides it is not effective to queue in WMP(because WMP doesn't give buffer soon and ffdshow have to wait). So, "Queue output samples" is off by default on WMP. It is reserved in dialog expecting improvement by Microsoft in the future.

hang up on ZoomPlayer on initialize(TffdshowDecVideo::IsOldRenderer).
hang up on Resize or aspect settings change(TffdshowDecVideo::reconnectOutput)
theoretical bug fix(?) of swscaler-multithreading.
Because the code seems not to be used in ffdshow, it is not tested.
For better single CPU/multithreading : THREAD_PRIORITY_ABOVE_NORMAL for video renderer.
THREAD_PRIORITY_BELOW_NORMAL, tested on prior patch, was not good on WMP.
fixed user defined OSD, broken since last patch.[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) ffdshow_multithread_060709.patch is PATCH to PATCH.
To rev2546 + ...060517.patch + ...060601.patch + ...060604.patch + ...060625.patch

[haruhiko_yamagata]

My build(SSE) (http://www.mooload.com/new/file.php?file=files/090706/1152429181/ffdshow-20060709-Q.exe)

pure GCC 4.0.3 build.

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060709.patch
TsampleFormat.patch

[Liisachan]

This one is really fast at least for me, faster than vm9's. everyone try it out! mirrored (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060709-Q.exe)

[LoRd_MuldeR]

This one is really fast at least for me, faster than vm9's. everyone try it out! mirrored (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060709-Q.exe)

Thx! :)

[LoRd_MuldeR]

My build(SSE) (http://www.mooload.com/new/file.php?file=files/090706/1152429181/ffdshow-20060709-Q.exe)

pure GCC 4.0.3 build.

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060709.patch
TsampleFormat.patch

The Auido-Normalizer doesn't work in that build :scared:
Any possibility to fix that problem?

[akapuma]

The Auido-Normalizer doesn't work in that build :scared:Same like the last build's from kurosu :-(

best regards

akapuma

[LoRd_MuldeR]

Same like the last build's from kurosu :-(

best regards

akapuma

Well, I can use MPC's internal audio normalizer. But I hope the problem can be found & fixed anyway...

[haruhiko_yamagata]

Hello, Liisachan. Thank you very much for the mirror.

The Auido-Normalizer doesn't work in that build
Thank you for report. I'll investigate.

[Jorgosch]

I think, that the audio normalizing function of the new ffdshow-builds from http://kurosu.free.fr/ffdshow.htm is broken.


I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.

[akapuma]

I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.I have movies with x264 and vorbis in a mkv-container. Normalization don't works with this files.

Best regards

akapuma

[Liisachan]

it's kinda finicky... the new one is fast on Win2k but not that impressive on winxp, exactly the same settings, the same physical machine, different os...
vmr9mixer mode+YUV mixing that works best for me on Win2k doesn't work well on WinXP either (the color space is werid)...

[Egh]

I can partially confirm that. Normalisation doesn't work for AC3 sound but DOES work for mp3 source.


You can output result to AC3Filter and do normalisation there.

[Egh]

Resize setting - automatic vertical size setting
Specify horizontal size and enter 0 as vertical size for Automatic aspect ratio. I don't think the user interface is a good idea. What should it be like?
I'm trying to support the "non-square pixcel", but it depends on video renderer's behavior.



so have you added that patch in your build? Atm entering 0 vertical value in the vertical resolution editbox causes MPC to crash :)

[haruhiko_yamagata]

it's kinda finicky... the new one is fast on Win2k but not that impressive on winxp, exactly the same settings, the same physical machine, different os...
As for build, I'm a beginer. Videomixer9 and people around here are very familiar with compiler and it's options. I build for distribution because they all seem to be holiday.
vmr9mixer mode+YUV mixing that works best for me on Win2k doesn't work well on WinXP either (the color space is werid)...
Is it the build specific problem? I modified swscaler this time, it may be related...

[haruhiko_yamagata]

so have you added that patch in your build? Atm entering 0 vertical value in the vertical resolution editbox causes MPC to crash :)
Yes.
It is not reproducible here. What the settings(video renderer(includeing mode), color space, video card etc) are?
Is usual resize working? Can you change(not to 0) setting while playing?

[Egh]

Yes.
It is not reproducible here. What the settings(video renderer(includeing mode), color space, video card etc) are?
Is usual resize working? Can you change(not to 0) setting while playing?

LOL :P just checked -- it's fully b0rked :) I.E. resize itself crashes. It doesnt' crash only if target resolution is same as video (i.e. then no actual resizing occur).

It crashes always after checking resizing check box and playing the video afterwards. (e.g. when i pause the video, tick the box and start the video again)

For instance:

sauce: 640*480, SAR 1/1, DAR 4/3
In ffdshow resize section settings as follows:
No aspect ratio correction, Specify Size 1024 768; Resize Always.

Those setting work with last VM's build but fail if your build is installed. If I reinstall VM's build all is working as usual again.

My CPU is SSE1 only, if that matters, btw.

MPC settings: do not matter whatsoever. Crashes on VMR9 (no mixer mode) with any of three modes (plain, 2D & 3D). Crashes on Overlay Mixer as well. Crashes with YV12 colorspace and with forced RGB32.

EDIT: thru Remote Desktop I just tried new ffdshow on a PC which has even SSE3. Still same stuff. Besides, that PC has D.E.P. enabled for all programs, and D.E.P. exception was raised first before general message about MPC crash :P

[haruhiko_yamagata]

Hello, Egh.

Well, I think I build for SSE1 only, but I'm not familiar with build settings. Or is it the source?

Please try "replase libmplayer.dll with the last videomixer9's".

[Egh]

Hello, Egh.

Well, I think I build for SSE1 only, but I'm not familiar with build settings. Or is it the source?

Please try "replase libmplayer.dll with the last videomixer9's".

Nah, still same stuff. Even with both libmplayer & libavcodec taken from last VM9's build.

As for SSEx it doesn't seem to be a problem, as I already said in the edit text in my last message :) D.E.P. seems to be an answer :) So you might not have a crash due to different build of MPC or something else. But the problem is here...

[videomixer9]

wow damn homepage was deleted, uploaded it elsewhere again, use the link in the sig. was just away for some days and it's like that, typical.

[LoRd_MuldeR]

wow damn homepage was deleted, uploaded it elsewhere again, use the link in the sig. was just away for some days and it's like that, typical.

Now that you are back, can you make a build with latest patch by haruhiko_yamagata, so we can see what's the matter with the audio-normalizer ???

[videomixer9]

I'm on it currently, had to redo from scratch my sourcetree didn't like that latest patch so it takes a while :P

And to all the japanese paranoids out there that trust their fucked up antivirus programs more than me, there is no virus anywhere in my builds and ICL9 just generates larger code, that's all. I wonder where all these noob theories come from. I take the recent wave of antivirus programs detecting open source installers and programs as trojans as an attack vs. open source software and recommend you to get evtl. money you paid for those programs back.

Btw. new build is up ... here (http://ffdshow.pyrokar.lima-city.de/current.php).

[LoRd_MuldeR]

Btw. new build is up ... here (http://ffdshow.pyrokar.lima-city.de/current.php).

That build seems to work fine :) What about an SSE version ???

[videomixer9]

maybe later, only interesting for filter uses of filters that are embedded into the ax file or other libs than libmplayer.

[Egh]

That build seems to work fine :) What about an SSE version ???

What is more, it doesn't crash on rezise :P

Though i think the CPU usage for resizer somewhat increased.

Another thing for the patch is that it works ok in VMR9 mode, but in Overlay Mixer it doesn't actually resize :) Not that I care since I don't use OM...

[videomixer9]

With Overlay Mixer you need to reopen the video to make resizing take effect, it only works on the fly with VMR modes.

[akapuma]

No problems with normalizing. Thank you, videomixer9.

Best regards

akapuma

[Yama4050242]

@videomixer9
your build ffdshow-20060709-rev2546
can not play my old x264 encodes
sample here
http://www.megaupload.com/?d=AZRHIBZV

[videomixer9]

that shit file again ... it only doesn't work with the gcc 4.1.1 sse build though and works with the other, dunno which craptastic art it is that makes your shit borked on sse all the time. Prolly SSE doesn't like chinese. Might be libfaad though too. Other than that it produces overflows on memory reservation, wonder if this video isn't just made to make things crash ... at least when ICL9 comes into play, I remember this video crashing before with the same settings.

Stick to the nosse version for now, it uses optimizations too but it doesn't have important things like the checkboxes use SSE :O Yes, these are the thing that get SSE optimized by the compiler ... that so doesn't help with anything. Even with GCC things, if you define -msse it will get undefined in the code anyways again.

[haruhiko_yamagata]

Hello, videomixer9. Your build is great. I should have waited.

[videomixer9]

I think the problem is still the pure GCC try, it just doesn't work correctly, especially on the parts of MS headers etc. being involved. As for me, special SSE builds are no more, next versions will be ICL+GCC 3.4.5 without any of the SSE things in ICL enabled. Too many problems with ICLs extra switches, and /arch:SSE is a pure useless switch. GCC 4.1.1 seems broken and seems to be the culprit for broken old files by Yama ...

[thuan]

The file from yama above and shon3i still crash with your newest build with nosse. I don't think it because gcc4.1.1 sse because it works with haru build, clsid build, vm9's older builds with msvc ffdshow.ax and the crash reported it is a crash in ffdshow.ax module. I think icl ffdshow.ax is the problem whether sse or not. My CPU is SSE only.

[videomixer9]

Oh well dunno where it overflows but I did a mix build now with ICL91 for anything but the .ax, the ax as msvc 2005 and gcc 3.4.5 for the rest.

[thuan]

Works perfectly now, thanks vm9. This problem seems to cause by a revision of x264, actually watch a lot of anime but haven't stumb upon any file like this beside here.

PS. Haruhi ends so fast before I know it damn.

[LoRd_MuldeR]

ffdshow-20060710-rev2546.exe breaks KernelDeinterlacer :(

[videomixer9]

just replace it with an old one, nothing changed and in which way it is broken, I tested it and it worked. There's nothing different in that compile than in every other one.

edit: okay i got something that is actually broken with it, I'll just replace this version quietly with a new one. ICL culprit again.

So ...

ffdshow.ax: doesn't like any optimizations of ICL for certain files (/O2 /O3 /Ox all breaking certain x264 files)
kernelDeint: doesn't like high level optimizations and compiles ages when not using link time code generation (/O3 breaks code, /Ox is fine, use /LTCG)
libfaad: floating point improvement breaks the sound (don't use /Op, /O3 and /LTCG okay though)
TomsMoComp: works fine but get stuck in optimization loop when not using link time code generation (/O3, use /LTCG o.k.)
FLT_ffdshow, ffvdub, makeAVIS, ffavisynth, ffwmv9, ffunrar, ffvfw, ff_acm: currently all using /O1 or with /LTCG, so far no reports of broken code
liba52, libdts, realaac, libmad, tremor, libmpeg2, theora: all doing fine with /O3 and /LTCG so far
auto parallelisation generally breaks things on intel cpus sadly (don't use /Qparallel)

btw. the build is updated with a fixed kerneldeint.

[LoRd_MuldeR]

Thank you once again!

[videomixer9]

btw. I tried kurosu's latest ffdshow for athlon xp with the posted x264 sample and it crashes too here O_o Also recommended for everyone trying to avoid being detected as virus try updating to nsis 2.18. nsis 2.16 gets your download detected as virus immediatly while downloading.

Also hey, I broke it so I have to repair it :P Now I should really keep those settings saved somewhere properly and stop fiddling.

[Egh]

@ haruhiko_yamagata:

lol, it seems that your patch sometimes is broken.

I have one sauce which is 1280*1080 (yes, HD anamorphic:P) and if I enter 1024,0 in the resizer it actually resizes too much in the vertical resolution, making less than 576 (DAR is 16:9).

It works with dvd anamorphic, like 720*480.

[Liisachan]

As for build, I'm a beginer. Videomixer9 and people around here are very familiar with compiler and it's options. I build for distribution because they all seem to be holiday. Oh, don't be so modest :)

Is it the build specific problem? I modified swscaler this time, it may be related... Nah, I didn't notice that until recently, as I didn't ususally use xp. It's not your build's pb, just general... perhaps my hw-specific.

for me things are like these.
RGB32 Output on VMR9Renderless + VMR9Mixer + YUV mode =
- Cool and very fast on Win2K
- Color Space is wrong and not very fast win xp
RGB32 Output on Overlay
- Not really fast on Win2k
- Very fast on Winxp

And what I meant by 'finicky' is, it's working amazingly depending on a minor detail configuration. NOT that it's all bad but I figured it would still need some tinkering... Keep up your great job!

[videomixer9]

isn't RGB32 output a bit stupid in VMR9 YUV Mixing mode, I mean it's meant for YUV input so it converts back to YUV or rather just ask upstream filters to output YUV or fails.

Overlay doesn't accept RGB32 input for me, MPC will also automatically fall back to VMR7 then. I guess on 2k it falls back to GDI or something which is slowass compared to VMR7.

[LoRd_MuldeR]

isn't RGB32 output a bit stupid in VMR9 YUV Mixing mode, I mean it's meant for YUV input so it converts back to YUV or rather just ask upstream filters to output YUV or fails.

Overlay doesn't accept RGB32 input for me, MPC will also automatically fall back to VMR7 then. I guess on 2k it falls back to GDI or something which is slowass compared to VMR7.

Colors look incorrect unless I froce RGB32 output in ffdshow.
Even in VMR9 YUV Mixing mode! Don't know why, but that's the way it is...

[clsid]

I have made an InnoSetup install script for ffdshow. With CPU detection :)

download (http://rapidshare.de/files/25481987/ffdshow_innosetup_script.rar.html)

[videomixer9]

Try using YUY2 and not YV12. Must be a reason Xvid and DivX decoders use it as default colorspace too :O

[LoRd_MuldeR]

YUV output:
http://img63.imageshack.us/img63/1222/yuv3ls.png

RGB32 output:
http://img63.imageshack.us/img63/3100/rgb323ih.png


YUY2 or YV12 makes no difference. I'll keep on force RGB32 output...

[videomixer9]

Well that is a VMR shoot, of course YV12 will look like YV12 only using the limited colorrange. I don't see anything wrong there, and if RGB32 looks like that with YUV mixing mode on VMR9 it's like wrong, should looks more like the first shot. I still don't get the VMR9mania, I stick to Overlays even though using them on VMR7 which is the fastest thing you can get on XP with hardware level conversion.

[LoRd_MuldeR]

Well that is a VMR shoot, of course YV12 will look like YV12 only using the limited colorrange. I don't see anything wrong there, and if RGB32 looks like that with YUV mixing mode on VMR9 it's like wrong, should looks more like the first shot.

Still the second one looks better, at least for my eyes :D
Haali Renderer always looks like the second one, but it has the delay problem...

[videomixer9]

Haali renderer just does level or RGB32 conversion itself. Of course YV12 will look funny on RGB32 screens, on TV out e.g. you prolly won't notice it though and that's what YV12 VMR9 is good for, you can output unchanged video to your TV. The colors are not wrong it's just that they are stored like this, but well what to tell all these VMR9 loving kids, only good thing on this modes is that you can view multiple videos at once, in reality nobody does that thus MPC auto switching of Overlay to the active player instance is fine enough for me when trying to do that. I don't see improved quality on those renderers either, but well people got rich imagination or never found the overlay color settings of their video cards, and why waste CPU time on things like Haali Renderer, as much as some may like it but e.g. OpenGL renderer in mplayer or VLC works way faster giving you basically the same benefits like using software resizers and colorspace converters. So much wasted energy for rendering video fancy when it works way easier with way less load. Remember that CoreAVC vs. Avivo checks, while Avivo may have been a bit faster than CoreAVC, the system used dozens of less watts for the almost same result :P

[Egh]

Hmm. I really don't understand what the fuss about levels. You can simply readjust levels in ffdshow or avisynth. So if you want YV12 output with corrected colors you can do that.

@ Liisachan: "RGB32 Output on Overlay" you sure you actually have "overlay mixer" in filters' list, not old GDI "Video Renderer".

@ VM9 : overlay doesn't allow screenshots iirc.

[videomixer9]

Well I don't do screenshots that often, and VMR7 windowed which uses Overlays additionally you can actually do screenshots, though of course the shot will come out without corrected levels if you don't correct them per software. This mode is also default on XP and working very fine, also using ffdshow for making shots isn't that bad.

[Liisachan]

@ Liisachan: "RGB32 Output on Overlay" you sure you actually have "overlay mixer" in filters' list, not old GDI "Video Renderer".
What I meant was MPC's Overlay + ffdshow's RGB32, on XP. That's only for testing but it was fast. I don't actually use it, because MPC's softsub is my life.

[SeeMoreDigital]

@ VM9 : overlay doesn't allow screenshots iirc.Unless I'm misunderstanding something... It seems to work okay for me: -

http://img269.imageshack.us/img269/4607/vmr9snap2uu.jpg

Cheers

[videomixer9]

What he meant was basically the same as me, you wrote it isn't really fast on 2k and that being due to it not being really Overlay. Also I wonder if on XP it really used Overlays as said, at least for me RGB32 ffdshow output makes Overlay not working and it will fall back to VMR7 without using overlays. Also softsubs might be a bit less resolution with vsfilter instead of using MPC internal renderer but it's fine enough for me and if you really need the quality just resize the video to a higher res via software so vsfilter renderers onto a better res, on TV it's no quality difference anyways, and most effects you can do with this filters are hardcoded mostly by encoders anyways as rendering eats massive CPU.

SeeMoreDigital: trying to run for the clowns award? he talks about overlays, not VMR9 (or as I'd call it kids toy, I think the original intention of that renderer is to give game designers the possibility to display videos on objects ingame). But VMR9 is cool and new so all the kids must use it for video playback duh.

[Egh]

What I meant was MPC's Overlay + ffdshow's RGB32, on XP. That's only for testing but it was fast. I don't actually use it, because MPC's softsub is my life.

and yet as I pointed out already, it's no wai an overlay :P


AFAIK, with ffdshow forcing RGB32 colorspace output, it does NOT use overlay on XP. And, it does not fallback to VMR7 as well (@ videomixer9).

It shows here (and always shown for me on any XP PC I tried) only "Video renderer", which is same as "Old Renderer" option in MPC. Though it might be due to videocards used on those PCs (all were NVidia).

Thus, Liisachan, you can pretty much have same result by selecting "Old renderer" instead of overlay mixer.

[Liisachan]

Egh: Yeah, I guess. What matters is not whether it is really Overlay or not, but it was fast when I ticked the box that says Overlay, on Win XP. I don't usually use XP to begin with. So that was just a random test so to speak.

...softsubs might be a bit less resolution with vsfilter instead of using MPC internal renderer but it's fine enough for me... Yeah, that's fine if it's fine for you.
most effects you can do with this filters are hardcoded mostly by encoders anyways as rendering eats massive CPU. It is understandable that leechers think that way, because their purpose is to read subs to enjoy the anime/movie. If it's readable and in a decent quality, it should be ok for them, and that's normal and nothing's wrong with that. Although, encoders (whom you talked about) themselves may have different perceptions. Anyway to sum up,
(1) there is a checkbox called Overlay Mixer in MPC's Output config, and selecting it may effect the performance
(2) Ticking the above "Ovelay" box doesn't necessarily mean that what is called Overlay is really used.
(3) If Overlay is really used, it's directly from HW, so you can't screencap. Otherwise you can.

Now back to the subject... What I was trying to say was:
- Ppl say "this ffdshow build is fast, and that is not fast" etc. but the speed is quite different according to your settings (this part is obvious). And there can be great difference even if the settings are the same, between Win2k and XP, and I found it kidna interesting.

[haruhiko_yamagata]

I have one sauce which is 1280*1080 (yes, HD anamorphic:P) and if I enter 1024,0 in the resizer it actually resizes too much in the vertical resolution, making less than 576 (DAR is 16:9).

What are the SAR (You can get the value in OSD)?
Does restarting of the video application improve anything?

[_xxl]

I have made an InnoSetup install script for ffdshow. With CPU detection :)
download (http://rapidshare.de/files/25481987/ffdshow_innosetup_script.rar.html)
InnoSetup install for ffdshow with CPU detection:
http://rapidshare.de/files/25562637/FFdshow_rev2546_20060711.zip.html
CPU detection:MMX,SSE&SSE2.

[videomixer9]

xsharpen is broken now and produces green funk when using it together with resizing, the effect is only to be seen on MSVC .ax files. *grrrr* ffdshow's wild codemix starts pissing me off. Affects my own build and that build drevil_xxl just posted :O

On the other side, I got a sharpness control for overlays in my gfx card settings, another big bonus :P Also this whole postprocessing thing is highly annoying anyways, people should just produce proper encodes that don't need filtering. Any video I get that would need postprocessing is usually immediatly deleted by me. If the source is bad the encoder should fix it and not the user on playback.

Once mplayer or VLC got a proper sub renderer I think I kiss goodbye to this shit and rather spend time on a minimal mplayer without all the filtercrap that's plain bloat for playback.

[clsid]

I don't see any green funk in my rev2543 build. Perhaps it's related to the recent resizing patches?

[videomixer9]

Well it seems the resizer is the culprit on this one indeed, replaced libmplayer.dll fixes this, odd though that both filters work fine independantly but break as a team, compiler mix again prolly, maybe due to different behavior in generated code or different variable strength or mixed bitorders. i'm currently at university and don't have any code, also it doesn't seem urgent as prolly less than 1% of ffdshow users use this, a bit more maybe that only use sharpen and maybe way less using the resizer (prolly only japanese people, they got a craving for fake high res stuff, their p2p is full of upsampled shit with total blown up bandwidth like 50mbit/s wmv9 :O).

okay did some test on my notebook:

always xsharpen + resize:
my build: green
drevil_xxl: green
kurosu: crashes
haruhiko is fine ... I guess all of the three first use instruction sets forced enabled on GCC and some other settings. So GCC is prolly the culprit, I'll look into it later. Haruhiko probably used the default not enabling any intrinsic by the compiler used on libmplayer. I guess my nosse versions don't suffer from the green effect then either. This means the definite end of me trying to change anything in makefile_c.inc.

[haruhiko_yamagata]

This means the definite end of me trying to change anything in makefile_c.inc.
No, I think my recent patch triggered a bug? of GCC. If it is so, I can try fail-over. Please tell us what was the culprit switch when it get clear.

[videomixer9]

For that last build I used -fprefetch-loop-arrays (I used this on SSE builds often as many said seeking was slower when I removed it) and -msse -mmx and -mfpmath=sse,387 and had to upgrade to-march=pentium3 and -mtune=pentium3 so that I can use the prefetch-loop-arrays, the rest is -fgcse-after-reload and -fweb, I downgraded to -O2 so unswitching of loops is disabled. makes it look like this:

-O2 -mmmx -msse -mfpmath=sse,387 -march=pentium3 -mtune=pentium3 -fweb -fgcse-after-reload -fprefetch-loop-arrays and the rest which is there per default, don't remember it now. No fancy switches. Skipping the loop unswitching doesn't decrease speed while making libavcodec like 1 MB smaller and mplayer a bit too. If you don't add intrin things like -msse there it's not used as it is disabled per default on libavcodec and libmplayer in favor for pure automatic cpu detection and hand optimized code.

[videomixer9]

Removed the intrin switches and went back to i586 and i686 and dropped prefetch and it works ... prefetch only works with p3 or higher, prefetch removed alone didn't change anything. First time intrinsic broke stuff for me.

btw. I always wondered if there was a japanese or asian based filehoster like all those others, i got some from europe and usa but none asia based.

Also, as for this ffdshow.ax being used when reinstalling. /DELAY:UNLOAD fixes this too when using ICL or MSVC, the problem is, it unloads the .ax but it doesn't unload libmplayer.dll ... duh. Plan failed.

[LoRd_MuldeR]

mooload.com downloads with < 2 KB/s here. always.
Is that a local problem or is it always that slow?

[acrespo]

@videomixer9: After install vcredist_x86.exe (available in your page) and the latest version of ffdshow (20060711), when I open virtualdubmod I receive this error:

This application can't be started because not found MSVRC80.dll. The reinstall application can correct the problem.

I already copy this DLL and the manifest to virtualdubmod but I still have problem (a different message). The strange is that after press OK button in messagebox I can use virtualdubmod normal.

[videomixer9]

Well, if the redist is installed the problems should never appear, otherwise if you copy any files elsewhere than in the ffdshow directory the packed in runtime won't be found and it fails, vdubmod loads the plugin probably which you copied there or it detects. As said, if the redist is installed there should be no problem except it's errorness or you're trying to pull using some crap windows 9x which I doubt :P Don't think vdubmod needs this.

[kurt]

@ acrespo: http://forum.doom9.org/showthread.php?p=846991#post846991

[acrespo]

It was not function. The problem still here.

[acrespo]

Well, if the redist is installed the problems should never appear, otherwise if you copy any files elsewhere than in the ffdshow directory the packed in runtime won't be found and it fails, vdubmod loads the plugin probably which you copied there or it detects. As said, if the redist is installed there should be no problem except it's errorness or you're trying to pull using some crap windows 9x which I doubt :P Don't think vdubmod needs this.
I don't know what's happen here. The only thing I did is install vcredis_x86.exe and ffdshow20060711 in this order and virtualdubmod give me this message. I don't understand.



EDIT: I removed vdub filter and the problem still here but when I remove ffavisynth.dll filter the problem gone.

[foxyshadis]

That's a good one, the installer script should be modified to not install the aviynth plugin by default anymore, and when selected, not default to the actual avisynth plugin folder (because some builds will crash avisynth duing its filter enumeration). Perhaps the ffdshow folder isntead.

[_xxl]

InnoSetup with CPU detection:
http://rapidshare.de/files/25630509/FFdshow_rev2546_20060711.rar.html
Updated 2006-07-12

[acrespo]

That's a good one, the installer script should be modified to not install the aviynth plugin by default anymore, and when selected, not default to the actual avisynth plugin folder (because some builds will crash avisynth duing its filter enumeration). Perhaps the ffdshow folder isntead.

I don't have this problem with the version from x264.nl page. The avisynth plugin was not show this messages.

[kurt]

@ acrespo: just untick this during installation of videomixer's build

http://img100.imageshack.us/img100/1017/image17ak.jpg

[videomixer9]

Smartness overcoming people again, GCC builds don't use msvcrt as easy as that, that's why there is no such problems, they just statically include those parts. The compiles are larger usually cause of this too. b0bor build has like twice the .ax file size than my current build. More drastically with the avisynth plugin, 7.5kb vs. 62kb. 8 times larger filesize. Of course it has also other reasons but statically including things is also one.

If the CRT installer cannot get the CRTs to be properly found it not my problem but the one of your Windows install, nothing else. Randomly things tend to produce errors when it finds conflicting versions of this libraries or random smartness of people that try and copy that stuff in the system dir without manifests or similar. The redist installer usually copies them to something that looks like this: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd

I packed the CRT together like many do now that use MSVC 2005 but it won't be found when the plugins are installed in some directory where there is no copy of the CRT and the manifest, copying CRT and manifest to the avisynth plugin dir where the plugin is would probably also work.

[foxyshadis]

I don't think it was because of a CRT error, last I'd heard it was because it's a C dll whereas avisynth can only autoload C++ dlls, since it's in the folder it'll try anyway and either give up and move on, or find something it likes and error out when it can't properly initialize the plugin. I haven't tried to find out which builds actually cause that though, since I always put it in a non-autoload folder.

[videomixer9]

The language a dll was written in before it was compiled to binary code doesn't matter in any way and LoadLibrary and by compiler linked libraries can be loaded without any language border, as long as the compiler output is compatible to the linker you're using to combine the things you can mix any languages. I can assure you avisynth will load any DLLs if it has the ability to load DLLs. The conflict is based on other things. This one here is simply based on the fact the msvcr80.dll cannot be found in the directory where the avisynth plugin is placed in and the redist obviously failed installing or it needed a reboot. I read about some other problem where errors are thrown that an application tried to load the runtime incorrectly, this is usually the manifest missing or being corrupted it being manipulated in other ways, often also with misplaced copies of it somewhere in the system folders.

[haruhiko_yamagata]

For that last build I used -fprefetch-loop-arrays (I used this on SSE builds often as many said seeking was slower when I removed it) and -msse -mmx and -mfpmath=sse,387 and had to upgrade to-march=pentium3 and -mtune=pentium3 so that I can use the prefetch-loop-arrays, the rest is -fgcse-after-reload and -fweb, I downgraded to -O2 so unswitching of loops is disabled. makes it look like this:

-O2 -mmmx -msse -mfpmath=sse,387 -march=pentium3 -mtune=pentium3 -fweb -fgcse-after-reload -fprefetch-loop-arrays
It seems to be the version of GCC.
GCC 4.0.3 compiles fine with your option above.
When compiled by GCC 3.4.4 (with or without special option), it's green.

I have not specified the patch that triggered it yet.

[videomixer9]

Now I went with GCC 3.4.5 to avoid exactly such issues and that's the thanks from the gnu crew! I'm deeply disappointed ;O Maybe I move on to GCC 4.1.1 permanently after all.

[Egh]

Now I went with GCC 3.4.5 to avoid exactly such issues and that's the thanks from the gnu crew! I'm deeply disappointed ;O Maybe I move on to GCC 4.1.1 permanently after all.

who's pictured in the new 0712 build? :P

[videomixer9]

No clue, I created a lot of these installer pictures a while ago from random nice shots I had :O

[haruhiko_yamagata]

Well it seems the resizer is the culprit on this one indeed, replaced libmplayer.dll fixes this,
This is true, and replaced ffdshow.ax(by GCC 4.0.3) fixes this too.
The source code that triggered the problem is rev2528 or older.
I give up. There's no choice but to use 4.0.3 or newer for libmplayer.dll or at least for "swscale.o".

[Egh]

This is true, and replaced ffdshow.ax(by GCC 4.0.3) fixes this too.
The source code that triggered the problem is rev2528 or older.
I give up. There's no choice but to use 4.0.3 or newer for libmplayer.dll or at least for "swscale.o".

btw, speaking about ffdshow resizer.

I asked Milan long time ago, but nothing was done (typical:)). Can you tell me why Lanczos resizing produces noticable horizontal lines on resizing? AVS Lanczos resizing never produces that.

But in many "taps" settings in ffdshow you can see artefacts like horizontal lines (try setting taps to 1,2,3). I still not certain whenever it's a bug or not (Milan told me he uses code different to AVS one). Of course those lines are noticable only on clear colors like anime-style videos :) I have SSE1 only processor here, if it's relevant (maybe if it's a bug it's only in SSE1 code? )

If you studied the code for that resizer, btw, can you tell me the relation between taps in ffdshow and standard AVS 3tap 4tap? I think somehow they are not same.

[videomixer9]

Now a screen shot would help a bit maybe, I dunno if it's the same but when I tried with a family guy episode and with some hard trying I saw vertical lines o_O When I made a screenshot the effect was gone though, heh, maybe something else or imagination. Other than that I'm using generic versions usually as this SSE code generation is kind of useless anyways, setting arrays to all zero works fast enough without SSE :P

Lanczos resized image with 3 taps:
http://xs303.xs.to/xs303/06284/snapshot20060713204028.jpg.xs.jpg (http://xs.to/xs.php?h=xs303&d=06284&f=snapshot20060713204028.jpg)

[_xxl]

ffdshow-20060713 SSE
http://rapidshare.de/files/25765403/ffdshow-20060713.exe.html
ffdshow-20060713 SSE2
http://rapidshare.de/files/25758917/ffdshow-20060713.exe.html
libavcodec.dll & libmplayer.dll are GCC 4.1.1

[Egh]

Now a screen shot would help a bit maybe, Other than that I'm using generic versions usually as this SSE code generation is kind of useless anyways, setting arrays to all zero works fast enough without SSE :P



OK, fair enough. I just installed your 0713 build and reproduce the potential bug :)

Here's the result. Sauce: 640*480 xvid, resized with ffdshow Lanczos to 1024,0, taps: default, no additional sharpening or processing whatsoever.

The region where is the problem was cut out of the frame and 2x upscalled *with point resizing only* to demonstrate the problem more clearly.

http://xs303.xs.to/xs303/06284/linez.2x.png.xs.jpg (http://xs.to/xs.php?h=xs303&d=06284&f=linez.2x.png)
And the SAME frame with all setting but just changed taps doesn't produce that effect. It doesn't produce it @ taps=2 but will produce @ taps=3 again :)

[videomixer9]

Now the resizing code should come from mplayer, so if they didn't fix something their maybe try if the same effect is seen with mplayer when doing lanczos resize.

[Egh]

Now the resizing code should come from mplayer, so if they didn't fix something their maybe try if the same effect is seen with mplayer when doing lanczos resize.

I asked about that effect last year btw. In fact I noticed it even before that, several months at least. So if it's a bug it's been quite a long time.

[videomixer9]

You could try to turn of MMXEXT and try to see if it disappears, swscaler got a MMXEXT optimized horizontal scaler routine that is used if available. If nothing changes that one is okay at least, other we could conclude that one is borked. As said if mplayer also shows this effect it's just borked mplayer code and asking them to check the issue would be better.

[LoRd_MuldeR]

Now the resizing code should come from mplayer, so if they didn't fix something their maybe try if the same effect is seen with mplayer when doing lanczos resize.

I've seen that effect in a movie resized/encoded with MEncoder.

Snapshot (http://img65.imageshack.us/img65/8697/snapshot0so.png)

[videomixer9]

Btw. there's way too much //FIXME comments in that code ... seeing it i'd rather resize with something else but swscaler rofl -_-; Well, no obvious errors as expected so I have no clue either about the problem. Well, as stated before, hardware does it faster and well usually.

[haruhiko_yamagata]

btw, speaking about ffdshow resizer.

I asked Milan long time ago, but nothing was done (typical:)). Can you tell me why Lanczos resizing produces noticable horizontal lines on resizing?
I understood the problem.
Btw, please respond to my post (http://forum.doom9.org/showthread.php?p=850987#post850987).

Thanks, LoRd_MuldeR. It's very good for testing.

[Egh]

I understood the problem.
Btw, please respond to my post (http://forum.doom9.org/showthread.php?p=850987#post850987).


No, it doesn't improve anything. I'm at job so I don't have that file atm, SAR was equal to 3/2 iirc.

[haruhiko_yamagata]

Now the resizing code should come from mplayer, so if they didn't fix something their maybe try if the same effect is seen with mplayer when doing lanczos resize.
Yes, it is reproducible with mplayer too. The command line is simple.
mplayer.exe -vf scale=1024:480 filename.mov

You could try to turn of MMXEXT and try to see if it disappears, swscaler got a MMXEXT optimized horizontal scaler routine that is used if available.
When MMXEXT is unchecked, it works. It should be the MMX optimized code, so the debug will be hard.

[sander815]

i am trying to install ffdshow-20060707.exe on my windows 2003 server edition, but get this error: error while registering ffdshow.ax...whats wrong?

[videomixer9]

missing runtime libs as usual, at least for my builds some packs don't include them, forces people to get the redist and skip out of problems with avisynth plugins e.g. :P

[videomixer9]

When MMXEXT is unchecked, it works. It should be the MMX optimized code, so the debug will be hard.

I think it should be posted on the mplayer mailing lists then though to maybe get the original author to fix it, he should have a better overview of what he's done.

[Egh]

I think it should be posted on the mplayer mailing lists then though to maybe get the original author to fix it, he should have a better overview of what he's done.

since the code is from mplayer, that's most reasonable thing to do.

But where's that bugreport list for mplayer and who's going to report it (if not done already, of course)

[LoRd_MuldeR]

But where's that bugreport list for mplayer and who's going to report it (if not done already, of course)

http://www.mplayerhq.hu/design7/info.html#mailing_lists

[haruhiko_yamagata]

When xsharpen + Resize is enabled,
ffdshow.ax(MSVC8 Release build) + libmplayer.dll(MSVC8 Debug build) :
sws_getDefaultFilter cannot receive proper parameter from TimgFilterResize.cpp line 214.

SwsFilter *sws_getDefaultFilter(float lumaGBlur, float chromaGBlur, float lumaSharpen, float chromaSharpen, float chromaHShift, float chromaVShift, int verbose)
All the flot value that sws_getDefaultFilter receive is -1.#IND000.
It seems to be responsible for the green problem.

Is it a bug of MSVC8 ? It may be a bug of ffdshow, but I can't find anything wrong.
Is GCC innocent then?
What can I do about this?

I'm not good at compiler issue, please help me.

[regeszter]

Hi,

I have tested videomixer9 builds but I have not found any multithreading. The 1st CPU core was used about 50% and the 2nd core was used 1-5%. Is this the multithreading in ffdshow or I have missed something configure in my system?

thanks!

[LoRd_MuldeR]

Hi,

I have tested videomixer9 builds but I have not found any multithreading. The 1st CPU core was used about 50% and the 2nd core was used 1-5%. Is this the multithreading in ffdshow or I have missed something configure in my system?

thanks!

I guess you need to test it with something that needs more CPU power. It doesn't even fully load your first CPU, so why use the second one?

[regeszter]

I guess you need to test it with something that needs more CPU power. It doesn't even fully load your first CPU, so why use the second one?

Other multithreading enabled codec balance the cpu load between the 2 cores. I expect about 25%-25% instead of the 50%-5% in my test.

[LoRd_MuldeR]

Other multithreading enabled codec balance the cpu load between the 2 cores. I expect about 25%-25% instead of the 50%-5% in my test.

Well, I don't remember what features of ffdshow can be processed on different threads/CPUs. So you should try to enable some more features like resizing and other filters. Maybe you'll notice some effects of multi-threading then...

[regeszter]

Well, I don't remember what features of ffdshow can be processed on different threads/CPUs. So you should try to enable some more features like resizing and other filters. Maybe you'll notice some effects of multi-threading then...

I use

- levels
- Blur & NL
- Subtitles
- Resize & aspect
- Sharpen

in a divx/xvid file.

[_xxl]

I use

- levels
- Blur & NL
- Subtitles
- Resize & aspect
- Sharpen

in a divx/xvid file.
use a h264 file...1280*720

[regeszter]

use a h264 file...1280*720

Ok, I see, the multithreading support is not fully in ffdshow. Only in some cases like h264.

Thanks!

[foxyshadis]

No, h.264 decoding is not multithreaded at all yet (and it's a huge bottleneck). The entire filter chain itself is what's multithreaded, and resizing gets its own extra threads. It usually ends up a rather lopsided 80%/30% on mine, with AVC, since decoding is all in the main thread.

Try taking your favorite xvid video and resizing to 1280x1024, plus your other filters. See if that brings it up to using both cores.

Also make sure that in misc options "queue output samples" is on.

[regeszter]

No, h.264 decoding is not multithreaded at all yet (and it's a huge bottleneck). The entire filter chain itself is what's multithreaded, and resizing gets its own extra threads. It usually ends up a rather lopsided 80%/30% on mine, with AVC, since decoding is all in the main thread.

Try taking your favorite xvid video and resizing to 1280x1024, plus your other filters. See if that brings it up to using both cores.

Also make sure that in misc options "queue output samples" is on.

source file is a divx6 avi

the queue output samples is ON

This options were used:
- levels
- Blur & NL (denoise3d) <- this use about 30% from total (48%)
- Subtitles
- Resize & aspect 720*576 -> 1024*768
- Sharpen

and here is the result
http://kepfeltoltes.hu/060718/kep1_www.kepfeltoltes.hu_.jpg

without Blur & NL
http://kepfeltoltes.hu/060718/kep2_www.kepfeltoltes.hu_.jpg

I think the denoise3d does not use 2 cores.

[haruhiko_yamagata]

regeszter, read this (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) and you'll know what's multithreaded.

CPU usage is not importantl at all.
The frame rate is most important.

Compare ffdshow older than 20060418 and the newest. With the files that have frame rate more than 20 with old one, you will see improvement. Enable OSD item "Queued samples" and confirm your video renderer support multithreading. WMP, the old renderer and some VMR9 renderer(intel 82865G etc) does not support queue. In this case test MPC + VMR7 or VMR9 renderless.

[foxyshadis]

I think he's right. I'm going to have to find some older versions of ffdshow to test against, but by checking out process explorer it's obvious that one single thread (splitter.ax, oddly, not ffdshow.ax) uses 50% cpu and desync or stuttering starts occuring. Queued samples is 0 almost all the time, even with all filters off; occasionally it jumps to 1 for a single frame. I know for sure that it used to queue better. (And I have an even stronger cpu now!) I have to test whether it's only vm9's builds or not.

MPC (latest), ffdshow build 20060714, sample queuing is on. It occurs at least with all the july builds.

[videomixer9]

Can mplayer and ffmpeg use multithreading on anything else than MPEG1/2 yet? as long as ffmpeg doesn't implement decoder multithreading you won't see much spreaded load on h264 decoding.

[haruhiko_yamagata]

I think he's right. I'm going to have to find some older versions of ffdshow to test against, but by checking out process explorer it's obvious that one single thread (splitter.ax, oddly, not ffdshow.ax) uses 50% cpu and desync or stuttering starts occuring. Queued samples is 0 almost all the time, even with all filters off; occasionally it jumps to 1 for a single frame. I know for sure that it used to queue better. (And I have an even stronger cpu now!) I have to test whether it's only vm9's builds or not.

MPC (latest), ffdshow build 20060714, sample queuing is on. It occurs at least with all the july builds.
What is the video renderer? Some of the VMR9 renderer does not give us buffer soon. In such case, the queue is not effective. Please test other video renderer (VMR9 renderless or VMR7).

Calling video renderer's "Receive" from the thread that is differnt to the one called "GetBuffer" is not documented feature. Some renderer may fail to give us buffer, and ffdshow have to wait and re-try. As far as I know, WMP(DMO wrapper is connected to ffdshow) and VMR9(i82865G) is the case.

As for i82865G, MPC + VMR7 or VMR9 renderless is successfull.
G400 was OK with all the renderer except for the old one.

//EDIT
Of course, when video is too heavy, ffdshow can't queue. The frame rate should be better than 70% with the single thread version.

[foxyshadis]

Can mplayer and ffmpeg use multithreading on anything else than MPEG1/2 yet? as long as ffmpeg doesn't implement decoder multithreading you won't see much spreaded load on h264 decoding.
Well, okay, I'll give you that, but it's 0 no matter how many or how few filters, no matter whether the cpu usage is 5% or 50% or anywhere in between.

haruhiko, normally it's haali's, but it's exactly the same with VMR9 modes. (VMR7 simply doesn't work now, wtf?) It's a X1300 card. Maybe I'll try a different graphics driver, it's possible the latest omega drivers broke something. Weird.

[haruhiko_yamagata]

Can mplayer and ffmpeg use multithreading on anything else than MPEG1/2 yet? as long as ffmpeg doesn't implement decoder multithreading you won't see much spreaded load on h264 decoding.
Multithreading of decoder is very important, of course.
I played the 1080p superman trailer with mplayer. It seems to use multithreading. Updating libavcodec is really worth while(but I don't have time now...).

[videomixer9]

Well I get no queued samples either except if I use Haali Renderer where it occasionally jumps to 1.

[thuan]

Mine Semprom 2200+ XP, with a G4MX4000 91.28 no queue in OverlayMixer with any file, with VMR9 renderless depend on how heavy the files and how many filters I use it goes from 0 to 9 queue sample.

I found one weird things in vm9 latest nosee build, in VMR9 renderless and only renderless mode aac decoding seems to be broken with any types whether it's SBR or not. clsid build works fine, it's maybe ICL fault again.

[haruhiko_yamagata]

I found one weird things in vm9 latest nosee build, in VMR9 renderless and only renderless mode aac decoding seems to be broken with any types whether it's SBR or not. clsid build works fine, it's maybe ICL fault again.
clisd's build doesn't include the queue AFAIK. It may be single CPU/multithreading(thread priority) problem. Does disabling "Queue output samples" improve anything?

[thuan]

No, it doesn't matter whether ffdshow is used as video decoder or not same for queue output sample just as long as there's aac with vmr9 renderless and bang. Internal MPC's aac decoder works fine whether ffdshow video decoder is used or not. I think ICL must be the culprit.

[regeszter]

Here is my another test.

a h264 file, MPC with vmr9 renderless, queue output samples is on

resize is on, NR is off, the move is smooth

http://kepfeltoltes.hu/060719/623361222k_p1_www.kepfeltoltes.hu_.jpg

resize is on, NR is on, the move stutter

http://kepfeltoltes.hu/060719/k_p2_www.kepfeltoltes.hu_.jpg

So there is power in cpu but the move stutter, the multithreading does not work well. :(

[_xxl]

InnoSetup with CPU detection:
http://rapidshare.de/files/26330053/FFdshow-20060716-rev2546.exe.html
libavcodec.dll & libmplayer.dll are GCC 3.4.2

[Kostarum Rex Persia]

Guys, what's going on with 64-bit build of FFDSHOW? I am very nervous about lacking 64-bit support.

Can anyone send me a private message with an idea how to contact Milan, author of FFDSHOW?

[celtic_druid]

Same thing that is going on with 32bit ffdshow... Not much. 64bit build does work though.

Doesn't look like Milan is around or at least isn't spending any time on ffdshow. Which is fine. Once again, all the source is there for you to work on.

[Liisachan]

In case anyone needs the link to celtic_druid's build (64-bit):
http://ffdshow.faireal.net/mirror/ffdshow/ffdshow64-rev2546.exe

[celtic_druid]

How many 64bit Media Players anyway?

[nfm]

Windows Vista x64 Edition features native 64-bit wmp11. New wmp11 for Windows XP Pro x64 Edition and for Windows Server 2003 x64 Editions is supposed to 64-bit. I hope that all codecs will continue to work in 64-bit directshow player? I will have to test newest Vista build and see.

[celtic_druid]

Last time I had a look at the WMP11 download it was 32bit only. So the current Vista beta includes 64bit WMP11?

[haruhiko_yamagata]

OSD item "Video delay"
ffdshow has IQualityControl since rev2411(just after the release of the ffdshow-20051115.exe). When the video is delayed more than 1500ms, ffdshow drops a frame. It improves audio-video sync. H.264 (and perhaps some other codecs) cannot(?) show the next frame untill it gets "sync point". Next sync point may be very far, so sometimes ffdshow cannot show a new frame for seconds.
Resize setting - automatic vertical size setting
Improved? "non-square pixel" support (Bug fix).
As for MPC + MKV, use proper external mkv spliter and disable MPC internal matroska source filter for non-square pixel support.
Avoid multithreading of resize(swscaler) if the CPU is Pentium4-HTIt is not faster at all and use more CPU. (Swscaler depends much on MMX and P4HT have only one MMX unit.)
Use more multithreading of resize(swscaler) if the CPU is dual core or multi-CPU.

Imported changes of swscaler from mplayer/libswscale.
Rewrited multithreading of swscaler to synronize to mplayer/libswscale (doesn't mean it fixes the holizontal line problem).
[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) ffdshow_multithread_060721.patch is PATCH to PATCH.
To rev2546 + ...060517 + ...060601 + ...060604 + ...060625 + ...060709.patch

[haruhiko_yamagata]

This time's patch is trivial for most users.

Btw, the newest original libavcodec's H.264 is not only faster, but also support quality control("skiploopfilter/skipidct/skipframe decoder options for very fast H.264 decoding"), so I would like to use it. Anyway, I would like to update libavcodec.dll but it looks very difficult.

The OSD item "Video delay" explains how ffdshow controls audio-video sync. There's room for improvement.

Could you guide me "How to import changes from ffmpeg"?

[haruhiko_yamagata]

ffdshow-20060722-Q.exe
Needs SSE
http://www.mytempdir.com/818768

libmplayer.dll, libavcodec.dll and libmpeg2.dll are by GCC 4.0.3.
The rest are by MSVC8(VS2005).

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060721.patch
TsampleFormat.patch

[_xxl]

InnoSetup with CPU detection:
MMX, SSE & SSE2.
http://rapidshare.de/files/26603725/FFdshow-20060722-rev2546.exe.html
libavcodec.dll & libmplayer.dll are GCC 4.0.3

[NULUSIOS]

Now waiting for videomix? :D

[LoRd_MuldeR]

When will all those patches be in the SVN ???
We are at r2546 for over 2 month now...

[haruhiko_yamagata]

When will all those patches be in the SVN ???
We are at r2546 for over 2 month now...
I asked milan 2 weeks ago, still waiting for reply...

[Liisachan]

mirrored

ffdshow-20060722-Q.exe (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060722-Q.exe)
12c0100c8cdc1a0698fb4cc709cda7a4

FFdshow-20060722-rev2546.exe (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/FFdshow-20060722-rev2546.exe)
bc0d6679017209bce1054e6d0cba480d

[haruhiko_yamagata]

Liisachan, thank you very much.

[videomixer9]

Btw. oddly as non-admin resizing stopped to work for me at all, whyever that is. However I updated too, found to be here (http://ffdshow.pytalhost.eu/current.php).

Triple play: MSVC 2005 for ffdshow.ax, libmplayer and libavcodec gcc 4.1.1 and the rest ICL 9.1

[haruhiko_yamagata]

oddly as non-admin resizing stopped to work for me at all
What does this mean? Please explain.

Thank you for your build.

[videomixer9]

I fiddled some more and it seems to be only that it only works with output queue enabled, if output queue is disabled it doesn't work, just my admin account had output queue enabled while I had it disabled in my user account. Though I just noticed it doesn't often work with it enabled either.

So short said, as admin user resizing always works, but as regular user it often doesn't no matter which settings. Users that permanently work as admin are imo big time newbs so this issue is kinda annoying to me. Any functions used that need admin rights? It worked without problems before usually.

Tested some more vids and it just randomly occurs.

[Egh]

Imported changes of swscaler from mplayer/libswscale.
Rewrited multithreading of swscaler to synronize to mplayer/libswscale (doesn't mean it fixes the holizontal line problem).


BTW, the dev for swcaler asked for additional info. Remind me the link to that QT file which clearly shows the problem, and also mplayer CLI settings for it to show both cases (i.e. with and without the bug).

[haruhiko_yamagata]

BTW, the dev for swcaler asked for additional info. Remind me the link to that QT file which clearly shows the problem, and also mplayer CLI settings for it to show both cases (i.e. with and without the bug).
Thank you for reporting the problem.

The snapshot was posted by LoRd_MuldeR .
http://forum.doom9.org/showthread.php?p=852128#post852128
Direct link
http://img65.imageshack.us/img65/8697/snapshot0so.png

Command line to show bug
mplayer.exe -vf scale=1024:480 filename.movI don't have sample command line not to show bug.

[haruhiko_yamagata]

I fiddled some more and it seems to be only that it only works with output queue enabled, if output queue is disabled it doesn't work, just my admin account had output queue enabled while I had it disabled in my user account. Though I just noticed it doesn't often work with it enabled either.

So short said, as admin user resizing always works, but as regular user it often doesn't no matter which settings. Users that permanently work as admin are imo big time newbs so this issue is kinda annoying to me. Any functions used that need admin rights? It worked without problems before usually.

Tested some more vids and it just randomly occurs.
Thank you.
I can't reproduce untill now.
It's you, so it's very unlikely but please confirm the access right to the file(libmplayer.dll) and related registry keys. As for registry key, I added "resizeIsDy0" to \GNU\ffdshow\default.

[videomixer9]

Access rights are okay, also I had the registry values wiped. Maybe it's something else. Not that I really care that much. If it's not reproducible it must be sth. with the settings here. Still kind of odd the problem only occurs as user and not as admin. The settings are correctly stored under HKCU and access rights are okay ...

[haruhiko_yamagata]

Egh,
If he can't download QT file, the link below is available (posted by LoRd_MuldeR).
http://jfl1974.free.fr/upload/superman.mp4

Resizing to large size is necessary to see it clearly. For holizontal size 1280 or more is recommended.

[foxyshadis]

Hmm, I thought I had a cause for the lack of queuing but it didn't pan out. Is there any way that a diagnostic build could log information about what succeeds and what fails when attempting to start and use the queue? I guess I could look through it and try to find it myself.

btw, as to ffmpeg (lavc), I tried it the old fashioned way: backup, delete, resync. Only got tons of errors for my trouble. ^^; It's possible gcc would do better if you also used the updated makefiles.

[haruhiko_yamagata]

Hmm, I thought I had a cause for the lack of queuing but it didn't pan out. Is there any way that a diagnostic build could log information about what succeeds and what fails when attempting to start and use the queue? I guess I could look through it and try to find it myself.

btw, as to ffmpeg (lavc), I tried it the old fashioned way: backup, delete, resync. Only got tons of errors for my trouble. ^^; It's possible gcc would do better if you also used the updated makefiles.
The queue is tryed unless the video renderer is the old one, the application is WMP, the dialog is unchecked. If the OSD item "Queued samples" sometimes show 1, the queue is being tryed. One main reason the queue fails is error on GetBuffer. See TffdshowDecVideo::initializeOutputSample/Tffdecoder.cpp. It has DPRINTF(_l("GetDeliveryBuffer returned %x"),hr); after GetDeliveryBuffer. If you can use MSVC's debugger, you'll see the error code. Typically 0x80040223 if your video renderer does not support this special multithread feature.
GetBuffer and Receive may be supposed to be called from the same thread synchronously. It is not writtern in document (may or may not). So we might be better to consider it as bonus. If it have been working on your system with the same video card, there's room for work around though.

[NULUSIOS]

...

are you sure your links work?
have a hard time connecting

[videomixer9]

duh lame hosters always dying:

http://www.mooload.com/new/file.php?file=files/220706/1153566369/ffdshow-20060722-rev2546.exe
http://www.mytempdir.com/819217
http://s16.simpleupload.de/febe8be78/ffdshow-20060722-rev2546.exe.html
http://ultrashare.net/hosting/fl/73229f29f3/
http://rapidshare.de/files/26609917/ffdshow-20060722-rev2546.exe.html
http://files.to/get/142940/16908/ffdshow-20060722-rev2546.exe

oh well, not much you can expect from drunken linux kiddies trying to run a hosting service and also for free. Can be only hours till some of those drunkards notice.

[NULUSIOS]

np dude :)

[videomixer9]

okay updated to other host, again but this time with direct downloads too.

[foxyshadis]

[5552] Receive Returned 0
[5552] GetDeliveryBuffer returned 0
[5552] COutputQueue queued a sample
[5552] CTransformInputPin::Receive 5688
[5552] CTransformInputPin::Receive 5780
[5552] CTransformInputPin::Receive 5780

Odd, it seems to be working fine. Resize multithreading works fine, loading both cores when I turn it way up, but no matter what I do everything else seems to be processed within a single thread. The first core is always around 5% while the second is near 100%. This is going to drive me mad until I figure it out. Oh well, I'll see whether I can find out why on my own.

[haruhiko_yamagata]

Odd, it seems to be working fine. Resize multithreading works fine, loading both cores when I turn it way up, but no matter what I do everything else seems to be processed within a single thread. The first core is always around 5% while the second is near 100%. This is going to drive me mad until I figure it out. Oh well, I'll see whether I can find out why on my own.
To see the first core is nealy 100%, the movie may be just too heavy. But probably you mean smaller size picture doesn't queue too...
The second core's CPU usage may be small just because your video renderer is too fast.

[haruhiko_yamagata]

The picture attached shows a case queue is effective.
In this case, CPU usage of second core is very low, but it drops no frame. When queue is off, there are some frame drops.

[foxyshadis]

Ah, I think it came down to using your builds instead of vm9's; with his I get full utilization of both cores and can watch much larger video (or add more filters) before it starts to lag. I'm glad it was something like that, I take it gcc's multithreading just isn't that hot.

[_xxl]

haruhiko_yamagata:
Minimum CPU requirement: SSE
libmplayer.dll, libavcodec.dll and libmpeg2.dll are by GCC 4.0.3.
The rest are by MSVC8(VS2005).
http://www.mytempdir.com/818768
http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/ffdshow-20060722-Q.exe

videomixer9:
Minimum CPU requirement: SSE
http://ffdshow.da.cx/
http://www.mooload.com/new/file.php?file=files/220706/1153566369/ffdshow-20060722-rev2546.exe
http://www.mytempdir.com/819217
http://s16.simpleupload.de/febe8be78/ffdshow-20060722-rev2546.exe.html
http://ultrashare.net/hosting/fl/73229f29f3/
http://rapidshare.de/files/26609917/ffdshow-20060722-rev2546.exe.html
http://files.to/get/142940/16908/ffdshow-20060722-rev2546.exe

clsid:
Minimum CPU requirement: MMX
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, kerneldeint.dll, TomsMoComp_ff.dll)
- GCC 4.0.3 (mplayer.dll)
rev2543:
http://rapidshare.de/files/26625385/ffdshow_rev2543_20060722.exe.html
rev2546:
http://rapidshare.de/files/26625534/ffdshow_rev2546_20060722.exe.html

XXL:
Minimum CPU requirement: MMX
InnoSetup with CPU detection:
MMX, SSE & SSE2.
libavcodec.dll & libmplayer.dll are GCC 4.0.3 (mmx, sse & sse2)
http://rapidshare.de/files/26603725/FFdshow-20060722-rev2546.exe.html
http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/FFdshow-20060722-rev2546.exe

[videomixer9]

use services like xs.to, imageshack or others for pictures, attachments take ages to get approved here. As to multithreading it is sad that ICLs /Qparallel switch makes things crash on several systems.

[clsid]

I have made a special test build of ffdshow containing 13 different versions of libavcodec.dll. One of these can (if supported by your cpu) be selected during installation. The rest of the components are taken from my latest rev2546 build.

This build is for testing the pure decoding speed of libavcodec when using certain optimization switches and GCC versions. Testing other stuff, like filters, is pointless since that isn't done by libavcodec.

The following libavcodec.dll builds are included:
* GCC 3.4.5 [default makefile]
* GCC 4.0.3 [default makefile]
* GCC 4.1.1 [default makefile]
* GCC 3.4.5 [-march=i686 -mtune=i686 -mmmx] (MMX)
* GCC 3.4.5 [-march=i686 -mtune=i686 -mmmx -msse -mfpmath=sse] (SSE)
* GCC 3.4.5 [-march=i686 -mtune=i686 -mmmx -msse -msse2 -mfpmath=sse] (SSE2)
* GCC 3.4.5 [-march=athlon -mtune=athlon]
* GCC 3.4.5 [-march=athlon-xp -mtune=athlon-xp -mfpmath=sse]
* GCC 3.4.5 [-march=k8 -mtune=k8 -mfpmath=sse] (AMD Athlon 64)
* GCC 3.4.5 [-march=pentium3 -mtune=pentium3 -mfpmath=sse]
* GCC 3.4.5 [-march=pentium4 -mtune=pentium4 -mfpmath=sse]
* GCC 3.4.5 [-march=pentium-m -mtune=pentium-m -mfpmath=sse]
* GCC 3.4.5 [-march=prescott -mtune=prescott -mfpmath=sse] (New P4 models)

download (http://www.mytempdir.com/821659)

Some results I got when testing an H.264 file on an AMD Athlon:
* GCC 3.4.5 is the fastest for a plain build. Closely followed by GCC 4.0.3. GCC 4.1.1 is the slowest.
* MMX build is fastest, Athlon build comes in second.

[videomixer9]

try to make -O3 into -O2 and just add any default parameters -O3 enables except for loop unswitching, note GCC 3.x and 4.x those are different :P Other than that it seems to be in favor of what I always stated, ffdshow libavcodec is runtime cpu detection enabled by default thus almost all other optimizations are not making much of a difference.

[iron2000]

XXL:
Minimum CPU requirement: MMX
InnoSetup with CPU detection:
MMX, SSE & SSE2.
libavcodec.dll & libmplayer.dll are GCC 4.0.3 (mmx, sse & sse2)
http://rapidshare.de/files/26603725/FFdshow-20060722-rev2546.exe.html
http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/FFdshow-20060722-rev2546.exe

I'm using this build now.
I experienced a DirectShow crash while trying to watch a video([gg]_Coyote_Ragtime_Show_03_[A3AEEC9E].mkv).

On using GSpot the crash is credited to libavcodec.
Does it mean the ffdshow is faulty?

[thuan]

Try clsid build his is the most stable IMHO, no crash here with that file.

Maybe because drevel use ICL (ffdshow.ax compiled by ICL crash with specific x264 encode)

clsid:
Minimum CPU requirement: MMX
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, kerneldeint.dll, TomsMoComp_ff.dll)
- GCC 4.0.3 (mplayer.dll)
rev2543:
http://rapidshare.de/files/26625385/...60722.exe.html
rev2546:
http://rapidshare.de/files/26625534/...60722.exe.html

[Egh]

Wow, it seems that horizontal lines bug was corrected :) Indeed it was vertical mmx scaler :)

New mplayer has slower but moar accurate "-vf scale=...:arnd=1" scaling method. Will it be possible to import it into ffdshow?

Interesting to note that lines were causes by +/- 1 rounding errors :O

[videomixer9]

Bleh, that's handcrafting as milan has quite many changes in the code. Wonder if I'll find time to do that especially considering I never use the resizer and also haruhiko wildly changed stuff :P

[haruhiko_yamagata]

Wow, it seems that horizontal lines bug was corrected :) Indeed it was vertical mmx scaler :)

New mplayer has slower but moar accurate "-vf scale=...:arnd=1" scaling method. Will it be possible to import it into ffdshow?

Interesting to note that lines were causes by +/- 1 rounding errors :O
Thank you very much, Michael Niedermayer.

The newest patch looks like modifing MMX code of swscaler, but in fact no. I just undid all my MMX modifications and updated to Michael's newest. So it should be easy to import:) .

[Chainmax]

Since my computer now refuses to run some of the WMVs I have (it only displays pink, green and blue colors), I decided to completely update the codecs in my machine. Could someone summarize for me the different builds available and their strengths?

[thuan]

ffdshow is the farthest thing from wmv decoding if you don't enable ffdshow wmv decoding (the wmv1/2 decoder have no problem IIRC). Have you updated driver recently, do you use ATI card (the infamous hardware accelerated WMV decoding)? If so maybe it's the problem here (http://www.cccp-project.net/wiki/index.php?title=Issues:WMV_Playback_Problems).
About which ffdshow is best for you, you should test it out for yourself. drevel sum it up pretty well here (http://forum.doom9.org/showthread.php?p=854832#post854832) just missing the newest nosee build from vm9 which is here (http://ffdshow.da.cx/). Personally I use clsid's build it's the most stable IMHO. Also judging from the size of drevel build I think he uses ICL (haven't tried it) because of that it will crash with certain encode with specific x264 revision as someone reported a few posts back.

[Chainmax]

I did update drivers recently, having upgraded from a Radeon 7200 to a 9600Pro. The suggestion in that CCCP wiki page you linked me to solved tthe issue, so thanks for the heads-up :). What's weird is that the update was a couple of weeks ago and I only started experiencing this problem today.

As for the ffdshow question, I like stability more than anything so I'll go with clsid's compile. Thanks for clearing that up as well http://smilies.vidahost.com/otn/wink/thumb.gif.

[_xxl]

I'm using this build now.
I experienced a DirectShow crash while trying to watch a video([gg]_Coyote_Ragtime_Show_03_[A3AEEC9E].mkv).

On using GSpot the crash is credited to libavcodec.
Does it mean the ffdshow is faulty?

What version of libavcodec.dll (mmx,sse,sse2),media player, mkv splitter are you using?Haali Media Splitter?

[foxyshadis]

Okay, I got lavc to update, it wasn't so hard. I just copied the whole i386 folder over, and then the files for all the codecs that I figured I might want - anything related to h26*, xvid, x264, mpeg, svq*, indeo, etc, along with whatever support files I needed. A couple that will cause the build to fail if updated are:
avcodec.h, golomb.c, golomb.h
I'll look into merging them and porting everything over; if successful I'll make a patch. Just copy a few at a time and recompile until the builds fail! Too bad AVC decoding doesn't seem to have any performance increases yet (no multithreading ;_; ).

I won't even try replacing ffdshow's buggy wmv9 with lavc's new vc-1 decoder, though. Someone more versed in ffdshow would have to tackle that.

[videomixer9]

The revision MBAFF was added there was even a funny remark about regular h264 becoming 1-2% slower due to it.

[_xxl]

Try clsid build his is the most stable IMHO, no crash here with that file.

Maybe because drevel use ICL (ffdshow.ax compiled by ICL crash with specific x264 encode)

ffdshow.ax is compiled by MSVC2003,
libavcodec.dll & libmplayer.dll are GCC 4.0.3 (mmx,sse,sse2)
and the rest are by ICL9.

[foxyshadis]

Hey, vm9, I'm curious. In my VC8 builds, it seems lavc is compiled right into ffdshow.ax, I think, whereas in yours and most others it's separate somehow, and almost twice the size when added to ffdshow.ax. (And testing proved it wasn't extraneous.) Is it something to do with using GCC/ICL? Or am I doing something wrong? It seems to work correctly...

[videomixer9]

libavcodec incl. into the .ax file? heh. I'm pretty sure that wouldn't work as it's loaded by Tdll class. I bet you just mixed up some stuff and have the dll in a directory and can be found. There are no real direct references either in the code so statically linking wouldn't really work either. Other than that you prolly use the Debug Config that outputs larger code :P

[foxyshadis]

Oh, I see, it was picking up libavcodec in the old ffdshow install folder. Geez, it's not in the path or anything, that's totally unexpected. I guess I was wrong about it then, back to the drawing board. I hate building monstrocities like this. >.>

[haruhiko_yamagata]

Okay, I got lavc to update, it wasn't so hard. I just copied the whole i386 folder over, and then the files for all the codecs that I figured I might want - anything related to h26*, xvid, x264, mpeg, svq*, indeo, etc, along with whatever support files I needed. A couple that will cause the build to fail if updated are:
avcodec.h, golomb.c, golomb.h
I'll look into merging them and porting everything over; if successful I'll make a patch. Just copy a few at a time and recompile until the builds fail!
Oh yes, it's a good news.
Too bad AVC decoding doesn't seem to have any performance increases yet (no multithreading ;_; ).
I was wrong about it. There's no multithreading. Mplayer have multithreading to play AVC file, but it seems not to be the decoder.

[iron2000]

What version of libavcodec.dll (mmx,sse,sse2),media player, mkv splitter are you using?Haali Media Splitter?

Here are the details:

libavcodec.dll(mmx,sse,sse2) : 51.9.0
media player : BSplayer 1.37 and MPC 6.4.9.0
mkv splitter : Haali Media Splitter 1.6.162.22

[videomixer9]

Wow, kurosu even added the new WMV3/VC-1 decoder to his builds, well it's not that great yet and mostly interesting for ffmpeg rather than ffdshow as it is interesting to not depend on the MS dlls on other platforms.

Whatever, sadly kurosu refused to send me any patches to changes he made so I guess I have to wait to get these changes merged into the real one.

In his mail he was rather pissed and I'd recommend not to bother him about anything like that, probably he's kind of annoyed by milans sleepiness :P

[akapuma]

Audio-normalizing don't works with kurosu's build 20060727-00H07 at my PC. Same problem like 7th July 2006, I posted this here.

Best regards

akapuma

[Egh]

Wow, kurosu even added the new WMV3/VC-1 decoder to his builds, well it's not that great yet and mostly interesting for ffmpeg rather than ffdshow as it is interesting to not depend on the MS dlls on other platforms.


Is it possible to add this new decoder in another builds?

[videomixer9]

I'm not really eager to do it and imo that's wasted time currently too as it is slower than the MS codec too. I got like zero WMV3 except for useless trailers. It seems WMV3 is popular with japanese only, some friend has a tons of japanese tv stuff as wmv3 in total oversize. Prolly it's not hard to do, but I don't see a point in it currently.

More interesting would be a some other codecs ... kurosu wouldn't give out the a patch to it after my impression, even though it kind of violates GPL :P

Also since people asked this often enough, here a package of the current sourcetree I'm using incl. the ICL projects etc. here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow.7z)

[Egh]

BTW, what Debanding filter ffdshow uses?

Is that filter available as a standalone avs plugin?

[foxyshadis]

(the somewhat buggy) gradfun2db.

[haruhiko_yamagata]

Quality control
(1)Which do you give preference to image quality or frame rate?
(2)Which do you choose droping frame or to losing synchronization of audio and video?

as for (1), it is supported only in H.264. By default, it is set to skip loop filter/deblocking on delay > 350ms. When the video catches up audio, the quality is back. Though the quality drops, I think it's better than no new frame for seconds.
as for (2), on delay > 1500ms, ffdshow give up decoding for a while. If the file is H.264, you may have no new frame for seconds.

Both (1) and (2) have configuration at "decoder options/quality control" in the dialog.
Resize
Update to libswscale rev 19211. It fixed the holizontal line problem. It may be slower and if it is matter for you, uncheck "Resize & aspect/Settings/Accurate rounding".

An old bug fix: While playing resized HD movie, when one try to enter new holizontal size the the application sometimes crashes. I set minimum holizontal size 64 instead of 8 to fix this.
[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) ffdshow_multithread_060730.patch is PATCH to PATCH.
To rev2546 + ...060517 + ...060601 + ...060604 + ...060625 + ...060709 + ...060721.patch

[haruhiko_yamagata]

ffdshow-20060730-Q.exe
Needs SSE
http://www.mytempdir.com/833254

libmplayer.dll, libavcodec.dll and libmpeg2.dll are by GCC 4.0.3.
The rest are by MSVC8(VS2005).

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060730.patch
TsampleFormat.patch

[Liisachan]

to save some clicks
ffdshow-20060730-Q.exe (http://space34.at.infoseek.co.jp/ffdshow-20060730-Q.exe)
lazy is beautiful

[videomixer9]

btw. that patch is bollox, it contains full pathes. Had to fix it up to get it applied.

[haruhiko_yamagata]

btw. that patch is bollox, it contains full pathes. Had to fix it up to get it applied.
Excuse me. I replaced the patch.

[videomixer9]

So my version is done too, as always on the website or directly here (http://www-users.rwth-aachen.de/jens.daumann/ffdshow-20060730-rev2546.exe) (hotlinking from random locations allowed). Almost exactly one week after the last one? :P

[haruhiko_yamagata]

It's just my working copy.
My local SVN rev 33.
size= 13.1MB

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060730.patch
TsampleFormat.patch
http://www.mytempdir.com/833815

[videomixer9]

Btw. does anyone have MBAFF h264 video material, just wanna test if my patching worked?

[MatMaul]

http://www.giusberto.ch/hdtv/

[videomixer9]

thx, I could confirm with this that MBAFF works, however Haali TS Splitter may crash on this so when trying use Gabest one or others. I updated my build silently with a new libavcodec that supports MBAFF.

MBAFF patch: here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow_mbaff.patch)
all patches used: here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow_patches.7z)

I also tried adding VC-1 support as inserting other codecs shouldn't be hard but the vc-1 files threw an error like these:
libavcodec/vc1acdata.h:7: error: expected '=', ',', ';', 'asm' or '__attribute_' before 'vc1_ac_tables'
libavcodec/vc1acdata.h:233: error: expected '=', ',', ';', 'asm' or '__attribut__' before 'vc1_index_decode_table'
libavcodec/vc1acdata.h:402: error: expected '=', ',', ';', 'asm' or '__attribut__' before 'vc1_delta_level_table'

but to me the tables looked fine so I'm stuck.

[Egh]

thx, I could confirm with this that MBAFF works, however Haali TS Splitter may crash on this so when trying use Gabest one or others. I updated my build silently with a new libavcodec that supports MBAFF.


Dunno but that file (bbc HD test) works fine here both with mpc internal TS splitter and with Haali. No crashes.

[foxyshadis]

vm9, ICL has issues with uint8_t (and 16/32), it isn't defined by default so it thinks that's the symbol you're trying to define. Including common.h should fix it but apparently doesn't in this case, maybe you could include <inttypes.h> at the top of the header.

I understand why lavc was so rarely updated after spending the last week on it, it's a real pain to keep it gcc & mcvc compatible, especially when common headers are shuffled significantly, and if you don't have something encoded by each codec to test against.

[conando]

@videomixer.. thx so much for the regular builds and all the work.. but: makeavis.exe seems to be broken in your builds.. crashes immediately...

[LoRd_MuldeR]

@videomixer.. thx so much for the regular builds and all the work.. but: makeavis.exe seems to be broken in your builds.. crashes immediately...

I can reproduce this error:

http://img153.imageshack.us/img153/1948/makeavisyc8.th.gif (http://img153.imageshack.us/my.php?image=makeavisyc8.gif)


And yes, I have installed the vcredist_x86.exe :D

[foxyshadis]

Question for you guys as I'm finishing up the lavc reimport patch: To include various random formats use in video game movies, or no? This includes: mdec, mmvideo, roqvideo, rpza, vqavideo, xan, xl, along with other random stuff like 4xm and rtjpeg. None of them are remotely difficult to port, but nor is there a very compelling reason to keep them. (Most are in proprietary containers that only lavf can read anyway.)

Man, I wish I hadn't wasted time on chasing down one nasty h264 bug caused by not commenting one merged line out. ^^;; Ah well.

After this I'll fixup ffdshow to use the new vc-1 and avs decoders, and release a patch for that separately.

This reminds me of something else, later down the line I'll see if I can get msvc to cleanly link with gcc object files, so gcc can do the at&t asm while either of the others does the former, as an attemp to obtain maximum optimization. (I can dream, non?) It'll probably just take some reconfiguring of the projects.

[conando]

btw how is it currently compiled to get "best" performance? i just started looking into the ffdshow sources and yesterday did my first build to do the vfw preset fix thing... at the moment i'm building everything using vc2003... on playback with some filter if gut 34% cpu usage whereas a build by videomixer9 shows 6% :D .. after compiling libavcodec, libmplayer etc. with mingw i'm down to 12%.. fine but still double of what the other builds use.. i looked at the build options but seem to miss the magic speedup setting or something :(

[conando]

ok forget it.. silly me used different filter settings/presets ;) the difference is just 1-2% and i can live with that right now... but seems there's a better way to build libavcodec, libmplayer than just using mingw with the supplied makefiles.. guess i've got to tune that.. didn't find the msvc solution/project file anywhere thats mentioned in the docs that should use an icl/gcc combination for libavcodec..

[haruhiko_yamagata]

btw how is it currently compiled to get "best" performance? i just started looking into the ffdshow sources and yesterday did my first build to do the vfw preset fix thing... at the moment i'm building everything using vc2003... on playback with some filter if gut 34% cpu usage whereas a build by videomixer9 shows 6% :D .. after compiling libavcodec, libmplayer etc. with mingw i'm down to 12%.. fine but still double of what the other builds use.. i looked at the build options but seem to miss the magic speedup setting or something :(
As for VS2003, you need professinal edition or better to optimize. Standard edition doesn't support optimize. It makes large difference.

[haruhiko_yamagata]

// EDIT after writing this I saw your second post...

[Egh]

@ haruhiko_yamagata:

I've noticed a interesting thing in the newest builds on this system. It's always reproducible here.

If "queue samples" is on, then if I pause a video, I see a black screen (instead of a still frame). If I switch off queuing, then all is as it should be. So, the question is: is it bug or feature? :)

It happens even if ffdshow is only used as a passthru, not doing any actual decoding (like receiving data from WMV decoder DMO)

[Liisachan]

I think you are talking about this (http://forum.doom9.org/showthread.php?p=837296#post837296)?


If "Queue output samples" is unchecked, you'll get a static picture (video frame) when you pause the video (which is normal).

If "Queue output samples" is ticked, you'll get nothing (blackness) when the video is paused, which is not too nice. If so, you can read the following discussion first, to make the report more specific.

[Egh]

I think you are talking about this (http://forum.doom9.org/showthread.php?p=837296#post837296)?

If so, you can read the following discussion first, to make the report more specific.

Well I recall there was such problem reported earlier, and I thought it was fixed and this bug is actually a regression.

Maybe then it wasn't fixed at all :)

Sometimes you can actually see all is paused OK, still frame is shown and after that frame becomes blank :)

[videomixer9]

I got a fork project on SourceForge approved and already added some of the people here for access to it and SVN repository to commit changes. I think this is a good base for all the changes proposed by various people and I can add more developers flexibly without making any harm to the original project and everyone can check out things incl. the patches. Also people can upload their builds there which could end all this hosting on dozens of freehosters that are full of ads and waiting delays.

Also the development on the patches by many people might be more transparent and you can easily created patches via the webinterface to propose them as changes to the original ffdshow.

Project:
https://sourceforge.net/projects/ffdshow-tryout/

if someone wants access to commit changes on svn just ask me or the other admins I just added without telling them ;P

[MatMaul]

Thanks videomixer9 !

I don't know if it is possible, but I think a good improvement is to update ffdshow to can use directly the dlls produced by the ffmpeg project.

[videomixer9]

I think that is just a thing of modifying the entry points in the dlls from ffmpeg. I wondered about this for a while, maybe it's time again to seriously try it. Question is if that really works so easily as the question is which additional parts of the 3 dlls ffdshow really needs. But the original reason for stripping down was probably cause the original dlls are significantly larger than the ffdshow version.

As said everyone with some sense is welcome to participate in the fork.

[MatMaul]

at this time, I have still some problems to compile the ffmpeg dlls.
this dlls do not compile with a "configure make", some hacks are needed.
I think the size of the dll is not a problem : users generally download codecs packs and the size of codecs packs generally exceeds 20 or 30 mo...

EDIT : I can now compile ffmpeg dlls !

Tuto to build ffmpeg dlls :

read this tuto (particulary the parts "Fixing "msys.bat"" and "Building FFmpeg SVN dlls" if you have mingw installed) : http://ml20rc.msnfanatic.com/ffmpeg/msysguide.html

use gcc 3.4.5, gcc 4.0.3 doesn't work

./configure --enable-memalign-hack --enable-shared --disable-static

then open the file config.mak, and add "-Wl,-rpath-link,$(BUILD_ROOT)/libavutil -Wl,--output-def,$(@:.dll=.def)" at the end of the LDFLAGS line.

then make

[videomixer9]

Compiling the dlls never was a problem for me, you just always get a version number added at the end. I added MBAFF support to the tryout svn and also the newest vorbis changes from today.

[_xxl]

InnoSetup with CPU detection:
http://rapidshare.de/files/28031171/FFdshow-20060803-rev2546.exe.html
ffdshow.ax is compiled by MSVC2003,
libavcodec.dll & libmplayer.dll are GCC 3.4.2 (4.0.3)
and the rest are by ICL9.
Minimum CPU requirement: MMX
http://rapidshare.de/files/28031890/ffdshow-20060803-rev2546-MMX.exe.html
Minimum CPU requirement: SSE
http://rapidshare.de/files/28032215/ffdshow-20060803-rev2546-SSE.exe.html
Minimum CPU requirement: SSE2
http://rapidshare.de/files/28032468/ffdshow-20060803-rev2546-SSE2.exe.html
patches used:
aspect.diff,vorbis6ch.patch,inttypes.diff,accuracy.diff,dts.patch,tsampleformat.patch,
faad2.patch,mbaff.patch,ffdshow_multithread_060730.patch

[videomixer9]

and for the ones with rapidshare phobia here:
http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-20060803-rev2546.exe?download

[foxyshadis]

Why do you need memalign (which is deprcated anyway) with gcc 3.4.5? It has _aligned_malloc. Oh, right, the vanilla lavc doesn't use _aligned_malloc for some reason, probably to work on some ancient unixes.

The reason vanilla lavc dlls can't be used is that the ffdshow versions are modified to hook into parts of ffdshow, and parts of ffdshow to hook into its structures and registrations. If you can keep just the header files in sync, that might be enough, but I'm not sure. To be honest though, keeping the header files cross-compilable while updating them was significantly more difficult than updating the individual codecs, which is minor drudgery at worst once you figure out the differences between the compilers, and the tweaks Milan made to some codecs. (h264 will definitely not work without removing a lot of code from decode_frame, because ffdshow itself does some of it first, to facilitate speedups.) If you're more experienced than me it might go a lot faster though.

However, it's at least worth looking into, there might be surprising results that could save a lot of time down the road.

It's too bad ffmpeg guys would never consider keeping MSVC compatible sections in their headers. ^^;;

I suppose I should put up or shut up now that VM9 has a source I can much more easily patch against. The only thing pertinent that isn't included is vorbis updates; it's an interesting case because ffdshow's has a much more robust tag-reading functionality. I'll get on that.

The patch that ate Miami. (http://foxyshadis.slightydark.com/random/ffdshow-lavc_merge-xboxhueg.zip)

Edit: If VM9 already updated vorbis I'll just remove it from mine. Ugh, I hope it works, parts of the patch seem to have messed up line feeds, but maybe it's just editplus's fault.

Remember to compile with ALLOW_INTERLACE (that should really be CONFIG_H264_ALLOW_INTERLACE, oh well) if you want to test MBAFF.

[videomixer9]

You can directly commit to the SVN yourself, you got access rights to the tryouts svn. Feel free to commit any changes you make (to login use your regular sf.net account). I also had h264 mbaff merged to ffmpeg (my latest build can play mbaff h264 video), dunno if it's all complete but it mostly worked fine. I was trying to implement CAVS and VC1 but i'm still searching where milan hid all the CODEC_ID (ffcodecs.h) thingies and if allcodec.h is his replacement for allcodecs.c O_O If you already figured it out it may be better you commit those changes though as I'm not really far. I randomly had to remove functions called via DSPContexts that as I didn't see a real reason to merge those changes and it also would be more complex that way. It's preferable to remove the defines set by original ffmpeg authors that e.g. only compile codecs when specified explicitly.

If the patches only work against unpatched other version feel free to overwrite them if neccessary to get them updated.

To generate the updates I usually use the webinterface for the ffmpeg svn and select interesting changes and then let it generate patches for the file affected and apply them with patch -l to the source files. It randomly fails and needs hand editing.

Commit changes should be done in as small batches as possible as it's easier to revert in case of mistake usually. Also it's possible to just easily revert to earlier versions.

[MatMaul]

VC1 support here (https://sourceforge.net/tracker/index.php?func=detail&aid=1534044&group_id=173941&atid=867362)
works with some wmv3 videos, I don't have vc1 samples.

[LoRd_MuldeR]

VC1 support here (https://sourceforge.net/tracker/index.php?func=detail&aid=1534044&group_id=173941&atid=867362)
works with some wmv3 videos, I don't have vc1 samples.

Any builds with VC-1 support yet?

[videomixer9]

kurosu added it a while before, I merged the patch to the ffdshow-tryout svn and started rebuild things. Nice work @ MatMaul.

[BeNooL]

careful with drevil_xxl autodetect builds, it deleted all my FFDShow config... uguu <_<

[videomixer9]

new build with VC-1 support:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev24-20060803.exe?download

changelog:
http://svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log

[_xxl]

http://www.microsoft.com/windows/windowsmedia/musicandvideo/hdvideo/contentshowcase.aspx
http://www.alanwake.com/movies.html
http://download.remedygames.com/movies/alanwake_720p60_51_15mbps.wmv

[LoRd_MuldeR]

I just tried a WMV9 AVI files and MPC still uses the Windows Media DMO filter for decoding :scared:

VC-1 and WMV9 support is enabled in ffdshow and ffdshow has highest priority of all filters...

[videomixer9]

many of those use trailer use DRM for some reason :P I tried some wmv3 avis too but I didn't get anything to be decoded by ffdshow so far either, though 4CC etc. seems added properly and it's enabled. Real WMVs work fine though.

[LoRd_MuldeR]

many of those use trailer use DRM for some reason :P I tried some wmv3 avis too but I didn't get anything to be decoded by ffdshow so far either, though 4CC etc. seems added properly and it's enabled. Real WMVs work fine though.

I made this WMV9-AVI myself with the WMV9 VCM codec (VirtualDub).
But I cannot get ffdshow to decode it though.

The HD WMV trailers by M$ are decoded by ffdshow, but MPC crashes immediately :(


// EDIT

Screenmshot:
http://img244.imageshack.us/img244/6896/reef2az3.jpg

[videomixer9]

pft 1080, i bet it was so overloaded with it that it gave up, that decoder is still awesome slow. Or maybe you use ffdshow wma and that part crashes :P

[NULUSIOS]

...ok stupid question coming up...

...will we get H264 "coreavc" quality any time?
Or is their code THAT special?

Also is DXVA used by any part of ffdshow?

(ok two stupid questions)

[LoRd_MuldeR]

pft 1080, i bet it was so overloaded with it that it gave up, that decoder is still awesome slow. Or maybe you use ffdshow wma and that part crashes :P

MPlayer plays that file 100% fine :rolleyes:
But I'll try the 720 version now ...


//EDIT

Hmm, the 720 version doesn't crash, but performance is really bad and there are artifacts.

[videomixer9]

DMO from Microsoft has an inbuilt postprocessor, I doubt the ffmpeg implementation really has it too.

[foxyshadis]

Not in the near future, although pengvado's always working on it.

The reason I didn't commit it was that I wanted someone else to test codecs I couldn't, but I guess we can always back out the changes in the future if necessary. Now I guess I can't update, conflicts all over between ours. ^^;; Oh well, I'll clear out and try again.

VC1 probably doesn't work because ffdshow isn't set up to use it yet, it still wants to use wmv9 decoder, and fails over to MS when that isn't found.

[_xxl]

careful with drevil_xxl autodetect builds, it deleted all my FFDShow config... uguu <_<
Please backup ffdshow config!

[Tzim]

I'm trying to write a .net media player for people who don't care about what's behind the scene, so I'd like to give my users a unified experience whatever the underliing codec is, especially for audio and subtitle selection.
I'd like to access exposed COM function to directly select audio stream and subtitles without having to use the old IAMSelectStream (where you can find everything, from settings to streams and subtitles).
But in order to do the COM interrop and access ffdshow interfaces, I need the IDL or typelibs (tlbs) of ffdshow, which aren't provided. Are theses discarded by the builders (as they aren't needed for ffdshow to work), or not build at all ?
If some builder can help me with this matter ?

While I'm there : I tested celtic's ffdshow-x64 build (the good thing about .net is that you can choose whether you want it run on x86 or x64), but if xvid decoding works, many filters (like OSD, resizing, postprocessing) doesn't yet. Is there more recent x64 build I could try ?

Thanks in advance (and sorry for my approximative english).

[MatMaul]

MPlayer plays that file 100% fine :rolleyes:
But I'll try the 720 version now ...


//EDIT

Hmm, the 720 version doesn't crash, but performance is really bad and there are artifacts.

don't use mpc, it doesn't like wmv file (I don't now why).
try with zplayer (works good for me).

[MatMaul]

many of those use trailer use DRM for some reason :P I tried some wmv3 avis too but I didn't get anything to be decoded by ffdshow so far either, though 4CC etc. seems added properly and it's enabled. Real WMVs work fine though.

Do you know other 4CC for wmv3 and vc-1 videos (except WMV3 and WVC1) ?

[LoRd_MuldeR]

Do you know other 4CC for wmv3 and vc-1 videos (except WMV3 and WVC1) ?

The 4CC of my WMV9-AVI is "WMV3", but ffdshow doesn't want to decode it ...

[MatMaul]

The 4CC of my WMV9-AVI is "WMV3", but ffdshow doesn't want to decode it ...

Can I have a avi sample please ?

[videomixer9]

Btw. I'm going on a trip for an uncertain time since it's still lecture free time and I got no exams left so don't wonder nothing will get updated for a while. Not that people wonder like last time where even the website went down :P

[LoRd_MuldeR]

Can I have a avi sample please ?

Do you have some FTP space for me to upload?
I cannot use Rapidshare and alike here, because the router here doesn't like HTTP uploads (always results in time-out error)

[MatMaul]

see your mp

[Peuj]

Hi,

I've read in the "Changes in FFDShow MPEG-4 Video Decoder rev. 2546" from http://www.free-codecs.com

- another quicktime format: twos
Can somebody tell how to enable it or if it's enabled by default ?

Thanks

[foxyshadis]

MatMaul: WMVA. Fat chance of that ever being supported though.

I can't get ffdshow to decode with any of its decoders even with all 4 enabled, only WMVideo DMO & ffdshow hooking the raw video. *shrug* I'll see if I can pinpoint the point of failure.

[haruhiko_yamagata]

Kurosu replyed to me and send a important part of his work.
Volume normalization bug fix.
I commited it to ffdshow-tryout.

[haruhiko_yamagata]

Better management of buffers of the queue.
It starts up faster. Prior version took 8 seconds to start playing 1080p file on my PC, now only 3 seconds.

It used to keep 10 buffers for the queue even if "Queue output samples" is unchecked. This time it is fixed. Two for multi-CPU system, one for single-CPU system, if "Queue output samples" is unchecked. "Two for multi-CPU system" to support on the fly enable of the queue.

[MatMaul]

MatMaul: WMVA. Fat chance of that ever being supported though.

I can't get ffdshow to decode with any of its decoders even with all 4 enabled, only WMVideo DMO & ffdshow hooking the raw video. *shrug* I'll see if I can pinpoint the point of failure.

hum, this problem do not occur with .wmv file.
kurosu build's with VC-1 support have the same problem.
Graphedit doesn't want to link the output of avi splitter (4CC : WMV3) with ffdshow BUT the 4CC WMV3 is supported by ffdshow.

[MatMaul]

@ foxyshadis : I think your last libavcodec.dll update break vc1 support.

rev 24 : my wmv file works
last rev : it don't work

[videomixer9]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev38-20060804.exe?download (ICL 9.1.028 + GCC 3.4.5)

currently all my wmv files work except the avis, the VC-1 testvid from mplayer samples ftp doesn't work though.

[_xxl]

WMV VC1 doesn't work.

[LoRd_MuldeR]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev38-20060804.exe?download (ICL 9.1.028 + GCC 3.4.5)

currently all my wmv files work except the avis, the VC-1 testvid from mplayer samples ftp doesn't work though.

Sorry, but now behavior is even more strange:
1. I can't get MPC to use ffdshow for the WMV trailers at all
2. The 1080 version plays fine (Windows Media DMO)
3. The 720 version makes the player freeze

Plays alle fine in Windows Media Player though - without ffdshow :scared:
Maybe M$ found a way to locked their WMVs for open-source players :p

[MatMaul]

actually wmv3 decoder is broken, I work on it.
the previous build of videomixer9 (rev24) works with .wmv samples.

[LoRd_MuldeR]

actually wmv3 decoder is broken, I work on it.
the previous build of videomixer9 (rev24) works with .wmv samples.

approved.

[videomixer9]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev39.exe?download :rolleyes: only libavcodec is recompiled, that should be enough I think, tell me if I'm wrong.

[MatMaul]

non it doesn't work.
it's not a compile problem : when I compile myself libavcodec,

rev 29 -> no problem
rev 30 with my last patchs -> problem

zplayer try to use ffdshow and crash (memory exception etc)

so the libavcodec update of foxyshadis is the problem, but I actually don't know why.

EDIT : to videomixer9 : I haven't fix it for the moment, it's not necessary to compile a new version at rev40

[foxyshadis]

Huh, WMV1/2 is working okay, I guess I'll just have to trace it. Well, that was easy, oops, mistake in dsputil.c. Grr, I could have sworn I remember merging that line into mine.

Now the weird part: WMV2 works fine even though wmv1/2 support is not compiled in. Bizarre, I wonder if it's using vc-1 as well. No! Creepy!

Oh, now I notice that #include "wmv2.c" line at the bottom of msmpeg4.c :p

[videomixer9]

ffdshow-tryouts-rev42.exe (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow-tryouts-rev42.exe)

whatever is usable now and whatever not O_o you can randomly find revisions on that host as it allows automated upload. They all just for fun testing so don't go update too often or you'll go mad :P

[LoRd_MuldeR]

ffdshow-tryouts-rev41.exe (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow-tryouts-rev41.exe)

whatever is usable now and whatever not O_o you can randomly find revisions on that host as it allows automated upload. They all just for fun testing so don't go update too often or you'll go mad :P

Now we hav the old behavior:
720 WMV Trailer plays, but performance is unacceptable
1080 WMV Trailer makes player crash after a few frames
WMV9-AVI doesn't use ffdshow for decoding

[videomixer9]

What I currently wonder about is where the mbaff support in h264 went to.
edit: duh of course the merging reenabled the ALLOW_INTERLACE stuff ...

[MatMaul]

Now we hav the old behavior:
720 WMV Trailer plays, but performance is unacceptable
1080 WMV Trailer makes player crash after a few frames
WMV9-AVI doesn't use ffdshow for decoding


720 WMV works great with zplayer (it's slow because the decoder is actually not optimized).
mpc seem to use outdated splitter, graphedit uses also by default this outdated splitter (but no problem with graphedit if I use the same splitter than zplayer)

1080 WMV crashs after some frames for me too.

[foxyshadis]

vm9, I don't think it's a good idea to remove ALLOW_INTERLACE yet, because is does cause a several percent slowdown. Add it by default to the makefile and projects if you want, but to force it always on at this point, when ffdshow still struggles to decode hidef on many systems, seems wrong. A better solution would be to replace them all with #ifndef CONFIG_H264_NOINTERLACE.

I bet the 1080 wmv just uses some not-supported or buggy feature, I mean, you'd likely be able to find a D1 or QCIF resolution file that crashes it just as easily. (Like a couple of wmv2s I have.) Still, it'd be good to have to try to trace the problem.

[videomixer9]

Nah my patch before enabled it per default but the merger of course disabled this and included it the way it's in the original ffmpeg too. It just made me wonder why it suddenly didn't work anymore. Actually I added a parameter to the makefile that allows you to enable it seperatly at compile time via a compiler parameter.

just use sth. like "make H264MBAFF=yes" and it should be enabled.

I think some codecs can be killed off from the source though. There is no chance some of them will ever be playable with ffdshow cause there are no simply directshow parsers for them.

Another funny thing to implement will be AVS and I wonder why they made a special container based on MPEG-PS for that one, it's a myth to me currently how it distinguishes itself this way from MPEG2. Currently ffmpeg/mplayer also mistakes it for MPEG2 without telling ffmpeg/mplayer specially. The problem might be that ffmpeg/mplayer adjust their parsers and that won't be much usuable just with ffdshow but would need a hack into other files.

vc-1 doesn't seem to have real mmx/sse etc. optimization so far so bad speed if kind of explainable.

[LoRd_MuldeR]

720 WMV works great with zplayer (it's slow because the decoder is actually not optimized).
mpc seem to use outdated splitter, graphedit uses also by default this outdated splitter (but no problem with graphedit if I use the same splitter than zplayer)

1080 WMV crashs after some frames for me too.

I don't think MPC has it's own ASF splitter, so it will use the same as any other DShow player. Furthermore it's the same in MPC as you say it for zplayer: WMV 720 works (slow!) and WMV 1080 crahses after a few frames. So it's definitely some problem in ffdshow and/or libavcodec.

[videomixer9]

Well even in mplayer the DMO is still prefered as decoder if available. Just give the developers some time.

btw. sourceforge deleting cookies right after it set them during login on firefox really pisses me off recently.

[MatMaul]

I don't think MPC has it's own ASF splitter, so it will use the same as any other DShow player. Furthermore it's the same in MPC as you say it for zplayer: WMV 720 works (slow!) and WMV 1080 crahses after a few frames. So it's definitely some problem in ffdshow and/or libavcodec.

MPC don't use it's own asf splitter, it uses "Windows Media source filter"+"ASF ACM handler"+"ASF ICM handler".
zplayer uses "WM ASF Reader".

[LoRd_MuldeR]

MPC don't use it's own asf splitter, it uses "Windows Media source filter"+"ASF ACM handler"+"ASF ICM handler".
zplayer uses "WM ASF Reader".

Well, I can't say which source-filter MPC uses for WMV files, because the caption of the sorce-filter is just the file-name. But what I see is, that the source is directly connected to the "WMVideo Decoder DMO" and "WMAudio Decoder DMO". No "ASF ACM handler" or "ASF ICM handler" in use here...

Also note MPC's option: Use the WM ASF Reader for Windows Media files (enables faster seeking, but won't seek with incomplete files at all)

[videomixer9]

I installed a phpbb forum on the sourceforge project site just in case this gets out of the hand on discussions :P any builder who wants can also have their own forum part they if they want. This thread here is getting awfully clogged up :O

[MatMaul]

Well, I can't say which source-filter MPC uses for WMV files, because the caption of the sorce-filter is just the file-name. But what I see is, that the source is directly connected to the "WMVideo Decoder DMO" and "WMAudio Decoder DMO". No "ASF ACM handler" or "ASF ICM handler" in use here...

Also note MPC's option: Use the WM ASF Reader for Windows Media files (enables faster seeking, but won't seek with incomplete files at all)

Thanks a lot !!
It's why I had broken playback of wmv3 files !
Play good now with mpc !

[LoRd_MuldeR]

Thanks a lot !!
It's why I had broken playback of wmv3 files !
Play good now with mpc !

I've now disabled WMV3/VC-1 support in ffdshow.
Now MPC plays fine the 1080 trailer (WMVideo Decoder DMO).
But it freezes on the 720 trailer :scared:

:confused:

[_xxl]

ffdshow.ax is compiled by MSVC2003,libavcodec.dll & libmplayer.dll are GCC 4.0.3 and the rest are by ICL9.
patches used:
aspect.diff,vorbisch.patch,inttypes.diff,accuracy.diff,dts.patch,tsampleformat.patch,faad.patch,
mbaff.patch,ffdshow_multithread_060730.patch,volume normalization bug fix,Better management of buffers of the queue,VMR9 blackout on reconnect by h_yamagata.
Autodetecting best optimizations:
http://rapidshare.de/files/28252610/FFdshow-20060805-rev2546.exe.html(libavcodec.dll is by GCC 4.0.3)
http://rapidshare.de/files/28384944/FFdshow-20060805-rev2546.exe.html(libavcodec.dll is by GCC 3.4.2)
Generic:
http://rapidshare.de/files/28253068/ffdshow-20060805-rev2546-MMX.exe.html(libavcodec.dll is by GCC 4.0.3)
http://rapidshare.de/files/28385994/ffdshow-20060805-rev2546-XXL.exe.html(libavcodec.dll is by GCC 3.4.2)
SSE:
http://rapidshare.de/files/28253260/ffdshow-20060805-rev2546-SSE.exe.html
SSE2:
http://rapidshare.de/files/28253430/ffdshow-20060805-rev2546-SSE2.exe.html

[clsid]

rev 2546 tryout rev 44
compiled as usual
download (http://www.mytempdir.com/847966)

[videomixer9]

both also on sourceforge, drevil_xxl only the autodetect build though

clsid: http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2546_t44_20060805.exe?download
drevil_xxl: http://prdownloads.sourceforge.net/ffdshow-tryout/FFdshow-20060805-rev2546.exe?download

[_xxl]

http://ffdshow.wyrdic.net/?N=D

[videomixer9]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev47.exe?download

1080 trailers should be playable now.

[LoRd_MuldeR]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev47.exe?download

1080 trailers should be playable now.

Approved. But performance is unuseable. Slideshow...
Might SSE build be faster ???

[videomixer9]

I'm currently trying to mix ICL with the rest as the current state ICL seem to not build stuff at all. Also saw new ICL has now /QxT for Core2 Duo with SSE4 ;P Question is just how to get ICL to output an object file compatible with GNU linker. GCC sse build doesn't change anything really.

Btw. the new extras added by haruhiko disabled and queue output samples too and Coral Reef Adventure 1080 looked kind of fluently playing with only sound stuttering around quite much.

[videomixer9]

hm, some asked here for an updated libtheora ...
http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=11

but honestly I have the same problem as when I tried earlier, there are missing references to some structures I cannot find anywhere, and the asm code doesn't compile correctly with any of my compilers, not even gcc. Anyone a clue how to get theora updated without grabing some random ogg libs and other stuff? Honestly I never saw such a mess as the theora source package.

[LoRd_MuldeR]

ffdshow-tryouts-rev47-sse.exe doesn't install :(
The non-sse build is fine.

[videomixer9]

any more specific error?

[akapuma]

any more specific error?"Fehler bei der Registrierung von ffdshow.ax"

W2000SP4, Athlon64

Best regards

akapuma

[videomixer9]

It uses automatic parrallelization of ICL again, works fine on my PC but appearently causes some problems on some others. I don't really plan fixing this though for this build :P The failed registration error is btw. useless for me, registering per hand will prolly throw a better error as usual telling you specifics why it failed. Now either it'll throw a missing dll error or crash. If a dll is missing it would be probably libguide40.dll though it should be statically linked stuff.

http://www-users.rwth-aachen.de/Jens.Daumann/libguide40.dll

There's no real speedup anyways.

[akapuma]

Hello,

I found no libguide40.dll on my PC. I found this dll in the web (http://www.dlldll.com/files/libguide40.dll) and copied this to c:\winnt\system32 (vm9: problem with your link). Then, the installation of ffdshow-tryouts-rev47-sse works.

Best regards

akapuma

[videomixer9]

Funny. It's uploaded by and shows up but isn't downloadable, oh well.

From tomorrow on i'll be gone for some time btw.

[rig_veda]

I just gave celtic_druid's ffdshow-rev2546-SSE2 and drevil_xxl's autodetecting FFdshow-20060805-rev2546 a try. Contrary to my previously used version (ffdshow-20060420-gcc4.0.3-sse-x264.nl), there is a problem with outputting RGB Modes: The picture looks like no hardware scaling is used, it's doing just what looks like low quality point resize now. Maybe overlay support is broken?
I also just checked the recent x264.nl compiles, and these seem to work ok though... There's still something slightly wrong with it when menus overlap the picture (the image seems to shift slightly), but the scaling there seems to work right.

Btw, does somebody know how "High quality YV12 to RGB conversion" in ffdshow is done? Is it the same as the avisynth's ConvertToRGB? I'm noticing that both give much better results than doing it in hardware on my gf5700fx (less banding!), but I wondered whether they produce identical output.

[videomixer9]

High quality converts to YUY2 first and then to RGB iirc.

[LoRd_MuldeR]

Hello,

I found no libguide40.dll on my PC. I found this dll in the web (http://www.dlldll.com/files/libguide40.dll) and copied this to c:\winnt\system32 (vm9: problem with your link). Then, the installation of ffdshow-tryouts-rev47-sse works.

Best regards

akapuma

Thank you. That fixed the problem for me too.

[clsid]

rev47 build (http://rapidshare.de/files/28534994/ffdshow_rev2546_t47_20060807.exe.html)

short url for ffdshow project on sf site (http://ffdshow.info)

[Flexy]

hi CD and VM9, i just posted this in "general", but i guess here is a better place.

---snip---
well i dont know what forum i could write this....

() The SSE ffdshow builds, both by videomixer9 AND drevil_xxl crash on my machine under various circumstances using VDubmod/vdub-mpeg2...wg. using certain codecs like Huffyuv. (the ones built in ffdshow)

The only SSE build which works is the yakamoto (SP ?) build on the "tryouts" page.

(!!!!!!) Both, the videomixer9 and drevil_xxl builds did something WEIRD to my system, and i spend a LONG time restoring all my codecs....thank god for daily registry backups.

By uninstalling either one of those two (vm9/xxl) ffdshow builds ALL formerly otherwise registered AV codecs get unregistered (or something like that)....resulting that my system didnt recognize ANY format anymore....eg. i had DivX, Xvid, Nero, PowerDVD, you name it, lame, all the standard MS codecs etc...all those went unaivalable after i uninstalled any one of those ffdshow builds. You can doublecheck this by uninstalling ffdshow...then load up vdubmod and try to encode something...ALL the video codecs are gone together with ffdshow.

Maybe VM9 or XXL should look into that...also, i dont know why they crashed under certain operations....it's odd since i run on AMD 64...but in general seem to have problems with certain programs optimized for SSE.

add:

i also had problems with certain other options, eg warpsharp (one of the few options i played around)..and the two above builds it didnt work right....NOW it works fine.

also...i am kinda confused regarding the "audio configuration" page....because i really dont know what libs to use or just disable them. Eg. libmad, mp3lib, libdts libfaad, libsomething.....is there something like optimized defaults for the audio decoders ?

---- snap ---

i also have another question:

I got a movie which claims to be in HD format, and GSpot says its WMV3, Windows Media 9. I cannot play that movie in MPC, i also cant play it in MP 11 beta...i can only play it in Mplayer !

ffdshow should play wmv3, right ?

[wyrd]

short url for ffdshow project on sf site (http://ffdshow.info)

wow great!

btw, why QDM2(mov) is noisy in recent ffdshow-tryouts?
e.g. sample file (http://ffdshow.wyrdic.net/moe/sample/mov/sample_sorenson%5bSVQ1+QDM2%5d.mov)
ffdshow-tryouts-rev24-20060803.exe = work fine.
ffdshow-tryouts-rev38-20060804.exe or later = noisy.

at MPC611(with Directshow,internal mov/mp4 spliter)
other .mov sample (http://ffdshow.wyrdic.net/moe/sample/mov/)

degrade at tryout rev30?(may be wrong...)
dose anyone reproduce this?

thanks,

[foxyshadis]

Probably the more recent version of lavc breaks something. Thanks for the sample file, I'll check it out, it might just need reverting to the old version.

Flexy, I checked out the script used to uninstall (at least, VM9's script) and it clearly only removes the value, not the whole key, unless it's an NSIS bug. I'm not saying you're wrong - it's not the first report of it happening - I just can't figure out where it came from. Do you know specifically what builds it was?

[_xxl]

By uninstalling either one of those two (vm9/xxl) ffdshow builds ALL formerly otherwise registered AV codecs get unregistered (or something like that)....resulting that my system didnt recognize ANY format anymore....eg. i had DivX, Xvid, Nero, PowerDVD, you name it, lame, all the standard MS codecs etc...all those went unaivalable after i uninstalled any one of those ffdshow builds. You can doublecheck this by uninstalling ffdshow...then load up vdubmod and try to encode something...ALL the video codecs are gone together with ffdshow.?
1).VfW issue with vdubmod is Fixed.
2).Please tell us:
a).the exact version of ffdshow(generic,sse,sse2)
b).the system type(CPU,MP,VDUB)
c).the options given when ffdshow was configured
d).more details,video sample...

[Flexy]

1).VfW issue with vdubmod is Fixed.
2).Please tell us:
a).the exact version of ffdshow(generic,sse,sse2)
b).the system type(CPU,MP,VDUB)
c).the options given when ffdshow was configured
d).more details,video sample...

hi,

a)
i try to recap. Yesterday i got your builds 8/3, 8/5..and VM9's latest, all SSE builds. I will try (and double-check) again later with the latest on the tryout-site, tho. Will report back with results.

b) AMD 64 3500+, dfi lanparty NF4, 1GB memory., SP Pro SP2
Vdub-mod 1.5.10.2, (2540), vdub-mpeg2 1.6.15 (24600)

c) ffdshow options, well i set all codecs (fvw, ds) at "set all stable formats to libavcodec but i disable H264.


(*) in general...i will try to reproduce everything now since i had a mess with codecs and now everything is cleaned up...will try with the latest builds and report back in a few.

Edit: Ok.

I deinstalled my working fdshow (yakamato build) and got the latest
20060805-rev2546 drevil build.

Installed it...did some tests. Loaded *any* video and then used the ffdshow builtin Huffyuv to decode. First run looked ok, second time i seletcted a part of the video and tried to encode (save as avi) with ffdshow/huffyuv again and vdub crashed. Tried again to encode the whole movie (because i thought it might only happen when i select a section)...but crashed again.

Tried warpsharp...SEEMED to work.

Uninstalled ffdshow and...BOOM ! I have the proof here, guys :(

Here something doesn't look right either where the WMV codecs are supposed to be, the strings are messed up (should be "ISO mpeg4 video v1" and "windows media [......]".

http://home.comcast.net/~gwrauh1/d1.jpg

After i unintsall drevil build:

ALl video codecs gone:

http://home.comcast.net/~gwrauh1/d2.jpg

Audio codecs gone too:

http://home.comcast.net/~gwrauh1/d3.jpg


() restored my system again :) - and after uninstalling the (working) yakamato build the codecs are still there (as i can check w/ vdubmod)...except of course the entry for ffdshow is gone. There is defintly something weird going on with those builds.

If i can help....let me know how.

ADD: My system *should* be setup well otherwise since i deinstalled PowerDVD, Nero 7, DivX, some players, ffdshow and other codec-related stuff...cleaned registry and re-installed all those applications and codecs inclusive ffdshow new again to make sure it's not something else causing the problem.

[_xxl]

1).The problem is caused by Inno Setup.
Please backup:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]
bug fixed!
2).Huffyuv/libavcodec.dll (SSE,SSE2) crashes?
3).WMP10 crashes with ffdshow.ax?
4).WMV3/VC-1 is not supported!
5).Please test the builds:
clsid rev47:
http://rapidshare.de/files/28534994/ffdshow_rev2546_t47_20060807.exe.html
videomixer9 rev47:
http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev47.exe?download
xxl:
Generic:
http://rapidshare.de/files/28253068/ffdshow-20060805-rev2546-MMX.exe.html
SSE:
http://rapidshare.de/files/28253260/ffdshow-20060805-rev2546-SSE.exe.html
SSE2:
http://rapidshare.de/files/28253430/ffdshow-20060805-rev2546-SSE2.exe.html

[DSP8000]

@drevil_xxl,

this is the error that I'm getting with your last posted build.

http://img77.imageshack.us/img77/9279/ffdshowerrorbm0.gif

DSP8000

[_xxl]

http://img223.imageshack.us/img223/5269/ffdshowbj6.th.jpg (http://img223.imageshack.us/my.php?image=ffdshowbj6.jpg)
ok!
ffdshow maybe in use?

[breez]

Sometimes the ffdshow.ax remains 'in use' even if any applications using ffdshow were closed a long time ago. Rebooting helps, but is a pain.

[LoRd_MuldeR]

Sometimes the ffdshow.ax remains 'in use' even if any applications using ffdshow were closed a long time ago. Rebooting helps, but is a pain.

There must be some app using/locking the ffdshow.ax
Somtimes it's explorer.exe or something.
Use ProcessExplorer (http://www.sysinternals.com/Utilities/ProcessExplorer.html) to check which app causes the problem.

[_xxl]

http://rapidshare.de/files/28615324/ffdshow-20060808-rev2546-Test.exe.html

[Liisachan]

Sometimes the ffdshow.ax remains 'in use' even if any applications using ffdshow were closed a long time ago. Rebooting helps, but is a pain.
This information might be helpful.
http://sourceforge.net/tracker/?func=detail&atid=471491&aid=1472926&group_id=53761


Date: 2006-06-25 06:49
Sender: h_yamagata
...
Refuse loading from blacklist :
Re-installing ffdshow.ax sometimes fails because
ffdshow.ax cannot be deleted.
Explorer.exe loads ffdshow.ax and never releases.
That causes annoying error on re-install that one have to
log off.
With this patch, ffdshow.ax avoids to be loaded by
returning false on DllMain
if the caller is included in BlackList ("Don't use
ffdshow in:").

[Egh]

Just recently found out: last VM9's builds crash vdub 1.6.15 when loading avis with h264 (high-profile). Vdub tells:


An out-of-bounds memory access (access violation) occurred in module 'ffdshow'...
...reading address 000002B8.


Same avis are played OK with ffshow in MPC.

And other avi videos (i.e. not h264) seems are loading fine in vdub.

[DSP8000]

Tnx. guys, I figured it out.
I manualy deleted the ffdshow.ax file, did temp files clean up, rebooted and installed it.Works good.
Also makeAVIS works :cool:
In VM9's builds it's broken.
Unlocker is a good tool for this situation.

Can you please elaborate what's patched,new,fixed in your ffdshow-20060808-rev2546-Test build?

:thanks:
DSP8000

[Peuj]

Hi,

With the wm3/9 enabled from the videomixer9's build ffdshow-tryouts-rev47-sse.exe, the video has some strange artifacts:

wm3/9 enabled:
http://i3.tinypic.com/241jriq.jpg

wm3/9 disabled:
http://i6.tinypic.com/241js48.jpg

no postprocessing, output set in ffdshow has yv12 and vmr9 renderless in mpc

the video can be downloaded from here http://www.jeuxvideo.fr/telecharger-elveon-31819.html

Thanks

[SeeMoreDigital]

If you require your images to be seen instantly you are probably better off using a free image hosting server such as TinyPic (http://tinypic.com/)....


Cheers

[Peuj]

If you require your images to be seen instantly you are probably better off using a free image hosting server such as TinyPic (http://tinypic.com/)....


Cheers

ok thanks for the idea, I have edited my message.

[MatMaul]

@LoRd_MuldeR : I have found why your wmv-avi sample isn't decoded by ffdshow.
Your file use complex profile of wmv3 and ffmpeg wmv3 decoder doesn't support this profile !

I have just test with my own wmv-avi encode, main profile works great with ffdshow, but complex profile use the DMO decoder.

So wmv-avi main profile files work with ffdshow.

[Flexy]

drevil, i just tested the two you posted here last...the problem with the uninstaller seems to be gone.

But your SSE2 build again crashed vdub while trying to encode something with huffyyv - and the other test-build came up with a error-message "unknown error...possible corrupted data" or something while trying to use the huffyuv.

I didn't do further testing...just very quick.

Also..i noted the garbled strings in the encoder dropdown list (see my list above in one pic) were still there.

>>
2).Huffyuv/libavcodec.dll (SSE,SSE2) crashes?
>>

looks like it.

ADD:
Btw. the problem with the locked ffdshow.ax...easiest is you just terminate all instances of explorer in taskmanager....and then file--> new task--->"explorer" starts a new one....temporary workaround which saves a reboot :)

[asasadad_1]

libfaad2 in ffdshow_rev2546_t47_20060807.exe decode this sample (http://d.turboupload.com/d/859937/ffdshowlibfaad2_bug.mp4.html) incorrectly(play too fast),coreaac aduio decoder(1, 2, 0, 575) and MPA Decoder Filter(1, 0, 0, 3) has the same problem as ffdshow audio decoder(libfaad2).
3ivx D4 4.5.1 Pro DirectShow Audio Decoder、Elecard AAC Decoder(0, 9, 10, 60315) and ffdshow audio decoder(realaac) is ok with that sample.MPlayer dev-SVN-r19260-4.0.3 is ok too.

[haruhiko_yamagata]

rev51

"It should help rebuilt process by properly tracking dependencies (gcc >=3.2 required) under mingw."

It fixes the broken rebuild process. We no longer have to type "make depend". Just type "make" and we will have "*.d" files that helps rebuild properly. The dependency files are updated automatically every time we make. It's very comfortable.

Thank you very much, Kurosu.

[foxyshadis]

asasadad, can you report it to ffmpeg instead? They'd be in a better position to fix it.

haruhiko, I found a crash when unloading ffdshow in swscale.c, sws_freeContext, apparently because CPUCount is 2 but the second context was never allocated after recent changes. However, making it crash in release mode is very rare indeed.

wyrd, I can't get QDM2 audio to play no matter what version of the codec or what splitter I use, so I can't test. =\

[clsid]

That too fast audio bug has been in libfaad2 for a long time now :(

[haruhiko_yamagata]

haruhiko, I found a crash when unloading ffdshow in swscale.c, sws_freeContext, apparently because CPUCount is 2 but the second context was never allocated after recent changes. However, making it crash in release mode is very rare indeed.
I reverted src/ffmpeg/libavutil/mem.c. I think it fixes swscaler though I could not reproduce. Please see if it is fixed and doesn't break anything.

[wyrd]

@foxyshadis
Thank you for your reproduce test.

Hmm..
I play in celtic_druid's mpc611 (set .mov with directshow mode & use internal mp4/mov splitter).

settings: mpc1 (http://tirnanog.fate.jp/tmp/snap/mpcset1.jpg) , mpc2 (http://tirnanog.fate.jp/tmp/snap/mpcset2.jpg) , ffdshow (http://tirnanog.fate.jp/tmp/snap/ffdset.jpg)
snapshot (http://tirnanog.fate.jp/tmp/snap/mpcplay.png)

or

graphedit with celtic_druid's mp4splitter.
snapshot (http://tirnanog.fate.jp/tmp/snap/geplay.png)

Is this useful information for trouble shoot ?

Best Regards.

[clsid]

It would be useful if there was a list of known bugs/issues that are present in the latest revision of ffdshow and its libs. Possibly in a pinned topic on the sf forum or in a new topic here?

A list of changes/improvements since rev. 2543 (the last one before the MT patches) would be nice too.

That hopefully makes it easier to keep track of things, specially for people who don't follow this topic closely.

[Flexy]

haruhiko,

you test your SSE builds on AMD A64 ? Your builds are the only ones i have NO problems with :)

Starting to think i i want to compile on my own...but then we have enough builds already, i am sure :)

[_xxl]

http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html


2).Huffyuv/libavcodec.dll (SSE,SSE2) crashes?
looks like it.

Bug Fixed:
Huffyuv,Vorbis/libavcodec.dll.
Please test h264/libavcodec.dll decoder.

[videomixer9]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

[Flexy]

http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html


Bug Fixed:
Huffyuv,Vorbis/libavcodec.dll.
Please test h264/libavcodec.dll decoder.

looks all good here extcept that in the vfw-encoder section the "wmv" entries still only say "W" or "I". No problems with huffyuv or h264.

[Flexy]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

looks good. Can even read wmv3 now :)

Please note i do very quick and dirty testing...right now only short encoding runs huffyuv...and then install/uninstall and checking my codecs.

Oh yeah...ffdshow.ax was locked again here - otherwise this looks very good to me especially with the wmv3 support. No problem with Huffyuv. ALso, the vfw/encoder drop-down list looks all right.


I dont know...but i assume this stuff works only when you dont enable SSE optimizations for libavcodec, right ?

[videomixer9]

Well no fancy optimization stuff for the kids that are always crying cause they need optimized pseudo-speed :P No fancy optimizations = no fancy crashing for no reason.

Reading 2ch.net especially japanese are the super optimization trolls, I think I'll just retag a generic build as Core2 Duo build and they go droll days over it even though Intel Compiler 9.1.028 got Core2 Duo optimizer now ;P However pretty senseless as libavcodec cannot be really compiled again with ICL and I doubt it gives really more speed. And what's the optimizations worth if everybody comes back crying that it's unstable.

Btw. I love this bullshit about generic builds having SSE or whatever disabled, that is plain bullshit. ffdshow libavcodec will always use automatic CPU detection whatever parameters you will specify on compiletime and it will use 3dnow or SSE, MMX etc. assembler optimized routines if available. It'll just not have useless routines use SSE. As I explained earlier almost only useless stuff is vectorized by Intel Compiler or GCC autovectorizes, and without vectorization that code is even more worthless to gain speed. E.g. the most useless parts of the sound mixing in ffdshow is vectorized in the most useless parts, loops that are only to check GUI elements are vectorized and other stuff. That's just useless and also results in them breaking.

Besides I doubt that using SSE all the time for anything speeds things up, rather it will probably slow it down as everything is getting stuffed with SSE while the regular execution units got nothing to do.

As seen almost all errors that appear are related to these instruction sets being made of use of for the most idiotic stuff. I guess it's time to do as Dirk Paehl and declare all generic builds as "runtime cpu detection" build, as that is what libavcodec and many other filters do.

And also you can build non-SSE needing builds with MingW properly, the only thing will probably be libdts or liba52 crashing as milan enabled sse2 in the makefiles per default there iirc or whatever else it was.

[_xxl]

It seems to me that generic builds are the fastest and stable!
Maybe we can test to see the difference between a generic libavcodec.dll and SSE(SSE2) one?
There is no need to compile SSE(SSE2) versions of libavcodec.dll?
Some new speed tests between builds are welcome!

[videomixer9]

Just go ahead and test it on a SSE2 CPU. I doubt there'll be any major difference except for some minor test fluctations you always get.

[clsid]

I already made a test build containing several different libavcodec.dll compilations. Difference between fastest and slowest was very small, less than 3%.

Changing -march=i586 to -march=i686 in makefile_c.inc gives a 2% performance boost on my (old) system. So that could be added to SVN.

[videomixer9]

did this stay like that around multiple tests? timeCodec.exe e.g. can vary quite a bit depending on the surrounding apps running and also on caching that may be used the second time you test a file. Other than you could have SVN access if you had an SF account, or do you have one?

But oh well as said the general thing is that there's not much profit with special versions.

[_xxl]

Generic ffdshow build:
http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html
Tested h264/libavcodec decoder.
generic:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 63.3
mmx,sse:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.5, dfps: 63.1
mmx,3dnow,sse,387:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 62.7
Video Sample:
bbc_m420p.mp4
http://rapidshare.de/files/28813683/bbc_m420p.mp4.html

[videomixer9]

getting worse haha :P

[clsid]

did this stay like that around multiple tests? timeCodec.exe e.g. can vary quite a bit depending on the surrounding apps running and also on caching that may be used the second time you test a file.Yes, I did multiple timecodec runs with each build.

[MatMaul]

Generic ffdshow build:
http://rapidshare.de/files/28788574/ffdshow-20060809-rev2546.exe.html
Tested h264/libavcodec decoder.
generic:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 63.3
mmx,sse:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.5, dfps: 63.1
mmx,3dnow,sse,387:
User: 33s, kernel: 0s, total: 34s, real: 35s, fps: 65.4, dfps: 62.7
Sample:
bbc_m420p.mp4

what flags do you use for generic build please ?

[_xxl]

Generic:
gcc -c -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline -finline-functions
mmx,sse:
gcc -c -O3 -march=i586 -mtune=i686 -mmmx -msse -mfpmath=sse -fomit-frame-pointer -finline -finline-functions
mmx,3dnow,sse,387:
gcc -c -O3 -march=i586 -mtune=i686 -mmmx -m3dnow -msse -mfpmath=sse,387 -fomit-frame-pointer -finline -finline-functions

[MatMaul]

thanks

[Flexy]

looks good. Can even read wmv3 now :)

Please note i do very quick and dirty testing...right now only short encoding runs huffyuv...and then install/uninstall and checking my codecs.

Oh yeah...ffdshow.ax was locked again here - otherwise this looks very good to me especially with the wmv3 support. No problem with Huffyuv. ALso, the vfw/encoder drop-down list looks all right.


I dont know...but i assume this stuff works only when you dont enable SSE optimizations for libavcodec, right ?


VM9, i think i judged too quick.

The above still stands...but i discovered crashes when i use the *external* X264 codec....i also had some problems with Koepi's Xvid.

I am now back to the one yamagata build and i haven't seen any of those problems.

Also...well hell yeah you're all right, SSE, SSE2 *sounds* all great but it's worthless if it dont work..then better generic and relabel it whatever....at least as long as everything works :)

ReCap, from *my* quick testing...what has to be looked at is installer/uninstaller (codecs) {which i think is fixed now).....libacvodec especially HuffyUV, H264....AND external ones like X264/Xvid. (This just from what i looked at)

[videomixer9]

so what does ffdshow have to do with x264 or xvid? nothing really ... looks more like another bs problem related to something else. And not that "i had problems" is some useful info too. I wonder why people think that others are magic mind readers.

Besides I got a nice error report elsewhere to by some guy who overclocked his CPU which is really useful if you want to aritifically make many things crash especially with FSB overclocking. Don't even dare to report me video corruptions or anything with overclocked broken hardware :P

And HuffVuy might be broken because of the libavcodec updates the haruhiko build doesn't have ... don't compare apples with eggs :P Would be better to test builds that feature these updates too and also get sure it's not the avi splitter that crashes, gabest one might easier crash then ms or haali do as I noticed for this earlier when i captured stuff from analog input.

And also not that huffyuv may decode slowly or eating very much cpu on playback (though that's the ff variant mostly) and framedrop function may crash it, or even the output queue sampling depending on the footage. That said everything works fine for me on that.

[Flexy]

so what does ffdshow have to do with x264 or xvid? nothing really ... looks more like another bs problem related to something else. And not that "i had problems" is some useful info too. I wonder why people think that others are magic mind readers.

Besides I got a nice error report elsewhere to by some guy who overclocked his CPU which is really useful if you want to aritifically make many things crash especially with FSB overclocking. Don't even dare to report me video corruptions or anything with overclocked broken hardware :P

And HuffVuy might be broken because of the libavcodec updates the haruhiko build doesn't have ... don't compare apples with eggs :P Would be better to test builds that feature these updates too and also get sure it's not the avi splitter that crashes, gabest one might easier crash then ms or haali do as I noticed for this earlier when i captured stuff from analog input.

And also not that huffyuv may decode slowly or eating very much cpu on playback (though that's the ff variant mostly) and framedrop function may crash it, or even the output queue sampling depending on the footage. That said everything works fine for me on that.


i am aware that external xvid or x264 basically has not much to do with ffdshow...although it might be interesting to know that with some builds the external codecs work...and with others they dont. It's not that i deliberately try to blame errors on sepcific builds...i am just reporting what's happening :)

As it is i the external codecs are the same since nothing gets changed....EXCEPT ffdshow....so if the calls dont work...its *likely* it's something with ffdshow ?!

[foxyshadis]

A good bug report indicates the software you're using (eg, vdub), the action you're making (encoding, decoding, playing), the video format, the exact build used, and the crash message if any. vdub is great, puts together this spiffy text file for you and everything.

If you're getting a crash in vfw it may be related to the recent vfw patches, but it might be something entirely different.

[Egh]

New build from VM9 seems to be good:

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

At least fixes previously reported crashes in vdub for me.

P.S. I wonder why there's no date for each build on ffdshow-tryout download page :)

[thuan]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download
This build crash when playing vorbis audio (in ogm, mkv, ogg audio only too) with libavcodec, tremor is fine.

[foxyshadis]

Yeah, and it's in some of the new assembly code just added to ffmpeg. Non-asm builds aren't susceptible. Unfortunately I don't know how to debug with gdb - not to mention the interface is classic 1970's terminal emulation, so I don't really care to try.

[_xxl]

careful with drevil_xxl autodetect builds, it deleted all my FFDShow config... uguu <_<
Bug fixed.

Installed it...did some tests. Loaded *any* video and then used the ffdshow builtin Huffyuv to decode. First run looked ok, second time i seletcted a part of the video and tried to encode (save as avi) with ffdshow/huffyuv again and vdub crashed. Tried again to encode the whole movie (because i thought it might only happen when i select a section)...but crashed again.
Uninstalled ffdshow and...BOOM ! I have the proof here, guys :(
Bugs fixed.
Vorbis/libavcodec bug fixed.
Added an option (defaulting to no):
Don't use ffdshow in WMP9 & Windows Explorer.
Autodetecting best optimizations:
http://rapidshare.de/files/28868885/FFdshow-20060810-rev2546.exe.html
Inno Setup:
http://rapidshare.de/files/28871336/inno.rar.html

[Peuj]

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev60.exe?download

nothing spectacular.

I still have the issue http://forum.doom9.org/showthread.php?p=860774#post860774

and on some video like this one http://www.megaupload.com/?d=7BURSN0S the image freeze like if I have 100% CPU usage and I don't have this problem with wm3 disabled.

Thanks

[MatMaul]

I still have the issue http://forum.doom9.org/showthread.php?p=860774#post860774

and on some video like this one http://www.megaupload.com/?d=7BURSN0S the image freeze like if I have 100% CPU usage and I don't have this problem with wm3 disabled.

Thanks

Actually wmv3 decoder isn't finished and the developpement of this decoder is related to ffmpeg project.

So please report your bug at the mailing list of ffmpeg, ffmpeg-devel@mplayerhq.hu (archives of this mailing list (http://archives.free.net.ph/list/ffmpeg-devel.en.html))

[Peuj]

Actually wmv3 decoder isn't finished and the developpement of this decoder is related to ffmpeg project.

So please report your bug at the mailing list of ffmpeg, ffmpeg-devel@mplayerhq.hu (archives of this mailing list (http://archives.free.net.ph/list/ffmpeg-devel.en.html))

ok thanks

[MatMaul]

please wait 1h please before report, I download and test your samples with vlc to be sure it's ffmpeg related.

edit : you can report for the jeuxvideo.fr sample, I have the same color problem with vlc.

Your second sample (warhammer.wmv) works good (but it's slow) with vlc and ffdshow on my computer.
I think your computer is too old to decode wmv3 720p video with ffmpeg decoder (ffmpeg wmv3 decoder is actually slower than microsoft wmv3 decoder)

[MacAddict]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?

[clsid]

ffdshow_rev2546_t63_20060812.exe (http://rapidshare.de/files/29155628/ffdshow_rev2546_t63_20060812.exe.html)

Automatically uses MMX, MMXExt, SSE, SSE2, SSE3, SSE4, 3DNow! and 3DNow!2 SIMD instructions when available and supported*. :devil:

In other words a generic build, which means it is as stable as the source code allows it to be. Has decoding performance comparable to so-called optimized builds, which are usually unstable.

[multiblitz]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?
Yes, I de-istalled th 3008 version, even though I would loved to have the exact rounding. It crashed immediately if you wanted to jump in ZP by clicking on the bar in ZP

[haruhiko_yamagata]

Anyone else had problems using the 'resize' function in all of the August builds posted in this thread? The problems I'm seeing on both of my computers are when I use Lanczos Resizing I'll see the picture not be so smooth, could have a green overlay or just generally crash. I keep reverting back to the ffdshow-20060730-Q.exe build and it works just fine using resize. Anyone else?
One of the bugs of swscaler was fixed at rev 52. Please try ffdshow-tryouts-rev60.exe or newer.
At rev 63, I posted long life worker thread of swscaler.

[thuan]

Has the libavcodec vorbis decoder problem solved yet in t63? I guess not looking at the changelog.

[MacAddict]

One of the bugs of swscaler was fixed at rev 52. Please try ffdshow-tryouts-rev60.exe or newer.
At rev 63, I posted long life worker thread of swscaler.
Thanks for the fix:) I'm happy to report that clsid's new 't63' build works wonderful now with resizing.

One thing I noticed though and I'm not sure if it's expected or not is that the CPU usage almost doubles when resizing is set to 720x480 compared to just resizing to 640x480. So 640x480 is averaging about 28% CPU usage while 720x480 is averaging almost 50% CPU time. Is this expected?

[haruhiko_yamagata]

Thanks for the fix:) I'm happy to report that clsid's new 't63' build works wonderful now with resizing.

One thing I noticed though and I'm not sure if it's expected or not is that the CPU usage almost doubles when resizing is set to 720x480 compared to just resizing to 640x480. So 640x480 is averaging about 28% CPU usage while 720x480 is averaging almost 50% CPU time. Is this expected?
No, it's not expected. I have no idea why...:confused:

[Facct]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?

I'm afraid I can't really help pinpoint the problem It was a few weeks ago now so I don't remember the specifics and I've gone through all the recent July builds pretty much without keeping track.

I tried first VM9's build: possibly 20060711 which caused some problems crashing on certain scripts (lancszos4 resize before limitedsharpen) but only some variations, I tried then XXL's which I remember having more success with but still crashing.

I think it was either this or the next build (ver # I dont recall, possibly 20062207, but was VM9's build) which i noticed resizing wasn't working, and it was also one of these where I lost all the codecs. I tried the 29/07 builds (VM9 and Q, I think XXL too) and then the 30/07 VM9 but still always had the same problems with crashing: as soon as I pressed play zoomplayer would hang, but not always - sometimes the exact same configuration would work on different times. And if it crashed once (say using a 'bad' configuration), it would always crash even when using a previously working preset, unless I rebooted, but this also didn't always fixed it. As far as I could tell in my limited testing it was quite random and I gave up in frustration and went back to 20060530 (iirc this is VM9's build) which I don't recall whether or not I ever tested, but the multithreading performance is great, I can watch DVD's with See-Saw & LimitedSharpen & Lanczos4 1920x1080 resize.

[_xxl]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?
1).PLEASE make detailed, accurate bug report.
2).Please tell us:
a).the system type(CPU,MB,Ram...)
b).the exact version of ffdshow(generic,sse,sse2)
c).the options given when ffdshow was configured
d).media player,ax filters,video sample...

[Flexy]

Hi, I also had the problem with losing all my codecs a few builds back (quite a lot, now) is there any way I can get them back without reinstalling Windows?



not sure..just guessing according what drevil said. First, create a new windows restore point for the current date.

You can restore your system with the system restore utilty in XP to an earlier date (where everything worked)...and export the following path from that old registry:

backup:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]

Then restore your system back to the current date...and import/merge those back.

That's what i would try.

[Px]

ffdshow_rev2546_t63_20060812.exe (http://rapidshare.de/files/29155628/ffdshow_rev2546_t63_20060812.exe.html)

Automatically uses MMX, MMXExt, SSE, SSE2, SSE3, SSE4, 3DNow! and 3DNow!2 SIMD instructions when available and supported*. :devil:
What about adding more checkboxes for SSE3/4 to "Info & debug" window? :rolleyes:

[B.F.]

I think UI and installer in ffdshow need a lot more then just few checkboxes.

FFDshow grow in a quite big programm, with a tons of options, but UI is still the same as before.

[SeeMoreDigital]

I think UI and installer in ffdshow need a lot more then just few checkboxes.

FFDshow grow in a quite big programm, with a tons of options, but UI is still the same as before.Personally I would be happier if it there were no check-boxes at all during the installation..

It's far more straight forward to select the decoders (and other options you require) after FFDshow has been fully installed....

[clsid]

FAAD2 v2.5 has been released.
http://www.audiocoding.com/modules/mydownloads/

[igor1st]

FAAD2 v2.5 has been released.
http://www.audiocoding.com/modules/mydownloads/
Nothing changes since 2006-08-08 source code (that comes in my builds) except include file with version. :)

BTW, I communicate with Menno now about this "speed playback problem". I'll inform the results later.

[Facct]

1).PLEASE make detailed, accurate bug report.
2).Please tell us:
a).the system type(CPU,MB,Ram...)
b).the exact version of ffdshow(generic,sse,sse2)
c).the options given when ffdshow was configured
d).media player,ax filters,video sample...

Sorry for the lack of specifics.

a) AMD x2 4400+, Abit AN8 SLI Fatal1ty, 2GB Corsair XMS3500-LL, NVIDIA 7800GT running Windows XP SP2

b) ffdshow-20060722-rev2546 either XXL AutoDetect (SSE2) or videomixer9 (SSE)

c) H.264 disabled, Raw Video set to YV12

Resize: 1920x1080 Lanczos4
Avisynth: LimitedSharpenFaster (no supersampling)
Overlay: YV12, Queued Output Samples

Putting Resize after LimitedSharpen worked sometimes without crashing, but I noticed resizing often didnt work (I don't recall a single time where it played without crashing, that resizing worked, but I didn't check always as my interest was in resizing before LSF)

I don't use the Administrator account in XP (recall posts regarding this mentioning resizing this around that time)

d) Zoomplayer Pro 4.51, NVIDIA PureVideo Decoder, any DVD

have i forgotten anything?

[clsid]

Nothing changes since 2006-08-08 source code (that comes in my builds) except include file with version. :)Could you make a patch/diff file? Then I can include it in my builds as well.
BTW, I communicate with Menno now about this "speed playback problem". I'll inform the results later.I have uploaded a small test file that exhibits the problem. Download (http://www.mytempdir.com/864866).



A new build:
* Tryout SVN 63
* H.264 MBAFF support enabled (optional in installer)

Download (http://www.mytempdir.com/864857)

[nfm]

please don't forget about Aud-X support in new builds (audxlib.def and audxlib.dll).

[B.F.]

Personally I would be happier if it there were no check-boxes at all during the installation..

It's far more straight forward to select the decoders (and other options you require) after FFDshow has been fully installed....
But most of ffdshow users don't know anything about advansed settings.
They want to install a programm, and see a result.
And what do they see?
1)List of supported video codecs in install dialog is about a quater of supported by ffdshow.
2)Some codecs need postprocessing, others not.
Postprocessing is good on low bitrate mpeg(1,2,4), but on high bitrate and uncompressed video it only make picture look worse.
On install dialog I can enable postprocessing, but try to watch HD AVC video after that (automatic quality control is disabled, and postprocessing on max by default (cpu load x2)). :)
Ffdshow can save and load profiles.
How about a option to set different profiles to different codecs. (not unique profile to each codec, but some profiles like "no PP","debloking only" ets..).

[foxyshadis]

I remain of the opinion that PP should be permanently globally disabled in AVC and WMV/VC-1, and perhaps any non-"standard" dct codec. (Deringing is better handled by avisynth if you have 2+ cores anyway.) But since no one else seems to care, I'm hesitant to make such a change.

Codecs that could use it:
MPEG-1/2/4 (asp) (perhaps switching off based on quant)
SVQ3, Indeo, FLV1/VP31, maybe DV at low bitrates.
All others either include inloop filtering or have artifacts unrelated to DCT's.

[SeeMoreDigital]

I care... I'm with you Foxy ;)

At the end of the day FFdshow is a powerful codec suite and should really be targeted toward more skilled users who have a good working knowledge about about what most of its functions do/provide.

Inviting beginners/new users to select options via a installers GUI without knowing what they do, could lead to user disappointment, confusion and eventual deletion.

In my opinion FFdshow users should be encouraged to delve deeper into its functions so they can see exactly what's in there.... And if they are ready for it.

[KoD]

Could you make a patch/diff file? Then I can include it in my builds as well.
I have uploaded a small test file that exhibits the problem. Download (http://www.mytempdir.com/864866).

It looks like libfaad in either ffdshow, coreaac or foobar2k is detecting that file as having 2 audio channels when in fact it has only one.

[haruhiko_yamagata]

I remain of the opinion that PP should be permanently globally disabled in AVC and WMV/VC-1, and perhaps any non-"standard" dct codec. (Deringing is better handled by avisynth if you have 2+ cores anyway.) But since no one else seems to care, I'm hesitant to make such a change.

Perhaps no one around here knows better about PP than you. I think you don't have to hesitate to do something about PP. Though I can't comment individual codecs.

[igor1st]

Could you make a patch/diff file? Then I can include it in my builds as well.
diff file for ffdshow-tryout rev49-63 (http://d.turboupload.com/d/879658/faad2.zip.html)