+mlamouri@, ddorwin@:
The "getVideoPlaybackQuality()" method and related objects have been removed from MSE spec v1. The spec for it was immature, not well tested, didn't really belong in MSE, shouldn't have been spec'ed to be specific to just video (and not audio), and left open a few holes around discovery and interpretation of exposed "quality" metrics in various implementations. Chrome has it implemented, but it's behind the experimental flag. Mounir's spinning up a Media Capabilities spec that will make this feature more reusable. Meanwhile, we expose the necessary prefixed metrics in stable that YT and other sites really need.

Thanks.  It was Mounir's spec that I found (see description) that led me to assume this is not deprecated.  Is the behavior of this API in the other browsers roughly interoperable already?  If so, aren't we kind of past the point of trying to design the API correctly?  It's likely too late for that - what some spec says isn't really relevant if it doesn't resemble what's already in wide deployment.

rbyers@, the compat situation is unfortunately not simple. The API as it used to be described by the MSE spec wasn't implemented by all browsers. There were some information that were not exposed (totalFrameDelay), wrongly exposed (corruptedFrames).

You can see for example, Mozilla's implementation: https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLVideoElement.cpp#238

The two real values here are totalFrames and droppedFrames. However, even droppedFrames doesn't provide a real and useful information. Some browser might never drop frames but instead delay them.

The Media Playback Quality spec is a fork of the MSE VideoPlaybackQuality in order to have a better API shape but also something that websites will be able to use reliably. Keeping the current MSE API in the spec is obviously an option if it has concrete compat issue for developers.

Is it "just" a matter of defining the attributes to do something useful? The names seem to be the same in Gecko and https://wicg.github.io/media-playback-quality/#idl-def-videoplaybackquality at least.

The spec is still WIP. I think we will use different API entry point to avoid breaking implementations of the MSE version of the spec.

Is video.getVideoPlaybackQuality() really so broken that an interoperable intersection that's still useful can't be found?

Somewhat related is also that any new API can hopefully replace webkitDecodedFrameCount and webkitDroppedFrameCount as well.

mlamouri: It sounds like there's an open issue on the spec here (whether the API should keep this name, etc.), right?  I don't see an issue in GitHub for that, do you want to file one?  Then we can consider this impl bug as blocked (ExternalDependency) on the spec issue.

This bug shouldn't be in unconfirmed status. Assign to rbyers@ to start, please re-assign appropriately.

rbyers, WDYT of https://github.com/WICG/media-playback-quality/issues/7 ?

Looks good, thanks Mounir.  I've added some data to the spec issue, and we can leave this impl bug blocked on a resolution to the spec issue.

Feedback requested on https://github.com/WICG/media-playback-quality/issues/7 from Chromium developers who have thought about implementing this, how feasible is it to ship this in Chromium and then add more bits to the spec if these metrics aren't the best that could exist.

I replied: https://github.com/WICG/media-playback-quality/issues/7#issuecomment-319831618

This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge