ffdshow tryouts project: Discussion & Development

[Reino]

...you mean, besides the occasional overflows, right?
anyway, you should like the new one much more. (regain volume checked)Overflows as in crashes? Never had that.


We decided not to support non-standard files.
(more detailed explanation here: http://forum.cockos.com/showthread.php?p=252076#post252076)I'm actually talking about every audio format FFDShow supports; mp3,aac,vorbis, etc.
I have certain mp3 files where the amplification would have dropped to 70-80% in some cases with the older FFDShow revisions. And like I said; now it doesn't go below 100% anymore.

[Taurus]

...download from mpchc sourceforge site newest standalone mpeg splitter, and give it highest merit (if it hasnt already). I didnt tested but may help with other dshow players.

@Ger and bebo
Yes, might be a problem with the splitter.
I can confirm jaggy playback on Ger's sample with libavcodec and MPC builtin splitter. Haali's Splitter is even worse.
Strange thing: On 2 machines I've got the jags.
1 machine is doing fine. Identical setups as far as I can see.
Will try bebo's suggestion on standalone splitter.

[Ger]

@Taurus

You're actually quoting littleD's suggestion for bebo's MLP problem. This has nothing to do with my sample. Two separate issues. It just looks a little weird because the start quote tag is missing in bebo's last post.

[MatMaul]

about DVD decoding with libavcodec : it doesn't work well at least on my computer.
the video play fast during half a second and then hang half a second, then play fast again half a second etc
no problem with libmpeg2.

this does not happen if I read directly the IFO file containing the film (VTS_01_0.IFO) directly, but it does happen if I read the VIDEO_TS.IFO file (even after loading the main film from the menus).

after checking seems like the problem appears when the majortype is MEDIATYPE_DVD_ENCRYPTED_PACK, no problem when the majortype is MEDIATYPE_Video (so when I directly play VTS_01_0.IFO)

[fastplayer]

about DVD decoding with libavcodec : it doesn't work well at least on my computer.
the video play fast during half a second and then hang half a second, then play fast again half a second etc
no problem with libmpeg2.

this does not happen if I read directly the IFO file containing the film (VTS_01_0.IFO) directly, but it does happen if I read the VIDEO_TS.IFO file (even after loading the main film from the menus).

after checking seems like the problem appears when the majortype is MEDIATYPE_DVD_ENCRYPTED_PACK, no problem when the majortype is MEDIATYPE_Video (so when I directly play VTS_01_0.IFO)
I reported (http://forum.doom9.org/showthread.php?p=1107246#post1107246) about the exact same issue a couple of months ago. Apparently nothing has changed since then...

[littleD]

@Ger and bebo
Yes, might be a problem with the splitter.
I can confirm jaggy playback on Ger's sample with libavcodec and MPC builtin splitter. Haali's Splitter is even worse.
Strange thing: On 2 machines I've got the jags.
1 machine is doing fine. Identical setups as far as I can see.
Will try bebo's suggestion on standalone splitter.

The most recent filter is on xvidvideo.ru site (on the right side). Halli splitter is great, but has problems with new hd audio formats, MLP as Bebo said and LPCM in my case, and probably more. As latest ffdshow finally can decode all hd audio, its quite irritating:p. So i switch between halli and mpc mpeg splitter, but (again) latter has sometimes problems with hd video spliting (no stream visible).. while halli work flawless with it.

BTW, i ve read one day on the forum, that halli is gonna be updated.(?) I hope we wont be waiting much :)

[STaRGaZeR]

I reported (http://forum.doom9.org/showthread.php?p=1107246#post1107246) about the exact same issue a couple of months ago. Apparently nothing has changed since then...

Same here. However libmpeg2 is faster than libav.

[Atak_Snajpera]

However libmpeg2 is faster than libav.
really :)


Source: HDV Canon HV20 - 1440x1080@29.97 - 24MBps

Q6600@3Ghz:
libavcodec -> 166 dfps (2 cores were used)
libmpeg2 -> 116 dfps (only 1 core was used)

Microsoft MPEG-2 decoder -> 174 dfps (2 cores were used)

Microsoft decoder is still unbeaten

ATI MPEG Video Decoder -> 375 dfps (1 core was used + GPU decoding?)

[Mercury_22]

:preally :)


