[Ffmpeg-devel] [PATCH] cook compatible decoder

mkhodor7 at yahoo.com mkhodor7
Tue Nov 8 18:41:46 CET 2005

Benjamin Larsson wrote:

> The real problem is the way cook is stored in rm. They store subpackets
> out of order. Realplayer reorders the subpackets in the demuxer. I
> did the reordering in the codec to simplify the demuxer layer. But to be
> able to know how to reorder I need 2 variables from the ra header. Those
> variables are added to the extradata and passed to the decoder. Currently
> 5 extra variables are passed, it could be reduced to 2 but it doesn't solve
> the problem of being able to mux cook into something else without
> cook specific code in the (de)muxer, if the codec reorders the subpackets.
> We could do it the way Realplayer does it, then we would only pass real
> extradata and let the demuxer reorder the subpackets. This way it might
> be possible to mux into another container without cook specific code.
> The rm demuxer would need a rewrite for it to work though.

This is a general problem with RealMedia.  The byte order in the 
container is not always the same as what the codec expects.

For example, with AC3 every pair of bytes is swapped.  The demuxer
swaps the bytes in rm_read_packet before sending the data to liba52.
With G.728 there is a more complicated rearrangement of the packets
(I don't think the current code actually works right.)

Anyway, the code should be consistent in where we do this.  If we're
going to reorder the dnet data in the demuxer to output standard AC3,
then we should reorder the 28_8 data in the demuxer to output standard 
G.728, and we should reorder the cook data in the demuxer to output 
whatever the cook codec expects.

I'm not sure exactly what Matroska does with this.  I believe that AC3
is converted to standard order and given the generic A_AC3 tag.
They don't have an ID for G728 so presumably this is stored in the 
original realnetworks format with the ID A_REAL/28_8.  It may be better 
to just leave it like that, since unlike AC3, I don't think anyone
actually uses G.728 outside of RealAudio.  Someone should write a spec 
for the cook extradata in Matroska and decide what the canonical packet 
ordering is.

More information about the ffmpeg-devel mailing list