W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 18 Jan 2011 17:00:12 -0500
Message-ID: <4D360D6C.2000801@mit.edu>
On 1/18/11 4:37 PM, Glenn Maynard wrote:
> If you don't have enough bandwidth, then the necessary buffer size is
> effectively the entire video[1]

No, it's really not.  Your footnote is, of course, correct.

If my bandwidth is such that I can download the video in 2 hours, and 
it's one hour long, then letting me start playing after 1.5 hours of 
downloading seems perfectly safe to me, if the download speed is stable 
enough (has a 2x margin of safety).

If the download speed is not stable enough, then it doesn't matter 
whether on average you can stream the video, because the outliers will 
still kill you.

> Mikko seems to suggest that it's the
> entire video times some multiplier, where that multiplier can be
> discovered by binary searching.

The multiplier should just be a function of the ratio of the stream 
bitrate and the available download bandwidth if those are both constant.

But note that available download bandwidth is non-constant.  A number of 
cable services around here, at least, seem to do something where they 
give you N bytes per second for the first K bytes of a download 
(presumably that's a single connection, but who knows how they define 
it) and N/2 or N/3 or N/10 bytes per second for the rest of the 
download.  The connection is sold as an N/2 or N/3 or N/10 connection, 
not a connection that can actually produce N bytes per second.  But 
nevertheless, the average download rate will differ depending on the 
file size, and hence the multiplier is different for different file sizes.

Given that I think the random speedup bit is per-connection, I doubt 
that this can be discovered with some sort of binary search, though. 
Agreed on that.

-Boris
Received on Tuesday, 18 January 2011 14:00:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC