ffdshow tryouts project: Discussion & Development

[FreeFall]

System Setup

Windows 7 Professional x64
Zoomplayer 7 Home Max 7.10 Alpha 3
Gabest Mpeg Splitter - standalone filter svn 1809 x32
Haali splitter - 27-03-2010
FFDShow rev 3374 x32
EVR renderer output


Blu-ray Disc Sword Of The Stranger

Subtitles don't display with rev 3371 - 74, working with 3370. Using FFDShow decoder subs colour is orange, with the Microsoft decoder subs are the correct colour (blue).

Sample http://www.mediafire.com/?txzygwnnxmt Subs http://www.mediafire.com/?lkwttbz4ndd


DVD subtitles inside mkv container don't display after working at first. Sample Drunken Master, subs work up until the end of the first fight scene and won't display in the dojo scene until you turn them off and on again.

Sample http://www.mediafire.com/?l223ejwjywu Subs http://www.mediafire.com/?dhthkm0jmx1


Thanks
FreeFall

[hoborg]

@albain:

-Fixed audio/subtitles streams switching from keyboard
:thanks:

[STaRGaZeR]

Albain, this is not the first time I've seen a post like this (http://forum.doom9.org/showthread.php?p=1394100#post1394100), does ffdshow really need a limitation in the number of format changes? Besides, the 3 second trick you added in r3335 doesn't work here. Commenting

if (audioParserData.nbFormatChanges>=4 || (m_tStart / 10000 / 1000 > 3))
return codecId;

out fixes all my issues, and I bet it will fix most problems with audio switching for other users too.

[XhmikosR]

More compiler comparison. This time I compared the speed difference between MSVC, ICL and GCC for xvidcore.

XviD, 25fps, 1778 Kbps, 704x400 (25000 frames)

ICL 11.1.065 /O3
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 760.6, dfps: 759.5
User: 33s, kernel: 0s, total: 33s, real: 33s, fps: 753.8, dfps: 751.3
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 762.0, dfps: 760.6
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 764.2, dfps: 762.4
User: 32s, kernel: 0s, total: 32s, real: 33s, fps: 757.7, dfps: 756.6
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 760.9, dfps: 759.9


MSVC 2008 SP1
User: 50s, kernel: 0s, total: 50s, real: 50s, fps: 496.5, dfps: 495.7
User: 49s, kernel: 0s, total: 50s, real: 50s, fps: 499.5, dfps: 499.1
User: 50s, kernel: 0s, total: 50s, real: 50s, fps: 497.5, dfps: 496.9
User: 50s, kernel: 0s, total: 50s, real: 50s, fps: 498.5, dfps: 497.5
User: 49s, kernel: 0s, total: 50s, real: 50s, fps: 498.8, dfps: 497.2
User: 49s, kernel: 0s, total: 50s, real: 50s, fps: 498.9, dfps: 498.0


GCC 4.5.0
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 763.1, dfps: 761.7
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 760.2, dfps: 758.8
User: 32s, kernel: 0s, total: 32s, real: 33s, fps: 758.8, dfps: 757.3
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 761.7, dfps: 761.0
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 762.4, dfps: 761.3
User: 32s, kernel: 0s, total: 32s, real: 32s, fps: 760.9, dfps: 760.2
=====================================================================


=====================================================================
DivX, 29.97fps, 3917 Kbps, 1280x720 (10000 frames)

ICL 11.1.065 /O3
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 195.7, dfps: 195.3
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 196.0, dfps: 195.9
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 195.8, dfps: 195.7
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 196.0, dfps: 195.7
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 195.9, dfps: 195.6
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 195.7, dfps: 195.4


MSVC 2008 SP1
User: 68s, kernel: 0s, total: 68s, real: 68s, fps: 145.9, dfps: 145.7
User: 68s, kernel: 0s, total: 68s, real: 68s, fps: 146.0, dfps: 145.7
User: 69s, kernel: 0s, total: 69s, real: 69s, fps: 143.4, dfps: 143.3
User: 68s, kernel: 0s, total: 68s, real: 69s, fps: 145.0, dfps: 144.6
User: 68s, kernel: 0s, total: 68s, real: 68s, fps: 146.2, dfps: 145.7
User: 68s, kernel: 0s, total: 68s, real: 68s, fps: 145.6, dfps: 145.1


