Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should MediaPlaybackQuality keep VideoPlaybackQuality backward compatibility #7

Open
mounirlamouri opened this issue Sep 28, 2016 · 9 comments

Comments

@mounirlamouri
Copy link
Member

commented Sep 28, 2016

Questions are:

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

This comment has been minimized.

Copy link

commented Sep 29, 2016

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

This comment has been minimized.

Copy link

commented Sep 29, 2016

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

This comment has been minimized.

Copy link

commented Jul 11, 2017

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

@cpearce

This comment has been minimized.

Copy link

commented Jul 11, 2017

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

This comment has been minimized.

Copy link

commented Aug 3, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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

This comment has been minimized.

Copy link

commented Aug 3, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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

This comment has been minimized.

Copy link

commented Apr 4, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.