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

RE: Track fragments

From: Davy Van Deursen <davy.vandeursen@ugent.be>
Date: Tue, 16 Feb 2010 09:04:14 +0100
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'DENOUAL Franck'" <Franck.Denoual@crf.canon.fr>
Cc: <public-media-fragment@w3.org>
Message-ID: <000c01caaede$a147f220$e3d7d660$@vandeursen@ugent.be>
Silvia, Franck,

On feb 15, 2010 at 22:23, Silvia Pfeiffer wrote:
> Cc: public-media-fragment@w3.org
> Subject: Re: Track fragments
> Hi Franck,
> In the W3C HTML5 Accessibility Task Force, which is a subgroup of the 
> HTML WG, we are right now working on a API for multitrack media files, 
> see http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI .
> Per track there will be the following attributes: name, role, type, 
> lang, enabled .
> Right now, the only interface we have regarded for track fragment URIs 
> is to address them by name - which is a name given by the creator of 
> the resource, i.e. it could be any random string.
> 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?

If we decide to add support for addressing multiple tracks, I think this
should be done based on a list of track names. Note that this is already
implemented within our NinSuna platform: when using track selection, we
mostly select more than one track using the 'tracks' selector:

http://example.org?track='track1' : to address one track
http://example.org?tracks='track1';'track2' : to address multiple tracks

> I actually have a an open issue at
> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4 about this, 
> which hasn't progressed because we haven't really reached discussions 
> about tracks yet - our focus so far was on the time dimension. It may 
> be a good time now to start discussions on other dimensions.
> 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 :-).

Best regards,


Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse
Received on Tuesday, 16 February 2010 08:04:21 UTC

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