- 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>
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 -- 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