W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2010

Re: Track fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 18 Feb 2010 10:38:49 +1100
Message-ID: <2c0e02831002171538u3a74ad66s10492fcb139b4826@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
2010/2/18 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
>>> Why do you use 'tracks' instead of 'track'?
>>> What prevent you to use: #track='track1'&track='track2'?
>> Because that might not be compliant to our grammar :-)?
> Well, we don't consider 'tracks' with an 's' either in the grammar :-)
> We have discussed in today's telecon that we would not like to allow
> something like: <uri>#t=30,90&t=10,15. More generally, we don't want that
> the time or the space dimension is specified more than once in the fragment
> because we don't want to bother trying to understand what does it mean. The
> question remains for the track dimension, since it is reasonable to restrict
> a media file to a number of tracks.
> I see (at least) two points to resolve:
> †- What are the changes we need to make (if any) in the grammar to allow a
> selection of multiple tracks in a fragment? Silvia has proposed:
> #track="audio(audesc,en);video(main,en);text(cc,en);text(sub,fr)" ... a
> semi-colon separator

Nah, replace the semicolon with a comma - we haven't got the comma as
a separator in our spec.

Also, it's not a proposal - it's a brainstorm for how to do "standard"
track naming in a sensible manner. It may not be sensible at all.

> †- What is the semantics of the fragment when one or multiple tracks is
> specified in a fragment? Does it mean *only* the tracks selected explicitly
> in the fragment? In other words: #track="audio(audesc,en);text(sub,fr);"
> will not contain video but just an audio and subtitle tracks?

Franck suggested an additional marker for "includes" and "excludes".
Interesting idea...

Received on Wednesday, 17 February 2010 23:39:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC