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

Re: Track fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 16 Feb 2010 23:00:38 +1100
Message-ID: <2c0e02831002160400t786e4292lf37eeba4cdd6c03d@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: DENOUAL Franck <Franck.Denoual@crf.canon.fr>, public-media-fragment@w3.org
Hi Davy,

On Tue, Feb 16, 2010 at 7:04 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> On feb 15, 2010 at 22:23, Silvia Pfeiffer wrote:
>> It is possible do devise a track addressing method that includes some
>> of the other attributes. For example, a combination of type, role and
>> lang could make sense, something like:
>> #track=audio(audesc, en)&video(main,en)&text(cc,en)&text(sub,fr)
>> I just made this up, so feel free to suggest any other markup means.
> So 'audio(audesc, en)&video(main,en)&text(cc,en)&text(sub,fr)' corresponds
> to the trackname?

Nah, I did indeed mess this one up. "&" should not have been used
here, since it separates name-value pairs. You've used semicolon to
separate your track names, so this would be more appropriate:


and this would imply that the media resource has basically named the tracks:
* audio(audesc,en)
* video(main,en)
* text(cc,en)
* text(sub,fr)

They could just as well have been named
* a1
* v1
* t1
* t2
or anything else, but the idea is to explore if some scheme can be
found that helps addressing rather by features of the track than by a
generic name. I think this was what we meant by "default names".

>> One thing I need to add to this discussion is that track addressing
>> with *URI fragments* may be less about addressing and more about
>> activating. So, it interrelates very closely with the JavaScript API,
>> which is why I am waiting for that to stabilise and have some initial
>> implementations. This is certainly different if we use URI queries (?)
>> for addressing, since then we compose a new resource with just the
>> requested tracks.
> Do you mean by 'activating' that the server typically sends all the tracks
> to the UA? If so, than this might cause (bandwidth) problems when multiple
> video tracks are present within the media resource ... I don't see any
> difference between track and time fragments within the discussion of ? vs. #
> (do you?), so I think that track addressing with URI fragments is really
> about addressing :-).

The biggest issue with addressing tracks is that they tend not to
easily map to byte ranges - at least not to a small number. In fact,
they tend to map to a large number and it is almost impossible for the
client to know which byte ranges belong to which track (at least
within Ogg).

How did you implement it in NinSuna? Did you use "?" to compose a new
resource with the restricted number of tracks or did you use byte
range requests?

(No, I don't see a difference in the discussion of ? vs. # except as I
said in the number of byte range requests potentially necessary to
download a particular track).

Received on Tuesday, 16 February 2010 12:02:00 UTC

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