Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: DVD replay is unsmooth



On 22 Apr 2002 Andreas Schultz <aschultz@mail.CS.Uni-Magdeburg.De> wrote:

>> Well, if I understand the docs right, it should be better to
>> disable dynrng compression for normal living rooms. Don't get
>> confused by your reverse logic: if the setup option is disabled
>> (set to no) you are calling a52_dynrng with NULL callback which
>> in fact disables compression. Right?
> 
> well, i have take most of the code more or less straight from a52dec, the
> dynrng logic is the same as there. I belive that calling dynrng with NULL
> sets a flag that dynrng has already been done, an will therefore not
> happen again, which due to the NULL parameter will deactivate dynrng.

Well, now I'm getting confused :-(
The liba52 doc says:

--8<--
void a52_dynrng (a52_state_t * state,
                 sample_t (* call) (sample_t, void *), void * data);

This function is purely optional. If you dont call it, liba52 will
provide the default behaviour, which is to apply the full dynamic
range compression as specified in the A/52 stream. This basically
makes the loud sounds softer, and the soft sounds louder, so you can
more easily listen to the stream in a noisy environment without
disturbing anyone.

If you do call this function and set a NULL callback, this will
totally disable the dynamic range compression and provide a playback
more adapted to a movie theater or a listening room.
--8<--

This means if you do nothing compression is ENABLED. If you call
it with NULL compression is DISABLED.

In ca52.c you are doing:

if (!Setup.AC3dynrng)
    a52_dynrng (state, NULL, NULL);

This means if the setup option is set to NO (false) dynrng() is
called with NULL and compression is disabled. Seems to be fine.

And according to the liba52 doc, the prefered setting for a
living room should be OFF. ;-)

>> One more thing: while DVD playback is much better with the new
>> syncing method, some (may by all) VDR recordings starts to have
>> these video jumps with new syncing (and running fine with old
>> syncing). Seems that the syncing code still needs work ...
> 
> The syncing affects only pts generation for decoded AC3 frames, normal vdr
> recordings (without AC3 track) can't be affected, recordings with AC3
> tracks however could suffer.

As I said in another posting, I was talking about recordings with
AC3 only, of course.

> The solution for that should be pretty easy, i'll provide a patch as soon
> as my vdr box is running again.

Fine. Hurry up ;-)

-- 
Stefan Huelswitt
huels@iname.com  | http://home.pages.de/~nathan



Home | Main Index | Thread Index