[FFmpeg-devel] [PATCH] Handle AAC in RM similar to other audio codecs

[Kostya]

On Wed, Feb 11, 2009 at 07:54:33PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 11, 2009 at 10:06:33AM +0200, Kostya wrote:
> > On Sat, Feb 07, 2009 at 01:56:21PM +0100, Michael Niedermayer wrote:
> > > On Sat, Feb 07, 2009 at 10:25:09AM +0200, Kostya wrote:
> > > > On Fri, Feb 06, 2009 at 11:34:05PM +0100, Michael Niedermayer wrote:
> > [...]
> > > >  
> > > > > and about rewriting from scratch, first you have to understand the code
> > > > > to judge that it is worse than what you have in mind.
> > > > 
> > > > For now we have three approaches in the code:
> > > > 1. Video frame approach - if not all data is read from the current packet,
> > > >   rm->remaining_len is set to the length of the leftover and in the next
> > > >   pass demuxer continues from that position with the same stream parsing
> > > >   that packet. (i.e. parse() - read(), parse() - read(), ...)
> > > 
> > > > 2. Most RM audio codecs (with fixed frame size) allocate temporary buffer
> > > >   at start, during parsing frame read all data there at once and memcpy()
> > > >   from there during subsequent calls
> > > >   (i.e. parse() - read(), cache() - memcpy(), parse - read(), ...)
> > > 
> > > getting rid of this memcpy is welcome
> > 
> > Err, the reason behind memcpy was simple and stupid as RM format - for some
> > codecs like Cook each packet stores some subpackets but you have to read
> > several packets and reorder subpackets inside them by very idiotic formula:
> 
> one can read directly into the right pos of the right packet

Not without extensive seeking - first subpacket is stored in the first packet
but the next subpacket will be stored in usually 8-th packet (and 8-th subpacket
is in the second packet then).
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB