[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