Should MediaPlaybackQuality keep VideoPlaybackQuality backward compatibility

[mounirlamouri]

Questions are:

• should the old API be supported?
• if yes, how much of it?
• should the supported bits be marked deprecated?

[RByers]

Some data from the chromium bug: current versions of Safari, Edge and Firefox all support this API, but Chrome does not.

In general for such a case (without knowing details of the behavior of this specific API), the most pragmatic path to interop is to spec something that's close to (maybe a subset of) whatever is already shipping in these browsers and also ship in Chrome. It seems unlikely that WebKit, Gecko and EdgeHTML will all be willing to remove this API unless the usage is incredibly low.

I did a quick HTTP Archive search and found that ~37k of the top 500k websites include the string 'getVideoPlaybackQuality', coming from scripts from ~300 different origins (eg. so YouTube embeds counted exactly once, since they were a substantial fraction of the 37k). I spot checked a few and they all appeared to be in video players, often with some fallback for a webkit-prefixed API when not present. So at first glance, it doesn't seem likely that Gecko at least (and probably Edge) would be able to remove this API without substantial compat risk or needing to instead ship some webkit-prefixed APIs. But I didn't dig in more detail.

[RByers]

Of course, none of this is to say that the API shouldn't be relegated to some "legacy - obsolete, do not use" section of the spec. There's lots of precedent for that.

[jan-ivar]

I'm confused. If getVideoPlaybackQuality() is legacy, what is non-legacy?

[cpearce]

Is Google's resistance this API caused by Chrome's implementation making it hard to count dropped and corrupted frames? We have tier-1 streaming sites using our drop frame count to successfully do rate adaption, so the VideoPlaybackkQuality API as defined is clearly useful when correctly implemented.

[ddorwin]

The concerns are about the API as it was defined and the resulting implementations. We believe these issues should be addressed and that further iteration is necessary. For examples, see w3c/media-source#69 and w3c/media-source#76. It's also worth noting that VideoPlaybackQuality and the related method are not currently in a REC-track spec.

Note that the latter issue says that Firefox always reports 0 for corruptedVideoFrames. Is that still the case?

/cc @wolenetz

[foolip]

Searching for "VideoFrames" in those issues I find these concerns:

• corruptedVideoFrames always 0 in Firefox?
• Should droppedVideoFrames be split into different reasons for dropping?
• totalVideoFrames is inconsistent in Edge. (details unclear)

For droppedVideoFrames, the straightforward thing is to make the spec match what browsers have already shipped, if it doesn't already. Then add more fields if needed.

The other two sound like implementation bugs, both corruptedVideoFrames and totalVideoFrames looks well-enough defined in https://wicg.github.io/media-playback-quality/#dfn-corrupted-video-frame-count and https://wicg.github.io/media-playback-quality/#dfn-total-video-frame-count

Is there anything more that I've overlooked?

[ddorwin]

If I recall correctly, there might be implementations cannot support corruptedVideoFrames, but the API provides no way for apps to distinguish this from 0. I think there might be some question of the usefulness of some values as well.

Dropped frames is probably the most useful and Chrome has long exposed it (webkitDroppedFrameCount; clearly we'd like to move to an unprefixed standardized API). Chrome has changed the way dropped frames are counted in the past to be more useful for apps; we should make sure there is consensus on how to count for any new API.

[foolip]

If I recall correctly, there might be implementations cannot support corruptedVideoFrames

Is there anything a web app might do differently between an implementation that doesn't support it, compared to thinking it's supported at that there are no corrupted frames?

[goldenratio]

In Chrome HTMLVideoElement.getVideoPlaybackQuality doesn't exist. Am I right, Chrome is only browser still hasn't implemented it?

let video = document.createElement('video');
typeof video['getVideoPlaybackQuality']; // undefined

[chcunningham]

Chrome shipped VideoPlaybackQuality as currently spec'ed. Additional features will extend in a backward compatible fashion or define new APIs without breaking backward compat.