ffdshow tryouts project: Discussion & Development

[Jeremy Duncan]

http://aycu02.webshots.com/image/19041/2004209699754571741_th.jpg (http://allyoucanupload.webshots.com/v/2004209699754571741)

http://aycu04.webshots.com/image/15923/2004222122390351138_th.jpg (http://allyoucanupload.webshots.com/v/2004222122390351138)

http://aycu15.webshots.com/image/15814/2004201984852626319_rs.jpg (http://allyoucanupload.webshots.com/v/2004201984852626319)

Log (http://files.filefront.com//;7678266;;/)

ffdshow_rev1220_20070531_clsid_sse_icl9.exe
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev1220_20070531_clsid_sse_icl9.exe?modtime=1180652956&big_mirror=0

ffdshow_rev1222_20070601_xxl.exe
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev1222_20070601_xxl.exe?modtime=1180719225&big_mirror=0

Using ffdshow_rev1220_20070531_clsid_sse_icl9.exe, I took these screenshots, and the log I linked to.
It would only get tot he root menu, then die. It quit and all I had was a black screen, and the movie stopped playing.
I was resizing it to 1680, 950.

I then decided to make the resizing a multiple of 4. So I changed the resizing to 1680, 952.
It worked.
When I got to the root menu, it was still a black screen, but I moved the mouse around.
Each time the mouse moved over a icon on the rrot menu screen, it counted as a frame.
*****If I'm at the root menu, and I don't move the mouse over the icons, no frames move, so the screen stays black.*****
The good news, is that it counted 2 ahead from the moment I started the movie.

I then thought that it was a resizing issue, and that if I set the resizing to a multiple of 4, then the previous version of FFDshow would have similiar results.
Nope. ffdshow_rev1222_20070601_xxl.exe showed no frames ahead at all. Zero.

Hahaha.

So now, we need to figure out how to get it so that resizing doesn't need to be a multiple of four, and that the root menu isn't black.
But the frames ahead is working fine.

I used Gabest MPC, Nvidia video codec, FFDshow Audio codec, the plugins I linked to before.
VMR9 Renderless, and default output in MPC.
I tested various sizes inclding 1680, 952, this worked, and 720, 480, this worked too. 1680, 950 did not work, I couldn't get out of root menu to the movie.

This was the Avisynth code I used.
SetMemoryMax(1024)
FluxSmoothT(3)
ColorMatrix(Mode="Rec.601->Rec.709",scaling=2,threads=2)
MT("SeeSaw(NRlimit=0, NRlimit2=5, Sstr=2.40, Szp=1, Slimit=50, Sdamplo=16, Spower=1, sootheT=95, SdampHi=39)",3)
lanczosresize(1680, 952)

[Jeremy Duncan]

See the picture with the lady sitting down, in my previous post.
See that ahead is 2...the Buffer checkbox is unchecked !

I noticed this, and decided to play a movie and switch checking and unchecking the Buffer box to see what the osd would do.
Regardless if the buffer box was checked or not, it stayed at two.
I then closed MPC, and opened the FFDshow video configuration and unchecked the Buffer box, then started the movie and watched the osd to see if the Ahead would be at two. It was ! :)

[haruhiko_yamagata]

@Leak
I have fixed the AR problem with Haali's renderer.
I have another issue related to AviSynth. This problem is not new.
Please try this.

First resize to 720x720. Keep original aspect ratio.
Next use AviSynth filter.

The AR is broken. The video renderer does not matter.

Another case,
With the sample I have sent you (ARchangeDuringPlayback.ts) and Haali's video renderer, first start playing only resize on, next check AviSynth during playback, it's more messy...

I hope you can fix this.

[Leak]

Leak, I basically get the same OSD as
Jeremy Duncan (0 in the back/ahead fields and "requested none" with my SeeSaw script when I usually see back=0 / ahead=1) when I use ffdshow_rev1220_20070529_clsid.exe but everything is good when I use ffdshow_rev1220_20070531_clsid_sse_icl9.exe...
Okay, this is getting seriously weird now. Yes, I get the exact same result when using the non-ICL9 build as opposed to the ICL9 build, but the non-ICL9 one should in theory behave quite the same as my local MSVC/GCC development builds which never exhibited this behaviour... :confused:

