[Bug 23169] reconsider the jitter video quality metrics again

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23169

--- Comment #10 from Jerry Smith <jdsmith@microsoft.com> ---
It’s true that frame delays would be quantized to the display refresh rate;
however, total delay can still provide more information than counting late
frames, assuming late frames are counted once per frame whether they are late a
single refresh cycle or multiple.  That should mean that once the video stream
is one frame late, every frame would be counted as late, the TotalLateFrame
metric would expand and client JS would presumably respond by lowering the
video quality.  If just one refresh cycle late, that may not be appropriate.

TotalFrameDelay in this instance would accurately communicate that frames were
running a specific time interval late, and JS would be allowed to make it's own
determination on whether the delay is perceptible to users.  If, however, the
stream moved to multiple refresh cycles delayed, this would show as a larger
value in TotalFrameDelay, but not in TotalLateFrames.  

If this example is accurate, it would suggest that TotalLateFrames may more
aggressively trigger quality changes, but perhaps not desirable ones; and
TotalFrameDelay communicates more information that would allow tuning of the
response to slight, moderate or large delays in the video stream.  The analog
nature of the time data makes it a more desirable feedback signal in what is
essentially a closed loop system.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 5 November 2013 01:34:03 UTC