W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2011

Re: minutes of 2011-05-11 teleconference

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 31 May 2011 23:38:08 +1000
Message-ID: <BANLkTinY2q+iSYfYBrmQYOspOg-zPixktw@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: Media Fragment <public-media-fragment@w3.org>, RaphaŽl Troncy <raphael.troncy@eurecom.fr>
2011/5/31 Davy Van Deursen <davy.vandeursen@ugent.be>:
> On 27/05/2011 11:43, Silvia Pfeiffer wrote:
>>
>> Hmm... I wonder if the server knows how to map the chapter to time and
>> how to map time to byte ranges, why would it not immediately go from
>> chapter to byte ranges?
>
> Good question. I think we have the following two possibilities:
>
> 1) Redirect to a temporal fragment
> GET /video.ogv HTTP/1.1
> Range: chapter=chapter1
> =>
> HTTP/1.1 307 Temporary Redirect
> Location: http://www.example.com/video.ogv#t=10,20

.. and then leave it to the browser to request the appropriate byte
ranges? Hmmm...


> 2) Serve bytes
> GET /video.ogv HTTP/1.1
> Range: chapter=chapter1
> =>
> HTTP/1.1 206 Partial Content
> Content-Length: 3743
> Content-Type: video/ogg
> Content-Range: bytes 19147-22880/35614993
> Content-Range-Mapping: { chapter chapter1 } = { bytes 19147-22880/35614993 }
>
> You are right that, for the first case, the server needs to know the mapping
> between chapters and time ranges; while in the second case it is sufficient
> to have a mapping between chapters and byte ranges.
>
> I think that we should recommend the second case, but nothing prevents a
> server from following the first case.


I think in both cases does the server would need to know how to map
chapters to time ranges and it would certainly know how to map time
ranges to byte ranges. So, I guess the second one sounds more
realistic to me, though the first one is of course theoretically
possible.

Cheers,
Silvia.
Received on Tuesday, 31 May 2011 13:38:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC