[whatwg] <video>/<audio> feedback
silviapfeiffer1 at gmail.com
Thu Apr 30 06:15:10 PDT 2009
> 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
>> specifies that a URL that looks like this
>> 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
>> 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:
>> 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
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.
More information about the whatwg