RE: Track fragments

Raphaël,

On feb 16, 2010 at 19:29, Raphaël Troncy wrote:
> Cc: 'Silvia Pfeiffer'; 'DENOUAL Franck'; public-media-fragment@w3.org
> Subject: Re: Track fragments
> 
> Hi Davy,
> 
> > 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
> 
> 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 :-)? The only reason was
that I wanted to keep the identifiers currently specified by the group as
they were. That can be easily changed of course, it's just a matter of
syntax sugar I guess. As a side note, similar to 'tracks', we also have the
'ts' identifier which can be used to identify more than one time range
(e.g., #ts=0,10;20,30) but I think multiple time ranges is less relevant for
us right now.

> 
> > Do you mean by 'activating' that the server typically sends all the 
> > tracks to the UA?
> 
> We might consider that in any case, the UA will receive a complete 
> media file containing all the tracks and will decide to play 
> (activate) some of these tracks specified in the URI.
> I see the use case, where a media file contains multiple video tracks, 
> has very borderline: how many files out there have such a property?
> 
> Serving only a number of tracks would be useful to save bandwidth if 
> the video track is not served (e.g. audio + audiovision + subtitle for 
> a blind user). But then, we would need a minus operator to tell the 
> server ... send me this media file except the video track. How to 
> express that?
> 
> So the more I think, the more I tend to agree with Silvia that in most 
> of the cases, we want to the UA to behave a certain way more than 
> complex processing on server side. In particular when the track 
> selection into a byte range request becomes a nightmare.
> I might be very wrong :-)
> My 2c.
> 

I also agree that in most cases of track fragment selection, it is likely to
have the full media resource at client-side. Therefore, I think we should
soon make a decision regarding which fragment axes are supported through
HTTP headers (temporal only?) and which are not (spatial, track, named?).

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 Wednesday, 17 February 2010 12:19:58 UTC