On 2 February 2010 20:26, ogg.k.ogg.k at googlemail.com
<ogg.k.ogg.k at googlemail.com> wrote:
>> Right now, I can see two different systems: the order in which their
>> BOS pages are given in the Ogg header part - or the order in which the
>> serial numbers go, when ordered. Alternatively, we can introduce an
>> explicit track ID and order by that number.
>> If one reencodes an Ogg stream (eg, using a video editor, etc), the
> serial numbers and BOS ordering might change.
>> There are no tools that I know of that allow ordering BOS pages in a
> specific order, so that'd have to be created, and all writing programs
> would have to be made to preserve ordering.
>> Ordering by serial numbers, even assuming they do not change, will
> give you an arbitrary ordering (as serial numbers are most often
> random to avoid collisions when merging with another file), which
> conflicts with an author specified ordering.
>> Such an ordering is a property of the whole stream, rather than its
> individual constituent logical streams. Indeed, it may change if you
> remove/add streams, while the constituent streams will stay unchanged.
>> Thus, I think such an ordering may be best done as a specific property
> placed in the fishead for this particular stream, eg "Track-ID: 5".
I agree -- the serialno is really a lower-level attribute to
differentiate logical bitstreams (tracks) and physical bitstreams
(chain links) when a totally new serialno is seen. It is defined in
the original Ogg spec to have the role of avoiding collisions, and is
recommended to be random. It will be regenerated when content is
re-encoded -- eg. if multiple representations of a resource exist
(such as versions with different bitrate).
What is really needed here is a higher-level description of the roles
of each track. I think the attributes Silvia has described are the
right kind of thing, and we should introduce a mapping in the fisbone
from such roles to the particular serialno. Fisbones are already a way
of describing a particular serialno, so the first thing is to describe
these roles in the fisbone.
I'm not convinced that numeric identifiers are what we need though --
they imply a global structure of a file. For things like graphic
rendering order, perhaps we would be better off labelling one track as
"base" and another as "blend ontop of base". This pair of tracks could
be ripped out and re-encoded without affecting the labelling of
unrelated tracks like audio.
As for alternates, our previous discussions regarding mapping of ROE
into skeleton were to allow multiple tracks to each claim to Provide a
feature (eg. Provides: subtitle) such that a player would choose one
of those tracks based one some other criteria like Language.
The general idea here is to avoid having a global table of groupings,
but to have the equivalent information distributed through the headers
for each track. The purpose of that is that a single track could be
removed from or added to a file without rewriting the information for
the other tracks.
Conrad.