Source: HDV Canon HV20 - 1440x1080@29.97 - 24MBps

Q6600@3Ghz:
libavcodec -> 166 dfps (2 cores were used)
libmpeg2 -> 116 dfps (only 1 core was used)

Microsoft MPEG-2 decoder -> 174 dfps (2 cores were used)

Microsoft decoder is still unbeaten

ATI MPEG Video Decoder -> 375 dfps (1 core was used + GPU decoding?)

Really ? :p how 'bout Cyberlink's Video/SP Decoder (HomeNetwork) and elecard's ?

[Atak_Snajpera]

Really ? how 'bout Cyberlink's Video/SP Decoder (HomeNetwork) and elecard's ?

Here is source:
http://www.mediafire.com/?indmqdxynzm

[Mercury_22]

Here is source:
http://www.mediafire.com/?indmqdxynzm

Yes :thanks: but I don't have the same hardware / CPU :mad:

[STaRGaZeR]

Source: Black Hawk Down Blu-ray, 1920x1080@23,976 MPEG-2 ~27Mbps. E8400@4GHz.

libmpeg2 (1 core was used, ~60% usage) --> User: 153s, kernel: 0s, total: 153s, real: 154s, fps: 171.3, dfps: 170.0

libavcodec (2 cores were used, ~90% usage) --> User: 23s, kernel: 0s, total: 23s, real: 129s, fps: 1120.4, dfps: 202.9

And when playing actual content, not this benchmark, CPU usage is lower with libmpeg2. 5-10% lower, total ~20-25% for libav and ~15-20% for libmpeg2. Also libav has problems with DVD as already stated here and it doesn't correctly flag interlaced content (yet).

For only 1 core libmpeg2 is much faster ;)

[Atak_Snajpera]

For only 1 core libmpeg2 is much faster
Yes we know that :)

[STaRGaZeR]

Yes we know that :)

So for MPEG-2 you'll only need speed in really slow machines. In those cases libmpeg2 is a better option.

[tal.aloni]

Overflows as in crashes? Never had that.

Overflow as in clipping.
The old algorithm was calculated based on average value,
as a result, sometimes the amplification was too high, and caused "overflow" (sound level greater than allowed),
and the sound had to be clipped.

The new algorithm is based on maximum value instead,
and as a result, the sound is much more pleasant to hear,
I demonstrated this earlier using the "Iron man" trailer, the old algorithm gave pretty awful results.
see for yourself:
http://iknowu.net/files/public/ffdshow/Normalization/ffdOldNorm-selection.flac
http://iknowu.net/files/public/ffdshow/Normalization/ffdshowNewRegainVolume-selection.flac


I'm actually talking about every audio format FFDShow supports; mp3,aac,vorbis, etc.
I have certain mp3 files where the amplification would have dropped to 70-80% in some cases with the older FFDShow revisions. And like I said; now it doesn't go below 100% anymore.
The right way of doing Dynamic Range Compression (a.k.a. regain volume) is to amplify the quiet parts, (not reducing the volume from the louder ones! when you're attenuating the volume, you're basically reducing the resolution of the file)

The new algorithm allows you retain much more of the original sound characteristic.

Tal

[Snowknight26]

I just installed ffdshow on my 4x Quad-core Opteron server (16 cores), but it set the number of decoding threads to 16 (even though the maximum is apparently 8). ffdshow wouldn't work until I set the number of decoding threads to 8 or less (so I set it to 4).

[tal.aloni]

I just installed ffdshow on my 4x Quad-core Opteron server (16 cores)