I'll wait and see if this happens again when clsid releases his next build; it's only an OSD display bug after all since the AviSynth filter *is* applied - just add an "Info()" at the script's end and you'll see... :)

np: The Black Dog - Techno Playtime (Book Of Dogma)

[Leak]

See the picture with the lady sitting down, in my previous post.
See that ahead is 2...the Buffer checkbox is unchecked!
It's only reporting that the script requested a frame that's two frames ahead vs. the current frame - it doesn't matter if buffering is on or off, it just shows the script's behaviour.

Anyway, yeah, static menus *will not work* if you don't use ffdshow's built in MPEG2 decoder set to "libmpeg2" to decode MPEG2 video. Period.

When playback hits a static menu, decoding just stops, but of course the menu image is then only buffered ahead and never requested. I've modified the libmpeg2 codec so it'll signal the end of an MPEG2 sequence so the AviSynth filter can return those 2 frames at the end, but this plain doesn't work with external decoders - there's nothing I can do about that, I'm afraid. If you want to watch DVDs and get working static menus, use ffdshow for decoding them.

@haruhiko: I'll look into it.

np: The Black Dog - Seers & Sages (Book Of Dogma)

[clsid]

Doing a full clean rebuild now. New build will be online asap.

[Leak]

@Leak
I have fixed the AR problem with Haali's renderer.
Thanks. :)
Please try this.

First resize to 720x720. Keep original aspect ratio.
Next use AviSynth filter.

The AR is broken. The video renderer does not matter.
Ah, I see - the resize adds borders at the top and bottom that of course aren't in the image data (so AviSynth will still see an image with no borders), but are taken into account when I request the DAR of the image.

I'll see if I can figure out a way to get the DAR of the image without the borders. Still, the borders will be lost that way, but what should I do? AviSynth has no concept of "padding" the image on it's four sides (as much as it has no concept of "aspect ratio", that's why I added those 2 variables - but I really don't want to frankenstein yet another workaround like this into the filter), so I'd either have to add the borders to the image data (yuck) or simply drop them.

I'll probably just add a "ffdshow_SetDAR" script function to AviSynth that'll change the DAR if you want and leaves everything alone if it isn't used. But of course, it's best not to use the resize filter before the AviSynth filter; if you need to resize you can always do that at the beginning of the AviSynth script - that'll also save some RAM as it won't buffer the resized images; it's probably best to put the AviSynth filter as early as possible in your filter chain anyway.

np: The Black Dog - Tactile (Book Of Dogma)

[clsid]

In the default order the AviSynth filter is below Resizing. So the order needs to be changed.

[multiblitz]

Good to read that Haali and the ffdshow team have progressed on this issue ! As long as the IVTC flags are given by the the splitter and the timestamps are properly set, there isn't any need to implement RFF (that is to repeat fields in the output). This flag is only useful to display progressive content on an interlaced display (by turning a 24fps progressive movie into a 30 fps interlaced movies). The only thing that may be required is to further adjust the timestamps if RFF is detected.

That sound promissing, so I understand that Haali's splitter needs to progress first before you guys can start to pick up the ball in ffdshow ?

Anyway, this would be absolutely fantastic. Many thanks to this community for bringing it together !

[Leak]

Okay, I added some extra checking code the the ffdshow_source filter that should complain about a "bogus input pointer" in DebugView if the missing OSD is caused by what I think is the culprit (namely the wrong ffdshow_source filter instance being used by AviSynth)...

I'm afraid I still can't reproduce this in my own builds so someone else has to make a new build to test this. The checking code also has the added bonus that the OSD *should* work despite it's complaining, but that's more a workaround than a solution to be honest...

np: The Black Dog - Chiba (Book Of Dogma)

[Jeremy Duncan]

