New ffdshow build (?) [Archive] - Page 23

videomixer9

30th April 2006, 22:53

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

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

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

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

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

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

foxyshadis

30th April 2006, 23:52

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

videomixer9

30th April 2006, 23:57

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

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

Egh

1st May 2006, 01:36

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

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

Liisachan

1st May 2006, 05:43

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

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

Liisachan

1st May 2006, 05:57

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

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

multiblitz

1st May 2006, 09:48

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

videomixer9

1st May 2006, 11:09

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

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

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

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

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

Liisachan

1st May 2006, 11:41

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

haruhiko_yamagata

1st May 2006, 13:14

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

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

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

haruhiko_yamagata

1st May 2006, 14:22

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

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

foxyshadis

1st May 2006, 18:15

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

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

videomixer9

1st May 2006, 20:25

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

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

dk75

1st May 2006, 23:00

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

dk75

1st May 2006, 23:06

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

zilexa

2nd May 2006, 18:27

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

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

videomixer9

2nd May 2006, 18:44

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

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

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

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

dk75

2nd May 2006, 21:02

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

kurt

2nd May 2006, 21:24

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

videomixer9

2nd May 2006, 21:25

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

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

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

Egh

3rd May 2006, 04:44

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

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

haruhiko_yamagata

3rd May 2006, 05:14

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

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

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

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

videomixer9

3rd May 2006, 07:11

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

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

issa

3rd May 2006, 07:35

Rev 2539 Build,

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

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

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

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

videomixer9

3rd May 2006, 13:02

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

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

breez

3rd May 2006, 14:47

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

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

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

dillee1

3rd May 2006, 21:12

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

videomixer9

3rd May 2006, 21:21

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

dk75

3rd May 2006, 22:03

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

haruhiko_yamagata

4th May 2006, 02:01

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

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

haruhiko_yamagata

4th May 2006, 02:57

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

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

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

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

videomixer9

4th May 2006, 07:32

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

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

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

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

haruhiko_yamagata

4th May 2006, 09:38

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

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

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

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

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

videomixer9

4th May 2006, 11:57

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

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

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

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

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

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

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

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

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

haruhiko_yamagata

4th May 2006, 15:43

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

videomixer9

4th May 2006, 15:43

ffdshow rev. 2544

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

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

issa

4th May 2006, 15:48

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

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

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

clsid

4th May 2006, 16:57

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

(rev 2544)

videomixer9

4th May 2006, 17:05

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

LoRd_MuldeR

4th May 2006, 19:42

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

dillee1

4th May 2006, 21:19

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

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

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

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