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 13:43:22 +0200
Message-ID: <4DBFEA5A.7060408@ugent.be>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Media Fragment <public-media-fragment@w3.org>
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 ...

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse
Received on Tuesday, 3 May 2011 11:43:56 UTC

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