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

[Mikko Rantalainen]

2011-01-18 23:37 EEST: Glenn Maynard:
> On Tue, Jan 18, 2011 at 8:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> On 1/18/11 6:09 AM, Glenn Maynard wrote:
>>
>>> I'm confused--how is the required buffer size a function of the length of
>>> the video?  Once the buffer is large enough to smooth out network
>>> fluctuations, either you have the bandwidth to stream the video or you
>>> don't; the length of the video doesn't enter into it.
>>
>> The point is that many users _don't_ have enough bandwidth to stream the
>> video.  At that point, the size of the buffer that puts you in
>> HAVE_ENOUGH_DATA depends on the length of the video.
> 
> If you don't have enough bandwidth, then the necessary buffer size is
> effectively the entire video[1].  Mikko seems to suggest that it's the
> entire video times some multiplier, where that multiplier can be discovered
> by binary searching.  This doesn't make sense to me:

Perhaps my wording was not too clear but I was trying to say that (in
case of insufficient bandwidth), the required buffer is some multiplier
of full length of the video, not a constant time span. Obviously that
multiplier is always less than or equal to 1.0.

Example: User has viewed 8 video clips of one minute each. Video
playback statistics show that each video would have been viewable
without buffer underruns if the prebuffer had been at least 12 seconds.
This means that any new clip should be prebuffered at least 12/60 = 0.2
or 20% before the playing should start. As such, a one minute clip
should start with a 12 second prebuffering delay and a two hour movie
should start with a 2*60*60*0.2 or 1440 second delay.

In case of insufficient bandwidth, the required buffer size should be
always big enough to smooth out network fluctuations and as such should
only consider average bandwidth (which can be computed from statistics).
Obviously, any buffer short of 100% cannot smooth out total network
failure, which can obviously happen regardless of available bandwidth.
So either the UA must always buffer 100% of the video or it must be
ready to display an UI for the case that buffer underrun happens.

Notice that it really does not matter if the insufficient bandwidth is
because of user's network connection, CPU speed or something else. It
could be even HDD bandwidth bottleneck in the server's storage system. A
reasonably smart buffering in the UA should be able to deduce a suitable
buffer for such a system as long as the slow downs are not totally random.

I think a statistically valid method would be to first decide how often
it's acceptable to have a buffer underrun. If it's never acceptable, the
only logic you need to implement is to have 100% buffer. If it's always
acceptable (rare), the buffer should be set to 0%. Usually the suitable
buffer would be a static time span in case user has sufficient bandwidth
and a small (less than 1.0) multiplier of full length of the video in
case of insufficient bandwidth.

-- 
Mikko