GCC 4.5.0
User: 50s, kernel: 0s, total: 51s, real: 51s, fps: 195.6, dfps: 195.5
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 195.4, dfps: 195.3
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 195.7, dfps: 195.5
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 195.4, dfps: 194.7
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 194.8, dfps: 194.7
User: 51s, kernel: 0s, total: 51s, real: 51s, fps: 195.2, dfps: 195.0
=====================================================================


=====================================================================
XviD, 24fps, 16.1 Mbps, 1280x720 (2000 frames) (Big Buck Bunny)

ICL 11.1.065 /O3
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.4, dfps: 130.8
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.2, dfps: 130.8
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.4, dfps: 131.0
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.1, dfps: 131.0
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.6, dfps: 130.8
User: 15s, kernel: 0s, total: 15s, real: 15s, fps: 131.4, dfps: 130.8


MSVC 2008 SP1
User: 22s, kernel: 0s, total: 22s, real: 22s, fps: 87.2, dfps: 87.1
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 87.2, dfps: 86.9
User: 22s, kernel: 0s, total: 22s, real: 22s, fps: 87.5, dfps: 87.2
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 87.2, dfps: 86.8
User: 22s, kernel: 0s, total: 22s, real: 22s, fps: 87.4, dfps: 87.2
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 87.2, dfps: 86.9


GCC 4.5.0
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.2, dfps: 134.1
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.5, dfps: 134.1
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.0, dfps: 133.4
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.4, dfps: 133.8
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.8, dfps: 134.2
User: 14s, kernel: 0s, total: 14s, real: 14s, fps: 134.0, dfps: 133.7

And I wonder, what was the reason for changing xvidcore's compiler from GCC to MSVC? Also it's obvious that ICL is superior to MSVC. The compiled dlls are here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335caf38cabe7f356913a) for anyone interested. If you do try to replicate my results, don't use a 320x240 XviD video. Use something bigger with high bitrate.

And another libmpeg2 benchmark


mpeg2 remuxed to avi with mencoder, 59.940fps, 15.7 Mbps, 1280x720

MSVC 2008 SP1
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 291.2, dfps: 290.3
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 292.6, dfps: 292.0
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 290.7, dfps: 290.6
User: 29s, kernel: 0s, total: 29s, real: 30s, fps: 288.2, dfps: 287.4
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 289.8, dfps: 289.2
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 292.0, dfps: 291.5

ICL 11.1.065 /O3
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 312.9, dfps: 311.9
User: 27s, kernel: 0s, total: 27s, real: 28s, fps: 308.4, dfps: 307.5
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 308.7, dfps: 308.4
User: 27s, kernel: 0s, total: 27s, real: 28s, fps: 308.6, dfps: 307.5
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 310.3, dfps: 309.4
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 311.3, dfps: 310.0

GCC 4.5.0
User: 40s, kernel: 0s, total: 40s, real: 41s, fps: 210.8, dfps: 210.4
User: 40s, kernel: 0s, total: 40s, real: 40s, fps: 211.6, dfps: 210.8
User: 40s, kernel: 0s, total: 40s, real: 40s, fps: 213.0, dfps: 212.5
User: 40s, kernel: 0s, total: 40s, real: 40s, fps: 212.4, dfps: 211.9
User: 40s, kernel: 0s, total: 40s, real: 40s, fps: 212.7, dfps: 212.2
User: 40s, kernel: 0s, total: 40s, real: 40s, fps: 212.5, dfps: 211.7

The compiled dlls are here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca33cdc61d280511ab). GCC is so much slower for libmpeg2 than MSVC, but still ICL is faster.

[tetsuo55]

So these benchmarks seem to point out that all the non-gcc optimised stuff might as well be built with icl.

A simple change that can give up to 40% speed improvement over msvc(on my system the difference varied between 40% and 50% for xvid)

This clearly helps, xxl or clsid could you update the projectfile?
We did some testing and almost all of ffdshow can be build with icl and appears to be faster across the board.
Since the way we did it was a bit hacky we dont have scientific results.

[dimitrik]

But once again, I don't like DXVA : the picture is blurry compared to software decoding, and with multithreaded decoding AND postprocessing, you have the best results even if you don't have a (very) recent CPU on HD content



in any case, the PQ benefits of not using DXVA are only the benefits of using ffdshow's (or other renderer) colorspace conversion, at least for the radeon.
Tal


