[Bug 23169] reconsider the jitter video quality metrics again

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

--- Comment #6 from Jerry Smith <jdsmith@microsoft.com> ---
The rationale over all is that there needs to be something that measures frame
lateness, and that having dropped frames is not enough.

We believe frame delay communicates more information than late frames.  We
expect that the totalFrameDelay metric would be monitored at some interval. 
The usage of totalFrameDelay would then be:

1)  Not changing value – good quality playback
2)  Uniformly increasing value – consistent A\V sync (video is behind) but no
further improvements or degradations (no jitter)
3)  Non-uniformly increasing value – most likely worsening playback (video
falling further behind) or jitter caused by the application trying to
compensate by reducing resolution, etc (i.e. improving playback)

So, the totalFrameDelay attribute on its own can provide useful information.

It's possible for a system to go into frame-dropping mode and still be in #1
above since the frames that aren't dropped are still on-time. That state would
be detected by the droppedVideoFrames attribute.

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

Received on Tuesday, 15 October 2013 18:37:37 UTC