Re: MSE V1Editorial issues

For our part, we are actively using both dropped frames and totalFrameDelay
to detect CPU overload and reduce resolution as a result. If this
functionality were dropped, it would result in substantially lower
quality-of-experience for our customers and so I think it unlikely that
browsers will drop this functionality before an alternative is available.
Since this will likely be quite some time, I believe we should have the
existing functionality documented. If there is work ongoing on a future
alternative, it would make sense to signal that to readers so that those
who have not implemented VideoPlaybackQuality can make an informed decision
on whether to implement that or whether to wait for the alternative.

...Mark

On Fri, Jul 29, 2016 at 10:11 AM, Jerry Smith (WPT) <jdsmith@microsoft.com>
wrote:

> Relative to my comments on videoPlaybackQuality:
>
>
>
> -          We still believe VideoPlayBackQuality should stay, with the
> existing caveats.
>
> -          It may be that dropped frames is most important.  We implement
> totalFrameDelay, but I’m not sure how comparable it is across UAs.
>
>
>
> I’ve confirmed Edge has implemented totalFrameDelay.  It is returned in
> seconds as a double (converted from an internal integer value using hundred
> nanoseconds).
>
>
>
> Jerry
>
>
>
>
>
> *From:* Matt Wolenetz [mailto:wolenetz@google.com]
> *Sent:* Thursday, July 28, 2016 2:33 PM
> *To:* Jerry Smith (WPT) <jdsmith@microsoft.com>
> *Cc:* Paul Cotton <Paul.Cotton@microsoft.com>; Mark Watson <
> watsonm@netflix.com>; public-hme-editors@w3.org
> *Subject:* Re: MSE V1Editorial issues
>
>
>
>
>
> On Thu, Jul 28, 2016 at 2:32 PM, Matt Wolenetz <wolenetz@google.com>
> wrote:
>
> hose minimal implementations are not app-visible in such case,
>
>
> (Though, of course, the lack of TrackDefaults support and the "full"
> default {language,label,kinds} algorithms *is* app-visible.)
>