- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 14 Dec 2009 14:42:23 +1100
- To: Yves Lafon <ylafon@w3.org>
- Cc: Raphaël Troncy <Raphael.Troncy@cwi.nl>, Conrad Parker <conrad@metadecks.org>, Media Fragment <public-media-fragment@w3.org>
2009/12/9 Yves Lafon <ylafon@w3.org>: > On Tue, 8 Dec 2009, Raphaël Troncy wrote: > >>> Basically I'm viewing things like "track=audio" the same way that >>> Language representations are handled. It works and it doesn't >>> interfere with caching. >> >> I like this argument. > > Yes, track=audio is not really a fragment, doing conneg on content is more > in order, in that case sending back a CL with a "?"-grade URI would be in > order. A note on the current spec: Right now I have treated "track=audio" as a range request, because a audio track is a set of byte ranges in a media file, thus it falls under the same conditions as other media fragment approaches. However, there is a big argument to be made for "track=audio" on a video file resulting not in another video file, but in an audio file and therefore being a different mime type and therefore needing to be done through a URI query rather than a URI fragment. OTOH, there are track-based fragments that do not change the mime type. Thus, I assume we will need to continue doing it for both URI fragments and URI queries. Let's discuss. Cheers, Silvia.
Received on Monday, 14 December 2009 03:43:16 UTC