[whatwg] What is the purpose of timeupdate?

[Brian Campbell]

On Nov 5, 2009, at 3:11 PM, Andrew Scherkus wrote:

> On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell <brian.p.campbell at dartmouth.edu 
> > wrote:
> 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
>
> I'll see if we can do something for WebKit based browsers, because  
> today it literally is hardcoded to 250ms for all ports.
> http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254
>
> Maybe we'll end up firing events based on frame updates for video,  
> and something arbitrary for audio (as it is today).
>
> Brian, since Firefox is doing what you proposed -- can you think of  
> any other issues with its current implementation?  What about for  
> audio files?

The way Firefox works is fine for me. I haven't yet tested it with  
audio only, but something around 25 or 30 updates per second would  
work fine for all use cases that I have; 15 updates per second is  
about the minimum I'd consider useful for synchronizing one off events  
like bullets or slide transitions (this is for stuff where you want  
good, tight sync for stuff with high production values), and while  
animations would work at that rate, they'd be pretty jerky.

-- Brian