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

[Richard Kern]

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,
scripting could control the url, and bring up an "insufficient funds" or
similar frame, seamlessly.  The user would also be able to select a
different quality of video on the fly, without having the video reload.
 Another application is a playlist - if I wanted to post a video and "edit"
out or splice in certain parts, the modified version could be played
seamlessly and use the original files instead of using a newly encoded
video.

<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


In the case of specifying a section with start_offset="5000ms", it may not
be trivial for the browser to know how far to seek in order to start
playback at that time.  It may also be a problem for "end_offset" or in
Herman's case "buffer", because the browser would have to partially decode
the video stream in order to know how many frames have been downloaded.
 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.





On Wed, Jun 30, 2010 at 10:10 AM, Nicholas Stephan <
nicholas.stephan at gmail.com> wrote:

> I know some internet providers around the world are still charging by
> bandwidth. I'm sure those customers would appreciate not being sent, and
> charged for, content they don't even watch. An option to set the buffer size
> and a toggle to only preloaded the buffer rather than the whole video would
> go a long way to facilitate that.
>
>
>
>
> On Jun 30, 2010, at 8:40 AM, Marques Johansson <marques at displague.com>
> wrote:
>
>  This attribute fits in with what I was requesting last week.
>>
>> My server provides a pay-per-minute video-on-demand service.  I don't
>> want the browser to request more than I am going to send it and in
>> HTTP I have no way to tell the browser to use "Range: bytes 0-1000",
>> let alone "Range: 0-" (which my service would refuse to serve).   My
>> service would set the buffer attribute to an acceptable amount of time
>> that my service would essentially be giving the user for free
>> (something we already have to do in our Windows Media world).
>>
>> Along with this attribute, attributes to set the max fetch size and
>> the fetch style would serve my purposes very well.
>>
>> <video buffer="5000ms" partialrequestsonly maxpartialrequest="10000">
>>
>> These are horrible attribute names, but something like this would
>> avoid needing to change the HTTP spec to get the browser to use
>> "Range:" in requests and to set the upper bound for ranges.
>> _______________________________________________
>> Help mailing list
>> Help at lists.whatwg.org
>> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
>>
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100630/3320e6b4/attachment-0002.htm>