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

Reply via email to