- From: <bugzilla@jessica.w3.org>
- Date: Tue, 12 Nov 2013 01:06:36 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169 --- Comment #13 from David Singer <singer@apple.com> --- We think there are (at least) three possible ways to go to get a measure that will help noticing when the media engine or platform is 'in trouble.' We assume in all cases there is some reasonable way to reset the counters (which is probably not on every fetch, or high-frequency checking is likely to be less helpful as it will involve small numbers, making the web app responsible for analyzing them). A moving window is another possibility, but these are harder to implement and need another parameter (the window length), so it's not so good. 3 possibilities: 1) Keep the following variables * dropped frames * displayed frames * mean displayed lateness * standard deviation of the lateness * late frame count 2) Keep a count of * dropped frames, * on-time frames (or displayed frames) * maximum lateness, and * late frame counts in buckets. * total late frames (sum over all buckets) Because the precision of the delay is less and less important when the delay increase, we size the bucket-width in powers of two. The buckets windows can be [0;1ms[, [1ms;2ms[, [2ms;4ms[, [4ms;8ms[, [8ms;16ms[ (these first buckets are always 0 for a 60Hz display), [16ms;32ms[, [32ms;64ms[, etc. With this property, all we need to agree on is the base (here 1ms) on which the window size is calculated. I think this value can be more easily determined because it has a low impact on the usefulness of the buckets. (We could also base the buckets on the display frequency (giving [0;1/f[, [1/f;2/f[, [2/f;4/f[, [4/f;8/f[, etc.).) This gives a reasonable number of buckets. 3) If those are too complex, keep the following counts * dropped frames * on-time frames (or displayed frames) * slightly late frames * noticeably late frames where noticeably late is frames that are late by larger than some threshold, which is set at initialization, or which has a suitable default and a reset API. For many purposes, frames that are late by 1-2 frame durations (when that is well defined) or late enough to cause audio sync problems, are the ones to notice, whereas 'slightly late' frames may not be a concern, or only a minor concern. Because when a frame is displayed it is either on-time or late, giving on-time frames is equivalent to giving displayed frames. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 12 November 2013 01:06:38 UTC