- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 4 May 2009 21:46:20 -0700
On Thu, Apr 30, 2009 at 6:42 PM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > 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. I think there are two use cases: 1. Wanting to start the user at a particular point in a video, while still showing the user that the full video is there. For example in a political speech you may want to start off at a particularly interesting part, while still allowing the viewer to "rewind" to any part of the speech in order to gain more context if so desired. This is very similar to how web pages work today if you include a fragment identifier. The UI accounts for the full page, but the page is scrolled to a particular part. 2. Wanting to only show a small part of a longer video. For example in the video containing a movie, it would be possible to link to a particular scene, with a given start and end time. The danger of only doing 2, even if it's possible somehow for the user to switch to make the UI display the full range of the movie, is that unless the UI is extremely obvious, most users are not going to see it. Or to put it another way. I think there is a use case for both linking to a specific point in a video file, as well to point to a range in it. Probably even a combination of the two where you point to a point inside a range. / Jonas
Received on Monday, 4 May 2009 21:46:20 UTC