Pardon my ignorant question, but I don't understand - aren't h.264 decoders supposed to be bit-identical? This PQ argument seems to imply that they are not? :confused:

[dimitrik]

By the way I found something strange in the ffdshow h.264 DXVA subtitles filter.

The letterbox option doesn't seem to work (it works fine with software decoding).

Is it a bug or is it just not possible under DXVA?

[Keiyakusha]

Pardon my ignorant question, but I don't understand - aren't h.264 decoders supposed to be bit-identical? This PQ argument seems to imply that they are not? :confused:

Short answer: after the stream is decoded, there is other things that need_to/may be done, before you will see picture on your screen.
EDIT: also bugs are possible ^_^

[tal.aloni]

The letterbox option doesn't seem to work (it works fine with software decoding).

Is it a bug or is it just not possible under DXVA?

not possible under DXVA.

[clsid]

what was the reason for changing xvidcore's compiler from GCC to MSVC?Who says it has changed? I for example always use GCC for xvidcore.dll

[XhmikosR]

Yeah, right. You maybe, I didn't because xxl insisted in the past that msvc is "better" and added xvidcore in the solution file which overwrote my previous gcc compilation, so I removed xvidcore build with gcc from my scripts.
Anyway, how about the ICL? Don't you think it's time to update to ICL 11? And build everything with ICL.

[Delerue]

Any chance to introduce mjpeg video and twos/sowt audio decoding since they're already supported by FFMPEG? Samples here:

mjpb: http://red.cachefly.net/video/milkgirls1080p.mov
twos: http://www.fileshack.com/file.x/17838/ATI+Radeon+HD+3000+'Ping+Pong'+Tech+Demo+Video

Thanks!

[STaRGaZeR]

Yeah, right. You maybe, I didn't because xxl insisted in the past that msvc is "better" and added xvidcore in the solution file which overwrote my previous gcc compilation, so I removed xvidcore build with gcc from my scripts.
Anyway, how about the ICL? Don't you think it's time to update to ICL 11? And build everything with ICL.

You disable vectorization (/Qvec) in ICL11 because it breaks the Info&CPU tab, right? Does this affect speed in the decoders or image filters?

[tal.aloni]

Hi Guys,
I've tested some performance optimizations that Tetsuo55 suggested for the generic x86 build (only for the main executable for now), the results might be interesting:
User: 5s, kernel: 0s, total: 5s, real: 50s, fps: 881.6, dfps: 97.0 ==>> 3337 - current SVN
User: 5s, kernel: 0s, total: 5s, real: 50s, fps: 909.7, dfps: 97.4 ==>> 3339 - linker optimizations (/NXCOMPAT /DYNAMICBASE)
User: 4s, kernel: 0s, total: 4s, real: 50s, fps: 1105.1, dfps: 97.3 ==>> 3339 - linker optimizations (/NXCOMPAT /DYNAMICBASE) + /O2

can someone please explain what dfps means?


--- ffdshow_2008.vcproj Sun Apr 25 20:22:23 2010
+++ ffdshow_2008.vcproj Mon Apr 26 22:52:40 2010
@@ -285,7 +285,7 @@
/>
<Tool
Name="VCCLCompilerTool"
- AdditionalOptions="/MP"
+ AdditionalOptions="/MP /O2"
Optimization="2"
InlineFunctionExpansion="2"
EnableIntrinsicFunctions="true"
@@ -325,6 +325,7 @@
/>
<Tool
Name="VCLinkerTool"
+ AdditionalOptions="/NXCOMPAT /DYNAMICBASE"
RegisterOutput="false"
IgnoreImportLibrary="true"

[clsid]

Anyway, how about the ICL? Don't you think it's time to update to ICL 11? And build everything with ICL.I will continue to make generic builds and occasionally ICL10.1 builds. I will not upgrade to ICL 11.1 unless anyone can show me it has any real benefit compared to ICL 10.1.

My generic builds use MSVC for ffdshow.ax, GCC for libavcodec.dll ffmpegmt.dll libmplayer.dll xvidcore.dll ff_x264.dll, ICL10 for various other DLLs, and MSVC for the remaining small files.

[clsid]

