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

[Sascha Sommer]

Hi,

On Sonntag, 6. September 2009, Laurent Aimar wrote:
> 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)

Are you also doing this when the packet is not refilled in between e.g. when 
the returned number of bytes was smaller than the packet size? I think adding 
FF_INPUT_BUFFER_PADDING_SIZE for the first call should be enough then. Also 
you can change the buffer pointer whenever you pass in new data. It only is 
not allowed to change when the same packet contains multiple frames.

Regards

Sascha