[Vorbis-dev] Mapping = 1 Ambisonic Vorbis flag

[Silvia Pfeiffer]

On Sat, Sep 13, 2008 at 7:25 AM, Martin Leese
<martin.leese at stanfordalumni.org> wrote:
> Sampo Syreeni <decoy at iki.fi> wrote:
> ...
>> Third, Richard Lee's argument about ambisonic channel metadata carries
>> over to channel semantics in general: you need to know what each channel
>> means from the word go, so channel mappings need to be present in the
>> codec initialisation headers, and not, say, in Skeleton. Otherwise we're
>> going to experience delay before the channels can be played properly,
>> which isn't going to be appreciated by the better part of people who are
>> used to fast synch in DVDs, big screen movies, and indeed the other
>> container formats.
>
> No, the Skeleton stream comes ahead of all
> other streams.  (In Ogg-speak this is "chaining".)

No, it's not "chaining". For "chaining", all the logical bitstreams of
the current physical bitstream must be ended with the EOS page and
then a new Ogg bitstream is started consisting of "new" logical
bitstreams.

It is however true that Skeleton is a "header-only" logical bitstream
that has no data pages and its EOS page comes before any data page of
the other logical bitstream.

The order in which data is in the bitstream and expected to be parsed
is as follows:

1. Skeleton bos page
2. Bos pages of all other logical bitstreams
3. Secondary header pages of Skeleton
4. Secondary header pages of all other logical bitstreams
5. Skeleton eos page
6. any content pages of any logical bitstream

So, putting setup information into Skeleton is not going to delay your
encoding since Skeleton will be parsed before any of the codec
headers.

The decision of whether to put information into Skeleton or your Codec
header pages should be based on the answer to the question: assuming
you need to chop a temporal subsegment out of your Ogg physical
bitstream (e.g. from minute 5 to minute 6), does the data in skeleton
provide you all the information required to do a correct seek to the
byteoffsets of the logical bitstreamas from which and until which we
need to cut? If it doesn't, you havent put enough information into
skeleton.

Whether to replicate information already stored in Skeleton back into
the codec header is another issue. Old codecs' media mappings
obviously don't do it since skeleton had not been around when their
media mapping was defined. Newer ones could avoid duplication, but
have often chosen to keep a copy the same information in skeleton as
in codec packet headers. The advantage is that in your codec library,
you get all the information from the same location in the video file.
Duplication and therefore potential inconsistency is the other
argument.

You have to weigh all these issues for yourself to decide.

Cheers,
Silvia.