W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

Re: ACTION-112 follow-up: Conrad's vs current's proposal for Media Fragment Processing

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 14 Dec 2009 14:42:23 +1100
Message-ID: <2c0e02830912131942r2a919641m9912a646c3d4e3c1@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:35 GMT