[FFmpeg-cvslog] r19763 - trunk/libavcodec/wmaprodec.c
Tue Sep 8 16:31:39 CEST 2009
On Sun, Sep 06, 2009 at 11:48:10PM +0200, Laurent Aimar wrote:
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-cvslog