ffdshow tryouts project: Discussion & Development

[BatKnight]

@tal.aloni

I've noticed that it might exist a cosmetic bug at the information that ffdshow audio decode shows.
Playing a DTS-ES 6.1 WAV file it should identify it as 7 channels but it shows like this:

libdts: 44100 Hz, 6 channels 1411 kbps dts (libdts)
libavcodec: 44100 Hz, 6 channels dts (libavcodec)

Another example:
- Playing WALL-E.1080p.BluRay.x264-HD1080.mkv which has a 6.1 DTS-ES Matrix track, ffdshow says on the input: 48000Hz 6 channels 1536 kbps (libdts). I can confirm it's a 6.1 track because I'm passing-it-trough via SPDIF and my external decoders tells me so.

I'm bringing this up because when decoding a 7.1 MLP file with libavcodec, for example, it correclty passes the information as 96000Hz, 8 channels mlp (libavcodec)

This bug also happens on 6.1 and 7.1 AC3 files and 7.1 DTS. It always shows only 6 channels.
Why doesn't fddshow always shows 6 channels for 5.1; 7 channels for 6.1 tracks and 8 channels for 7.1 tracks?

I am using ffdshow-mt 2351 build, but I've always noticed this since the times of the libavcodec branch development.

Bat

[clsid]

No, for Win98 support use VS2005 or VS2003
Well, the idea was to eventually remove support for VS2003/VS2005.

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.

[avivahl]

I'm using rev.2322 (13NOV2008) and I'm having some problems with ASS-subtitles. I believe this due to rev.2270.


Around a month ago I made a tutorial movie (ASS subtitle encoded on top of the video stream!)

