On Nov 6, 2009, at 5:52 PM, Simon Pieters wrote:
On Fri, 06 Nov 2009 18:11:18 +0100, Brian Campbell <brian.p.campb...@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
