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

On Mon, Jan 17, 2011 at 10:15 PM, Chris Pearce <chris at pearce.org.nz> wrote:
> On 18/01/2011 10:05 a.m., Silvia Pfeiffer wrote:
>>
>> If instead the bandwidth is the limiting factor, we do want to allow
>> buffering ahead a fair bit such that we don't end up in a "buffering"
>> state for the user too often. In this case, a dependency on the
>> playback rate as suggested by Petr might make sense. What we really
>> need though is to make the download buffer increasingly larger the
>> lower the available bandwidth and the higher the average bitrate of
>> the video. I believe we are starting to see such
>> measurements/statistics be introduced into HTML5 video, so these
>> should help Web authors set the correct download buffer size.
>>
>
> Perhaps we should only honour the downloadBufferTarget (or whatever measure
> we use) when the media is in readyState HAVE_ENOUGH_DATA, i.e. if we're
> downloading at a rate greater than what we require to playback in real time?
> That way we can afford to stop the download without introducing pauses to
> buffer more data, but we won't affect people on slow connections who want to
> buffer the media in its entirety in order to prevent pauses to buffer.

Hmm... it's certainly a necessary condition, but is it sufficient?

Probably if we ever end up in a buffering state (i.e.
networkState=NETWORK_LOADING and readyState=HAVE_CURRENT_DATA or less)
then we should increase the downloadBufferTarget or completely drop
it, since we weren't able to get data from the network fast enough to
continue feeding the decoding buffer. Even if after that we return to
readyState=HAVE_ENOUGH_DATA, it's probably just a matter of time
before we again have to go into buffering state.

Maybe it's more correct to say that we honour the downloadBufferTarget
only when the readyState is *always* HAVE_ENOUGH_DATA during playback?

Cheers,
Silvia.

Received on Monday, 17 January 2011 13:32:22 UTC