currentTime reporting, Chromium on Android

Hi all,

I’d like to give a quick update on some developments on Chrome, and some relevant points we have discovered.

The Unified Media Pipeline (can be enabled on Android Dev and Beta channels using chrome://flags) gives us variable playback rates on Android, allowing for a much tighter sync and nicer user experience. There’s a bug report tracking this development in [1].

During testing, we did however discover some discrepancies (which we have communicated), and I think this reflects a need for developers to have good testing systems for timing sensitive issues. The particular issue we noticed is that currentTime appears slightly off, and it’s off by a different amount for audio and video. This gives an audiable echo wieh played back on multiple devices within hearing range.  EDIT: This discrepancy was actually some other change that made us detect variable playback rate as broken prematurely.  After fixing it, there are still some open issues on some devices, but the difference between media types has gone.  Of course, video has a higher bitrate and is therefore also more prone to errors on resource limited devices.

The reporting of currentTime is quite critical for multi-device playback, with two main points:

1. consitency – how much does currentTime reporting vary
2. correctness – how closely does currentTime reflect the actual player state

This leads to the question: How do developers measure the correctness of currentTime reporting. Consistency is quite easy, we even have a page to do that [2]. For our sync library, we smooth the values, which seems to work quite well. Correctness is more tricky, and the way we have done this for now is to find a reference player (we use Chrome on a Linux machine) and play back synchronized content on both browsers. An example can be seen on [3] testing Chrome vs Firefox about a year ago. Chrome produced some audio artifacts as we synchronized it then – you can hear it in the right ear.

If I’m not mistaken, the currentTime reported to Javascript is actually specified as being an estimation, as it’s a snapshot that doesn’t change during execution of JS. We got some quite good results when sampling currentTime immediately after a timeUpdate event has been emitted, but this varies between browsers. I actually believe a bug report could be filed with HTML5 on this, as very little help is provided to implementers when it comes to correctness of currentTime.

Possible suggestions for a solution could be:

1. Add a new currentTimeTS property, providing a tuple of [currentTime, timestamp] to reflect at which time the sample was taken. This will allow us to compensate for the time passed between sample and reading the value.
2. A requirement that currentTime should be updated to be correct immediately before the timeUpdate event is emitted. This likely needs to save [currentTime, timestamp] internally, then estimating the currentTime before reporting.
3. Add a property currentTime (or currentTimeTS) to the timeUpdate event similar to 2 or 1.

Solution 1 could even be writeable, providing a way to specify that players need to compensate for buffering time, latency of decoding subsystems etc. This would give us a perfect foundation to provide very nice user experiences as a skip during playback will behave as if it started playing immediately even if invisibly (due to a lack of data).

I’d love to hear about any experiences or suggestions you might have in this respect.

Njål
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=263654
[2]: http://fanoli01.itek.norut.no/Analysis/
[3]: https://www.youtube.com/watch?v=lfoUstnusIE