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

Michael Niedermayer michaelni
Thu Feb 12 12:34:06 CET 2009


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090212/1cdbc96f/attachment.pgp>



More information about the ffmpeg-devel mailing list