[MPlayer-cvslog] r19162 - trunk/libmpcodecs/ad_hwmpa.c

[Reimar Döffinger]

Hello,
On Sun, Jul 23, 2006 at 10:48:18AM +0200, Nico Sabbi wrote:
> >I really don't think so, it is the number of bytes placed into buf, so
> >the old code was actually correct.
> 
> are you sure? even hwac3 works like the current hwmpa (returning teh 
> amount of
> "decoded" data corresponding to the amount of ac3 samples passed 
> through: 6144)

Well, I think so, since there is no other way to find out how many bytes
were placed into the buffer (and thus how many bytes must be copied
around e.g. in the filter chain).
Returning the amount of decoded data ends up in copying around a lot of
useless data.

> desync and excessive decoding (too many packets in the buffer stuff because
> sh_audio->pts was advancing much faster than sh_video->pts); the current 
> code

This in my experience is usually caused by a wrong value for get_delay
in the ao_ module.

> >Or how to reproduce without special hardware? 
> 
> -ao null exhibited the same behaviour

Which is no surprise:
> static float get_delay(void){
> 
>     drain();
>     return (float) buffer / (float) ao_data.bps;
> }

Unfortunately ao_data.bps is (AFAIK) set to
samplesize * samplerate * channels
which is obviously incorrect for compressed audio, and buffer contains
the number of not-yet-consumed bytes from the play function.
So changing in play
> buffer += bursts * ao_data.outburst;
to something that takes into account the size of the decoded MPEG frames
should work as well.
I am not sure that adding a special case for everything in ao_null is a
better solution than the current "hack" though.
And I have no clue at all how ao_mpegpes works, since its get_delay
always returns 0...

Greetings,
Reimar Döffinger