[matroska-devel] Re: references, KaxCodecPrivate for Vorbis

[Steve Lhomme]

> 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
>   stream,

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 -
>   length2),

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.
http://www.matroska.org