[whatwg] Author control over media preloading/buffering

[Robert O'Callahan]

When a media element loads, reaches the HAVE_CURRENT_DATA state, but is
paused, and 'autoplay' is not set, we have to decide whether to keep
downloading data or not. If we expect the user to play the stream, we should
keep downloading and buffering data to minimize the chance that buffering
will be needed during playback. But if we don't expect the user to play the
stream, we should pause the download to conserve resources. The latter is
especially important on pages with large numbers of media elements, only one
or two of which the user will play.

In general it's hard to see how to make a good guess automatically. If a
page has one (non-autoplay) media element on it, it's hard to know whether
the user is expected or not expected to play it. For example the user might
be expected to play it, but only after they've read some text before the
video (so autoplay is not appropriate). I think (but I'm not sure) that
authors are likely to be able to make better guesses, so I think it would be
useful to provide authors with control over this decision. I think that
authors are likely to want this control in the same way they like to be able
to preload images.

So, how about adding an "autobuffer" attribute, which instructs the browser
that the user will probably play the video and as much data as possible
should be pre-downloaded? By default (when the attribute is not present) the
browser would be expected to pause the download after reaching
HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090211/0330a1db/attachment-0001.htm>