Re: [ogg-dev] handling multitrack Ogg

On Tue, Feb 2, 2010 at 10:26 PM, [email protected]
<[email protected]> 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".
>

That was my first reaction, too. Have it there as an explicit field.

But it means that whenever we edit a video - cut out a track / add a
track - this field has to be rewritten.

Thus, it might be better if we used a more inherent order scheme that
doesn't require anything new in the stream.

We would, e.g. just need to prescribe that the order in which the bos
pages for the different tracks appear in the stream is also the
numbering order of the tracks. This won't break existing editing
approaches and doesn't require making changes to fields at the front
of the file when just oggz-merging or oggz-ripping. The bos order
right now is determined by the tools and the tools that I used kept
the given order and added any new tracks after the given ones. But
this would indeed be a behaviour that would need to be prescribed.

On the other hand, if there is a URL that points to e.g. the second
track in a video and the video is being changed on the server where
the second track is being replaced, then it points to the wrong track,
even though that track may still be available in the video file. This
wouldn't happen with an explicit reference.

We could just claim that the latter is unfortunate, but a problem of
the author / editor, who destroyed the links to the resource. Further,
if somebody wanted to really link to an explicit track, they could use
the serialnumber (however ugly it is). This will only break when the
video is edited and the serialnumber rewritten rather than when just
tracks are added/removed. I think this may be acceptable.

Cheers,
Silvia.