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

[Zachary Ozer]

What no one has mentioned so far is that the real issue isn't the
network utilization or the memory capacity of the devices, it's
bandwidth cost.

The big issue for publishers is that they're incurring higher costs
when using the <video> tag, which is a disincentive for adoption.

Since there are situations where both the publisher and the user are
potentially incurring bandwidth costs (or have other limitations), we
could allow the publisher to specify downloadBufferTarget and the user
to specify a setting in the browser's config. The browser would then
actually buffer min(user setting, downloadBufferTarget). At that point
there would probably need to be another read-only property that
specified what value the browser is currently using as it's buffer
length, but maybe the getter for downloadBufferTarget is sufficient.

Best,

Zach
--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com • e: zach at longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution



On Mon, Jan 17, 2011 at 6: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.
>
>
>
> --
> Roger "Rescator" Hågensen.
> Freelancer - http://www.EmSai.net/
>
>