ffdshow tryouts project: Discussion & Development

[tal.aloni]

With ffdshow-MT r2452 I get "slow motion" playback in DVBViewer, even when no filter is enabled!

this might be related to the compilation.

[avivahl]

Sometimes, when seeking a mkv file w/ AC3 I can hear little "clicks" (at the exact moment of seeking). This was verified by another person as well (he's on XP). It happens when using either liba52 or libavcodec.

ffdshow_rev2447_20081208_clsid.exe
ffdshow_rev2447_20081208_clsid_x64.exe
Vista x64 + SP1 + All Updates + Latest Drivers

Avi Vahl.

[LoRd_MuldeR]

With ffdshow-MT r2452 I get "slow motion" playback in DVBViewer, even when no filter is enabled!this might be related to the compilation.

I used "ffdshow_rev2452_20081208_xxl_mt.exe" from SourceForge site...


[EDIT]

The problem doesn't exist in "ffdshow_rev2447_20081208_clsid_sse_icl10.exe", but that one also has the "slow motion" problem with Yadif.

Again KernelBob works fine, so it can't be a 50 fps renderer problem.

[tal.aloni]

Sometimes, when seeking a mkv file w/ AC3 I can hear little "clicks" (at the exact moment of seeking).

this can be perfectly normal,
I wouldn't expect ffdshow to perform fading effects or decrease / increase volume....
do you have any audio filters / special settings turned on?

[avivahl]

this can be perfectly normal,
I wouldn't expect ffdshow to perform fading effects or decrease / increase volume....
do you have any audio filters / special settings turned on?I only have the Mixer filter on (which converts the 5.1 to 2.0). All the settings there are default.

Btw, after doing a clean installation w/ the default setup parameters, I could see that the "Normalize" in the Mixer tab isn't checked. But when I press the "Reset" button, it checks it (as if it was the default value). Are the defaults of the installation any different than the "Reset" ones? Is this inconsistency on purpose?

[Snowknight26]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.

[whurlston]

Some pieces of information:

... FWIW, here are the GUIDs used by Nero and ArcSoft splitters to signal TrueHD/MLP:

Nero: {1E889BE7-B276-4064-9A39-160A06895B52}
ArcSoft: {4288B843-610B-4E15-A53B-43007FCFF614}

IIRC PowerDVD uses just another GUID for TrueHD/MLP, but I don't know that right now. There doesn't seem to be a standard GUID for TrueHD/MLP, but every splitter seems to use its own GUID.


Arcsoft DTS-HD subtype: {F6498F57-B399-4A43-A6FA-F694AD42B9BE}

Cyberlink HD Audio major type (Used for DTS-HD and TrueHD): {43DC7A79-60B4-40B5-A3E7-963F9B35DC11}
Cyberlink DTS-HD subtype: {6A644687-5756-4D0D-8AA3-178ACF48DEC9}
Cyberlink TrueHD subtype: {2F02DABC-522A-4AAF-AE2C-43A54F29E919}

The Cyberlink demux only seems to expose the HD audio streams when playing a BD disc within PowerDVD.

[avivahl]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.Bug verified.

[whurlston]

Bug?

I cannot get ffdshow to autoload when rendering a media file with the Arcsoft Demux and a TrueHD audio stream. ffdshow is set to "Merit: very high" (0xffffff00) but the Arcsoft Audio Decoder HD loads every time (merit: 0x60000000). Both directshow apps I tested with are in the "Always use" list (I had to add one of them). It does work however if the audio stream is AC3.

[leeperry]

When playing a 23.976 fps H.264 stream, Movie FPS under Info & CPU jumps between 24.096 and 23.809 every 1 or 2 frames.
in a MKV container ?

[haruhiko_yamagata]

The problem doesn't exist in "ffdshow_rev2447_20081208_clsid_sse_icl10.exe", but that one also has the "slow motion" problem with Yadif.

Again KernelBob works fine, so it can't be a 50 fps renderer problem.Isn't any strange DirectShow filter added between ffdshow and VMR after moving the window?
Please make sure "Multiple ffdshow instance" is set to "only one -check all filters in graph".

[tetsuo55]

Use presets.

Imho using presets is not the best solution.

My suggestion will result in correct conversion for everyone in 99% of all cases without having to manually create presets every time

[STaRGaZeR]

Imho using presets is not the best solution.

My suggestion will result in correct conversion for everyone in 99% of all cases without having to manually create presets every time

I agree. Currently ffdshow uses BT.601 for everything by default. It would be better to use BT.601 for x<1280 or x<1025 and BT.709 for everything else automatically. Just like we have an Auto option for deinterlacing.

[haruhiko_yamagata]

I agree. Currently ffdshow uses BT.601 for everything by default. It would be better to use BT.601 for x<1280 or x<1025 and BT.709 for everything else automatically. Just like we have an Auto option for deinterlacing.
I agree. Simply add a radio button "Auto" (even without option) will help.
And H.264 has flag that indicates 601 or 709.
When I have time. And of course patches are welcome.

[leeperry]

sorry to repeat myself, Haruhiko....but do you think you could let the user choose how blurry he wants his subs ? :thanks:

[haruhiko_yamagata]

sorry to repeat myself, Haruhiko....but do you think you could let the user choose how blurry he wants his subs ? :thanks:I can do so, but its priority is not high.

[Kurtnoise]

@devs : what is the WAVE_FORMAT_xx type for eac3 streams ?

[Reino]

Today I updated to rev.2447 and I can confirm the ASS-subtitle problem I had here (http://forum.doom9.org/showthread.php?p=1216586#post1216586) is gone now.
Thanks!

[leeperry]

I can do so, but its priority is not high.
awesome! ideally I'd like to get very sharp subs..like most ppl using projectors on a large screen, they are pretty blurry atm :(

if you could also think about full blown OzoneMP support, that'd be so awesome :o

:thanks: for all your hard work Haruhiko http://forum.slysoft.com/images/smilies/bowdown.gif

[tal.aloni]

@devs : what is the WAVE_FORMAT_xx type for eac3 streams ?

sadly, the same as AC3 streams.
what are you building, Kurtnoise13?

[LoRd_MuldeR]

Isn't any strange DirectShow filter added between ffdshow and VMR after moving the window?
Please make sure "Multiple ffdshow instance" is set to "only one -check all filters in graph".

No, looks like this:

http://img116.imageshack.us/img116/5685/graphstudiora6.th.png (http://img116.imageshack.us/img116/5685/graphstudiora6.png)

Avisynth Yadif doesn't work either in latest builds. I'm now back at "ffdshow_rev2347_20081123-mt.exe", which seems to work good (internal Yadif and Greedy 2 Frame).

Something must have been broken after that build :confused:

[avivahl]

in a MKV container ?
Yes. I also noticed the "major" fps jumps in .mp4 files (shows "23.976 -> 24.xxx"; flickering as if the fps is changing every 10ms :/)
Even .avi files (some of them) show minor jumps in the "Info" panel. They show 23.976 which switches back and forth (flickering) to 23.975.
Happens in both x64 and x86 versions of ffdshow tryouts.

ffdshow_rev2447_20081208_clsid.exe
ffdshow_rev2447_20081208_clsid_x64.exe

[leeperry]

Yes. I also noticed the "major" fps jumps in .mp4 files (shows "23.976 -> 24.xxx"; flickering as if the fps is changing every 10ms :/)
Even .avi files (some of them) show minor jumps in the "Info" panel. They show 23.976 which switches back and forth (flickering) to 23.975.
well essentially MKV is not a fixed frame container, so it's quite normal that h264 MKV keep "bouncing" constantly...I also see it in HR's jitter in combination w/ Reclock, mind you :(

but mp4 has very stable jitter in HR, try to switch splitters maybe ?

try to remux your MKV sample file to TS/VOB, and I bet the frame rate will be rock stable in ffdshow ;)

[Snowknight26]

It also happens with m2ts files. It was fine with r2314 as the Movie FPS would always stay constant, but not anymore.

[leeperry]

It also happens with m2ts files. It was fine with r2314 as the Movie FPS would always stay constant, but not anymore.
good point, I just tried r2301 ICL10 w/ some HD bits and it's not drifting at all on 23.976 MKV :eek:

a wild guess would be that it was just giving the media info before, and now it's actually counting..only Haruhiko & clsid would know for sure :o

[avivahl]

good point, I just tried r2301 ICL10 w/ some HD bits and it's not drifting at all on 23.976 MKV :eek:

a wild guess would be that it was just giving the media info before, and now it's actually counting..only Haruhiko & clsid would know for sure :ohttp://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2456

[LoRd_MuldeR]

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

The "ffdshow_rev2460_20081209_clsid.exe" build still has the problem mentioned here (http://forum.doom9.org/showpost.php?p=1222356&postcount=5572) and here (http://forum.doom9.org/showthread.php?p=1222086#post1222086).

[whurlston]

Please forgive my noviceness but I don't know how to create a patch file. I was able to connect the audio decoder to the ArcSoft MPEG Demux with a DTS-HD audio track after making the following changes:

src/ffdshow_mediaguids.h : insert at line 393:
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DTSHD ,0xf6498f57, 0xb399, 0x4a43, 0xa6, 0xfa, 0xf6, 0x94, 0xad, 0x42, 0xb9, 0xbe);

src/TffdshowDecAudio.cpp : change line 215 (original line commented):
//else if (mt.subtype==MEDIASUBTYPE_DTS)
else if (mt.subtype==MEDIASUBTYPE_DTS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)

src/TffDecoder_reg.cpp : change line 439 (append comma and insert next line):
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_MLP },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DTSHD }

