Closed jpiesing closed 1 year ago
DPC Editing call implemented in v1.0.8
for video 2) The start-up delay should be sufficiently low. As user agents may pre-load the first frame, the time to first frame is not relevant, but what is relevant that once hitting play, the second frame is rendered within the considered start-up delay. Hence, TR [k, 2] – Ti < TSMax + 1/framerate
for audio, nothing is defined yet.
Thanks @haudiobe however it does not cover all different cases. We propose the following:
The start-up delay should be sufficiently low. As user agents may pre-load the first frame, the time to first frame is not relevant, but what is relevant is that once hitting play, the second frame is rendered within the considered start-up delay. In addition, there may be missing frames at start up. Hence, TR [k, x] – Ti < TSMax where x is the first detected frame change after the play() event.
DPCTF 2021/12/15 ok with this update.
@gitwjr Review current version of the spec to ensure start-up delay is correct and is used consistently in the spec.
Implemented in v1.38 of spec.
Most tests in the DPCTF spec have an observation something like this;
There is no definition of "start-up delay" other than the formula given.
From https://github.com/cta-wave/device-observation-framework/issues/27#issuecomment-869784306 , @louaybassbouss said "HTML5 players usually show the first frame even if you don't call play().".
What is start-up delay & how should it be measured?
One possibility would be to measure the time between when play() is called and when frame no. 2 is displayed and then correct for one frame interval.
Whatever we do, the DPCTF spec will need changing because using "TR [k, 1]" is clearly wrong regardless.