W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Public feedback on HTML5 video

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 24 Dec 2009 14:48:39 -0800
Cc: HTMLwg <public-html@w3.org>, comments@daringfireball.net
Message-id: <C7274E2F-F20F-4751-89F7-8919AA38A6E9@apple.com>
To: Gavin Carothers <gavin@carothers.name>

For what it's worth, we are planning to change WebKit's media element  
implementation to buffer more conservatively when both "autobuffer"  
and "autoplay" attributes are absent. However, I think it is probably  
better to treat this as a quality of implementation issue than to spec  
exact behavior. The details of buffering behavior likely need to vary  
per platform.

Note: our original implementation of HTML5 media elements predates the  
autobuffer attribute being added to the spec. And for technical  
reasons that will likely bore people here, it's tricky to get  
QuickTime to buffer less aggressively. That being said, we agree it  
would likely be better to buffer the minimum needed.

One question is just how much the bare minimum is. For videos without  
an explicit poster frame, it seems pretty clear that the best behavior  
is load enough to get a complete first frame, even when not  
autobuffering; this will also be enough determine the dimensions, and  
for most media formats, the duration. But there are a few trickier  
situations. When a <video> element has the poster attribute set, in  
theory the browser could refrain from loading anything at all, since  
there's no need to get an initial frame to display. But then the  
duration and dimensions of the actual video will be unknown, so it  
would not be possible to show a duration in the UI or in custom  
controls, unless it's hardcoded. Would it be better to load nothing,  
or the bare minimum to get a duration? It's actually slightly easier  
for us to load nothing at all, but we're not sure it's the most useful  
behavior. I do believe it is allowed by the spec, since it allows  
suspending the load at any time, even after getting 0 bytes, though it  
suggests it might be good to wait for metadata.

The same sorts of considerations apply to <audio>, where you never  
display a first frame to the user. There is also the case of  
indefinite duration streams, for instance using RTSP or HTTP Live  
Streaming. It might not even be possible to tell up front that we're  
getting an unbounded stream without trying to load it.

Thoughts from the community and other implementors on these issues are  


On Dec 22, 2009, at 7:47 AM, Gavin Carothers wrote:

> John Gruber of Daring Fireball on the autobuffer attribute for the
> video element:
> http://daringfireball.net/2009/12/html5_video_unusable
> Summary:
> "This attribute may be ignored altogether" should be removed from  
> the spec.
> Summarized Rationale:
> Avoid downloading video on pay per megabyte connections, and avoid
> extra bandwidth from the publisher on video that won't be played.
> The whole article is worth reading, and seems like a very reasonable
> argument based on real world usage of the video element.
> --Gavin
Received on Thursday, 24 December 2009 22:49:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC