[html5] Autoplay and preload insufficient for proper video playback.
mressler at gmail.com
Wed Jun 30 13:03:26 PDT 2010
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.
> <source min_buffer="1" max_buffer="2">
> <section src="URL1"/>
> <section src="URL2" start_offset="1000000bytes"
> <section src="URL3"/>
> 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>
>> 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
>> Help mailing list
>> Help at lists.whatwg.org
> Help mailing list
> Help at lists.whatwg.org
CEO and Founder
StatEasy by RessQ Technologies Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Help