[FFmpeg-cvslog] r19763 - trunk/libavcodec/wmaprodec.c

[Sascha Sommer]

Hi,

On Sonntag, 6. September 2009, Michael Niedermayer wrote:
> On Sat, Sep 05, 2009 at 12:07:55PM +0200, faust3 wrote:
> > Author: faust3
> > Date: Sat Sep  5 12:07:55 2009
> > New Revision: 19763
> >
> > Log:
> > reduce output buffer needs
> > (fixes playback of some multichannel files)
>
> i would have thought that the decoder should always decode the smallest
> unit possible instead of decoding as much as fits in the buffer.
> The reason being amongth other things cache & latency ...
>

Changed.

> Also ive not checked it too carefull but returning 0 from decode packet
> doesnt look too correct to me if part of the packet has been decoded
>

The code works correctly with ffmpeg, ffplay and MPlayer. The question is if 
what I'm doing is allowed to be done or not.
The code is based on the assumption that decode_packet is called with the same 
packet as long as the packet is not fully decoded (the sum of all returned 
bytes from decode_packet is equal to the original packet size). This includes 
the precondition that no data is appended to it. Otherwise it would never be 
possible to decide where a new packet starts. So I think this assumption is 
save.

When this is really the same packet e.g. also the data pointer does not change
it is possible to reuse the bitstream reader for multiple decode_packet 
invocations.
Otherwise, the bitstream reader has to be reinitialized every time decode 
packet is called. This also means that it has to jump to the correct bit 
position as the start of the frames is not byte aligned what increases the 
complexity of the code.

Regards

Sascha