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

[Laurent Aimar]

Hi,

On Sun, Sep 06, 2009, Michael Niedermayer wrote:
> > 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.
> 
> i think theres nothing in the API that gurantees that the actual pointer is
> identical, though i cant really see a reason why it would change, xcept maybe
> someone using lav* through JNI from java that can do very slow and freaky
> things with arrays
 If such behaviour is kept, I would be great if it could be documented.

 For example, in VLC, it might change as we do a realloc to ensure that
FF_INPUT_BUFFER_PADDING_SIZE is present at the end (at each iteration). 
(We could avoid the realloc if it is needed)

-- 
fenrir