Re: video use-case

On Wed, Oct 8, 2008 at 10:52 PM, Yves Lafon <ylafon@w3.org> wrote:
> On Wed, 8 Oct 2008, Silvia Pfeiffer wrote:
>> On Tue, Oct 7, 2008 at 6:10 PM, Yves Lafon <ylafon@w3.org> wrote:
>>> On Mon, 6 Oct 2008, Silvia Pfeiffer wrote:
>>>
>>>> My understanding of the URI RFC (now at
>>>> http://www.ietf.org/rfc/rfc3986.txt) is that a fragment is a secondary
>>>> resource that is addressed through the primary resource. For something
>>>> like http://www.example.com/text.html#id12345 the primary resource is
>>>> a html page. Seeing as the URI RFC states that the fragment is not
>>>> being communicated to the Web server, but only handled within the UA,
>>>> this request will always mean that a Web server will return the full
>>>> html page and the UA has to do something with the fragment.
>>>
>>> But what prevent the client to issue a something like a range request, if
>>> it
>>> is easy to figure out a way to request the fragment you need?
>>
>> After the time range has been communicated to the server and the
>> server has told the User Agent which byte ranges to get, it is indeed
>> possible to get the fragment through a range request. However, we
>> first need to communicate the time range to the server (as discussed
>> with Dave).
>
> Well, Range requests are for now defined as using byte ranges, but it is
> extensible, nothing prevents the creation of custom range units, like
> seconds, absolute time ranges, or whatever useful.

Thre's still the issue of dealing with time ranges in Web proxies who
should not have to deal with the whole complexity of media formats and
who will not be able to know for individual files how to map time to
byte ranges. Ultimately, byte ranges are the only way of safely
determining whether the Web proxy has all the bits it needs to hand on
the data to the client or not. The biggest problem here being that
time is inherently inaccurate (for being essentially a floating point
number) while bytes are accurate (for being an integer). So, if you
are asking for times 1:23-1:45.32 and then 1:45.33-1:56 in two
fragment requests, it is somewhat impossible for the Web proxy to know
whether that is enough data to compose 1:23-1:56 or whether it has
accidentally missed or duplicated a few dozen bytes because they fell
into the gap between the two segments because the time resolution
cannot be made completely accurate for media resources.


>>> # can work, but the UA has to be aware it is dealing with video and a
>>> fragment inside this video, in that case it can optimize its requests to
>>> the
>>> server.
>>
>> "#" cannot work for communicating the time range to the server. "#" is
>> stripped off before it reaches the server. "#" only works in
>> communicating a time range to the UA. As explained above and in the
>> long discussion with Dave, that is insufficient.
>
> No, but the UA can see there is a #, and using the context of the request,
> do the relevant HTTP request to get only what's needed. There is no need to
> always delegate the processing to the server, one because it avoids a round
> trip,

I can see the advantages of avoiding the round trip and it will indeed
work for MP4 and specific versions of MOV and a few other formats
(e.g. SUN audio). But it won't work for generic media resources. I
would regard this case as optimisation potential for specific media
types that a UA may decide to implement.

> second because you still have to process something client-side (in
> that case parse a custom header to generate an HTTP byte range request), if
> you are using the two requests solution.

Yes, there will be a small amount of processing required client-side,
but it is common across all media types. Thus, if you implement it
once, it will work forever, even if a new media type is suddenly
invented (which happens frequently with audio and video). In contrast,
the server already has to provide all sorts of custom code that is
media type dependent, such as custom multiplexing upon track
selection, or such as custom fragment extraction for actual completion
of the URI fragment request. So, a custom server module needs to be
implemented for new media types anyway. If we can avoid having to
implement custom UA code for new media types, it will be a big
advantage.

Cheers,
Silvia.

Received on Wednesday, 8 October 2008 13:45:24 UTC