[whatwg] <video>/<audio> feedback

[Silvia Pfeiffer]

> 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:
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.