- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 3 May 2011 22:28:45 +1000
- 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