New ffdshow build (?)

[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.