User: 5s, kernel: 0s, total: 5s, real: 50s, fps: 881.6, dfps: 97.0 ==>> 3337 - current SVN
User: 5s, kernel: 0s, total: 5s, real: 50s, fps: 909.7, dfps: 97.4 ==>> 3339 - linker optimizations (/NXCOMPAT /DYNAMICBASE)
User: 4s, kernel: 0s, total: 4s, real: 50s, fps: 1105.1, dfps: 97.3 ==>> 3339 - linker optimizations (/NXCOMPAT /DYNAMICBASE) + /O2

can someone please explain what dfps means?
How many times did you run these benchmarks? Because the differences are so small that they fall within the margin of error. You can get similar differences with multiple runs with the same build. It also now indicates that /O2 is rather pointless. But since most of the work is done outside of ffdshow.ax any compiler effects on ffdshow.ax are dampened. So to better analyze the effects of the additional switches, more work should be done by ffdshow, for example by enabling some processing filters.

[XhmikosR]

You disable vectorization (/Qvec) in ICL11 because it breaks the Info&CPU tab, right? Does this affect speed in the decoders or image filters?
Yes, I disable Qvec for ffdshow.ax because of that problem. The filters have vectorization enabled and decoders and image filters are not even built with ICL. But from my tests, libmpeg2 is faster when compiled with ICL. And so xvidcore is almost the same as when compiled with gcc when MSVC completely fails. Also I have managed to build a complete ICL build (except from ffmpeg, ffmpeg-mt, libmplayer, x264 and xvidcore). I can post that build after I tweak the settings a little bit.

I will continue to make generic builds and occasionally ICL10.1 builds. I will not upgrade to ICL 11.1 unless anyone can show me it has any real benefit compared to ICL 10.1.

My generic builds use MSVC for ffdshow.ax, GCC for libavcodec.dll ffmpegmt.dll libmplayer.dll xvidcore.dll ff_x264.dll, ICL10 for various other DLLs, and MSVC for the remaining small files.
Well how about the obvious, that you are using a compiler which is no longer available for download? Or is it somewhere hidden?

The ffdshow ICL project files should not be dependent of other project files. I mean, having to compile ffdshow with MSVC and after that ffdshow with ICL is not the best thing. Also, like I showed you above libmpeg2 has a significant speed gain when compiled with ICL. If I could measure other filters I'm pretty sure they would be faster. But that's a speculation only. (for the time being)

You wanted numbers in order to change something. I posted valid numbers from various tests.

[STaRGaZeR]

Yes, I disable Qvec for ffdshow.ax because of that problem. The filters have vectorization enabled and decoders and image filters are not even built with ICL. But from my tests, libmpeg2 is faster when compiled with ICL. And so xvidcore is almost the same as when compiled with gcc when MSVC completely fails. Also I have managed to build a complete ICL build (except from ffmpeg, ffmpeg-mt, libmplayer, x264 and xvidcore). I can post that build after I tweak the settings a little bit.

If you disable vectorization in ffdshow.ax you're disabling it in all the image processing filters, like deinterlacers, etc. That's what I'm asking, if you have done any tests to determine if for example yadif is slower using Qvec. It should be interesting, I've not made the change to ICL11 yet just because of this Qvec thingy, I don't know if ICL10 without Qvec is faster or slower than ICL11 with Qvec in the key parts of ffdshow (yadif, sharpen, etc.)

Just for the record, now that I'm working with the subs I use MSVC builds, and with deband+resize+sharpen+subtitles+RGB32HQ they have measurably higher CPU consumption (up to 15%) with the specs in my sign than my ICL10.1 builds, but I've not benched them. I imagine than in slower computers the difference will be bigger.

I'm interested in that build BTW.

The ffdshow ICL project files should not be dependent of other project files. I mean, having to compile ffdshow with MSVC and after that ffdshow with ICL is not the best thing.

I agree 100% with this.


@Albain, I've fixed my patch. Now the check is done in the parser, so any changes are applied to the entire chain.

- Fix for subtitles when movie dimensions are missing or incomplete in SSA/ASS scripts. Now ffdshow behaves like VSFilter in this regard.
- Fix for blur being (almost) always activated with SSA/ASS subs, now it responds to the Blur setting in the Font section.

Patch: http://www.mediafire.com/?dyhwwehyijz
ICL10.1 build: http://www.mediafire.com/?2zjerzwz3mz

[follz20]

