New ffdshow build (?)

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