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

[Kostya]

On Thu, Feb 12, 2009 at 12:34:06PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 12, 2009 at 08:18:37AM +0200, Kostya wrote:
> > 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).
> 
> any permutation of finite elements can be achieved with a single pass of
> sequential reading and non sequential write

Of course - and this is how it works now: RM demuxer reads subpackets from
packet into temporary buffer in scrambled order and then sequentially demux
them. So I don't see a sane way to change the current code for them.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB