On Thu, 20 Jan 2011 19:16:21 +0100, Zachary Ozer <z...@longtailvideo.com>
wrote:
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt
<phil...@opera.com>wrote:
* effective state can only increase to higher states, never go from e.g.
metadata to none (it makes no sense)
What if my bandwidth situation improves (moving from 3g to WiFi, for
example)?
At that point, perhaps I should go from auto to invoked?
preload=auto is requested by the page author because they think they need
to buffer the whole resource ASAP. We could have a user preference to
ignore it, but I don't think we'd ignore it *dynamically* based on the
network conditions.
I seem to have caused some confusion by talking about both
author-specified and browser-internal buffering strategy with the same
terminology, in particular preload=invoked. From now on I'll try to use
preload=foo to mean only user-specified preload state, and strategy=foo to
mean the effective strategy used, which is affected by:
* the value of the preload attribute
* the value of the autoplay attribute
* user interaction (play/pause/seek)
== New Proposal ==
Based on the feedback we've gotten, I'd like to propose the following:
* Adding an additional preload state between metadata and auto (I'll
call it state3, but we should name it "invoked" or "buffer")
* Adding the "downloadTargetBuffer" property, which can be updated at
any time
=== Use cases ===
[snip]
This was a (quite sensible) description of buffering strategies, not use
cases or problem descriptions.
I agree that there must exist a buffering strategy between
strategy=metadata and strategy=auto, but it's not clear that this must be
exposed as a preload state. The only difference between preload=metadata
and preload=state3 would be that preload=state3 would expect the user to
start playing soon and start buffering in anticipation of that. Firefox
has supported preload=metadata (and earlier, lack of autobuffer attribute)
for a long time. Is it a problem in Firefox that playback is slow to start
because too little was buffered before suspending?
Much work is needed to improve the buffering behavior of <video>, but
mostly it's an implementation issue at this point. I'm quite open to
extensions to the API, but we must be careful to not make assumptions
about buffering strategies. Specifically, an exact downloadTargetBuffer
doesn't work very well when buffering is done in larger chunks using HTTP
byte range requests rather than some kind of TCP rate control.
It appears that what one would actually want from state3 is a (soft)
guarantee that if the users starts playing, the video can play through to
the end without waiting for the network. If that's the case, then perhaps
it should just be called preload=playthrough, without any detailed control
of min/max levels for buffering.
Are there use cases for author control of buffering levels other than
working around buggy browser buffering strategies?
--
Philip Jägenstedt
Core Developer
Opera Software
