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

[Mike Ressler]

The UA is able to determine what Byte-Ranges to request when seeking to a
point in the video already, I'd imagine the same logic could be applied in
this scenario.  Sounds like the end_offset in time units might be a problem.

I know I'd make use of start_offset="50s" end_offset="70s" tags quite a bit
with the playlist use case you brought up.

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, 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
>>
>
>
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
>
>


-- 
Mike Ressler
CEO and Founder
StatEasy by RessQ Technologies Inc.
http://www.stateasysports.com
412-223-7377
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100630/3ff403df/attachment-0003.htm>