[Bug 22148] Request that we reconsider adding jitter to video quality metrics

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

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #5 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #4)
> I have a few questions about the new metric.
> 
> 1. Is this only supposed to apply to displayed frames or does it include
> dropped frames?

I understood it would only apply to rendered frames.

> 2. If it includes dropped frames how should pre-decode dropping be
> represented?
> 3. How is this supposed to allow the application to detect A/V sync issues?
> I wouldn't expect the delays to accumulate in a way to cause A/V sync
> problems. It seems like if frames are too late they should just be dropped
> instead of displayed extremely late.

Certainly frames *should* be dropped if they are extremely late.

However, the existing playbackJitter does not allow detection of a scenario
where the A/V gets out of sync, even temporarily. For example if a whole string
of frames are all rendered half a frame interval late, the playback jitter will
increase as you enter this state but then remain constant as long as you stay
in that out-of-sync state and then increase again when you exit that state
(because of the abs() then frame durations being less than normal - as needed
to bring you back into sync - show up as an increase in playbackJitter as
well.)

So, when you see an increase in the playback jitter value you don't know if
there was a move out-of-sync and then back (i.e. just one frame was late) or
just a move into a long-running out-of-sync state.

The proposed totalFrameDelay allows detection of this as well as detection of
all the events that playbackJitter could have detected.

Even if players "should not" do this it's good to be able to detect what is
actually happening as often all bets are off for actual behavior when you're in
a resource-constrained state.

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

Received on Wednesday, 3 July 2013 18:49:23 UTC