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

[Silvia Pfeiffer]

On Mon, Jan 17, 2011 at 7:19 PM, Roger Hågensen <rescator at emsai.net> wrote:
> On 2011-01-17 18:36, Markus Ernst wrote:
>>
>> Am 17.01.2011 17:41 schrieb Jeroen Wijering:
>>>
>>> We are getting some questions from JW Player users that HTML5 video is
>>> quite wasteful on bandwidth for longer videos (think 10min+). This because
>>> browsers download the entire movie once playback starts, regardless of
>>> whether a user pauses the player. If throttling is used, it seems very
>>> conservative, which means a lot of unwatched video is in the buffer when a
>>> user unloads a video.
>>
>> Could this be done at the user side, e.g. with some browser setting? Or
>> even by a "stop downloading" control in the player? An intuitive user
>> control would be separate stop and pause buttons, as we know them from tape
>> and CD players. Pause would then behave as it does now, while stop would
>> cancel downloading.
>
> I think that's the right way to do it, this should be in the hands of the
> user and exposed as a preference in the browsers.
> Although exposing (read only?) the user's preferred buffer setting to the
> HTML App/Plugin etc. would be a benefit I guess as the desired buffering
> could be communicated back to the streaming server for example for a better
> bandwidth utilization.


Most of the users will not notice what the browser is doing with the
video and whether it is buffering everything or not. Nor will they
understand what a buffer setting is or how to set it best. This really
isn't an issue of what the user wants, but it is about content
providers wanting to limit their bandwidth cost.

Assuming a browser is able to play back video in realtime, i.e. their
CPU and download bandwidth are sufficient to download video data at or
above the speed it is required in to provide continuous playback, we
can limit the downloaded data to a small amount. We do not need to do
a dependency on the possible playback speed as Petr is suggesting,
because our  required playback speed is always satisfied. With the
exception of a fast forward, maybe, but that may not be something we
want to worry about.

If a browser is, however, not able to play video back in realtime, we
have a different situation. If the CPU is the limiting factor, we can
download as much as we want - it won't help speeding up decoding. We
actually need to scale the video down and provide a lower bandwidth
version.

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.

Having thought this through (and assuming I didn't overlook anything),
I agree with Jeroen that a downloadBufferTarget attribute will help
the situation. That is: assuming the statistics API is being
introduced.

Cheers,
Silvia.