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

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,

Davy

[1] 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#contentrangemappingheaderdef

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