On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote:
On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell <
[email protected]> 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
