[ogg-dev] [theora-dev] handling multitrack Ogg

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Tue Feb 2 13:40:37 PST 2010

On Wed, Feb 3, 2010 at 1:54 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> Silvia Pfeiffer wrote:
>> I found out that the MPEG/QuickTime container format has an explicit
>> "track ID" that numbers its tracks.
>> The track order also determines the display order.
> ...
>> Further, MPEG/QuickTime has an explicit "alternate group ID". This ID
>> defines tracks that belong to the same group and can thus only be
>> displayed alternately of each other
> I think these are two good examples of what we _don't_ want.  The player
> should be able to decide whether to overlay a sign language track on top
> of the video, or to display it in a separate rectangle. Similarly, the
> player should be able to decide to display multiple subtitle languages at
> once, or play multiple audio tracks at once.  This is the nature of HTML:
> content is separate from presentation.

QuickTime doesn't force a player to use this information. But it needs
to be present, otherwise the player has no idea which information goes
on top of which other information, e.g. the caption track goes on top
of the video. Of course, the player is free to not do any overlaying
and draw separate display areas etc.

The issue is that this kind of information is not currently available
for Ogg tracks, so we need to add it to skeleton. What Conrad
expressed was also discussed briefly at FOMS - I just want to bring it
in front of more eyes and start putting the spec together.

>> I now wonder whether we need to introduce an explicit "track ID" into
>> Ogg, which will define a fixed order independent of the parsing system
>> and will allow us in JavaScript to directly address tracks.
> The ogg stream serial number is already such an explicit track ID.  Your
> proposed API should work fine; you just have to treat the tracks attribute
> as an associative array instead of an index array.  (Javascript
> associative arrays only support string keys, so you'll have to convert the
> track ID to a string, but that's fine.)  If MPEG streams use their index
> to specify overlay ordering then they can expose a "readonly attribute
> unsigned long altitude" (or whatever you want to call it).

Nobody wants to refer to such long numbers. They are also really hard
to "loop through". But I'll see what we come up with.


More information about the ogg-dev mailing list