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

[Sascha Sommer]

Hi,

On Dienstag, 8. September 2009, Michael Niedermayer wrote:
> On Sun, Sep 06, 2009 at 11:48:10PM +0200, 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.
>
> patch welcome
>

Sorry for the delay. I submitted a patch to ffmpeg-devel.

Regards

Sascha