[whatwg] <video>/<audio> feedback

[David Singer]

At 23:15  +1000 30/04/09, Silvia Pfeiffer wrote:
>  > On Thu, 30 Apr 2009, Silvia Pfeiffer wrote:
>>>  > On Wed, 8 Apr 2009, Silvia Pfeiffer wrote:
>>>  >>
>>>  >> Note that in the Media Fragment working group even the specification
>>>  >> of http://www.example.com/t.mov#time="10s-20s" may mean that only the
>>>  >> requested 10s clip is delivered, especially if all the involved
>>>  >> instances in the exchange understand media fragment URIs.
>>>  >
>>>  > That doesn't seem possible since fragments aren't sent to the server.
>>>
>>>  The current WD of the Media Fragments WG
>>>  http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/
>>>  specifies that a URL that looks like this
>>>  http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21
>>>  is to be resolved on the server through the following basic process:
>>>
>>>  1. UA chops off the fragment and turns it into a HTTP GET request with
>>>  a newly introduced time range header
>>>  e.g.
>>>  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
>>>  Host: www.w3.org
>>>  Accept: video/*
>>>  Range: seconds=12-21
>>>
>>>  2. The server slices the multimedia resource by mapping the seconds to
>>>  bytes and extracting a playable resource (potentially fixing container
>>>  headers). The server will then reply with the closest inclusive range
>>>  in a 206 HTTP response:
>>>  e.g.
>>>  HTTP/1.1 206 Partial Content
>>>  Accept-Ranges: bytes, seconds
>>>  Content-Length: 3571437
>>>  Content-Type: video/mp4
>>>  Content-Range: seconds 11.85-21.16
>>
>>  That seems quite reasonable, assuming the UA is allowed to seek to other
>>  parts of the video also.
>>
>>
>>>  > On Thu, 9 Apr 2009, Jonas Sicking wrote:
>>>  >>
>>>  >> If we look at how fragment identifiers work in web pages today, a
>>>  >> link such as
>>>  >>
>>>  >> http://example.com/page.html#target
>>>  >>
>>>  >> this displays the 'target' part of the page, but lets the user scroll
>>>  >> to anywhere in the resource. This feels to me like it maps fairly
>>>  >> well to
>>>  >>
>>>  >> http://example.com/video.ogg#t=5s
>>>  >>
>>>  >> displaying the selected frame, but displaying a timeline for the full
>>>  >> video and allowing the user to directly go to any position.
>>>  >
>>>  > Agreed. This is how the spec works now.
>>>
>>>  This is also how we did it with Ogg and temporal URIs, but this is not
>>>  the way in which the standard for media fragment URIs will work.
>>
>>  It sounds like it is. I don't understand the difference.
>
>Because media fragment URIs will not deliver the full resource like a
>HTML page does, but will instead only provide the segment that is
>specified with the temporal region.
>http://example.com/video.ogg#t=5s  only retrieves the video from 5s to
>the end, not from start to end.
>
>So you cannot scroll to the beginning of the video without another
>retrieval action:

which is fine.  I don't see the problem;  given a fragment we
a) focus the user's attention on that fragment
b) attempt to optimize network traffic to display that fragment as 
quickly as possible

Neither of these stop
c) the user from casting his attention elsewhere
d) more network transactions being done to support this

>i.e. assuming we displaying the full video timeline for a <video
>src="http://example.com/video.ogg#t=5s"..> element, and then the user
>clicks on the beginning of the video, a
>http://example.com/video.ogg#t=0s request would be sent.
>
>The difference is the need for the additional retrieval action, which,
>if the full resource was immediately downloaded for
>http://example.com/video.ogg#t=5s would not be necessary. But that's
>not how media fragments work, so I tried pointing this out.
>
>Cheers,
>Silvia.


-- 
David Singer
Multimedia Standards, Apple Inc.