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

[Marques Johansson]

On Wed, Jun 30, 2010 at 5:43 PM, Richard Kern <kernrj at gmail.com> wrote:
> What problems might this code or corresponding HTML cause?
> video.setSection(0, URL1, 0, 999999);
> video.setSection(1, URL1, 1000000, 2999999);
> video.setSection(2, URL1, 3000000, 5000000);
>
> Using your example below, the UA would send:
> GET http://example.com/video.webm HTTP/1.1
> Range: bytes 0-999999
> GET http://example.com/video.webm HTTP/1.1
> Range: bytes 1000000-2999999
> GET http://example.com/video.webm HTTP/1.1
> Range: bytes 3000000-5000000

This is fine when you are dealing with 3 predefined sections in the
same short video.

If the user is permitted to seek anywhere in the video then there are
countless (well, countable but I don't know how to express it
formally) sections available:

Range: bytes start-(start+requestsize)

Where:
 start = starting seek point
 requestsize = server-content-control-size
 filesize  = size of the webm file

Defining all of those possible <section> elements (I just realized you
are reusing an existing element - nice) would take thousands of bytes
in HTML or a good amount of memory if script created the same set of
sections.   Since, I don't care where the sections exist (so long as
they are accessed with a max request size) I suggested adding
attributes (ranges, maxrangelength) that would apply to the source or
video rather than the section.  Conceivably the same attribute could
exist for the sections.  The "ranges" attribute could be implied if
maxrangelength is given and may not have a reason to exist without
this attribute.

Having a maximum request size (along with a behaving UA no-cache
behavior) gives the server a viewer heart monitor - letting them know
that the viewer is still watching (they haven't paused, stopped, or
seek'ed elsewhere).  If the content can be cached then scripting in
the player would be needed to accomplish the same goal (albeit with
less certainty) because the UA would not seek for data is has already
fetched nor would the cache server (which also has the option of
reassembling the partial responses).

Maximum-look-ahead may be a better way to think of this. It is not the
same as a 'buffer' value which acts as a minimum-look-ahead.