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

[Kostya]

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:
sp = number of subpackets in packet
np = number of packets in whole metapacket (usually 16)
p = packet number
s = subpacket number in packet
N = real subpacket number

N = np*s + (np + 1)/2 * (p&1) + p/2
 
> > 3. With AAC subpacket sizes may vary, so parsing records their sizes and
> >   they are used in cache() calls
> >   (i.e. parse() - read(), cache() - read(), cache() - read(), ...)
> > 
> > I just propose moving that reading from cache() back to parse(), so it
> > will be executed in the same flow.
> 
> but that flow is broken in old and new format, and i really dont see the
> advantage of this change
> 
> and again, if you can simplify the code (that implicates reducing the number
> of statements and lines) that is welcome.

Better nuke Real several times.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB