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

Michael Niedermayer michaelni
Wed Feb 11 19:54:33 CET 2009


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

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20090211/88e0d6f6/attachment.pgp>



More information about the ffmpeg-devel mailing list