ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

Originally Posted by LoRd_MuldeR

No, looks like this:



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

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]

Originally Posted by tetsuo55

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]

Originally Posted by avivahl

http://ffdshow-tryout.svn.sourceforg...&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]

Originally Posted by haruhiko_yamagata

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]

Originally Posted by leeperry

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]

Originally Posted by STaRGaZeR

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

[LoRd_MuldeR]

Originally Posted by haruhiko_yamagata

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

I do when I get home tomorrow...

[haruhiko_yamagata]

Originally Posted by tetsuo55

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]

Originally Posted by leeperry

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

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]

Originally Posted by clsid

@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?...postcount=5579

[tetsuo55]

Originally Posted by haruhiko_yamagata

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]

Originally Posted by whurlston

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

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

[whurlston]

Originally Posted by clsid

Sure.

Thanks.

Originally Posted by clsid

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...41&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/ffdsh...C_Slider.patch

build:
http://iknowu.net/files/public/ffdsh...r_20081210.exe

[haruhiko_yamagata]

Originally Posted by tetsuo55

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.