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

[Richard Kern]

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.

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.

Below, you mentioned you had concern about reusing URL1.

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




On Wed, Jun 30, 2010 at 1:16 PM, Marques Johansson <marques at displague.com>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100630/08edd937/attachment-0003.htm>