- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 24 Dec 2009 14:48:39 -0800
- To: Gavin Carothers <gavin@carothers.name>
- Cc: HTMLwg <public-html@w3.org>, comments@daringfireball.net
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 welcome. Regards, Maciej 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