[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