[tetsuo55]

Possible bug, can someone confirm?

When i enable post-processing and i choose the preset, cpu usage jumps to 100%

but when i manually max out the settings with custom cpu usage is 30%

[haruhiko_yamagata]

Possible bug, can someone confirm?

When i enable post-processing and i choose the preset, cpu usage jumps to 100%

but when i manually max out the settings with custom cpu usage is 30%
I can't reproduce. Could you show us the settings (Screen shot or exported preset settings)?

[haruhiko_yamagata]

No, looks like this:

http://img116.imageshack.us/img116/5685/graphstudiora6.th.png (http://img116.imageshack.us/img116/5685/graphstudiora6.png)

Avisynth Yadif doesn't work either in latest builds. I'm now back at "ffdshow_rev2347_20081123-mt.exe", which seems to work good (internal Yadif and Greedy 2 Frame).

Something must have been broken after that build :confused:
I have no idea where to start. Could you send me the debug output again?

[tetsuo55]

Just rechecked it and you need to enable "automatic quality control"

Ps its build 2364

Cannot get a screenshot right now.

All settings at default
Output set to "RGB32" HQ checked

Using libvacodec

Postproccessing checked
-Presets bulleted
--Automatic quality control checked
--mplayer checked

Unchecking automatic quality control brings the cpu usage back down

------------

PS
What does the level fix thing do and why do we need it?

[haruhiko_yamagata]

Just rechecked it and you need to enable "automatic quality control"
[...]
I still can't reproduce.
Windows GUI is very slow. If you leave the dialog open, it will use a lot of CPU.

[leeperry]

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2456
cool! thanks for the heads up

there's no >2456 ICL10 version from clsid yet(or MT version from XXL), so I'll try the generic builds to see how the jitter goes in HR w/ Reclock :)

[tetsuo55]

I still can't reproduce.
Windows GUI is very slow. If you leave the dialog open, it will use a lot of CPU.

Found out what was wrong.

there isn't really a 100% cpu usage.
I enabled the OSD and added to the default selection "CPU LOAD"

When automatic quality control is enabled, the OSD displays 100% and sporadically displays 0%.
The slider is constantly changing position and real CPU usage is only about 30%

Looks like the CPU load calulcation is breaking or something

[STaRGaZeR]

cool! thanks for the heads up

there's no >2456 ICL10 version from clsid yet(or MT version from XXL), so I'll try the generic builds to see how the jitter goes in HR w/ Reclock :)

The actual frame rate has been always the same, only the calculation shown in Info & CPU changed ;)

[leeperry]

The actual frame rate has been always the same, only the calculation shown in Info & CPU changed ;)
well ?

that tells me otherwise : "After seeking several frames may have inaccurate timestamps."

if you throw frames w/ wrong timestamps to HR, its jitter is gonna go nuts :devil:

[LoRd_MuldeR]

I have no idea where to start. Could you send me the debug output again?

I do when I get home tomorrow...

[haruhiko_yamagata]

Found out what was wrong.

there isn't really a 100% cpu usage.
I enabled the OSD and added to the default selection "CPU LOAD"

When automatic quality control is enabled, the OSD displays 100% and sporadically displays 0%.
The slider is constantly changing position and real CPU usage is only about 30%

Looks like the CPU load calulcation is breaking or something
Then it's a bug, ffdshow probably reads and clear the CPU usage twice per frame. Not very important though.

[STaRGaZeR]

well ?

that tells me otherwise : "After seeking several frames may have inaccurate timestamps."

if you throw frames w/ wrong timestamps to HR, its jitter is gonna go nuts :devil:

How about the rest?

frame rate calculation: fix compatibility issue with some splitters (matroska, flv)
Matroska and flv splitters round timestamps to milli-seconds. Thus frame rate calculation based on these timestamps has some error.
After seeking several frames may have inaccurate timestamps.

But go test it, you'll see how everything is the same.

[clsid]

@all

What are the remaining important bugs and regressions that need to be fixed for beta6?

[whurlston]

@all

What are the remaining important bugs and regressions that need to be fixed for beta6?

Would you mind adding this? http://forum.doom9.org/showpost.php?p=1222619&postcount=5579

[tetsuo55]

Then it's a bug, ffdshow probably reads and clear the CPU usage twice per frame. Not very important though.

It's actually more important than it seems.
Because if the miss-read CPU LOAD ffdshow is lowering the postproccessing settings for nothing

[clsid]

Would you mind adding this? http://forum.doom9.org/showpost.php?p=1222619&postcount=5579
Sure. Have you tested if ffdshow decodes correctly when connected to that splitter?

[whurlston]

Sure.Thanks.

Have you tested if ffdshow decodes correctly when connected to that splitter?

Yup. It decodes the DTS-Core only it seems but I expected that. It works using both libdts and libavcodec.

[MatMaul]

this one is still here but it is perhaps not a priority :
http://sourceforge.net/tracker/index.php?func=detail&aid=2298876&group_id=173941&atid=867360

EDIT : and here is a patch to enable 32bits output for flac when the bitdepth is superior to 16 (encoded from a bluray by eac3to for example)
Index: src/ffmpeg/libavcodec/flac.c
===================================================================
--- src/ffmpeg/libavcodec/flac.c (revision 2461)
+++ src/ffmpeg/libavcodec/flac.c (working copy)
@@ -611,7 +611,7 @@
const uint8_t *buf, int buf_size)
{
FLACContext *s = avctx->priv_data;
- int tmp = 0, i, j = 0, input_buf_size = 0;
+ int tmp = 0, i, j = 0, input_buf_size = 0, shift, offset_per_sample;
int16_t *samples = data;
int alloc_data_size= *data_size;

@@ -712,14 +712,31 @@
}
}
#else
+ avctx->bits_per_raw_sample = s->bps;
+
+ if (s->bps > 16)
+ {
+ offset_per_sample = 2;
+ avctx->sample_fmt = SAMPLE_FMT_S32;
+ shift = 32 - s->bps;
+ }
+ else
+ {
+ offset_per_sample = 1;
+ avctx->sample_fmt = SAMPLE_FMT_S16;
+ shift = 16 - s->bps;
+ }
+
#define DECORRELATE(left, right)\
assert(s->channels == 2);\
for (i = 0; i < s->blocksize; i++)\
{\
int a= s->decoded[0][i];\
int b= s->decoded[1][i];\
- *samples++ = ((left) << (24 - s->bps)) >> 8;\
- *samples++ = ((right) << (24 - s->bps)) >> 8;\
+ *(int32_t *)samples = (left) << shift;\
+ samples += offset_per_sample;\
+ *(int32_t *)samples = (right) << shift;\
+ samples += offset_per_sample;\
}\
break;

@@ -729,7 +746,10 @@
for (j = 0; j < s->blocksize; j++)
{
for (i = 0; i < s->channels; i++)
- *samples++ = (s->decoded[i][j] << (24 - s->bps)) >> 8;
+ {
+ *(int32_t *)samples = s->decoded[i][j] << shift;
+ samples += offset_per_sample;
+ }
}
break;
case LEFT_SIDE:

[tal.aloni]

I have commited the "DRC based on presets" patch as rev. 2467,
please note that AFAIK, DRC is not supported when working with DTS, both with libdts and libavcodec, I have tested AC3 successfully with both libraries.

there is another patch I have ready:
+ DRC slider added, this will allow to use dynamic range compression level between 0% to 100%.

two notes:
1. I had to patch liba52 to add this feature. (libavcodec have native support for custom DRC level)
2. although it sounds right, I'm not 100% sure about the accuracy of my method to calculate partial DRC in liba52.
here is the relevant line: (based on what I saw in libavcodec)

- state->dynrng = state->level * range;
+ state->dynrng = state->level * ((range - 1.0) * state->dynrngclevel + 1.0); //ffdshow custom code


patch:
http://iknowu.net/files/public/ffdshow/drc/2467-DRC_Slider.patch

build:
http://iknowu.net/files/public/ffdshow/drc/ffdshow_rev2467-DRC_Slider_20081210.exe

[haruhiko_yamagata]

It's actually more important than it seems.
Because if the miss-read CPU LOAD ffdshow is lowering the postproccessing settings for nothing
Only if both OSD-"CPU Load" and postprocessing "Automatic quality control" is enabled.
I'm afraid I can't fix all bugs. I have limited time.

[fastplayer]

Will Beta 6 be 32-bit only? Or: How complete are 64-bit builds currently?

[haruhiko_yamagata]

I'm not sure but perhaps 32-bit only.
64-bit builds are still experimental.