[Bug 23169] reconsider the jitter video quality metrics again

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

--- Comment #14 from Aaron Colwell <acolwell@google.com> ---
Of the 3 options that David proposed, #3 is the one I'd support if I had to
pick one. Ideally I'd like us to just pick reasonable constants for 'slightly'
and 'noticeably' late instead of making these thresholds configurable.

I'm not a fan of #1 because I believe the metrics would become less sensitive
to transient changes in performance as the number of frames increases. You
could probably back out the underlying sums from the metrics to counteract this
effect, but it may not be worth it.

Option #2 seems too complex w/o a whole lot of gain. I don't think it is clear
how applications should evaluate the current quality based on the bucket
distribution. I'd like to see us stick with a simpler metric than this.


At this point I'm ready to just defer to Jerry, Mark, and David here. I don't
really care beyond keeping things as simple as possible for this first version
of MSE. For what it's worth, my current preference order based on all the
proposals is:
1. Existing text. (Since it made Jerry & Mark happy, I can live with it, and
its a noop)
2. My single late frame count proposal.
3. David's option #3 which essentially adds 2 late frame counters instead of 1.

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

Received on Wednesday, 13 November 2013 09:10:08 UTC