Jesus. http://iknowu.net/files/public/w00t.gif
on a serious note, what do you mean "doesn't work",
can you narrow it down to a decoder / filter?

[Snowknight26]

When I check the bitrate graph in Haali Media splitter, the bitrates fly past at something like 500fps (the graph is 5 minutes wide @ 23.976fps), ffdshow doesn't show anything in the Info & CPU tab, MeGUI/MPC-HC freeze, and sometimes the DirectShowSource from the avs times out.

[tal.aloni]

When I check the bitrate graph in Haali Media splitter, the bitrates fly past at something like 500fps (the graph is 5 minutes wide @ 23.976fps), ffdshow doesn't show anything in the Info & CPU tab, MeGUI/MPC-HC freeze, and sometimes the DirectShowSource from the avs times out.

are we talking about libavcodec? is it ffdshow or ffdshow-MT?

[Snowknight26]

H.264 is set to libavcodec. Just ffdshow.

Point being though, the installer sets it to 16 when the greatest value you can normally type into the box is 8 (goes red otherwise).

[tal.aloni]

H.264 is set to libavcodec. Just ffdshow.

I can see where the problem is:
libavcodec does not allow more than 8 decoding threads, and ffdshow does not allow to select more than 8 decoding threads, but the setup routine set (in the registry) the number of threads to be the number of cores. (in your case, this is an illegal value)

I'll apply a patch to the setup routine soon.
Tal

[clsid]

Already done ;)

[Snowknight26]

Is there any benefit to setting the number of decoding threads to anything higher than 4? Or 2 even?

[LoRd_MuldeR]

Is there any benefit to setting the number of decoding threads to anything higher than 4? Or 2 even?

Depends on your number of cores. Using more threads than cores won't be helpful :p

Also the "ffmpeg-mt" branch, which is available through ffdshow-mt (http://www.xvidvideo.ru/content/category/1/40/30/) builds, benefits much more from multi-threading!
The throughput of the H.264 decoder now scales almost linear with the number of cores/threads :)

Have a look here:
http://forum.doom9.org/showpost.php?p=1214539&postcount=42
(all tests done with 4 threads on Q6600)

[Reino]

...The new algorithm allows you retain much more of the original sound characteristic.Okay, fair enough. Thanks for your explanation.

[Snowknight26]

Depends on your number of cores. Using more threads than cores won't be helpful :p

I'm talking about in the case of ffdshow, with, say, 16 cores.

[LoRd_MuldeR]

I'm talking about in the case of ffdshow, with, say, 16 cores.

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)

[jos99]

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)

So would it be correct that you don't see any benefit with mt unless you have a triple core and upwards?

[LoRd_MuldeR]

So would it be correct that you don't see any benefit with mt unless you have a triple core and upwards?

Even with a DualCore the "new" multi-threading implementation should be superior to the "old" one ;)

As said before: The "old" multi-threading method (move CABAC to it's own thread) isn't very efficient! Even with 2x CPU load, you won't get 2x speed-up. It's more like 30% speed-up. With the "new" frame-based multi-threading method the throughput scales almost linear with the number of cores/threads. Hence using n threads/cores will roughly multiply the throughput by n. The main reason not to go ffmpeg-mt/ffdshow-mt yet is reduced stability. The ffmpeg-mt branch is a work in progress. Nevertheless ffdshow-mt works fine with my H.264 samples so far. Same for DVBViewer usage...

[Thunderbolt8]

Current ffdshow will use exactly two threads/cores for H.264 decoding. And it's not very efficient (you will not get 2x speed-up for 2x CPU usage).
With ffdshow-mt you can use up to eight threads/cores now, which results in a speed-up of roughly 8x compared to a single core/thread.

No idea for other formats/decoders. H.264 should be most important anyway ;)
nooo, dont forget VC-1 :(. I like AVC better as well, but some studios just do produce VC-1 blu-rays. and x264 encodes are no problem anyway.

[Snowknight26]

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

[LoRd_MuldeR]

nooo, dont forget VC-1 :(. I like AVC better as well, but some studios just do produce VC-1 blu-rays. and x264 encodes are no problem anyway.

VC-1 is multi-threaded too in ffmpge-mt, I just didn't test it. So I can't tell you how well it scales ;)

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

Always remember: http://www.ligh.de/pics/this_is_beta.jpg

[cc979]

@tal.aloni

as far as i know of compression, there 2 types

downward compression - compresses above the threshold to make loud parts all equally as loud and then use make-up gain
and upward compression - expands the lower of the threshold, like gamma correction

is it not possible to offer/or combine both styles ?

[STaRGaZeR]

VC-1 is multi-threaded too in ffmpge-mt, I just didn't test it. So I can't tell you how well it scales ;)

