New ffdshow build (?)

[bob0r]

@Negi
Submit bugs @ ffdshow project:
http://sourceforge.net/tracker/?group_id=53761&atid=471489

@Shapierian
Test and find out.... i compile ffdshow direct via ffdshow/src > make.
I add only directx stuff, i do not edit anything.

[celtic_druid]

Unless things have changed, you have got low accuracy. You need to edit ogg_os.h or whatever it is.

[breez]

Is there anything wrong with using libavcodec for Vorbis? Any practical difference to tremor (when not in low accuracy mode)?

[videomixer9]

iirc I wanted to fix this in ffdshow when compiling but it wasn't defined. Not sure.

[Liisachan]

Is there anything wrong with using libavcodec for Vorbis? Any practical difference to tremor (when not in low accuracy mode)?
Using livavcodec for decoding vorbis is ok.

The problem, if anything, is:
(0) Many of those evil codec packs use ffdshow to decode vorbis without thinking carefully.
(1) If vorbis decoding is enabled while installing ffdshow, the default decoder which will be used will be tremor.
(2) Playing vorbis, he or she will then feel "Hmm, Ogg Vorbis is not as high-quality as they say... it's even noisy... vorbis sucks..."

That's not "my" problem, but I don't want to see that happening.

[celtic_druid]

So perhaps changing:

!insertmacro testcodec ffdshow_audio VORBIS ${IDFF_MOVIE_TREMOR} 0

to:

!insertmacro testcodec ffdshow_audio VORBIS ${IDFF_MOVIE_LAVC} 0

would work better?

[Liisachan]

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.

[dimzon]

Would that change the default vorbis decoder? If so, Yes, I think so. I assume almost everyone here agrees that lavc is safer than tremor at least for now.
Agreed 100%

[Egh]

g00d :) Milan actually now even corrects bugs from time to time:P

But i don't recall anyone recently reporting this one:

Revision 2506 - Directory Listing
Modified Tue Apr 18 19:20:55 2006 UTC (3 hours, 51 minutes ago) by milan_cutka
fixed mplayerc crash on exit when audio OSD enabled

[haruhiko_yamagata]

I uploaded a patch to support multithreading of video playback. Please test.

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

[Egh]

Lots of updates recently to ffdshow SVN, including updated x264 and libavcodec. So maybe time for a new build? :P

[bob0r]

SSE: http://x264.nl
SSE2: http://files.x264.nl/ffdshow

[Slave01]

Many people use ffdshow lanczos resize to obtain better quality expecially on great displays. However unfortunately this ffdshow resize eats great cpu so why don't put a shader window like media player classic in which insert small shaders to be executed by graphics card? Is this possible?

Greetings
John Slave

[CEC]

Many people use ffdshow lanczos resize to obtain better quality expecially on great displays. However unfortunately this ffdshow resize eats great cpu so why don't put a shader window like media player classic in which insert small shaders to be executed by graphics card? Is this possible?

Greetings
John Slave

Great idea!! I have a 21 inch monitor! Can this be done???

[haruhiko_yamagata]

Many people use ffdshow lanczos resize to obtain better quality expecially on great displays. However unfortunately this ffdshow resize eats great cpu so why don't put a shader window like media player classic in which insert small shaders to be executed by graphics card? Is this possible?

Greetings
John Slave

I don't konw if it is possible. If you have dual core CPU my patch may accelarate resize.

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

[Egh]

Many people use ffdshow lanczos resize to obtain better quality expecially on great displays. However unfortunately this ffdshow resize eats great cpu so why don't put a shader window like media player classic in which insert small shaders to be executed by graphics card? Is this possible?

a) This question is old and at least on bugtracker Milan already responded to that. No, ffdshow is NOT a video renderer per se, thus currently it doesn't have access to shaders.

b) Can't you use Haali renderer with proper bicubic resizer? The difference between lancz and bicubic (with proper adjustment) is quite marginal in many cases. Haali renderer does entirely shaders-based resizing.

c) On my FX5500 and Athlon XP (with just SSE1 !) lanc resizing in software is considerably faster than bicubic in hardware. I dont' haver trouble playing 720p videos and applying lanczos to them (just xvid though, not h264 :P). Thus on anything less than some good 6xxxx or better ge-force the speed in hardware will still be worse compared to CPU-based one.

[foxyshadis]

bob0r, would it be possible to make a build with that patch included? I'd like to give it a workover but I can never get ffdshow to compile properly.

