[whatwg] Apple Proposal for Timed Media Elements

[Ian Hickson]

On Wed, 21 Mar 2007, Robert Brodrecht wrote (in response to Apple's 
proposal, quoted):
> > 
> > If the presentation of timed media by the user agent has been disabled, if
> > the resource has an unsupported type, or if the preparations for its
> > presentation fail either because of a protocol failure or because the format
> > of the media is unrecognized, the user agent must fire an error event on the
> > element and display the element's fallback content, if available.
> 
> So, we have some fallback control.  That is good, as it is lacking from 
> WHAT WG at the moment and was something I'm concerned about.  This is 
> how I intuitively felt it should work.  I'm glad that is specified.

The way the <video> element now works in the HTML5 proposal is not quite 
this -- the fallback is only used if the browser doesn't support <video> 
at all, not if it doesn't support the codec. The primary reasons for this 
is to stop the bouncing around of content. This is similar to how <iframe> 
works. Fallback to different formats is provided via <source>.


> > The controller attribute is a boolean attribute. If the attribute is 
> > present, the user agent must display a user interface which allows the 
> > user to control the media element. The height attribute on the element 
> > does not include the size of the controller, it is the size of the 
> > video element only
> 
> I like being able to specify this, but the height of the controller needs to:
>
> 1) Be set normatively in this specification.  If the height of the 
> controller area changes across browsers, it's going to be a source of 
> irritation for developers.
>
> 2) Be set in CSS (as well as positioning options... I'd guess through a 
> pseudo element like :controller?).

We'll address this in the rendering section in due course.


> > When the src attribute is set, the user agent must immediately begin 
> > to download the specified resource unless the user agent cannot 
> > support video/audio, or its support for video/audio has been disabled
> 
> One reason I like YouTube is that the download is user-initiated.  If I 
> include YouTube content on my site, they see a nice thumbnail from the 
> video and a big play button.  If they are on dial-up, they don't have to 
> download it.  Autodownload, to me, is flawed.  I know I can set up the 
> image and video stuff with JavaScript to work like YouTube.  But if the 
> user DOESN'T have JavaScript on, they are stuck with nothing.  I would 
> love to see an "autodownload" attribute to complement "autoplay" or use 
> "autoplay=0" to disable the auto download.  A way to add a thumbnail 
> would be nice while not auto downloading.

The spec has an autoplay="" attribute now, and can stall downloading the 
content for as long as the user desires.


> > The DOM attribute currentRate is the rate at which a media element is 
> > currently playing.
> 
> I'm guessing this would be in frames per second?  Is it the frames per 
> second it is playing or the available frames per second encoded in the 
> video?

In the spec it's a multiple of the native rate.


On Thu, 22 Mar 2007, Chris Double wrote:
> >
> > Looping is useful for more presentational uses of video. Start and end 
> > time are useful in case you want to package a bunch of small bits of 
> > video in one file and just play different segments, similar to the way 
> > content authors sometimes have one big image and use different 
> > subregions. Or consider looping audio, or a single audio file with 
> > multiple sound effects. These are two examples.
> 
> Could the looping be done via javascript rather than having explicit 
> support for it with loopStartTime, etc? If an event is raised when the 
> video reaches endTime then event handler could then restart it.

On Sat, 24 Mar 2007, Kevin Marks wrote:
> 
> For smooth looping, you need to have the next buffer ready and cued up 
> when the previous one finishes. Doing this consistently with a roundtrip 
> through javascript events is going to stutter or gap. For video at 
> 30fps, you can make the interval, but audio at 48khz means you are more 
> likely to hear a click or gap.

The spec now does it declaratively.


On Wed, 21 Mar 2007, Eric Carlson wrote:
> > 
> > I'm guessing this would be in frames per second?  Is it the frames per 
> > second it is playing or the available frames per second encoded in the 
> > video?
>
> No, it is a multiple of the file's intrinsic (or "natural") rate. 
> "Frames per second" loses meaning quickly with digital media files, 
> where individual frames can have arbitrary duration (true even for 
> animated GIF files).

Right.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'