[whatwg] What is the purpose of timeupdate?

[Brian Campbell]

On Nov 6, 2009, at 5:52 PM, Simon Pieters wrote:

> On Fri, 06 Nov 2009 18:11:18 +0100, Brian Campbell <brian.p.campbell at dartmouth.edu 
> > wrote:
>
>>> 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.
>
> What if you have a video with say one frame per second? Unless I'm  
> mistaken Firefox will still fire timeupdate once per frame. (The  
> spec says you have to fire at least every 250ms.)

That's a fair point, though videos with frame rates that low are  
pretty rare. I suppose if you encoded something like a slideshow as a  
video, with a very low frame rate, you might get such an effect. Of  
course, if you're playing a video at that frame rate, I'm wondering  
what you would need to be synchronized at a higher frame rate; though  
if it has an audio track as well, you may be trying to synchronize  
against the audio.

If this is something that we think is worth worrying about, then I'd  
advocate for just saying that timeupdate events should be fired  
approximately 30 times per second, perhaps with a minimum of 15 and a  
a maximum of 60 or so. For videos over  15 FPS, the browser could  
simply send one update per frame; for videos with a lower frame rate,  
the browser would have to generate intermediate timeupdate events to  
keep the interval reasonable. Or, the browser could just pick a rate  
in that range and send the events at that rate, without tying them to  
when the frames are displayed. I'd be fine with just having a  
reasonably consistent rate of 30 updates per second while the video is  
playing.

-- Brian