[whatwg] Author control over media preloading/buffering

[Robert O'Callahan]

On Tue, Feb 24, 2009 at 12:16 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 11 Feb 2009, Robert O'Callahan wrote:> 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'.
>
> I've added this attribute.
>

Under "Once enough of the media data has been fetched to determine the
duration of the media resource, its dimensions, and other metadata", after
setting the state to HAVE_METADATA, steps 7 and 8 say

7. Set the element's delaying-the-load-event flag to false. This stops
> delaying the load event.
>
> 8. This is the point at which a user agent that is attempting to reduce
> network usage while still fetching the metadata for each media resource
> would stop buffering, causing the networkState attribute to switch to the
> NETWORK_IDLE value, if the media element did not have an autobuffer or
> autoplay attribute.
>

I suggested HAVE_CURRENT_DATA would be a better state for these actions, and
I still think so. These actions should not occur until the UA is able to
display the first frame of the video. Authors would want the first frame of
a non-autobuffered video to be visible, and the document load event should
fire after the first frame is available by analogy with images. Is there a
particular reason why you think these things should happen at HAVE_METADATA?

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/20090225/5a237fd1/attachment-0001.htm>