Re: Track fragments

On 17 February 2010 21:19, Davy Van Deursen <davy.vandeursen@ugent.be> wrote:
> 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?).

why?

I don't agree with that. A use case might be that a UA requests a
subset of available tracks from the server, being only the tracks that
are intended for display. The UA might expect to save bandwidth by
downloading only the required tracks of the content.

Whether or not the transport of those tracks happens by direct HTTP
GET, or indirectly by a sequence of redirctions to byte-ranges, is
irrelevent to the naming of the server-side fragment.

Conrad.

Received on Wednesday, 17 February 2010 12:40:27 UTC