[whatwg] <video>/<audio> feedback

[Silvia Pfeiffer]

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.