[MPlayer-dev-eng] [PATCH] use avcodec_decode_audio2

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Tue Mar 20 15:43:04 CET 2007


Hello,
[...]
On Tue, Mar 20, 2007 at 04:00:57PM +0200, Uoti Urpala wrote:
> On Tue, 2007-03-20 at 12:50 +0100, Reimar Döffinger wrote:
> > Sorry, previous patch was only correct on the first loop iteration,
> > attached one might actually be correct (though either is an
> > improvement over the current situation with no checking at all).
> 
> The current situation should be safe since dec_audio.c guarantees that
> maxlen >= minlen+sh_audio->audio_out_minsize. So decoders can safely
> ignore maxlen if they set audio_out_minsize to a suitable value.

I didn't mean to imply it is not safe, more like that it is suboptimal
that everything working right depends on half of mplayer.c being
correct.
Also maxlen >= minlen+sh_audio->audio_out_minsize is neither an obvious
condition nor one mentioned (in the almost non-existent) API
documentation, so any change that makes it work without this assumption
is an improvement...

> > Some testing would be welcome, since the function currently still
> > requires the buffer to be at least AVCODEC_MAX_AUDIO_FRAME_SIZE bytes
> > big whether the codec needs it or not it _might_ cause some regressions.
> 
> As explained above there should be no way for avcodec_decode_audio2 to
> get called with less buffer space than AVCODEC_MAX_AUDIO_FRAME_SIZE
> (unless some avcodec decoder now returns more data than that during an
> earlier call, but in practice even that would mean the loop just
> terminates because that amount of data would almost certainly be over
> minlen).

Well, there are always "if"s and "should"s. My feeling is that in this
case there are a few more than usual, and testing can't hurt. It's not a
big deal though.

Greetings,
Reimar Döffinger



More information about the MPlayer-dev-eng mailing list