[whatwg] Limiting the amount of downloaded but not watched video

On Thu, 20 Jan 2011 19:16:21 +0100, Zachary Ozer <zach at longtailvideo.com>  
wrote:

> On Thu, Jan 20, 2011 at 3:14 AM, Philip J?genstedt  
> <philipj at 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

Received on Saturday, 22 January 2011 02:57:29 UTC