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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 3 May 2011 22:28:45 +1000
Message-ID: <BANLkTinHct+NJu_4-bmUC5Hq9RL=y05v4Q@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: Media Fragment <public-media-fragment@w3.org>
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?

Silvia.


>
> 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 12:29:28 UTC

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