wolenetz@, what's the state of the replacement API video.getVideoPlaybackQuality()?

Not wolenetz@ but I'm working with other folks on an effort to better report media capabilities. This effort include a new video playback quality. wolenetz@ is trying to remove VideoPlaybackQuality from MSE (it's currently marked as deprecated). The new API work for playback quality info will happen here: https://github.com/WICG/media-playback-quality

Can I take this?

Do you know what needs to be done?

Do I need to send email to blink-dev about "Intent to Deprecate And Remove" before remove it?

Yes and now. You need to open an entry in chromestatus.com and send an intent but the CL would only mark the feature as deprecated, not removed. If you are not familiar with the process, I can deal with this.

An important consideration in a blink-dev intent is what web developers should use instead. Shipping video.getVideoPlaybackQuality() first and making sure that it's easy to transition to the new API (similar or identical semantics is nice) would be best I think. Notably, it doesn't seem to provide anything similar to webkitAudioDecodedByteCount, and nothing around decoded *bytes* for video either?

foolip@, why do we need to have an equivalent if the conclusion, it seems, is that these properties are not actually used?

I thought this was the whole of the old API, so it seemed odd that usage had dropped with no replacement, but it looks like usage of webkitDecodedFrameCount and webkitDroppedFrameCount is still going strong:
https://www.chromestatus.com/metrics/feature/timeline/popularity/172
https://www.chromestatus.com/metrics/feature/timeline/popularity/173

So I suppose that knowing the decoded byte count in isolation just isn't that useful. Can you confirm, wolenetz@?

If that's right, then there will never be a replacement, and I agree that deprecation and removal is appropriate, it's just a question of how long the deprecation period should be. Maybe 2 milestones?

Just to be clear, the deprecation would be for:
https://www.chromestatus.com/metrics/feature/timeline/popularity/164 (PrefixedAudioDecodeByteCount)
https://www.chromestatus.com/metrics/feature/timeline/popularity/165 (PrefixedVideoDecodeByteCount)

I was a bit worried when I saw the link above and I want to make sure it's clear that they are not the things we want to remove :)

Right :) The other two have high usage and really need a replacement first.

@mlamouri@chromium.org
It the process looks not familiar to me.
It will be good if you help me.

dropped/decoded frame counts are included in 'stats-for-nerds' by YT, IIUC. Please don't deprecate those until MediaPlaybackQuality has some good replacement shipped for them. Note that the VideoPlaybackQuality object/spec is *not* standardized, and is being removed from MSE shortly, so even though we have that implemented behind an experimental flag currently, it is *not* a viable replacement for the dropped/decoded frame counts. MediaPlaybackQuality work is expected to eventually subsume this VideoPlaybackQuality feature.

decodeByteCounts -- I don't recall working with those. dalecurtis@, please comment about their potential deprecation.

Note right now there is a client using decodedByteCounts since decodedFrameCount is stale until playback starts. I'm planning to fix that soon, but at least for M52 we might see a spike on usage of byte counts.

Just to dissipate potential misunderstanding, this was never about deprecating webkitDecodedFrameCount and webkitDroppedFrameCount. I suggest to focus back the discussion on webkitAudioDecodedByteCount and webkitVideoDecodedByteCount.

Dale, what do you mean by "there is a client using decodedByteCounts"? Do you expect usage to grow significantly higher than what we see today (see #10)? Should we not deprecate this properties?

 Issue 695906  has been merged into this issue.

yes but how understand if is a player loaded a video or a audio? or better if player contains video tracks or not?

For checking the loaded information, would the buffered range help? Regarding the video/audio tracks, we will launch an API that exposes this information. Safari, Firefox and Edge already ships it (ie. media.audioTracks and media.videoTracks).