[Rash]

Thanks b0bor, your builds are great. ;)

[Egh]

Thanks b0bor, your builds are great. ;)

Kurosu counter-released though :P


April 16
* Using accuracy over speed for tremor and libmad (not tested whether that matters, but ffdshow always report low accuracy mode - code shows it's hard coded)
* Patching source whenever possible; modify FPATCHES in update.cfg


So is it higher accuracy now for vorbis decoding by tremor in this kurosu build or not? :confused:

And what kind of patches were applied?

of course his builds are available at http://kurosu.free.fr/ffdshow.htm for those who still don't know :P I use sse1 only http://kurosu.free.fr/ffdshow-20060420-14H04-athlon.exe

[bob0r]

bob0r, would it be possible to make a build with that patch included? I'd like to give it a workover but I can never get ffdshow to compile properly.

gcc -c -I. -I.. -I../imgFilters -Ilibvo -w -ffast-math -mno-cygwin -mdll -mthreads -pipe -DNDEBUG -UDEBUG -DWIN32 -D_WIN32 -O3 -march=i586 -mtune=i686 -fomit-frame-pointer -finline-functions -finline -o postproc/swscale.o postproc/swscale.c
postproc/swscale.c:80:30: error: swscale_multicpu.h: No such file or directory
make[1]: *** [postproc/swscale.o] Error 1
make[1]: Leaving directory `/home/user/ffdshow_gcc_mt/src/mplayer'
make: *** [../bin/libmplayer.dll] Error 2

http://google.com/search?q=swscale_multicpu.h
Your search - swscale_multicpu.h - did not match any documents.

Doh!

[issa]

SVN REV.2523 Build with gcc 4.1.1 (20060421), please test it to see if the gcc 4.1 produce faster code.

SSE: ffdshow-20060421-gcc-4.1.1-sse.exe (http://rapidshare.de/files/18549439/ffdshow-20060421-gcc-4.1.1-sse.exe.html)
SSE2: ffdshow-20060421-gcc-4.1.1-see2.exe (http://rapidshare.de/files/18549758/ffdshow-20060421-gcc-4.1.1-see2.exe.html)

The following build compiled with auto vectorize turn on,

SSE: ffdshow-20060421-gcc-4.1.1-sse-vectorize.exe (http://rapidshare.de/files/18554087/ffdshow-20060421-gcc-4.1.1-sse-vectorize.exe.html) [vectorize information log (http://rapidshare.de/files/18554177/vect.sse.7z.html)]
SSE2: ffdshow-20060421-gcc-4.1.1-sse2-vectorize.exe (http://rapidshare.de/files/18550046/ffdshow-20060421-gcc-4.1.1-sse2-vectorize.exe.html) [vectorize information log (http://rapidshare.de/files/18575684/vect.sse2.7z.html)]

Please someone give it a try, and test to see if the auto vectorize break any part of the ffdshow.

[videomixer9]

As ICL GCC can tell you when it does vecotrization, would've been nice to have the compile logs for this build to see if it actually vectorized something useful, last GCC 4.1.1 build from march had horrible auto vectorization. Cannot test yours, don't have SSE2. I only noticed that TomsMoComp and KernelDeint dramatically increased compile time with auto vectorization on.

[ExtraEye]

SSE: http://x264.nl
SSE2: http://files.x264.nl/ffdshow

bob0r for me your build doesn't run mpg, only avi.
changing to libavcodec makes it run again but libmpeg doesn't work as far as can tell.

im using the sse2 version if it matters.

EDIT: same happens with issa's vectorize build. im trying the vectorize off version to see if it has anything to do with it.

[videomixer9]

thanks issa, as i can see from the log there wasn't much vectorization done. I hoped for some advance in the vectorization stuff for this new version of gcc 4.1.1. Intel Compiler still vectorizes much more successful.

Other than that it is like the time I tried the -ftree-vectorize switch, the decoder doesn't really crash, but it just doesn't work. It builds the graph several times and fails and then falls back to another decoder or none.

So the vectorized build is unusable.

[foxyshadis]

Drat about the SMP. It isn't in my MSVC either, so maybe it's ICL.

Vectorized SSE2 runs fine on mine. Core Duo, XP SP2, latest MPC. (And I did ensure that it's actually ffdshow doing the decoding.) I have no idea how useful it actually is, though, haven't benchmarked anything. Except wma audio, which I causes a crash every time. (Not sure if it's 7, 8, or 9.)

libmpeg is totally broken, but is there a compelling quality or speed reason to use it? Since it seems to break every other compile I've always left it on lavc.

[haruhiko_yamagata]

Hello foxyshadis and bob0r.
Thank you for testing and report.
I'm very sorry. It was a terrible mistake.
I uploaded the fixed version.

[ExtraEye]

libmpeg is totally broken, but is there a compelling quality or speed reason to use it? Since it seems to break every other compile I've always left it on lavc.
from my perspective there is. and a pretty big one.
i use zoom player and i use it to remember the last place i got to on the file im watching (like - closing the movie on 31:20, and when loading it again it starts from 31:20).
when using that option with libavcodec, the player crashes. with libmpeg it doesn't.
it's true that it's not rare for builds to have broken versions of libmpeg but that's just a reason not to move to them.
right now i changed back to "ffdshow-svn2503-20060407-unicode" build and it works so if you want look for it somewhere on this thread.

[bob0r]

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

SSE and SSE2: http://files.x264.nl/ffdshow/ look for -mt- in the filenames.

[ExtraEye]

works for me except for the problem with libmpeg2 already mentioned before

[foxyshadis]

Hmm, I've been pushing it as hard as I could (surprisingly difficult!), resizing, enabling many different filters & avisynth plugins, and it just refuses to use more than 50% cpu, even when it's stuttering. I used "ffdshow-20060421-gcc4.0.3-sse2-mt-x264.nl.exe".

[igor1st]

works for me except for the problem with libmpeg2 already mentioned before
I made quick test today for using ffdshow with dvd-video (it crashs on navigating menu year ago).

MPC rev592, ffdshow rev2523 (bob0r sse build).
libmpeg2 with selected "DVD decoding" works almost perfectly.
libavcodec as a decoder didn't work properly at all in this case.

[haruhiko_yamagata]

Thank you, bob0r.
As foxyshadirs said, it seems multithreading is not used in the build.
I checked out svn newly, applyed the patch, and just typed make for gcc 4.0.3 on MSYS and created an instraller. No problem found.
I use directX9 header and library.

[TheShadowRunner]

Hey all, I have a bug to report for :
http://kurosu.free.fr/ffdshow-20060420-14H04-P3.exe
Each time i open a video with "Subtitles" > "Vobsub" enabled it crashes the player (upon exit for WMP or as soon as the video starts with Zoom Player).
Previous build didn't have this bug.
Later,

TSR

[haruhiko_yamagata]

Hello, bob0r.

I found ffdshow-20060421-gcc4[1].0.3-sse-mt-x264.nl.exe
works on multi-thread.

[foxyshadis]

Yep, I can confirm SSE/MT works (should have tried that one too). It maxed out around 75%, could be because of using limitedsharpenfaster or just some combination of filters that aren't multithreaded yet. But at least it works! Horray!

[haruhiko_yamagata]

Originally Posted by foxyshadis
Yep, I can confirm SSE/MT works (should have tried that one too). It maxed out around 75%, could be because of using limitedsharpenfaster or just some combination of filters that aren't multithreaded yet. But at least it works! Horray!

Thank you for testing.
Ok it works. I feel relieved.
Go beyond 75% is difficult because threads depend each other. Optimization is required for scenarios used by many people.

[bob0r]

LOL, you both missed the "look for -mt- in the filenames." part :)

Very good, because i was sure i did everything right.

Now lets see what Milan thinks of it eh? :cool:

[Liisachan]

LOL, you both missed the "look for -mt- in the filenames." part :) What do you mean? You made -sse2-mt- and -sse-mt- and apparantly the only -sse-mt- works.

Now lets see what Milan thinks of it eh? :cool: I see no reason not to merge... If the patch makes it faster even by .5% it's really precious :D

[foxyshadis]

LOL, you both missed the "look for -mt- in the filenames." part :)
I used "ffdshow-20060421-gcc4.0.3-sse2-mt-x264.nl.exe".
???

I'm sure that's the one I used, since I tried to redownload it and reinstall it when it didn't spill over 1 cpu, just in case I had screwed up and used the wrong one. Blargh.

[JarrettH]

what is auto vectorize? :devil:

[JarrettH]

is there something i have to do to enable multithreading in the ffdshow options? mine never goes above 50%

also...

these latest SSE2 builds (13th, 20th) crash Media Player Classic and Got All Media when I try to use my image settings. the SSE versions work fine though

[Liisachan]

is there something i have to do to enable multithreading in the ffdshow options? mine never goes above 50% It is supposed to work automatically.

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

2. Configuration

There is no configuration to stop multithreading
currently. If your CPU is single core and non hyper-
threading, multithreading is avoided.

[zilexa]

Just wanted to say, THANK YOU KUROSU for creating (and maintaining)
THE ffdshow downloadpage... (http://kurosu.free.fr/ffdshow)
It is the only website I found listing the CPU-specific Ffdshow builds so clearly!
_______________________________________________



Do have one q: Can't there be just 4 builds?
instead of:# Build Athlon XP (has 3DNow, SSE1 but no SSE2), 20060420-14H04 (3826 KB)
# Build Pentium4 (has SSE1 and SSE2), 20060420-14H04 (3644 KB)
# Build Pentium 3 (only has SSE1), 20060420-14H04 (3994 KB)
# Build Prescott (has from SSE1 up to SSE3), 20060420-14H04 (3680 KB)
# Build Athlon 64 (has 3DNow, SSE1 and SSE2), 20060420-14H04 (3843 KB)for AMD:

3dNow! & SSE1
3dNow! & SSE & SSE2

for INTEL:

SSE1
SSE1 & SSE2

--> Why is there a build for Prescott? ffdshow doesn't use sse3.
And couldn't there be just 1 build? One build with 3dNow! & SSE1 & SSE2 if it would be used on AthlonXP then the SSE2 optimizations would not be used. If it would be used on a Pentium, 3dNow! wouldn't be used, if it would be used on a P3 only SSE1 would be used.
Seems more logical to me :)

[LotharZ]

"ffdshow-20060420-14H04-k8" continue causing problems with MPEG1/2 files if SSE2 option is enabled.
I dont have this problem with other compiles.

[bob0r]

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

SSE and SSE2: http://files.x264.nl/ffdshow/ look for -mt- in the filenames.

[foxyshadis]

zilexa, it doesn't define what hand-optimizations are used; those still go through a cpu-checking process and use whatever you have no matter what build you run. (It would be an interesting size optimization to modify the makefiles to chop out asm code above or below the "defined" level.)

It's the masses of straight C code we're attempting to autovectorize into iSSE/2/3. Of course, as seen here, gcc's autovectorize (as little as it does compared to ICC's powerful one) is still somewhat buggy. For the most part it makes only a minor difference, if you're suffering performance problems and need every possible boost.

Thanks bob0r, I'll give it another shot.

[multiblitz]

I think it is simply wonderful that you guys strted to work on the MT-capability of ffdshow. Thanks a lot.

Here is what I see currently using the latest MT-Version from x264 with my x2 3800:

With Milan's version from 20051129 one CPU maxes out at 100%, the other at 10-15%, total around 55-60%.

My settings are De-noise 0.5,0.5.0.5,5, HQ on; Resizing at 1920*1080 Lanszos 4 with Luma sharpening at 2; Sharpening with un-sharp-mask at 20

Picture-wise, with ZP and Dscaler in YV12, every 15 sec the picture stutters.

Same setting with the ffdshow-20060423-gcc4[1].0.3-sse2-mt-x264.nl.exe version:

One CPU at 90-95%, the other at 35-40%; total at 65-75%, so some MT haopens; Stuttering is much worse that in Milan's version of 20051129, every 5 secs.

[LoRd_MuldeR]

Question:

Does the MT patch effect multi CPU systems only?
Can I expect any improvements for my single CPU too?
Or could the MT patch even lower performance for a single CPU?


//EDIT

Okay, did some testing with that "super high resolution" Superman trailer (x264). With the previous ffdshow build the video was stutterting extremely. Sometimes no new frame for several seconds. And audio/video was completely out of sync. With the new one there's a difference: Video is running more fluid, but still not very well. Audio/Video is now in sync, but I get heavy "clicking" sounds all the time. So I'm not sure what is better...

CPU usage with *new* build (single CPU):
http://img522.imageshack.us/img522/7056/cpu0cp.gif

[JarrettH]

SSE2 version still doesn't work when I try to use image settings:scared:

[JarrettH]

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

I kind of regret updating now. I remember having a build from Feb 6, 2006 ICL9 unicode. Is there somewhere I can get the latest ICL9 build?