use ffdshow's built in MPEG2 decoder set to "libmpeg2" to decode MPEG2 video.

http://aycu09.webshots.com/image/18368/2002441676048623234_th.jpg (http://allyoucanupload.webshots.com/v/2002441676048623234)

http://aycu35.webshots.com/image/17474/2001536722732009033_th.jpg (http://allyoucanupload.webshots.com/v/2001536722732009033)

ffdshow_rev1220_20070531_clsid_sse_icl9.exe works fine now. Thanks.
It's a lot sharper than the Nvidia codec was though.

[Leak]

It's a lot sharper than the Nvidia codec was though.
And there I always thought people considered that a *good* thing... :)

np: Tied & Tickled Trie - A Rocket Debris Cloud Drifts (Aelita)

[haruhiko_yamagata]

Thanks. :)

Ah, I see - the resize adds borders at the top and bottom that of course aren't in the image data (so AviSynth will still see an image with no borders), but are taken into account when I request the DAR of the image.

I'll see if I can figure out a way to get the DAR of the image without the borders. Still, the borders will be lost that way, but what should I do? AviSynth has no concept of "padding" the image on it's four sides (as much as it has no concept of "aspect ratio", that's why I added those 2 variables - but I really don't want to frankenstein yet another workaround like this into the filter), so I'd either have to add the borders to the image data (yuck) or simply drop them.Please don't drop them. Users may want to adjust to full screen.
But of course, it's best not to use the resize filter before the AviSynth filter; if you need to resize you can always do that at the beginning of the AviSynth script - that'll also save some RAM as it won't buffer the resized images; it's probably best to put the AviSynth filter as early as possible in your filter chain anyway.
True, but bug is a bug...
Not all users are experts, they may want to use ffdshow's resize rather than learning how to use AviSynth's resize.

[Jeremy Duncan]

Can Clsid or xxl please make a FFDshow update that uses version 1239.

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/?view=log

[Leak]

Please don't drop them. Users may want to adjust to full screen.
Well, what do you suggest then?

Simply leaving the borders as they are is not an option as soon as the script does resizing. And I really don't want to kludge another set of variables (ffdshow_borderLeft/Right/Top/Bottom) into there...

Of course, if someone really needs borders for some reason there's always the "AddBorders" filter that adds a real (as opposed to a virtual) border around the image.

True, but bug is a bug...
Not all users are experts, they may want to use ffdshow's resize rather than learning how to use AviSynth's resize.
I would have just documented in the docs that any border on the image gets dropped and have left it at that, to be honest.

What good are those virtual borders anyway? They center the image, which is usually also done by the player application, and if you want to use that space to overlay something (like subs) at some point the virtual borders have to be turned into "real" borders (i.e. the kind that's made of black pixel data) anyway.

[haruhiko_yamagata]

Well, what do you suggest then?

Simply leaving the borders as they are is not an option as soon as the script does resizing. And I really don't want to kludge another set of variables (ffdshow_borderLeft/Right/Top/Bottom) into there...

Of course, if someone really needs borders for some reason there's always the "AddBorders" filter that adds a real (as opposed to a virtual) border around the image.
Who use resize both in ffdshow and AviSynth? If AviSynth filter change dimensions, there's no choice but to drop the borders. But if AviSynth does not change it, then it's best to keep it.

[Leak]

Who use resize both in ffdshow and AviSynth? If AviSynth filter change dimensions, there's no choice but to drop the borders. But if AviSynth does not change it, then it's best to keep it.
Ummm... yes, that was what I meant, actually. I was only talking about the case when the image is resized - though I probably should have worded it differently... :D

So what needs to be changed is for the AviSynth filter to use the correct(ed) AR for the actual image, not the AR for the image+borders. That, and simply leaving the AR alone if it isn't changed.

It might take a bit until I come around to fix that, though, along with a script function to set a new AR (so I can find out whether the AR should actually be changed) and maybe a rewrite of the AviSynth interface so it doesn't keep pouring ffdshow_source functions into the AviSynth script environment.

(I only recently realized that adding a function to AviSynth simply adds it to a linked list, no matter if there already is a function of the same name; this might just be the cause of the OSD weirdness...)

[clsid]

Wouldn't changing the (default) order of the filters in ffdshow solve this issue? Doing AviSynth before Resizing instead of the other way around.

[Leak]

Wouldn't changing the (default) order of the filters in ffdshow solve this issue? Doing AviSynth before Resizing instead of the other way around.
Not exactly, since users are free to change the order and they'll probably expect things to work the other way around as well - and I do agree that it should, I just hadn't expected/experienced/noticed/etc. this case since I always use AviSynth right after "Subtitles" as the first filter... :)