http://forum.doom9.org/showthread.php?p=1213627#post1213627

[LoRd_MuldeR]

http://forum.doom9.org/showthread.php?p=1213627#post1213627

So maybe I was mistaken. At least for ffdshow-mt we are limited to multi-threaded H.264 for now...

[STaRGaZeR]

Sounds like ffdshow-mt will be pretty awesome once issues such as http://img503.imageshack.us/my.php?image=snapshot20081113001923ez8.png are gone.

Correct link: http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.png

I messed it up somehow. Blu-ray, obviously 4 slices.

[Thunderbolt8]

Correct link: http://img503.imageshack.us/img503/415/snapshot20081113001923ez8.png

I messed it up somehow. Blu-ray, obviously 4 slices.
nice rainbows :D
although most of them with are gone with normal ffdshow (e.g. band of brothers, freedom series, babel), the within temptation blu-ray (also AVC) shows some artifacting even with the lastest ffdshow version at some places.

edit: or not, seems I forgot that I had -mt installed atm and then the problems showed. but now with normal they are gone again

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?

[LoRd_MuldeR]

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?

Since these filters are not part of ffmpeg/libavcodec, they won't become multi-threaded just by going ffmpeg-mt.
It depends on the implementation of the individual filter in ffdshow! However the "Yadif" deinterlace filter in ffdshow-mt is multi-threaded already...

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2333

[tal.aloni]

is it not possible to offer/or combine both styles ?
this in not very practical and not very useful.
as I said, reducing the volume will reduce the track resolution,
nothing good will come of it.

[haruhiko_yamagata]

edit: or not, seems I forgot that I had -mt installed atm and then the problems showed. but now with normal they are gone againDid you try the latest ffmpeg-mt? Recent updates fixed the rainbow for me.

are such things like sharpening or deinterlacing as well balanced over multiple cores, or are they all single core tasks? would it be possible then at least to alternate them over the different course, e.g. when sharpeing and deinterlacing both are applied then 1 is dropped on cpu0 and the other on cpu1?While image filter is being applied on one core, other cores are used for decoding next frames. So we don't have to multithread respective image filter.
Yadif is the exception, it's even heavier than H.264 decoding, if double frame rate is enabled. I would like to push double frame rate and I multithreaded yadif.
Here is an interesting observation. Multhithreading of yadif is 225% faster on Core2 Quad if it is used with single threaded decoder and 150% faster if it is used with H.264/ffmpeg-mt.
I don't know why it is not 300%, advice for further optimization is welcome.

note:Multithreading of yadif is available only in ffmpeg-mt branch.

[haruhiko_yamagata]

I use DVBViewer as well, and there are some channels that needs MPEG2 in FFDshow set to libmpeg2.

I recorded a short sample from a problem channel. Looks fine with MPC-HC internal (libmpeg2 based) decoder and with FFDshow set to libmpeg2, but is more or less unwatchable if I switch to libavcodec.

