[Ffmpeg-devel] [PATCH] cook compatible decoder
Tue Nov 8 19:04:43 CET 2005
On Tue, Nov 08, 2005 at 06:41:46PM +0100, mkhodor7 at yahoo.com wrote:
> 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.
I don't care which the demuxer does as long as it uses a correct codec
tag (G728 if the order is corrected, 28_8 if it's not).
More information about the ffmpeg-devel