[_xxl]

Parallelized h264 decoder:

Tested with:
http://www.mplayerhq.hu/MPlayer/samples/V-codecs/AVC1/bb2.mp4
1 core:
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 202.5, dfps: 202.5
http://www.imagehosting.com/out.php/t729627_Capture2.jpg (http://www.imagehosting.com/out.php/i729627_Capture2.jpg)
2 cores:
User: 0s, kernel: 0s, total: 0s, real: 17s, fps: 4365.5, dfps: 208.6
http://www.imagehosting.com/out.php/t729622_Capture.jpg (http://www.imagehosting.com/out.php/i729622_Capture.jpg)

Doesn't work with this sample.

[chros]

It seems that is broken.No multithreaded.
Woowww!!! At least some progress in this topic...
I'm hardly waiting a working version to test ... :)

[Inventive Software]

Tested with:
http://www.mplayerhq.hu/MPlayer/samples/V-codecs/AVC1/bb2.mp4
1 core:
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 202.5, dfps: 202.5
http://www.imagehosting.com/out.php/t729627_Capture2.jpg (http://www.imagehosting.com/out.php/i729627_Capture2.jpg)
2 cores:
User: 0s, kernel: 0s, total: 0s, real: 17s, fps: 4365.5, dfps: 208.6
http://www.imagehosting.com/out.php/t729622_Capture.jpg (http://www.imagehosting.com/out.php/i729622_Capture.jpg)
It seems that is broken.No multithreaded.

4365 FPS is mighty impressive, even if it's broken completely! :D

[Jeremy Duncan]

Using xxl 1240 FFDshow
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev1240_20070604_xxl.exe?modtime=1180967715&big_mirror=0

Here's the log
http://files.filefront.com//;7690920;;/

Here's a picture of the graph
http://aycu36.webshots.com/image/16995/2005470001086814868_th.jpg (http://allyoucanupload.webshots.com/v/2005470001086814868)

I used FFDshow Mpeg2 libavcodec dvd decoding and the nvidia video decoder.

It still showed no back or ahead, buffer was checked in Avisynth.
http://aycu25.webshots.com/image/17104/2005000146207085836_th.jpg (http://allyoucanupload.webshots.com/v/2005000146207085836)

i USED vmr9, DEFAULT OUTPUT IN mpc.
The plugins I linked to before.
and this code
#debug
SetMemoryMax(1024)
FluxSmoothT(3)
ColorMatrix(Mode="Rec.601->Rec.709",scaling=2,threads=2)
MT("SeeSaw(NRlimit=0, NRlimit2=5, Sstr=2.40, Szp=1, Slimit=50, Sdamplo=16, Spower=1, sootheT=95, SdampHi=39)",3)
lanczosresize(720, 480)

Edit. I'm using Vista Premium.

[matt2971]

Hi,

Sorry if this is the wrong place to post this question about ffdshow usage, but I'm having trouble finding the right place with so many different pages out there. If it is, can anyone point me to the correct place?

I've used a lot of different recent builds by various people with different results, and am wondering what is the best build for my particular setup, as I'm aware they are sometimes optimized for various Operating systems and instructions sets.

I have an old PIII 1.4ghz with MMX and SSE but nothing above that, and am running XP SP2.

I am currently using the ffdshow_rev1099_20070414_xxl.exe build.

Any advice on the best build to use, and where to get it would be appreciated.