MPEG2-sample Problem with libavcodec but OK with libmpeg2.ts - 13.95MB (http://www.zshare.net/download/515348831460b2bb/)

I generally only follow the FFDshow and MPC-HC threads here, so if someone wants to forward this to the ffmpeg/libavcodec developers, feel free. :thanks:
libavcodec-mpeg2 in ffdshow requires two (should be one) I frames after seeking to recover. The problem of your sample may be the same issue.
I have tried to fix the seeking issue without success. Patches are welcome.

[Keepitsimple]

Total noob question. I watch movies and dvb with ffdshow. I need to deinterlace the dvb source but not the movies. Is it possible to make a setting so deinterlacing is checked. Or perhaps force it on media with some certain resolution.

[clsid]

Have a look at "Profiles / Preset settings" in ffdshow options.

[tal.aloni]

Total noob question. I watch movies and dvb with ffdshow. I need to deinterlace the dvb source but not the movies. Is it possible to make a setting so deinterlacing is checked. Or perhaps force it on media with some certain resolution.

If the DVB channel is flagged correctly, Deinterlacing can be applied only to frames flagged as interlaced. ("Process frames flaged as progressive" is unchecked), this only applies to recent versions, so make sure you use the latest.

Tal

[bebo]

The most recent filter is on xvidvideo.ru site (on the right side). Halli splitter is great, but has problems with new hd audio formats, MLP as Bebo said and LPCM in my case, and probably more. As latest ffdshow finally can decode all hd audio, its quite irritating:p. So i switch between halli and mpc mpeg splitter, but (again) latter has sometimes problems with hd video spliting (no stream visible).. while halli work flawless with it.

BTW, i ve read one day on the forum, that halli is gonna be updated.(?) I hope we wont be waiting much :)



Folks - I appreciate the support and suggestions. But someone has had to have acheived a solution for this. I now have MLP working great in MPC-HC (by checking the "Mpeg PS/TS/PVA" filter). My objective is to replicate this functionality in VMC by selecting the right standalone filters and setting merits. I have been randomly trying all the Mpeg-2 files in the svn901 standalone filter package (from XvidVideo.ru) and none seem to either "see" or "see and split" the MLP stream from the container.

Which set of files from the standalone filter set acheives the the same functionality as checking the Mpeg PS/TS/PVA box in MPC-HC? Or can the MPC development team post the same exact standalone version of Mpeg PS/TS/PVA for use in VMC. Either way, once I get there I am sure MLP will decode in VMC perfectly.

Thanks in advance Guys...:thanks:

[Snowknight26]

In the Info & CPU tab, the Input bitrate seems to take forever and a day to change. While encoding from an H.264 source, checking Haali Media Splitter shows a wildly fluctuating bitrate, but ffdshow keeps it mostly constant. Did someone use the wrong value when averaging it? :p

[clsid]

@Bebo

MpegSplitter.ax is the correct one.

[bebo]

@Bebo

MpegSplitter.ax is the correct one.

Thanks CLSID!! Sounds like the last piece of the puzzle. Will load it in tonight and report results.:thanks:

[cc979]

@tal.aloni

with any compression up or down, always a loss of dynamic range/resolution

but thanks anyway

ps. with the new yadif deinterlacer, seems i found a problem with interlaced mp4/avc files it crashes mpc when enabled

[Thunderbolt8]

Did you try the latest ffmpeg-mt? Recent updates fixed the rainbow for me.
creenshots from the Freedom series Blu-ray (AVC), EP1, using ffdshow-mt svn 2333:

http://thumbnails9.imagebam.com/1887/014f5a18865317.gif (http://www.imagebam.com/image/014f5a18865317) http://thumbnails13.imagebam.com/1887/b2699118865318.gif (http://www.imagebam.com/image/b2699118865318)
http://thumbnails7.imagebam.com/1887/475f5f18865319.gif (http://www.imagebam.com/image/475f5f18865319)

noticed the other rainbows I had with 'Babel' are gone already with svn2333, but these here are still there, while gone with normal ffdshow

uploaded a 95mb remuxed video sample here: http://www.sendspace.com/file/bipcaq