[html5] Autoplay and preload insufficient for proper video playback.

[Marques Johansson]

On Wed, Jun 30, 2010 at 2:29 PM, Richard Kern <kernrj at gmail.com> wrote:
> If video were downloaded in sections, there could be a mechanism for telling
> the browser to wait for a certain number of sections to be downloaded before
> playback.  Also, if we had the option to specify a different URL/file offset
> for each section, that opens a few possibilities - in Marques's case,

Apple's solution involves a playlist file with .ts files that each
represent a few seconds worth of video.  I'm not a fan of cutting up
original seemless videos when these codecs were designed with
streaming in mind.

> <video>
>   <source min_buffer="1" max_buffer="2">
>      <section src="URL1"/>
>      <section src="URL2" start_offset="1000000bytes"
> end_offset="3000000bytes">
>      <section src="URL3"/>
>   </source>
> </video>
> or
> video.setSection(0, URL1);
> video.setSection(1, URL2, 1000000, 3000000);
> video.setSection(2, URL3);
> video.setMinBufferedSections(1);  //The first section must be completely
> downloaded before playback begins
> video.setMaxBufferedSections(2);  //The download will not be permitted to
> get more than 2 sections ahead

Sections like these would work to splice video from different sources
together.  My concern is with URL1 being used for each section rather
than URL1, URL2, and URL3.

My other problem with sections as you've provided them is that it
fills the document with unnecessary nodes.  In the case of a video
with 2-32 chapters / sections this would be fine, but realistically
every I-frame should be a section, allowing the user to seek a video
with very fine controls.  Needless to say, a video can have thousands
of I-frames.

I would be looking for something more like:
<source ranges maxrangelength="100000">
and
video.setRangedAccess(true);
video.setMaxRangeLength(100000);

This would prompt the UA to send:

GET http://example.com/video.webm HTTP/1.1
Range: bytes 0-99999

rather than the default behavior which seems to be

GET  http://example.com/video.webm HTTP/1.1
[ ... no range ...]

or

GET http://example.com/video.webm HTTP/1.1
Range: bytes 0-

The last two request methods are problems because the server has no
choice but to send the entire document to the client or respond with a
403 or 416 (to the Ranged request only).  These status codes are not
recoverable by the UA; there is no retry behavior or way to specify
what should have been different.  A 416 response can specify
Content-Range: */fullsize, but that won't change the client's Range
request behavior in terms of max requested range bytes.

The server would rather not reply with a 200 or a 206/Content-Range:0-
(essentially the same response) and keep the connection open for
throttling.. Likewise, the user would rather not be charged for more
video than they intend to watch.

In the real world a 307 redirect that specifies "Accept-Ranges: bytes"
will get some UAs to send a Range on the follow-up request, but the
range will be "Range: bytes 0-".  The server can also try to sneak a
206 response to an unranged request which seems to work against the
HTTP spec's terms.

If the HTTP spec expressly allowed a 206 response to contain less data
than requested and required the UA to follow-up with additional Ranged
requests I wouldn't be having this conversation.  When the server
responds with less than the full document Chrome users (and Opera Ogg
users(but not Opera webm)) will be happy because their browser will
continue to send Ranged GETs where the response left off.  Other
browsers will play the content provided in the short 206 response as
though it was a 200 or a 206 for the full length requested and stop
there.

>  Buffering from/to a specific time is still possible, but would require
> metadata correlating video time to file position.
> Searching to a random file address may also present a problem if it is not
> the address of an I-frame.  In this case the browser would need to continue
> seeking until it reaches a point it can decode from.

Chrome, as I have seen, fetches the beginning of a webm file and then
a block near the end of a webm file when it is made to request the
file with Ranges.  This seems like an obvious choice  for  <video
prefetch="metadata"> content but I have also seen it take this
behavior when given the URI to the direct video (or in my case a PHP
script that fseeks/fgets the range requested up to X bytes) which may
be related to the <video> element style controls they render for
videos with this mime-type.