[whatwg] VIDEO Timeupdate event frequency.

[Ian Hickson]

On Fri, 10 Sep 2010, Biju wrote:
> Matthew Gregan wrote in
> https://bugzilla.mozilla.org/show_bug.cgi?id=571822 :
> > Firefox fires the timeupdate event once per frame. Safari 5 and Chrome 
> > 6 fire every 250ms.  Opera 10.50 fires every 200ms.
> 
> Now in firefox bug 571822 they are changing Firefox fires the timeupdate 
> event at every 250ms
> 
> But this takes away control of somebody who want to do some image 
> process on every frame, as well as miss frames.
> 
> So can we have a "newFrame" event and/or a "minTimeupdate" property to 
> say what should be the minimum time interval between consecutive 
> timeupdate event.

The idea behind timeupdate is just to update the seek bar, and to do so at 
whatever rate the browser thinks is the best balance between power/CPU 
usage and user experience.

There's currently no way to do anything on a per-frame basis explicitly, 
but if we were to support that use case, I imagine we'd want to do 
something more efficient and precise than just firing an event and hoping 
the script can paint the video before the next frame.

That's probably a feature for later, though. Implementations haven't quite 
gotten the current set of features down reliably yet. :-)


On Fri, 10 Sep 2010, Simon Fraser wrote:
> On Sep 10, 2010, at 10:07 AM, Tab Atkins Jr. wrote:
> > On Fri, Sep 10, 2010 at 9:58 AM, Simon Fraser <smfr at me.com> wrote:
> >> In WebKit on Mac, video playback is hardware-accelerated, and the 
> >> presentation of video frames is disconnected from the web page 
> >> drawing machinery. A newFrame callback would force us to drop back 
> >> into software rendering, which is significantly more CPU intensive. I 
> >> don't support the general use of a 'newFrame' callback except in the 
> >> context of video processing via canvas.
> > 
> > In general, video processing via canvas is going to require dropping 
> > into software rendering, right?  I think that's what I was hearing 
> > from our dudes putting hardware-accelerated video into Chrome.  So at 
> > least in the case that I can see this often being put towards, you 
> > don't lose anything.
> 
> My concern would be pages registering for newFrame events just to do 
> stuff like updating a controller, which will vastly increase CPU usage.

Yeah, if we support this it would make sense to do it in some clever way 
where you couldn't (easily) abuse it, e.g. have the registered callback be 
GPU code that doesn't run in the same scripting context (not a concrete 
proposal, just an idea -- we'd have to wait until WebGL has a proven 
solution for safely running code on the GPU).


On Sat, 11 Sep 2010, Robert O'Callahan wrote:
> On Sat, Sep 11, 2010 at 11:03 AM, Tab Atkins Jr. 
> <jackalmage at gmail.com>wrote:
> > So...  no newframe event for now, leave timeupdate as it is, and fix 
> > this in the future?
> 
> I think so. Another factor is that a lot of the video effects people 
> have been using canvas for can actually be done with SVG filters, which 
> can be GPU-accelerated and are compatible with asynchronous compositing. 
> So it might be wise to focus on use-cases for video processing that 
> aren't amenable to SVG filters (or extensions thereof), and understand 
> what their requirements are.

Indeed.

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