Rendered with FFDShow rev.2322: (no settings were enabled under the "ASS/SSA config"-button)
http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.th.png (http://img253.imageshack.us/img253/9398/ffdshowrev2322asssubtitpe5.png)

Rendered with FFDShow rev.2054: (older version on my laptop)
http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.th.png (http://img117.imageshack.us/img117/5931/ffdshowrev2054asssubtitro1.png)

The actual subtitle line in the ass-file:
Dialogue: 0,0:02:48.48,0:02:55.52,Default,,0000,0000,0000,,{\pos(320,453)}You can find Avisynth
at {\c&H00FFFF&}http://avisynth.org{\c} and\Nclick the download-link in the upper left corner.
As you can see, the only break ("\N") comes after "and".
I haven't changed any settings compared to the older revision, so I'm wondering why FFDShow shows this behaviour.
Can this be fixed?
Maybe you have "Split long subtitle lines" checked? (under Subtitles->Text)
EDIT: Oh, I didn't notice the text shows up twice on the newer ffdshow. Looks like a bug.

[Px]

Well, the idea was to eventually remove support for VS2003/VS2005.

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.
Maybe, some final "stable" (not beta) build for Win98/ME? :)

[haruhiko_yamagata]

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.
Agreed.

[jamos]

With the latest beta build I can enable VC-1 video for the encoder but when loaded the video is distorted. In windows xp 32bit I do not get this issue with same build. Any clue on why in Vista 64 bit os it would be a problem?

using megui with FFdshow


thanks...

n/m Haali Media Splitter 1.7.401.3 works good in vista 64 with VC-1 files..Ill use that instead of FFdShow

[tal.aloni]

BatKnight, 6.1 AC3 and DTS show only 6 channels because that's what's being decoded.
the additional channels of DD Matrix / DTS-ES are not supported by ffdshow decoders.

[BatKnight]

BatKnight, 6.1 AC3 and DTS show only 6 channels because that's what's being decoded.
the additional channels of DD Matrix / DTS-ES are not supported by ffdshow decoders.
I see, so you mean that when Pass-through is selected the info provided by the ffdshow decoder is to be discarded, because there is no ffdshow internal decoding?
Wouldn't it be more accurate to present the info of the audio being passed-through? Because imagine this: if one wouldn't have an external decoder to provide the information of being a 6.1 track how would it be possible to know what is being passed-through via SPDIF if ffdshow shows the info as if it was itself decoding it?

Thanks in advance

Bat

[lych_necross]

We can't support those ancient OSes indefinitely. I suggest we finally make the step of discontinuing support for win9x.

I agree whole heartily. There is no need to support OSes that are approx. 10+ years old. In fact, removing support for Win9x based OSes will simplify the coding process and probably increase stability.

[tal.aloni]

I see, so you mean that when Pass-through is selected the info provided by the ffdshow decoder is to be discarded, because there is no ffdshow internal decoding?

True.


Wouldn't it be more accurate to present the info of the audio being passed-through?
but then you'll have to parse the audio, this is an unnecessary overhead. and even then, you'll have to recognize the track as 6.1, and since current decoders does not support it, you'll have to code you're own routine. this is too much work just for cosmetics.

[haruhiko_yamagata]

Good news,
Binary files of pthread libray for x64 is now online.
https://sourceforge.net/projects/mingw-w64/
Now I can build ffmpeg-mt branch for x64.

[Mercury_22]

Good news,
Binary files of pthread libray for x64 is now online.
https://sourceforge.net/projects/mingw-w64/
Now I can build ffmpeg-mt branch for x64.

FINALLY ! :thanks: I can't wait ! :helpful:

[KoD]

Bug report regarding wrong channel mapping when using libavcodec for DTS decoding:

1. one needs a file with multiple audio tracks, where the default audio track is DTS (like [CCCP]_Manhole_Test_Your_5.1_[revamped].mkv from here (http://www.cccp-project.net/beta/index.php?dir=test_files/), with a 5.1 DTS default audio track)
2. using Haali's splitter for splitting mkv
3. ffdshow audio configured to use libavcodec for dts decoding
4. doesn't matter if the mixer in ffdshow is enabled or not
5. the 5.1 dts audio track is played with wrong channel order: L is played on C, R is played on L, etc..

This doesn't happen if libdts is used instead of libavcodec.

Behavior experienced on ffdshow r2335, clsid's ICL10 build, ZoomPlayer 6 used as player.

[clsid]

DTS channel order was fixed at rev. 2340.

[Thunderbolt8]

So if you want to benchmark ffdshow vs. ffdhshow-mt on your local machine, download and use the timeCodec.exe (http://haali.cs.msu.ru/mkv/timeCodec.exe) tool and compare the "dfps" values.
is it possible to include the haali renderer there?

[haruhiko_yamagata]

FINALLY ! :thanks: I can't wait ! :helpful:
Well, can compile does not mean works stable...
But it's a step anyway.

[LoRd_MuldeR]

is it possible to include the haali renderer there?

Nope. Only VRM7, VMR9, Overlay Mixer and Old Renderer.

But the benchmark has to be done with the "Null" renderer anyways, since we won't to benchmark ffdshow and not a certain renderer ;)

If at all, the renderer would bottleneck the frame flow and distort your results...

[CruNcher]

im not sure if dfps is either a good measurement for null i guess real rendering time is the most efficient normal fps can also be funny with some decoder showing you 1000 of frames rendered which is impossible for the real render time :D :)
from my experience real rendering time never lies especialy when you compare very close results (CoreAVC,DivX) and can be nicely compared with mplayer -benchmark :)

[alexins]

Well, can compile does not mean works stable...
But it's a step anyway.

ffdshow-MT x64, libavcodec.dll compile without error, but does not work.

[Atak_Snajpera]

libavcodec can not decode this .mkv (vc-1) it works only when wmv9 is selected. Can I ask somebody to inform ffmpeg team about this.
http://www.mediafire.com/?ytesbxetzk4

[KoD]

DTS channel order was fixed at rev. 2340.

Thank you for the notice.

[haruhiko_yamagata]

libavcodec can not decode this .mkv (vc-1) it works only when wmv9 is selected. Can I ask somebody to inform ffmpeg team about this.
http://www.mediafire.com/?ytesbxetzk4I can tell you that ffplay does not play the file. Please submit a report directly.

[roozhou]

Then I calculated badly. But it's at least 160% faster.
Please remember to subtract decoding time.

rev2303:MMX-EXT
rev2307:SSSE3
rev2333:SSSE3 + 4 threads

On Core2 Quad,

MPEG-2 1080i, libmpeg2 yadif disabled
ffdshow_rev2333_20081117-mt.exe:User: 7s, kernel: 0s, total: 7s, real: 8s, fps: 158.8, dfps: 153.2 6.53ms/frame 0.00ms/yadif

Same file, yadif double frame rate
ffdshow_rev2303_20081106-mt.exe:User: 41s, kernel: 0s, total: 41s, real: 42s, fps: 29.2, dfps: 29.2 34.25ms/frame 27.72ms/yadif -> 100%
ffdshow_rev2307_20081107-mt.exe:User: 28s, kernel: 0s, total: 29s, real: 29s, fps: 42.3, dfps: 42.3 23.64ms/frame 17.11ms/yadif -> 162%
ffdshow_rev2333_20081117-mt.exe:User: 11s, kernel: 0s, total: 11s, real: 18s, fps: 109.3, dfps: 65.6 15.24ms/frame 8.71ms/yadif -> 318%

Well it is 60% faster, not 160%.

I tested it under mplayer and it should be more accurate.

E2160 1.8G
MPEG2 1440x1080i

w/o yadif:
mplayer -vc mpeg12 -vo null -nosound -benchmark -quiet -noaspect test.m2t

BENCHMARKs: VC: 2.747s VO: 0.000s A: 0.000s Sys: 0.376s = 3.123s

w/ yadif double-framerate:
mplayer -vc mpeg12 -vo null -nosound -benchmark -quiet -noaspect -vf yadif=1:0 test.m2t

MMX2:
BENCHMARKs: VC: 2.718s VO: 12.080s A: 0.000s Sys: 0.354s = 15.152s

SSSE3:
BENCHMARKs: VC: 2.726s VO: 9.465s A: 0.000s Sys: 0.498s = 12.689s

[haruhiko_yamagata]

I tested it under mplayer and it should be more accurate.
SSE2/SSSE3 optimization and multithreading of yadif are ffdshow original, mplayer does not have these code.
Your test is pointless.

[roozhou]

SSE2/SSSE3 optimization and multithreading of yadif are ffdshow original, mplayer does not have these code.
Your test is pointless.

I ported the SSE2/SSSE3 codes back and compiled mplayer myself.

You should test with the same svn build. Maybe the 60% speedup contains benefits from other optimization than SSSE3 of yadif.

And on AMD CPUs earlier than Phenom, MMX2 may be faster than SSE2. Hope you can test it on those AMD CPUs.

[haruhiko_yamagata]

I ported the SSE2/SSSE3 codes back and compiled mplayer myself.

You should test with the same svn build. Maybe the 60% speedup contains benefits from other optimization than SSSE3 of yadif.No, it's 60% faster on Core 2 Quad without multithreading or other optimization.
I don't know why it is only 27% faster for you.

And on AMD CPUs earlier than Phenom, MMX2 may be faster than SSE2. Hope you can test it on those AMD CPUs.I'm not interested in it.

Please don't reply to this post. Stop here.

[TheShadowRunner]

Hi All, I just attempted to upgrade to CLSID's latest icl10 build. I'm prompted to install "Microsoft Visual C++ 2008 SP1 Redistributable Package". I just would like to know if after installation it's safe to delete Microsoft Visual C++ 2005 Redistributable Package ? (ie, is the 2008 version going to replace the 2005 files or are these different files and I should keep 2005 too?)
Thanks for the info.

TSR

[fastplayer]

^Keep the 2005 redist, you never know what app might need em. The Redist files are installed side-by-side and don't overwrite anything.

[TheShadowRunner]

Exactly what i wanted to know, thanks.

[KoD]

I've also just attempted to upgrade to CLSID's latest icl10 build, and although I've got VS2008SP1 installed, I get the "MSVCR90.dll was not found" error message when trying to use ffdshow. Has someone tinkered with the manifest files ?

[LoRd_MuldeR]

Same problem here:

http://img155.imageshack.us/img155/59/ffdsinstallererrorym7.png

[TheShadowRunner]

Confirmed, same MSVCR90.dll error. XP SP3 with the "Microsoft Visual C++ 2008 SP1 Redistributable Package" installed.

Edit, contrary to LoRd, install went fine. It's upon using the codec that I'm getting the "MSVCR90.dll was not found" error.
Moving the dll to the ffdshow folder doesn't help either.

[fastplayer]

Has someone tinkered with the manifest files ?
AFAIK, they've been removed. Static linking is not 100% finished yet, too.

[KoD]

I didn't know it's possible not to use manifest files with these v7+ dlls from Microsoft. Usually the manifest files are loaded as a resource in the executable, though.

I've even tried editing the external manifest file, still no luck. Going back to an older version now.

Maybe this will help the developers: Why your application fails to load after building with a new version of VS? (http://blogs.msdn.com/vcblog/archive/2007/07/02/why-your-application-fails-to-load-after-building-with-a-new-version-of-vs.aspx).

[clsid]

A new ICL build will be online shortly. That will be linked statically. I have finished updating all project files.

Edit: build is online

[TheShadowRunner]

Thanks CLSID, installing now.

Edit: all good, works fine here, install and usage.

[LoRd_MuldeR]

Thanks CLSID, installing now.

Edit: all good, works fine here, install and usage.

Yup, works fine now :)

[clsid]

It would be interesting to see a benchmark between this new build (VS2008 static) versus one of my older builds (VS2003).

[LoRd_MuldeR]

Here you go:

E:\HD\palvik-Clip003 - Copy_001.mp4

[ffdshow r2335 ICL, 4 threads]
User: 1s, kernel: 0s, total: 2s, real: 18s, fps: 196.2, dfps: 23.0
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 177.9, dfps: 23.6
User: 1s, kernel: 0s, total: 2s, real: 17s, fps: 202.2, dfps: 23.7

[ffdshow r2373 ICL, 4 threads]
User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 111.7, dfps: 20.3
User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 111.7, dfps: 20.4
User: 3s, kernel: 0s, total: 3s, real: 18s, fps: 125.3, dfps: 22.0

[ffdshow-mt r2333, 4 threads]
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 278.0, dfps: 56.3
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 280.9, dfps: 56.4
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 242.6, dfps: 56.7

[Atak_Snajpera]

I can tell you that ffplay does not play the file. Please submit a report directly.
Where should i go with this file?

[LoRd_MuldeR]

Where should i go with this file?

http://ffmpeg.org/mailinglists.html

[LoRd_MuldeR]

According to the benchmark on my machine the latest ICL build is slightly slower than the previous one:
http://forum.doom9.org/showpost.php?p=1217432&postcount=5290

[tal.aloni]

I can definitely feel an improvement with audio processing.
Thanks clsid!

[clsid]

According to the benchmark on my machine the latest ICL build is slightly slower than the previous one:
http://forum.doom9.org/showpost.php?p=1217432&postcount=5290
Hmmm, that is a significant drop in performance. :eek: 7% when taking fastest values for both.

I shall make some additional builds of ffdshow.ax tomorrow for benchmarking. Maybe I can improve performance a bit.

[LoRd_MuldeR]

Hmmm, that is a significant drop in performance. :eek: 7% when taking fastest values for both.

Well, this was a test on one specific machines with one specific CPU type. You should get a few more tests from other people using different CPU types...

[Atak_Snajpera]

http://ffmpeg.org/mailinglists.html
Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429

[Eragon4ever]

bbc-japan_1080p.mov

[ffdshow r2335 ICL, 2 threads]
User: 179s, kernel: 0s, total: 179s, real: 198s, fps: 42.5, dfps: 38.4
User: 173s, kernel: 0s, total: 174s, real: 188s, fps: 43.8, dfps: 40.5
User: 171s, kernel: 0s, total: 171s, real: 177s, fps: 44.5, dfps: 42.8

[ffdshow r2373 ICL, 2 threads]
User: 165s, kernel: 0s, total: 166s, real: 172s, fps: 45.9, dfps: 44.2
User: 165s, kernel: 0s, total: 165s, real: 171s, fps: 46.1, dfps: 44.4
User: 168s, kernel: 0s, total: 168s, real: 182s, fps: 45.2, dfps: 41.8

[STaRGaZeR]

I've noticed something strage. With clsid builds, ICL and generic, playing Blu-ray videos results in ffdshow flagging progressive as progressive/interlaced in a regular pattern when AUTO is selected. It disappears obviously when force bob/weave, but the strage thing is that xvidvideo.ru builds don't have this issue whatsoever.

[MatMaul]

Reported!
ID 734 https://roundup.mplayerhq.hu/roundup/ffmpeg/issue?status=-1,1,2&@sort=-activity&@search_text=&@dispname=Show%20Unresolved&@filter=status&@group=priority&@columns=id,activity,title,creator,assignedto,status&@pagesize=50&@startwith=0&assignedto=429
I think this will just be ignored because your report does not seem to follow the rules stated here :
http://ffmpeg.mplayerhq.hu/bugreports.html

edit : I can't access the directory, I think it would be good to copy the description in the ticket

[Atak_Snajpera]

I think this will just be ignored because your report does not seem to follow the rules stated here :
I give up. Those rules are insane. Hack the address then do this , don't that ...

BTW. Looks like that libavcodec cannot decode interlaced vc-1 (I see horizontal lines in source)