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
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.
--
David Singer
Multimedia Standards, Apple Inc.
