You bring up some good points - I appreciate the detail. In the typical "youtube" scenario, sections aren't necessary, and buffering could be limited to a defined number of bytes.<div><div><br></div><div>Perhaps "sections" is not the right concept for limiting playback. There is value in being able to change the video source client-side, however. More specifically, beyond playlists mentioned below, it would allow providers to seamlessly serve advertisements, interactive video, channel surfing, changing audio stream to a different language, multi-angle, etc.<br>
<div><br></div><div>Below, you mentioned you had concern about reusing URL1.</div><div><br></div><div>What problems might this code or corresponding HTML cause?</div><div>video.setSection(0, URL1, 0, 999999);<br>video.setSection(1, URL1, 1000000, 2999999);<br>
video.setSection(2, URL1, 3000000, 5000000);<br><br></div><div>Using your example below, the UA would send:</div><div><br></div><div>GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>
Range: bytes 0-999999</div><div><br></div><div>GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>Range: bytes 1000000-2999999</div><div><br></div><div>GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>
Range: bytes 3000000-5000000</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Wed, Jun 30, 2010 at 1:16 PM, Marques Johansson <span dir="ltr"><<a href="mailto:marques@displague.com">marques@displague.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Jun 30, 2010 at 2:29 PM, Richard Kern <<a href="mailto:kernrj@gmail.com">kernrj@gmail.com</a>> wrote:<br>
</div><div class="im">> If video were downloaded in sections, there could be a mechanism for telling<br>
> the browser to wait for a certain number of sections to be downloaded before<br>
> playback. Also, if we had the option to specify a different URL/file offset<br>
> for each section, that opens a few possibilities - in Marques's case,<br>
<br>
</div>Apple's solution involves a playlist file with .ts files that each<br>
represent a few seconds worth of video. I'm not a fan of cutting up<br>
original seemless videos when these codecs were designed with<br>
streaming in mind.<br>
<div class="im"><br>
> <video><br>
> <source min_buffer="1" max_buffer="2"><br>
> <section src="URL1"/><br>
> <section src="URL2" start_offset="1000000bytes"<br>
> end_offset="3000000bytes"><br>
> <section src="URL3"/><br>
> </source><br>
> </video><br>
> or<br>
> video.setSection(0, URL1);<br>
> video.setSection(1, URL2, 1000000, 3000000);<br>
> video.setSection(2, URL3);<br>
> video.setMinBufferedSections(1); //The first section must be completely<br>
> downloaded before playback begins<br>
> video.setMaxBufferedSections(2); //The download will not be permitted to<br>
> get more than 2 sections ahead<br>
<br>
</div>Sections like these would work to splice video from different sources<br>
together. My concern is with URL1 being used for each section rather<br>
than URL1, URL2, and URL3.<br>
<br>
My other problem with sections as you've provided them is that it<br>
fills the document with unnecessary nodes. In the case of a video<br>
with 2-32 chapters / sections this would be fine, but realistically<br>
every I-frame should be a section, allowing the user to seek a video<br>
with very fine controls. Needless to say, a video can have thousands<br>
of I-frames.<br>
<br>
I would be looking for something more like:<br>
<source ranges maxrangelength="100000"><br>
and<br>
video.setRangedAccess(true);<br>
video.setMaxRangeLength(100000);<br>
<br>
This would prompt the UA to send:<br>
<br>
GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>
Range: bytes 0-99999<br>
<br>
rather than the default behavior which seems to be<br>
<br>
GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>
[ ... no range ...]<br>
<br>
or<br>
<br>
GET <a href="http://example.com/video.webm" target="_blank">http://example.com/video.webm</a> HTTP/1.1<br>
Range: bytes 0-<br>
<br>
The last two request methods are problems because the server has no<br>
choice but to send the entire document to the client or respond with a<br>
403 or 416 (to the Ranged request only). These status codes are not<br>
recoverable by the UA; there is no retry behavior or way to specify<br>
what should have been different. A 416 response can specify<br>
Content-Range: */fullsize, but that won't change the client's Range<br>
request behavior in terms of max requested range bytes.<br>
<br>
The server would rather not reply with a 200 or a 206/Content-Range:0-<br>
(essentially the same response) and keep the connection open for<br>
throttling.. Likewise, the user would rather not be charged for more<br>
video than they intend to watch.<br>
<br>
In the real world a 307 redirect that specifies "Accept-Ranges: bytes"<br>
will get some UAs to send a Range on the follow-up request, but the<br>
range will be "Range: bytes 0-". The server can also try to sneak a<br>
206 response to an unranged request which seems to work against the<br>
HTTP spec's terms.<br>
<br>
If the HTTP spec expressly allowed a 206 response to contain less data<br>
than requested and required the UA to follow-up with additional Ranged<br>
requests I wouldn't be having this conversation. When the server<br>
responds with less than the full document Chrome users (and Opera Ogg<br>
users(but not Opera webm)) will be happy because their browser will<br>
continue to send Ranged GETs where the response left off. Other<br>
browsers will play the content provided in the short 206 response as<br>
though it was a 200 or a 206 for the full length requested and stop<br>
there.<br>
<div class="im"><br>
> Buffering from/to a specific time is still possible, but would require<br>
> metadata correlating video time to file position.<br>
> Searching to a random file address may also present a problem if it is not<br>
> the address of an I-frame. In this case the browser would need to continue<br>
> seeking until it reaches a point it can decode from.<br>
<br>
</div>Chrome, as I have seen, fetches the beginning of a webm file and then<br>
a block near the end of a webm file when it is made to request the<br>
file with Ranges. This seems like an obvious choice for <video<br>
prefetch="metadata"> content but I have also seen it take this<br>
behavior when given the URI to the direct video (or in my case a PHP<br>
script that fseeks/fgets the range requested up to X bytes) which may<br>
be related to the <video> element style controls they render for<br>
videos with this mime-type.<br>
</blockquote></div><br></div></div></div>