[Ffmpeg-devel] [PATCH] cook compatible decoder

Rich Felker dalias
Tue Nov 8 06:35:11 CET 2005


On Tue, Nov 08, 2005 at 03:43:21AM +0100, mkhodor7 at yahoo.com wrote:
> Michael Niedermayer wrote:
> > On Sun, Nov 06, 2005 at 11:23:47PM +0100, Benjamin Larsson wrote:
> > > 
> > > The extradata handling has not been changed. The rm containter and codecs
> > > are not easy separated.
> > 
> > what exactly is the problem here? except the byte order of extradata, which 
> > seems a trivial thing to fix, just store the stuff in big endian order
> > instead of native or always little endian if you prefer
> 
> The issue is, if I extract the realaudio and remux it in MKV or
> whatever, the extradata should be exactly the same.  This doesn't work 
> if the demuxer is munging the data and reversing the byte order.

Let me clarify:

- If there is already a binary format for the extradata (the way it's
  stored in the actual files) then the demuxer MUST NOT do any munging
  of the data.

- If there is no preexisting format for the extradata, do something
  sane but consistent. This is what we did with vorbis where the xiph
  people failed to provide a sane way to store it. But again,
  extradata is considered a serialized form for storage. It does not
  contain host-order/host-aligned data!

> I see Michael has already shared some thoughts on this subject in
> libavformat/rm.c:
> 
> /* this is completly braindead and broken, the idiot who added this codec and endianness
>    specific reordering to mplayer and libavcodec/ra288.c should be drowned in a see of cola */
> //FIXME pass the unpermutated extradata
> 
> What's even more stupid about that is that ra288 doesn't really have any
> extradata.  There is actually only one way to decode it, so I don't know
> why the demuxer is adding extradata that doesn't really need to be
> there.  This code should just go away.

If this is the case then indeed it should...

Rich





More information about the ffmpeg-devel mailing list