ffdshow tryouts project: Discussion & Development

[SeeMoreDigital]

Just to confirm...

I've just installed "ffdshow_rev1737_20080101_clsid.exe". And both (6Ch) .AC3 and .DTS pass-thru' is working perfectly via SPDIF to my surround sound receiver.

So is "real-time" 6Ch AAC-LC/HE-to-AC3 (640Kbps) transcoding :)

[haruhiko_yamagata]

in my case instead I want
the Ac3 untoched (libac52 or spdif is set is indifferent? + the Ac3 checked)
and DTS converted... It seems I can't do it...
You can do so if you select S/PDIF for AC3, libdts for DTS and check AC3 in output page.

I'm skeptical if we need "Use SPDIF when AC3 output set" option though.

[SeeMoreDigital]

I'm skeptical if we need "Use SPDIF when AC3 output set" option though.Agreed...

Selecting "S/PDIF" via the drop-down menu should be enough...

While we're on the subject of the SPDIF output. A couple of years ago Pioneer started manufacturing amplifiers with on-board WMA9pro decoders. Could the ability of being able to pass an WMA9pro data-stream via SPDIF be added to FFdshow?

I can't test this myself because I don't have one of the afore mentioned amplifiers but there must be others on the forum who have!

Anyway, it's just a thought....

[fano]

You can do so if you select S/PDIF for AC3, libdts for DTS and check AC3 in output page.

Yes I'm doing this and works well...


I'm skeptical if we need "Use SPDIF when AC3 output set" option though.

In my opinion is a little confusing, too... :confused:

fano

[vlada]

The multi-threading path that xxl uses does not work properly with PAFF interlacing. But PAFF is quite rare in H.264 files, so that shouldn't be a big problem.

I don't agree. PAFF is very common in TV broadcasting and also all AVCHD camcorders I've seen use it.

[clsid]

Haruhiko has adapted the patch to automatically disable multithreading when PAFF interlaced content is encountered.

[tjmitchem]

PAFF is very common in TV broadcasting

As in every single one of Dish Network's HD channels :mad:

[haruhiko_yamagata]

haruhiko_yamagata:
I'll be keeping an eye on the change logs to see when the subtitle filter is split off so I can start integrationI have committed as rev 1741. It's simply a duplication of raw-filter. Only one difference is it always accept all the raw video formats.
Please tell me what you need.

One thing I noticed during my tests: If ffdshow is inputing subtitle from a input pin, subtitle file reader is disabled. This is OK, but if there are more than two ffdshow in the graph, one ffdshow accepts DirectShow input pin and other instances of ffdshow read from files. You would have to check if you have multiple instances of ffdshow and if yes, you would have to disable subtitle filter for other ffdshow.

[Blight]

haruhiko_yamagata:
Where is the download link for this build?

I need it to behave as closely as possible to DirectVobSub as i'm going to give the users the option to choose between the two. And by behave closely, I mean the filter connection aspect of the filter.

It would also be good if no filter setting other than the subtitle settings (and any connection-related settings) are exposed in the subtitle filter property page.

An exact duplicate of the RAW filter would cause confusion with users who only want to configure the subtitle portion.

[haruhiko_yamagata]

I need it to behave as closely as possible to DirectVobSub as i'm going to give the users the option to choose between the two. And by behave closely, I mean the filter connection aspect of the filter.I'm afraid it's too much work. ffdshow is not designed that way. It's entire new design, new filter. ffdshow would have to respond to any changes of the video on the primary input pin of the renderer.
ffdshow require raw video as input. Please send ffdshow black images, if ffdshow is connected to sub-picture input pin of the renderer. Of course images with pictures are welcome if ffdshow is connected to the primary input pin of the renderer.
Preferred input color spaces of subtitle filter are YV12 and RGB32 (any other color spaces will be accepted and converted internally). ffdshow will render in better quality if the output color space is RGB32.

It would also be good if no filter setting other than the subtitle settings (and any connection-related settings) are exposed in the subtitle filter property page.OK, it's easy.

[clsid]

Would it not be better to create a whole new standalone filter (like VSFilter) instead adding lots of 'workarounds' to ffdshow?

[_xxl]

Would it not be better to create a whole new standalone filter (like VSFilter) instead adding lots of 'workarounds' to ffdshow?
Wouldn't be easy to fix and improve VSFilter?

[Px]

Wouldn't be easy to fix and improve VSFilter?
As its already done with ffdshow and mpc :cool:

[clsid]

That would even be better.

[Delerue]

I want to point that VSFilter (aka DirectVobSub) is coming in a DLL file. But if you rename it to an OCX file and register ('regsvr32 file.ocx'), you'll get a great performance increase. I discovered this accidentally when I was comparing the performance of MPC vs VLC.

[clsid]

Your performance measuring methods must be flawed.

[Delerue]

Your performance measuring methods must be flawed.

I doubt it. Everything began when I discovered that DirectVobSub uses more CPU than the MPC internal subtitle, because both share the same subtitle engine. So I downloaded the old VobSub (I stop using it because of compatibility problems), and to my surprise it did a better job, I mean, used less CPU. But, hey, VobSub also uses the same basic source of the DirectVobSub. The only difference between them is the file type: Ocx (VobSub) vs Dll (DirectVobSub). So I renamed the DirectVobSub Dll to an Ocx file and registered it. Voilà! The performance increased, getting equal to the VobSub.

I tested with a x264 1080p video before multi-thread patch was implemented in FFDShow. In my C2D @ 3 GHz there's a scene where the CPU usage freezes in 50% (so full load). After my 'hack', the CPU usage fell almost 5%. If you doubt, try for yourself. ;)

[clsid]

I have tested it and as expected it makes absolutely no difference at all what the file extension is.

[check]

I have tested it and as expected it makes absolutely no difference at all what the file extension is
I can also confirm that sanity prevails and the extension makes no difference.

[Delerue]

Hmmm... I tried again and, well, you're right. I can see my mistake. First, when I said 'ocx' I actually mean 'ax', of course. Second, in fact there's a difference in performance betweeen VobSub and DirectVobSub (as you can see below), but they use different extensions, and that's probably why I made the mistake about the performance vs extension.

My Windows is in portuguese, so "último" means 'last', "médio" means 'average', "mínimo" means 'mininum' and "máximo" means 'maximum/peak'.

Wtihout subtitle:
http://img.photobucket.com/albums/v256/Delerue/Sem.png

With VobSub 2.23:
http://img.photobucket.com/albums/v256/Delerue/Vobsub.png

With DirectVobSub 2.7:
http://img.photobucket.com/albums/v256/Delerue/Direct.png

I tested for only 1:19 seconds, but is enough to see a 3% between VobSub and DirectVobSub in the average, and almost 10% in the maximum/peak.

Sorry for my mistake, and keep going.
;)

[leeperry]

guys, does fffdshow work with EVR on Vista ?
or does it freeze randomly like it does on XP ?

I might just install Vista if that can make ffdshow work..because EVR looks a lot better than Haali's Renderer.

Thanks,

[clsid]

Install .NET 3.5 and you have EVR on XP.

[leeperry]

hehehe, I do have EVR on XP but it's randomly freezing with ffdshow.

hence my question "does ffdshow work fine with EVR on Vista ? without freezing that is"

[_xxl]

Don't post 100 times the same issue with KMplayer + EVR on XP. Maybe I should blacklist KMplayer.

[leeperry]

I'm asking a simple question, whether ffdshow and EVR don't freeze on Vista.

a friend of mine running MPC HC + EVR + ffdshow on XP also encounters random freezes.......if he disables ffdshow, no more freezes.

maybe you should also blacklist mplayerc.exe all at once ? :D

I guess the XP EVR+ffdshow bug will never be fixed, I understand that....but what about Vista EVR + ffdshow ? does it "work" w/o freezes ?

I'm asking end users here, no need to be jumpy XXL :D

[sheppaul]

Or blacklist leepery :p

Why are you using evr on xp? It's not one of official renderers in xp: It's not guaranteed to work without hassles.

[leeperry]

yeah that's what I thought...hence I just wanna know if ffdshow works fine on Vista with EVR so I don't install Vista for nothing :D

[multiblitz]

Funny discussion on EVR.

BUT the real great news is that haruhiko_yamagata started the re-work of ffdshow to play back HD-DVD / Blu-Ray in 24p with audio and video in sync, see:

https://sourceforge.net/tracker/?func=detail&atid=867360&aid=1695996&group_id=173941

THIS IS PHANTASTIC NEWS !!!

PowerDVD is no longer able to play back from HArd-Disk; PDVD anyhow has only a reasonable picture quality on a real big screen if you use it with EVR under Vista (under XP it enables only overlay), but than you have other troubles like no re-clock anymore, no cutsom-timings with 8600GT, etcetc.

