currentTime reporting, Chromium on Android [via Multi-device Timing Community Group]

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.

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

 consitency - how much does currentTime reporting vary
 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:

 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.
 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.
 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



----------

This post sent on Multi-device Timing Community Group



'currentTime reporting, Chromium on Android'

https://www.w3.org/community/webtiming/2016/02/25/currenttime-reporting-chromium-on-android/



Learn more about the Multi-device Timing Community Group: 

https://www.w3.org/community/webtiming

Received on Thursday, 25 February 2016 09:48:28 UTC