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

Re: Behaviour of Smart UAs vs. UAs that need server help in error cases

From: Davy Van Deursen <davy.vandeursen@ugent.be>
Date: Tue, 03 May 2011 16:03:33 +0200
Message-ID: <4DC00B35.6010504@ugent.be>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Media Fragment <public-media-fragment@w3.org>
On 3/05/2011 14:28, Silvia Pfeiffer wrote:
> On Tue, May 3, 2011 at 9:43 PM, Davy Van Deursen
> <davy.vandeursen@ugent.be>  wrote:
>> Silvia,
>> On 3/05/2011 13:28, Silvia Pfeiffer wrote:
>>> On Tue, May 3, 2011 at 9:12 PM, Davy Van Deursen
>>> <davy.vandeursen@ugent.be>    wrote:
>>>> Dear all,
>>>> another topic related to the test case discussions ...
>>>> The issue is about the case where we have an invalid media fragment URI,
>>>> but
>>>> that invalidity is only detectable by the UA if it has information
>>>> regarding
>>>> the source media (see [1] in the spec). For example: media.webm#t=15 and
>>>> the
>>>> duration of media.webm is only 10s.
>>>> Suppose we have a smart UA (i.e., scenario described in [2], only byte
>>>> range
>>>> requests are used). The smart UA is able to determine the duration of the
>>>> media, interprets the media fragment URI, and seeks to the end of the
>>>> media
>>>> (as discussed in [3]).
>>>> So far so good, but what happens when we have a UA using a media
>>>> fragments-enabled server (i.e., scenario described in [4], where time
>>>> ranges
>>>> are used)? The UA does not know the duration of the source media.
>>>> Therefore,
>>>> it just sends an HTTP Range request to the server:
>>>> GET media.webm HTTP/1.1
>>>> Range: t:npt=15-
>>>> Since the requested time range is invalid, the server answers with a 416
>>>> (Requested Range Not Satisfiable), and the UA still doesn't have a clue
>>>> about the duration of the media.
>>> An intelligent server should inform the UA with every request about
>>> the content duration, even if it is an error, shouldn't it?
>> Ok, for this example, sending the content duration would work. But consider
>> an example for the track dimension: media.webm#track=foo where foo does not
>> exist in the source media. The behaviour in this case is to ignore the
>> non-existing track fragment and thus playing the entire media resource. This
>> means that after receiving a 416, the UA must request the entire resource
>> ...
> Even then, shouldn't the server inform the UA of the available tracks
> and the UA should then not re-do the retrieval action?

No, not according to the current version of the spec (ABNF syntax for 
the content-range-mapping for tracks also confirms this [1]). The same 
holds for the id dimension.

Best regards,


Received on Tuesday, 3 May 2011 14:04:08 UTC

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