RE: Public feedback on HTML5 video

Hi there,

I am not sure I follow the intricate details of the discussion, but
would like to make a couple of points from a content provider's point of
view.


Implicit behavior is not well suited to allow full author control of the
display.
Explicit behavior is always preferable.

The reason is that an action taken or not taken by an author should be
considered to be an explicit decision.
Such explicit decisions should then produce explicit behavior in
browsers which is predictable and can be corrected if so desired.

If it is left up to the browser to make an implicit decision, the
outcome is not predictable across browsers, based on implementation.
As such if something can be turned on in markup it should mean that not
doing so means the inverse...turning it off.

Referring to some of the things Maciej mentioned:
- buffering is a usability issue.  If something is displayed, buffering
ought to be used because it aids in smooth display
- bandwidth issues are not so big of an issue anymore.  While it is
important not to waste bandwidth, in the world of flatrates and
broadband, usability is more of an issue.
- whether a poster frame is loaded or not is a design issue and should
be up to author, including the choice which frame to show

-- Kai





> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com] 
> Sent: Thursday, December 24, 2009 11:49 PM
> To: Gavin Carothers
> Cc: HTMLwg; comments@daringfireball.net
> Subject: Re: Public feedback on HTML5 video
> 
> 
> 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 Monday, 28 December 2009 10:16:38 UTC