- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 30 Apr 2009 23:15:10 +1000
> 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.
Received on Thursday, 30 April 2009 06:15:10 UTC