[whatwg] What is the purpose of timeupdate?

[Brian Campbell]

On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote:

> On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell <Brian.P.Campbell at dartmouth.edu 
> > wrote:
> As a multimedia developer, I am wondering about the purpose of the  
> timeupdate event on media elements. On first glance, it would appear  
> that this event would be useful for synchronizing animations,  
> bullets, captions, UI, and the like. The spec specifies a rate of 4  
> to 66 Hz for these events. The high end of this (30 or more Hz) is  
> pretty reasonable for displaying things in sync with the video. The  
> low end, however, 4 Hz, is far too slow for most types of  
> synchronization; everything feels laggy at this frequency. From my  
> testing on a two year old MacBook Pro, Firefox is giving me about 25  
> timeupdate events per second, while Safari and Chrome are giving me  
> the bare minimum, of 4 timeupdate events per second.
>
> At 4 timeupdate events per second, it isn't all that useful. I can  
> replace it with setInterval, at whatever rate I want, query the  
> time, and get the synchronization I need, but that makes the  
> timeupdate event seem to be redundant. At 25 timeupdate events per  
> second, it is reasonably useful, and can be used to synchronize  
> various things to the video.
>
> So, I'm wondering if there's a purpose for the timeupdate event that  
> I'm missing. If it is intended for any sort of synchronization with  
> the video, I think it should be improved to give better guarantees  
> on the interval between updates, or just dropped from the spec; it's  
> not useful enough in its current form. To improve it, the maximum  
> interval between updates could be reduced to about 40 ms, or perhaps  
> the interval could be made settable so the author could control how  
> often they want to get the event.
>
> -- Brian
>
> I believe it's a convenience over using setTimeout/setInterval +  
> polling to determine whether playback has progressed ie., for  
> rendering your own playback progress bar.  I've also seen it been  
> used as a signal to copy frames into <canvas> on Firefox, however if  
> timeupdate frequency != fps of video you either miss frames or paint  
> too much.
>
> I don't think timeupdate today is very useful for doing anything  
> beyond a progress bar or other simple synchronized animations.

Right. That's what I figured the point is; I just wanted to check to  
make sure I wasn't missing something.

As implemented by Safari and Chrome (which is the minimum rate allowed  
by the spec), it's not really useful for that purpose, as 4 updates  
per second makes any sort of synchronization feel jerky and laggy. If  
it were done at the frame rate of the video, or perhaps with a minimum  
of 25 frames per second, it would be much more useful. Even at a  
minimum of 15 frames per second, you would still be able to get some  
sorts of useful synchronization, though animations synchronized  
wouldn't feel as smooth as they could.

> Would something like <video> firing events for every frame rendered  
> help you out?  This would help also fix the <canvas> over/under  
> painting issue and improve synchronization.

Yes, this would be considerably better than what is currently specced.

-- Brian