jpiesing
commented
5 months ago April 10th meeting Discussion
- Proposal to change 2/framerate + 20 to 1/framerate + 150.
- Issue is expected to be limitations on the communication between the media subsystem in the devices under test and the browser. Perhaps some mixture of overheads and/or infrequent polling or message passing.
- Makes analytic 2/framerate structuring less helpful. It was suggested to look at the test results & choose a value between 100 and 160.
- In theory can choose 0/framerate + 180.
- Concerns about more failures at higher framerates. Is this due to more errors at those framerates or because the threshold was lower (e.g. 100 falling to 60).
Proposal
- Reach tentative agreement here on 2 numbers - 0,180 if accepted by OF otherwise 1,150
- Fraunhofer to use those numbers when running the OF, initially on the 3 consistent best TV sets from the plugfest
- Numbers to be confirmed (or not) when Resillion are available
- Then edit the DPCTF specification
Proposal approved.
yanj-github
Looking at the results from the London plugfest, probably the most commonly failed observation is the accuracy of currentTime. Clause 8.2.5.2 of the DPCTF spec defines the accuracy as follows;
The same text is in 8.18.5.2. and 8.23.5.2.
(2/12.5 + 0.02) = 180ms (2/25 + 0.02) = 100ms (2/50 + 0.02) = 60ms
Looking at most of the failures, a value between 100ms and 160ms would result in a lot more passes. Failures above 160ms are unusual.
We could either increase 2/framerate to 3/framerate or even 4/framerate. but that would make the test useless for the 12.5/15Hz video.
I would be inclined to increase the 20ms to perhaps 100ms. That would result in the following.
(2/12.5 + 0.1) = 260ms (2/25 + 0.1) = 180ms (2/50 + 0.1) = 140ms
We might consider changing "2/" to "1/" to reduce the variation between these. That would give 180, 140 and 120.
It should be noted that "2" and "20' are set in a configuration file so this would not be a change of code by Resillion.
@yanj-github