[whatwg] <video>/<audio> feedback

On Fri, May 1, 2009 at 2:25 AM, David Singer <singer at apple.com> wrote:
> 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


re c):
It depends on how the UA displays it. If the UA displays the 5s offset
as the beginning of the video, then the user cannot easily jump to 0s
offset. I thought this was the whole purpose of the discussion:
whether we should encourage UAs to display just the addressed segment
in the timeline (which makes sense for a 5sec extract from a 2 hour
video) or whether we encourage UAs to display the timeline of the full
resource only. I only tried to clarify the differences for the UA and
what the user gets, supporting an earlier suggestion that UAs may want
to have a means for switching between full timeline and segment
timeline display. Ultimately, it's a UA problem and not a HTML5
problem.

Cheers,
Silvia.

Received on Thursday, 30 April 2009 18:42:54 UTC