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

[Philip Jägenstedt]

On Sun, 23 Jan 2011 12:13:15 +0100, Glenn Maynard <glenn at zewt.org> wrote:

> On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt <philipj at opera.com>
> wrote:
>>> I do think that in the basic case of a user pressing play on a video
>>> player, it's good to be able to make that respond instantly rather
>>> than waiting for a round-trip to begin playing.
>>
>> Have you found this to be an actual problem in Firefox, which does  
>> suspend
>> download after reaching HAVE_METADATA?
>
> It's not a big problem, but a user experience one: user interfaces are
> cleaner when they're immediately responsive.  I'd sooner give a crisp
> interface to users than one that feels delayed.

Just to be clear, I'd be happy to add a fourth preload state to cater to  
this, I just want to be very clear that there is an actual problem first.

>>> Another use case is the background of a game, where you want the video
>>> ready to start when gameplay begins.
>>
>> For that you should really use <audio preload=auto>, no?
>
> Not if all you want is for the video to start with the rest of the game,  
> and
> not to download the whole video.

But presumably you want some kind of guarantee that the video will be able  
to keep playing without waiting for the network, right? So if you don't  
use preload=auto, you'll at least need preload=playthrough or similar.  
Maybe that's precisely what you mean by preload=buffer?

> They're both minor, of course; helpful side-effects of preload=buffer,  
> not
> sufficient justifications by themselves.
>
>
> Hmm.  To get this effect without preload=buffer, you could set  
> preload=auto,
> watch the buffered attribute to see when some data is actually  
> downloaded,
> then set it to preload=metadata to stop autoloading.  That's a minor  
> hack,
> and would need to watch out for browsers that don't autoload on
> preload=auto, but it's probably good enough for the above cases.  It'd  
> only
> work if runtime changes to preload are applied, which would also be  
> needed
> for scripts to implement "preload=auto only when paused".

I intend to make that impossible by only allowing scripts to increase the  
effective buffering strategy, because:

1. preload->none makes no sense.
2. I haven't seen any use cases for auto->preload other than working  
around browser buffering bugs.
3. It would be a silly API, because you can't reasonably mean "I need it  
all! No, I need only metadata! No, I need it all!", you're clearly trying  
to do something else.

By not catering to that, we can instead focus on fixing the  
API/implementations to support the actual use cases authors might have.

-- 
Philip Jägenstedt
Core Developer
Opera Software