[matroska-devel] Re: references, KaxCodecPrivate for Vorbis
steve.lhomme at free.fr
Fri Feb 28 16:32:25 CET 2003
> 1. References
> What exactly do references point to? Let's take the frame sequence "I1
> P1 P2 P3 I2". The two I frames do not have any reference of course. P1
> has a reference to I1, that's also clear. But which frame do P2 and P3
> reference? Their predecessors (e.g. P2 -> P1 and P3 -> P2) or the I
> frame they belong to (which would mean P2 -> I1, P3 -> I1)?
Well, I really don't know. Since Spyder is having a look at the MPEG specs, he's
probably the one to ask. Apparently a P frame just references the previous frame
(not a B frame BTW).
> 2. Storing the header packets for Vorbis in KaxCodecPrivate
> Just to let you all know what I'm talking about: Vorbis actually needs
> three packets in order to be able to decode everything: the headers, a
> comment packet and the codec setup data. The question is how to store
> these three independent blocks.
> Cyrius and I have discussed numerous approaches, e.g.
> - using more than one KaxCodecPrivate element (which is a violation of
> the current specs),
Not good ! There must be one per Track.
> - putting only the header packet into KaxCodecPrivate and the other two
> packets into the first two KaxBlocks as part of the normal data
That's possible. But actually the Codec setup need to be in the CodecPrivate
element, that's what it's made for (and probably the headers too).
> - putting all three packets into the one KaxCodecPrivate: we'd store
> the length1 (four bytes, little endian), packet1, the length2 (again
> four bytes, little endian), packet2, packet3 (the last packet's
> length can be calculated by KaxCodecPrivate's length - length1 -
That solution is OK.
> - putting all three packets into the one KaxCodecPrivate using the
> lacing mechanism.
That's also a good solution, but probably overkill :)
> Method three sucks because we introduce endianess dependencies that we
> don't have anywhere else (apart from BITMAPINFOHEADER/WAVEFORMATEX, but
> these only occur in MS compat mode).
Does ODD+Vorbis handle the endianess setting in ODD or in Vorbis ? If it's in
Vorbis then we don't need to care about it, it is probably part of the 3 packets.
> Method four is what we propose. Lacing is already described on the
> Matroska specs page, so we could simply point the user to them from the
> codec page.
But that won't solve the endianess problem... So it's still overkill. Maybe wit
lacing you would be able to save space... or not.
> Summary: Cyrius and I vote for using lacing. If no one objects we'd like
> to have the codec page updated with this information. I can provide the
> text for it if you'd like.
So you can update it. It's in CVS (and downloaded directly from there) ! Feel free.
More information about the Matroska-devel