On Wed, 19 Jan 2011 10:42:01 +0100, Aryeh Gregor
<simetrical+...@gmail.com> wrote:
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
<jer...@longtailvideo.com> wrote:
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.
A lot of people are complaining about this right now, and it needs to
be addressed, but nothing I've seen makes it clear that it's a spec
issue rather than QoI. I.e., will this still be a problem once all
browsers reliably implement preload="" and iron our their video fetch
behavior a bit more? Are non-Mozilla browsers working on preload=""?
I'm working on <video preload> right now, so have had reason to think a
lot about this recently. At first sight exposing something like
downloadBufferTarget seems quite reasonable, but things are complicated,
as usual...
== Preload States ==
The 3 preload states imply 3 simple buffering strategies:
none: don't touch the network at all
preload: buffer as little as possible while still reaching readyState
HAVE_METADATA
auto: buffer as fast and much as possible
However, the state we're discussing is when the user has begun playing the
video. The spec doesn't talk about it, but I call it:
invoked: buffer as little as possible without readyState dropping below
HAVE_FUTURE_DATA (in other words: being able to play from currentTime to
duration at playbackRate without waiting for the network)
== Bandwidth Management ==
If the available bandwidth exceeds the bandwidth of the resource, some
kind of throttling must eventually be used. There are mainly 2 options for
doing this:
1. Throttle at the TCP level by not reading data from the socket (not at
all to suspend, or at a controlled rate to buffer ahead)
2. Use HTTP byte ranges, making many smaller requests with any kind of
throttling at the TCP level
After much deliberation, I've tentatively concluded that option 2 is best
on balance, for the following reasons:
* Browsers already have the infrastructure to do byte range requests for
<video>
* More requests gives the server more opportunities to do load balancing
* Servers may limit the number of concurrent requests, and the long-lived
requests caused by TCP throttling add to the total
* Using HTTP byte range requests, connections don't live longer than
necessary and it's possible to interleave fetching of many resources from
the same server
* Smooth reverse playback (playbackRate < 0) is only possible using byte
range requests (or waiting for the whole resource to buffer, which could
be impossible with a limited cache size)
* HTTP pipelining should ensure that a new connection doesn't need to be
established if the requests are not too far apart
(Since there is some overhead with each HTTP request, one must make sure
that they are not unreasonably small.)
When HTTP byte ranges are used to achieve bandwidth management, it's hard
to talk about a single downloadBufferTarget that is the number of seconds
buffered ahead. Rather, there might be an upper and lower limit within
which the browser tries to stay, so that each request can be of a
reasonable size. Neither an author-provided minumum or maximum value can
be followed particularly closely, but could possibly be taken as a hint of
some sort.
== User Expectations ==
The above buffering strategies are still not enough, because users seem to
expect that in a low-bandwidth situation, the video will keep buffering
until they can watch it through to the end. These seem to be the options
for solving the problem:
* Make sites that want this behavior set .preload='auto' in the 'paused'
event handler
* Add an option in the context menu to "Preload Video" or some such
* Cause an invoked (see dfn above) but paused video to behave like
preload=auto
* As above, but only when the available bandwidth is limited
I don't think any of these solutions are particularly good, so any input
on other options is very welcome!
--
Philip Jägenstedt
Core Developer
Opera Software
