It’s not absolute of course — because the speed of timing events is not consistent, so the difference in time between the two sources can be +/- maybe quarter of a second. That’s way to much for something like DJ mixing, but easily acceptable for audio descriptions.

But the real problem comes when buffering has to happen. If you seek a long way forward so the video has to buffer for a few seconds, then the audio will keep playing until the video catches up. Or if you start playing the video before the audio has loaded enough, then the audio won’t start playing the until it has. The native MediaController doesn’t have this problem, because it locks the sources together, so if one has to buffer then the other one pauses.

But even without native controllers, those problems are fixable. In the client project I’m working on, I’ve developed this idea much further. What I do is monitor the “progress” events, which give information on which parts of the video are in cache, and use that data to detect when the video has to buffer. When that happens, I pause the video and the audio, and then continue to monitor progress events until a few more seconds has preloaded, then play again. If the users seeks, a similar process occurs (and there are additional seeking events and properties to detect that too).

But ultimately, this is just a hack to cope with lack of support for MediaController — because only Chrome implements that, and its implementation is quite buggy anyway (in fact, in my client project, Chrome uses my solution and not a native controller, because it works better!)

However given time, when most browsers have a solid and reliable implementation of native media controllers, then hacks like this won’t be necessary.

Do you think the future of HTML5 video with this concept will be safe (safe in the sense, sync between a/v will be proper)?
Also @mediagroup will be an alternative for this hack, right?

Consider my questions as newbee. I am only a beginner.

thank you James.

I was going to add captions to this demo, but it seemed counter-intuitive, because (as you say) captions and descriptions are intended for different audiences.

Captions are a solved problem in any case, so it doesn’t need mentioning in this particular context (ie. when talking about technical limitations with HTML5 video), because there are no technical limitations.

What really takes the time with posts like this is researching, making and testing the demo. I spent a day on that, but only a couple of hours actually writing the blog post.

The trick is to write about things that you’re working on anyway, so that research and development time is an investment in knowledge and skills.