Matt

[clsid]

Any of the generic builds will do just fine.

[chros]

I have been playing around with the new Leak's patched ffdshow (ffdshow_rev1237_20070603_clsid.exe), and try to accomplish this:

Is it makes sense at all to telecine 23.976 fps progressive content to 59.94 fps progressive one on a LCD TV/monitor running 60 Hz (from my comp) ?

If it is:
I have tried a 720p-avc content, with MPC, ffdshow decodes H264 and Haali's renderer. Settings:
x Avisynth , Ignore Pulldown, Buffer back/ahead: 30/30 (I don't know which values must be entered for ChangeFPS)
my avisynth script:
# I'm using the modded dll
SetMTMode(1,0)
# some sharpening, good results with good speed
asharp(1,6,-1,true)
# telecine to 59.94 fps: it creates a 3232.. pattern from 23.976 fps
ChangeFPS("ntsc_double")

I doubled the default values in Haali's renderer too:
Buffers: 65M , Frames: 82

Without Leak's patch: it stutters like hell. :)
But with it, sometimes it skips frames, maybe my comp is slow for it ...
My comp is: Athlon X2 4600, 1GB DDRAM, GeForce 7600GT (256MB)

And last: thanks guys for your hard work!

[Leak]

Is it makes sense at all to telecine 23.976 fps progressive content to 59.94 fps progressive one on a LCD TV/monitor running 60 Hz (from my comp) ?
Errr... if you really were to 3:2 telecine progressive video you'd actually get combed frames, I bet that's not what you want...

Anyway setting the buffers to 30/30 is really close to madness; the higher you set them the more lag you'll get and I'd not be surprised if your dropped frames come from that.

You *should* see the current best values for ahead and back in the OSD ("AviSynth info"), but you might not since there's something funny going on with it currently that I can't pinpoint... :(

Anyhow, I bet 0/1 (or 0 and a very small number) should be plenty for your use case, but honestly I think your best bet would be to just play your video as-is and let the renderer duplicate frames where neccessary.

Of course, setting your monitor to 72 Hz would be best...

np: Mouse On Mars - Schlecktron (Double Mix) (Rost Pocks)

[fastplayer]

@all SF members:
Don't forget to vote for ffdshow tryouts (http://sourceforge.net/awards/cca/nomination.php?group_id=173941&from=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fffdshow-tryout)! :)
:thanks:

[mpioner]

Developers
plz add silent install options to InnoSetup

[matt2971]

OK, cheers for that.

[Delerue]

I think that MPEG1 (both libavcodec and libmpeg2) decode is broken. I tested with this sample (http://rapidshare.com/files/35312010/Bangalore_Choir_-_Loaded_Gun.7z.html) and noticed that it stutters a lot (at 0:11 sec, per example), and the aspect ratio isn't correct. The file was verified with MPC internal filter, Windows XP default decoder (with MPC and WMP11), VLC and SMPlayer (MPlayer), and it seems to run very well.

I tried with the build 1245 (inside the 'About' tab is written 1240, hehehe).

[B.F.]

Strange bug in SVQ3 decoder.
(Link was deleted)
It play fine with QuickTime decoder.

[chros]

Errr... if you really were to 3:2 telecine progressive video you'd actually get combed frames, I bet that's not what you want...
Are you sure it's working that way?
From the manual: ChangeFPS changes the frame rate by deleting or duplicating frames. So I'm think it doesn't produces combed frames.

Anyway setting the buffers to 30/30 is really close to madness; the higher you set them the more lag you'll get and I'd not be surprised if your dropped frames come from that. ...
Anyhow, I bet 0/1 (or 0 and a very small number) should be plenty for your use case, ...
Thanks. 0/1 values working pretty much the same like 30/30 :)
ChangeFPS("ntsc_double") is still unwatchable, I'll try ChangeFPS("ntsc_video") which results a 1111211112... pattern.

but honestly I think your best bet would be to just play your video as-is and let the renderer duplicate frames where neccessary.
If it's working this way, then probably this is the best choice. I'll ask Haali ...

Of course, setting your monitor to 72 Hz would be best...
Yep, but my TV is only capable of 60 Hz.

[Leak]

Are you sure it's working that way?
From the manual: ChangeFPS changes the frame rate by deleting or duplicating frames. So I'm think it doesn't produces combed frames.
Ummm... what I meant was that ChangeFPS alone in no way, shape or form will ever produce "true" 3:2 pulldown, as 3:2 pulldown needs to be applied to fields, not frames.

Thanks. 0/1 values working pretty much the same like 30/30 :)
ChangeFPS("ntsc_double") is still unwatchable, I'll try ChangeFPS("ntsc_video") which results a 1111211112... pattern.
What CPU load does the Windows task manager report? If it's around 50% on a dual-core machine it's probably too CPU-intensive... but seeing as it does work on a P4 2.8GHz here (okay, just the ChangeFPS("ntsc_double") part) I guess it's either the Asharp part gobbling up too much CPU or perhaps the usage of SetMTMode...

Yep, but my TV is only capable of 60 Hz.
Whoever is responsible for all kinds of displays being locked to 60Hz (often even in 50Hz PAL land) needs to be dragged out and shot with a cathode ray tube... :D

[foxyshadis]

Strange bug in SVQ3 decoder.
It play fine with QuickTime decoder.

SVQ3 with b-frames has had that problem for a while. It definitely sucks, I didn't find the problem last time but I'll look again - it might be a splitter issue though. (Sourceforge's tracker is impossibly bad for searching and sorting, but I think it isn't officially reported there. I'll take care of it. I'd donate if only they'd improve that and the mailing list, but I almost want to install Jira or Trac on the webspace instead.)

Bringing up a cam here was a bad idea though. Struck for rule 6.

[foxyshadis]

Put the changefps at the end of the script definitely, and try not to use other ffdshow filters after it. You'll now be (uselessly) filtering everything at 60fps instead of 24. You could also use convertfps (blended instead of jerky). Or make a short function to insert between each cycle a blend of frames 4 & 1 of the next, but that'll only be 29.97fps. I'd probably get too fancy for your tastes, I <3 the script. :p

Sometimes I really just wish you could have multiple avisynth instances, to run things like this after everything else.

[B.F.]

SVQ3 with b-frames has had that problem for a while. It definitely sucks, I didn't find the problem last time but I'll look again - it might be a splitter issue though. (Sourceforge's tracker is impossibly bad for searching and sorting, but I think it isn't officially reported there. I'll take care of it. I'd donate if only they'd improve that and the mailing list, but I almost want to install Jira or Trac on the webspace instead.)

Bringing up a cam here was a bad idea though. Struck for rule 6.

That was a smallest file I can find. :)
It was traler from one of movie news sites.
I just change extension from mov to mp4, so it can be played using Haali Splitter instead a QT.

P.S.
Can you delete that link from your post too?

[Leak]

Sometimes I really just wish you could have multiple avisynth instances, to run things like this after everything else.
*drops 10 foot pole*
*backs away slowly, trying to make no noise*
*turns around quietly*
*runs like hell*

:D

[clsid]

Developers
plz add silent install options to InnoSetup
All InnoSetup installers are already capable of performing silent installs...

installer.exe /verysilent

(changing the options in the installer is possible too with /components="item1,item2,etc" /tasks="item1,item2,etc")

[chros]

Ummm... what I meant was that ChangeFPS alone in no way, shape or form will ever produce "true" 3:2 pulldown, as 3:2 pulldown needs to be applied to fields, not frames.
So it was a little misunderstanding, caused by my not perfect knowledge :)

What CPU load does the Windows task manager report? If it's around 50% on a dual-core machine it's probably too CPU-intensive... but seeing as it does work on a P4 2.8GHz here (okay, just the ChangeFPS("ntsc_double") part) I guess it's either the Asharp part gobbling up too much CPU or perhaps the usage of SetMTMode...
But with what content? I tried with 720p-AVC, and yes: one of my core is at 80%. I have tried with a standard xvid content (640*xxx) and it worked ... Thanks

Whoever is responsible for all kinds of displays being locked to 60Hz (often even in 50Hz PAL land) needs to be dragged out and shot with a cathode ray tube... :D
:D At least it isn't interlaced ... :D

And an interesting thing with MPC-ffdshow_h264decoding on a dualcore CPU (no further filters are applied with the test):
1. start a 720p-AVC content, and see the loads of CPU (at here, core1 is minimal, core2 is very high)
2. stop the playback (don't close MPC), then start the playback again, and see the CPU: at here, the 2 cores is almost the same. :)
Can somebody reproduce this?
(I haven't installed AMD's DualCore Optimizer, but I use RMClock for it.)

[_xxl]

And an interesting thing with MPC-ffdshow_h264decoding on a dualcore CPU (no further filters are applied with the test):
1. start a 720p-AVC content, and see the loads of CPU (at here, core1 is minimal, core2 is very high)
2. stop the playback (don't close MPC), then start the playback again, and see the CPU: at here, the 2 cores is almost the same.
Can somebody reproduce this?

http://forum.doom9.org/showthread.php?p=923944#post923944
http://forum.doom9.org/showthread.php?p=923950#post923950

[chros]

http://forum.doom9.org/showthread.php?p=923944#post923944
http://forum.doom9.org/showthread.php?p=923950#post923950
Aha, I missed that, thanks.

Try process explorer's single aggregate graph, in process properties. Or just set MPC's affinity to one CPU. You'll find the graphs are mostly stable, and all you're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.
I'll try this, but as I remember, for me it really affected the performance.

[_xxl]

New test build:
http://rapidshare.com/files/35616997/ffdshow_rev1249_20070606_xxl.exe.html
Patch:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-June/030649.html

Works with:
http://www.moviemaze.de/media/trailer/2140/superman-returns.html

1 core:
User: 10s, kernel: 0s, total: 10s, real: 10s, fps: 337.4, dfps: 334.0

2 cores:
User: 3s, kernel: 0s, total: 3s, real: 7s, fps: 956.3, dfps: 463.3

http://www.moviemaze.de/media/trailer/1451/king-kong.html

1 core:
User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 206.1, dfps: 200.6

2 cores:
User: 8s, kernel: 0s, total: 8s, real: 14s, fps: 433.2, dfps: 256.9

It doesn't work with h264 evob's.

http://samples.mplayerhq.hu/evob/Departed%20Trailer.EVO

and this:

http://rapidshare.com/files/35755611/Star.Wars.V.mkv.html

[Keepitsimple]

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when.. :)

[fastplayer]

Slightly OT:
Am I the only one who has probs with SF's SVN? When I commit I get an error message that commit failed but the files are committed actually. And the changelog opens only after pressing the F5 button a hundred times... :confused:

[_xxl]

The same for me.

[clsid]

The commit issue only happens occasionally to me. The internal server error on the changelog page happens all the time. SF desperately needs extra server power. Or even better, make the webpages less bloated.

[foxyshadis]

This dual core support for h264 decoding. You who are in the know; what time frame are we talking about before its implemented in ffdshow? Imo the single most important update since I dont know when.. :)

That's exactly what the post above yours is about:
New test build:
http://rapidshare.com/files/35616997/ffdshow_rev1249_20070606_xxl.exe.html
Patch:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-June/030649.html
It seems to me to be broken.

We're totally dependant on some of the ffmpeg gurus dealing with it. There isn't and will never be a "time frame", although at the moment it's getting much closer. There's no point in asking repeatedly here, the reply's always the same.

[check]

Just a note to say that the h264 parallelisation going on there is slice level, which means unless the video was encoded with slices, you will see no benefit at all. I'm not sure how useful this will be in general, no HDVDs/BDs come with sliced video (afaik), and x264 does not slice anymore either.

[Delerue]

Can someone confirm this (http://forum.doom9.org/showpost.php?p=1010814&postcount=1431) bug, please?