- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 18 Jan 2011 10:02:40 +0100
On Tue, Jan 18, 2011 at 1:30 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 1/17/11 6:04 PM, Boris Zbarsky wrote: >> >> ?From a user's perspective (which is what I'm speaking as here), it >> doesn't matter what the technology is. The point is that there is >> prevalent UI out there right now where pausing a moving will keep >> buffering it up and then you can watch it later. This is just as true >> for 2-hour movies as it is for 2-minute ones, last I checked. >> >> So one question is whether this is a UI that we want to support, given >> existing user familiarity with it. If so, there are separate questions >> about how to support it, of course. > > I checked with some other users who aren't me, as a sanity check, and while > all of them expected pausing a movie to buffer far enough to be able to play > through when unpaused, none of them really expected the whole movie to > buffer. ?So it might in fact make the most sense to stick to buffering when > paused until we're in the playthrough state and then stop, and have some > other UI for making the moving available offline. I think that's indeed one obvious improvement, i.e. when going to pause stat, stop buffering when readyState=HAVE_ENOUGH_DATA (i.e. we have reached canplaythrough state). However, again, I don't think that's sufficient. Because we will also buffer during playback and it is possible that we buffer fast enough to have buffered e.g. the whole of a 10min video by the time we hit pause after 1 min and stop watching. That's far beyond canplaythrough and that's 9min worth of video download wasted bandwidth. This is where the suggested downloadBufferTarget would make sense. It would basically specify how much more to download beyond HAVE_ENOUGH_DATA before pausing the download. Cheers, Silvia.
Received on Tuesday, 18 January 2011 01:02:40 UTC