Just a quick question: Why does ffdshow say the output for all DTSHD MA tracks as 96khz, 8 channel @ 1536 kbps?

I'm sure this is probably addressed in this thread, but at 576 pages long it's a little hard to find!

Cheers ;)

[XhmikosR]

If you disable vectorization in ffdshow.ax you're disabling it in all the image processing filters, like deinterlacers, etc. That's what I'm asking, if you have done any tests to determine if for example yadif is slower using Qvec. It should be interesting, I've not made the change to ICL11 yet just because of this Qvec thingy, I don't know if ICL10 without Qvec is faster or slower than ICL11 with Qvec in the key parts of ffdshow (yadif, sharpen, etc.)

Just for the record, now that I'm working with the subs I use MSVC builds, and with deband+resize+sharpen+subtitles+RGB32HQ they have measurably higher CPU consumption (up to 15%) with the specs in my sign than my ICL10.1 builds, but I've not benched them. I imagine than in slower computers the difference will be bigger.

I'm interested in that build BTW.

I agree 100% with this.


Hmm you are right. Keep in mind, that maybe there's another solution to this problem. I mean, I found out by trial and error that vectorization breaks ffdshow in Info & CPU tab. I haven't benchmarked it but I could do it, although I'm not quite sure how to measure the performance of the internal filters. Maybe I could just use the cpu cycles as a comparison.

EDIT: OK, For the video part I can still use timecodec. I'll post my results soon, but from my initial tests I see that indeed ICL 11 even with Qvec- (vectorization disabled) is ~15% faster than MSVC.

RESULTS

ffdshow r3379 deband+sharpening+resize to 1920x1200

Big Buck Bunny 720p x264 (ffmpeg-mt)
ICL 11.1.065 Qvec-
User: 46s, kernel: 0s, total: 46s, real: 62s, fps: 99.6, dfps: 74.2
User: 45s, kernel: 0s, total: 46s, real: 61s, fps: 99.9, dfps: 74.3
User: 46s, kernel: 0s, total: 46s, real: 62s, fps: 98.2, dfps: 73.2
User: 45s, kernel: 0s, total: 45s, real: 62s, fps: 100.7, dfps: 73.6
User: 47s, kernel: 0s, total: 47s, real: 62s, fps: 97.3, dfps: 73.5
User: 46s, kernel: 0s, total: 46s, real: 62s, fps: 98.2, dfps: 73.5

MSVC 2008 SP1
User: 58s, kernel: 0s, total: 58s, real: 73s, fps: 78.8, dfps: 62.5
User: 56s, kernel: 0s, total: 56s, real: 72s, fps: 81.6, dfps: 63.2
User: 55s, kernel: 0s, total: 55s, real: 72s, fps: 82.3, dfps: 63.3
User: 58s, kernel: 0s, total: 58s, real: 73s, fps: 78.4, dfps: 62.5
User: 56s, kernel: 0s, total: 56s, real: 72s, fps: 81.1, dfps: 63.3
User: 57s, kernel: 0s, total: 57s, real: 72s, fps: 80.2, dfps: 63.2


Big Buck Bunny 720p XviD (libavcodec)
ICL 11.1.065 Qvec- (vectorization disabled)
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 71.9, dfps: 59.3
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 70.3, dfps: 59.5
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 71.6, dfps: 59.6
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 73.3, dfps: 59.3
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 70.9, dfps: 59.5
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 72.9, dfps: 58.9

ICL 11.1.065 (vectorization enabled)
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 72.1, dfps: 59.6
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 71.6, dfps: 59.7
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 73.5, dfps: 59.6
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 69.6, dfps: 59.7
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 73.7, dfps: 59.7
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 71.0, dfps: 59.6

ICL 10.1 r3356 clsid
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 70.5, dfps: 59.6
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 70.3, dfps: 59.4
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 71.9, dfps: 59.8
User: 27s, kernel: 0s, total: 27s, real: 33s, fps: 72.4, dfps: 59.4
User: 27s, kernel: 0s, total: 28s, real: 33s, fps: 71.1, dfps: 59.8
User: 28s, kernel: 0s, total: 28s, real: 33s, fps: 70.9, dfps: 59.6

MSVC 2008 SP1
User: 32s, kernel: 0s, total: 32s, real: 38s, fps: 61.1, dfps: 51.3
User: 33s, kernel: 0s, total: 33s, real: 39s, fps: 59.5, dfps: 50.9
User: 32s, kernel: 0s, total: 32s, real: 38s, fps: 60.9, dfps: 51.3
User: 32s, kernel: 0s, total: 32s, real: 38s, fps: 61.1, dfps: 51.4
User: 33s, kernel: 0s, total: 33s, real: 39s, fps: 59.9, dfps: 50.9
User: 32s, kernel: 0s, total: 32s, real: 38s, fps: 60.8, dfps: 51.4

EDIT: If someone creates some nice graphs we could update the wiki (http://ffdshow-tryout.sourceforge.net/wiki/faq:performance_with_filters) with my results which are closer to the newer processors compared to the Pentium 2 used. I will also upload my samples if go for that.

[albain]

@Albain, I've fixed my patch. Now the check is done in the parser, so any changes are applied to the entire chain.

- Fix for subtitles when movie dimensions are missing or incomplete in SSA/ASS scripts. Now ffdshow behaves like VSFilter in this regard.
- Fix for blur being (almost) always activated with SSA/ASS subs, now it responds to the Blur setting in the Font section.

Patch: http://www.mediafire.com/?dyhwwehyijz
ICL10.1 build: http://www.mediafire.com/?2zjerzwz3mz

Thanks, I am testing it right now and I will commit it then

[Blight]

Request:
Any chance of FFDShow exposing an IAMStreamSelect interface (at least for subs)?

[STaRGaZeR]

Hmm you are right. Keep in mind, that maybe there's another solution to this problem. I mean, I found out by trial and error that vectorization breaks ffdshow in Info & CPU tab. I haven't benchmarked it but I could do it, although I'm not quite sure how to measure the performance of the internal filters. Maybe I could just use the cpu cycles as a comparison.

I agree, this is interesting to say the least. Also, can you do another test with "Big Buck Bunny 720p XviD (libavcodec)" and ICL 11.1.065 but this time without Qvec-? Apples to apples comparison with the ICL10 build, even if it breaks Info & CPU.

[XhmikosR]

I updated my previous post. The speed gain is marginal, like when using specific cpu instructions. So to summarize, there's no speed loss between ICL 10 and ICL 11. But since no one can download ICL 10 anymore, ffdshow should update its ICL project files.

[fastplayer]

EDIT: If someone creates some nice graphs we could update the wiki (http://ffdshow-tryout.sourceforge.net/wiki/faq:performance_with_filters) with my results which are closer to the newer processors compared to the Pentium 2 used. I will also upload my samples if go for that.
I still have the Calc-template of these old tests somewhere here, so just post the complete results with/without filters and I'll make the graph.

[clsid]

If you want ICL11 projects then go ahead and add them. Just don't remove the ICL10 ones.

[STaRGaZeR]

I updated my previous post. The speed gain is marginal, like when using specific cpu instructions. So to summarize, there's no speed loss between ICL 10 and ICL 11. But since no one can download ICL 10 anymore, ffdshow should update its ICL project files.

Yeah, margin of error. Can you create and share the ICL11 projects so everything can be built with ICL11?

[XhmikosR]

OK then, I'll try to clean up my ICL 11 project files in the next days.

[albain]

System Setup

Windows 7 Professional x64
Zoomplayer 7 Home Max 7.10 Alpha 3
Gabest Mpeg Splitter - standalone filter svn 1809 x32
Haali splitter - 27-03-2010
FFDShow rev 3374 x32
EVR renderer output


Blu-ray Disc Sword Of The Stranger

Subtitles don't display with rev 3371 - 74, working with 3370. Using FFDShow decoder subs colour is orange, with the Microsoft decoder subs are the correct colour (blue).

Sample http://www.mediafire.com/?txzygwnnxmt Subs http://www.mediafire.com/?lkwttbz4ndd


Hi, I have tested your sample and it works fine on my side : the subtitles are displayed when ffdshow loading external sup file or using the embedded stream.
However they are yellow and it seems to be the right color : if you open the sup file with supread you'll get the same color.
To confirm this you could try to play your bluray with arcsoft,powerdvd or an electronic bluray player

[rpm7200]

if i enable lfe crossover, ffdshow always uses 32 bit floating point. is this a bug or something?

[FreeFall]

Albain,

Thanks for looking at it, your right I just tested with powerdvd and the subs are yellow, in earlier ffdshow builds they were originally blue so I just figured something got messed up.

I forgot to mention that the subs are orange when using the YV12 or YUY2 output, using RGB32 output displays the subs yellow as you've said.

I tested this using rev 3370 from the xvidvideo website as it's the latest build that works with Blu-ray subtitles for me. I tested rev 3371 & 3373 but the subs just won't display when selected, dvd subtitles worked fine except for the problem with the Drunken Master sample.

You said the Blu-ray subtitles are working on your end so I'll wait for a new build to test.


FreeFall

[djesteban]

@dev team
Ok, so, I have this sporadic problem when playing mkv's (with mpc-hc x64 and ffdshow x64 clsid latest and older builds) where at some point in the movie, it will start dropping the framerate for the duration of a particular scene, and right when the scene change it will jump to like 40 fps for 1-2 seconds and then go back to normal. For example, I am getting a steady 23.976, then it changes to another scene and the framerate goes down to 18fps, then changes scene again, it goes to 40fps for like a second or two and then back to a steady 23.976.
I have noticed that it happens on scene where the bitrate is (or seems to me) higher than the rest of the movie. Check the stats below that I have extracted from the info box in MPC-HC during playback.
http://img291.imageshack.us/img291/9262/fpsdp.jpg

I have also uploaded a sample (http://netfolder.in/folder.php?folder_id=0nRRYNE) (a little more than a hundred MB). Listen to it from the beginning, you will see it plays ok until you get to that "grainy, desaturated scene" part. Then you should see the fps drop slightly in MPC-HC... but it's enough to be noticeable and I didn't put the sound in this example but I can tell you that it jerks off the sound also.

Be aware that this DOES NOT happen at all when I am using CoreAVC 2.0 and plays smoothly all the way.
This is only one example, but I have a couple more mkv where this problem also arises.

Hope this can be fixed :P
Thanks in advance

[hoborg]

@albain:

-Fixed audio/subtitles streams switching from keyboard
:thanks:

Just installed rev 3383 from http://xvidvideo.ru/ and...
...stil not working, pressing CTR+ALT+F4/numpad 1 simply does nothing, no OSD, no strem switched.
Only for me? :/

[clsid]

@djesteban
this might help:
Options -> Decoder options -> disable "Drop frame on delay"

[dann23]

Catalyst 10.4 brings H.264 Level 5.1 support

http://www2.ati.com/relnotes/Catalyst_104_release_notes.pdf

I tested this with ffdshow but there are some artifacts (maybe a bug in ffdshow or in driver). But the movie is watchable. But I have to choose Ignore number of reference frames. Is this how is supposed to be? Or ffdshow must be able to detect if the driver is capable to decode 5.1 profile? And when ffdshow dxva will decode mpeg2?

[djesteban]

@djesteban
this might help:
Options -> Decoder options -> disable "Drop frame on delay"

Yeah, but that will just drop frames... do you know why it doesn't drop any frames with CoreAVC but doesn't play back smoothly with FFdshow?

[albain]

Request:
Any chance of FFDShow exposing an IAMStreamSelect interface (at least for subs)?

It already does

[albain]

Just installed rev 3383 from http://xvidvideo.ru/ and...
...stil not working, pressing CTR+ALT+F4/numpad 1 simply does nothing, no OSD, no strem switched.
Only for me? :/

Why do you have 3 activation keys ? Normally this is 2

For ex I mapped audio stream switching to "K" and when I do control+alt+K it switches audio stream

[albain]

Albain,

Thanks for looking at it, your right I just tested with powerdvd and the subs are yellow, in earlier ffdshow builds they were originally blue so I just figured something got messed up.

I forgot to mention that the subs are orange when using the YV12 or YUY2 output, using RGB32 output displays the subs yellow as you've said.

I tested this using rev 3370 from the xvidvideo website as it's the latest build that works with Blu-ray subtitles for me. I tested rev 3371 & 3373 but the subs just won't display when selected, dvd subtitles worked fine except for the problem with the Drunken Master sample.

You said the Blu-ray subtitles are working on your end so I'll wait for a new build to test.


FreeFall

You're right, in YUV mode they are orange I can reproduce that. This apart I don't have any other issues

[hoborg]

Why do you have 3 activation keys ? Normally this is 2

For ex I mapped audio stream switching to "K" and when I do control+alt+K it switches audio stream

I am not sure if i understand it correctly.
Default FFDShow activation keys are CTRL+ALT + mapped key.
For example CTRL+ALT+O to show/hide OSD, CTRL+ALT+S to show/hide subtitles. I have no problems with this (working fine).
But CTRL+ALT+F4 or CTRL+ALT+Nunpad1 simply does nothing for me, i tryed remap CTRL+ALT+F4 to CTRL+ALT+K, but still nothing (is there some OSD message about strem swithched?)

Here is my settings: (audio switcher/subtitles is enabled, testing Samurai Champaloo sample)
http://hobring.esero.net/saf/ffdshow/streams.png

[onomatopellan]

You're right, in YUV mode they are orange I can reproduce that. This apart I don't have any other issues
I have the same problem. Since rev3371 I can't see PGS bluray subtitles. Instead it shows NullTextRenderer at the top of filter list. :confused:
http://i43.tinypic.com/bi6on8.png

[XhmikosR]

@devs: I have updated libsamplerate to v.0.1.7 locally. The increase in the installer's size is ~800KB. Test binaries (x86 and x64) and the patch can be found here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335cae32d40843051dd14). The changelog for libsamplerate since 0.1.2 mentions:

# Version 0.1.3 (Mar 23 2008) Huge quality improvements to two best SINC based converters.
# Version 0.1.4 (Jul 02 2008) Fix segfault when using extremely low conversion ratios.
# Version 0.1.5 (Jan 11 2009) Optimisation resulting in dramatic throughput improvements ( See here (http://www.mega-nerd.com/erikd/Blog/CodeHacking/SecretRabbitCode/rel_0_1_5.html).).
# Version 0.1.6 (Jan 27 2009) Minor bug fix in test suite (account for rounding error on x86_64).
# Version 0.1.7 (Feb 14 2009) Fix a segfault bug. Fix compilation under MSVC.

What do you think? I mean, it's an important increase in size, but the changes sound very interesting.

[fastplayer]

Maybe you can compensate with a higher compression ratio in the installer?
LZMA2 was recently added to Inno.

[XhmikosR]

I've already tried it, no improvement unfortunately.

[clsid]

LZMA2 doesn't help much.

As usual I vote against the huge libsamplerate. Few people actually use it and most of them would probably not even hear a difference in a double-blind test.

[fastplayer]

I guess UPXing ff_samplerate.dll wouldn't make any difference too...

[tetsuo55]

the size increased because the current version was fundamentally flawed and the author had to refactor a large portion of code iirc

[Shark007]

@devs: I have updated libsamplerate to v.0.1.7 locally. The increase in the installer's size is ~800KB. Test binary based on r3387 can be found here (http://www.mediafire.com/?jugemjcjngk) and the patch is here (http://www.mediafire.com/?un0gju2itn0). The changelog for libsamplerate since 0.1.2 mentions:



What do you thing? I mean, it's an important increase in size, but the changes sound very interesting.

could you compile an x64 version for testing please?
Thanks in advance . . . (providing just the single dll would suffice)

[XhmikosR]

@Shark007: I updated my previous (http://forum.doom9.org/showthread.php?p=1396106#post1396106) post (both the binaries and patch). Keep in mind I haven't tested the x64 version at all since I don't have 64bit Windows.

[Sarasa]

I think I have a bug with the Resize & Aspect option

video size that don't work correctly : 400x300 / 480x352 / 512x384 / 576x432 / 640x480 / 640x496 / 704x512 / 1008x762
No problem with : 640x360 / 704x388 / 704x396 / 704x400 / 720x400 / 1008x560


Here is a test done with version 3387 and two video clip (640x480 / 704x396).
The parameter for Border are left with default option & setting > Lock / Bicubic
if I put this resize parameter
http://i43.tinypic.com/30963j7.jpg

The clip 1 is not resized right, has you can see the image has a black border.
http://i40.tinypic.com/6edizc.jpg
but clip 2 is resized correctly
http://i39.tinypic.com/2a9prbo.jpg

With this resize parameter
http://i41.tinypic.com/15e7hnq.jpg
It resize correctly the two clip
http://i41.tinypic.com/msbxy1.jpg
http://i39.tinypic.com/vxnec4.jpg


I'm doing something wrong or forgetting a option ? :confused: