I am by no means experienced in this area, but a quick search of MDN showed the 'timeupdate' event[1]. Is that not sufficient for the usecase you gave? The timestamp itself is available through the 'currentTime' property[2] so you can always have that value as well.
In theory, yes, that’s how you’re supposed to do it. Unfortunately, part of the real world problem with switching to HTML5 media elements is that browsers have an awful track record in terms of quality of implementation. At various points, even quite basic events simply haven’t been firing properly in one browser or another. And with browsers updating every six weeks and frequently changing things like the default controls you get on a video element, you’re constantly aiming at unnecessarily moving targets as a developer.
Yep, here's an example - if you mouse down on the video thumb, and don't move the mouse nor release the mouse button (so basically you've held the thumb in place):
- Does the pause event fire?
- Does the seeking event fire? Or does it only fire when you move the mouse to drag the thumb to a new time?
- Does the seekend event fire? Does it fire every time you move the thumb to a new position without releasing the mouse button? Or does it only fire when you release the mouse button?
- Does the timeupdate event fire? Does it fire once? Or repeatedly for the same position where the thumb is?
Every browser has different answers.
As for the timeupdate event, it only fires once every 250ms, which is painfully slow for applications that need to synchronize something with the video (slides, subtitles, etc.)
And even if you decided to ignore all the events and write a requestAnimationFrame-powered loop to query only the changes in the currentTime property, there's a bug in Chrome on Android where the video.currentTime property becomes out-of-sync with the video if any long-running JS or complicated animation blocks the event loop for a few seconds - https://code.google.com/p/chromium/issues/detail?id=509010