So a high-quality playback solution with post-processing through ffdshow with video and audio in sync is exactly what we need these days.

I wil start testing the latest version this evening, looking really forward to it.

[leeperry]

PowerDVD is no longer able to play back from HArd-Disk

well :D

I took a look at the previous 3319f patch, and found that the change in playback behaviour (i.e. not being able to play movies from you harddrive) was caused by changes in one single file, the \Navfilter\CLBDROMNav.ax file. The solution was simply to take the "CLBDROMNav.ax" file from the 3304 Build and overwrite the new one, and voilá, playback works as before

Sadly the new 3516 patch however, makes changes in PowerDVD.exe to totally grey out the "ok" box when wanting to play from the harddrive. You can change it back to normal without reinstalling the old version, by replacing the following of the 3516 files, by these 3304 files;

Navfilter\CLBDROMNav.ax
PowerDVD.exe
*.imp (10 files)

Now you should have some of the benefits/improvements of the new patch, while maintaing your ability to play from the harddrive.

[multiblitz]

I read that and all the ISO-ideas to out-smarten PDVD, but as Blue-Ray seems to win with the announcement of Warner yesterday, BD+ and PDVD got a new dimension of importance and in the latest version you can't even playback certain BD+ titles anymore when you have them through AnyDVD on your media-server as PDVD only plys them back, if it realizes the full-blown Copy-Protection is untouched....so....WE REALLY need an alternative way to playback HD-DVD, /Blu-Ray...now more than ever. FFDSHOW would be a wonderful solution.

[leeperry]

well yeah, HD commercial discs support in anything else than PDVD would be awesome, and a good reason for me to buy a combo drive.

the next winDVD and Arcsoft softwares are supposed to offer full blown HD support.

getting support from ffdshow is awesome, but decoding 1920*1080 content without hardware acceleration will require some bad ass CPU in order to avoid tearing.......

[_xxl]

libavcodec/motion_est_template.c:1120: warning: C99 inline functions are not supported; using GNU89
libavcodec/motion_est_template.c: In function 'ff_epzs_motion_search':
libavcodec/motion_est_template.c:1120: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

I can't compile with cc979 MinGW GCC 4.2.1 libavcodec.
If I exit MinGW then enter and run "make" again it worked.:confused:

[Yong]

are u using gcc version that compiled by cc979?

btw ffdshow video encoder crash for me too:
http://xs223.xs.to/xs223/08010/lavcerror.jpg
will post the detail tomorrow if someone want to fix it ;)

[Jay Bee]

I just tested VC-1 performance in newest build (rev1751) and libavcodec performance has increased a lot, it's smoother on one core than wmv9 decoder is on two cores on my machine! :up: Just one small bug: when I open and play a file (VC-1 in TS) the a/v synch is off until I seek in the file at least once, then it's fine. Only libavcodec, not wmv9.

[Delerue]

I just tested VC-1 performance in newest build (rev1751) and libavcodec performance has increased a lot, it's smoother on one core than wmv9 decoder is on two cores on my machine! :up: Just one small bug: when I open and play a file (VC-1 in TS) the a/v synch is off until I seek in the file at least once, then it's fine. Only libavcodec, not wmv9.

I tested here with this video (http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv). Using VC-1 by 'Libavcodec' I got an average of 8.8% of CPU usage and a peak of 13.2%, against 'WMVideo Decoder DMO' with 19.1% of average and a peak of 24.2%. Impressive!

[leeperry]

is there an easy way to reach 1.85 in the aspect ratio option of ffdshow WITH THE MOUSE ?

I can only reach 1.84 or 1.86...

maybe you could make it slower if right button is pushed or sumthing ?

I remember I asked for this feature ages ago, but that'd still be great to have 4 buttons like 2.35 / 1.85 / 1.78 / 1.33 :D

I've installed the updated EVR.dll from Vista SP1 on XP SP2, and MPC HC seems to work just fine with ffdshow 1757......so I think I will drop KMPlayer :D

I'll run more tests and report!

I've uploaded the updated EVR for XP here :
http://www.badongo.com/file/7196279

[fastplayer]

Use the arrow keys.

[leeperry]

yes thanks for the reply!

I figured it out before you answered :D

but I use it on my HCPC, so making it slower if right button is pushed or sumthing would be really handy :D

[sheppaul]

I tested here with this video (http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv). Using VC-1 by 'Libavcodec' I got an average of 8.8% of CPU usage and a peak of 13.2%, against 'WMVideo Decoder DMO' with 19.1% of average and a peak of 24.2%. Impressive!

http://www.citizeninsomniac.com/WMV/

Check if post-processors are enabled by default.

[Delerue]

http://www.citizeninsomniac.com/WMV/

Check if post-processors are enabled by default.

Great program, but all options in the decoder tab are off.

[Jay Bee]

I tested here with this video (http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv). Using VC-1 by 'Libavcodec' I got an average of 8.8% of CPU usage and a peak of 13.2%, against 'WMVideo Decoder DMO' with 19.1% of average and a peak of 24.2%. Impressive!

Playing this (http://rapidshare.com/files/79943655/VC-1_clip.ts.html) (rapidshare) I get total_average/total_peak/core1_peak of 38%/46%/84% with libavcodec vs 80%/89%/95% with WMVideo Decoder DMO'.

If ffdshow could do some multithreading it would absolutely smoke everything else out there. Right now Cyberlink is the best with 58%/60%/72%.

EDIT: Huh? Looks like libavcodec already is pretty good at multithreading but for some reason it doesn't kick in right away. This is CPU usage for each core playing the above file three times in a row:
http://img252.imageshack.us/img252/6200/clipboardimagezg7.png

What's going on here? Anyway to debug why it runs in one thread first and then later in two?

EDIT2: The only way I found to make both cores work is to load and start playing a file, press stop and press play again. Works in both ZP and MPC.

EDIT3: Updated percentages are 39%/45%/68%. So ffdshow would be the best if the a/v synch and multithreading bugs could be fixed.

[Delerue]

Playing this (http://rapidshare.com/files/79943655/VC-1_clip.ts.html) (rapidshare) I get total_average/total_peak/core1_peak of 38%/46%/84% with libavcodec vs 80%/89%/95% with WMVideo Decoder DMO'.

Your sample doesn't play here. It crashes MPC. Doesn't matter if I use Libavcodec or M$ default decoder. SMPlayer gets sound, but no image.

EDIT2: The only way I found to make both cores work is to load and start playing a file, press stop and press play again. Works in both ZP and MPC.

There's no multi-thread. The stop-and-play-pseudo-multi-thread is a common behaviour, but if you'll check, you'll see that CPU usage never pass the 50%.

[_xxl]

Libavcodec vc-1 is not multithreaded.

[Jay Bee]

What is perfmon showing me then? Is there a better way to check core usage?

Delerue:
Make sure you disable the MPC internal TS splitter and use Haali instead.

[Px]

Your sample doesn't play here. It crashes MPC. Doesn't matter if I use Libavcodec or M$ default decoder. SMPlayer gets sound, but no image.
Plays fine with mpc-hc, no crashes....
There's no multi-thread. The stop-and-play-pseudo-multi-thread is a common behaviour, but if you'll check, you'll see that CPU usage never pass the 50%.
Perfmon screen attached....

[_xxl]

Read more:
http://forum.doom9.org/showthread.php?p=924514#post924514

[Jay Bee]

I see. So Windows is somehow splitting the decoding onto both cores but it doesn't help performance? Or is perfmon just outright BS and it's really just one thread running on one core?

And the only way to check if a program is multithreading is by checking if it can make total CPU go considerably over 50%? Anyone know a better way?

[cc979]

I can't compile with cc979 MinGW GCC 4.2.1 libavcodec.
If I exit MinGW then enter and run "make" again it worked.:confused:

does it compile with the unpatched gcc-4.2.2 ?

[cc979]

are u using gcc version that compiled by cc979?

btw ffdshow video encoder crash for me too:
http://xs223.xs.to/xs223/08010/lavcerror.jpg
will post the detail tomorrow if someone want to fix it ;)

i think the encoder part was bugged when testing with gcc-4.2 pre-releases(svn) quite a while ago, not sure if anything was done about it

[Leak]

I see. So Windows is somehow splitting the decoding onto both cores but it doesn't help performance? Or is perfmon just outright BS and it's really just one thread running on one core?
Actually, it's one thread running on whichever core Windows gives it during scheduling (which can happen up to several hundred or thousand times a second). That's why you get load on both cores - Windows bounces the thread(s) around between your cores unless you set the process CPU affinity to one core only (using Task Manager, for instance).

If more than one core (i.e. more than one thread) is being utilized the "CPU load" column in the Task Manager will go above 50% - that's the best way to find out whether a process uses more than one core.

np: Tocotronic - Imitationen (Kapitulation)