Bugzilla

It's _somewhat_ related to [track.stats](https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics) ([MediaStreamTrackVideoStats](https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackvideostats-interface) and [MediaStreamTrackAudioStats](https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface) w/some members lacking consensus), except right now stats are limited to _"microphone audio tracks"_ and _"camera and screenshare video tracks"_... who knows if that will change, but yes it's at least a competing surface already for those sources.

But getVideoPlaybackQuality() is presumably still useful for e.g. remote peer connection tracks, not covered by track stats (at least not currently).

And at least when it comes to replacing mozPaintedFrames (comment 13) I think there's value here in comming to some agreement.

I haven't read super-carefully but naively I'd expect `getVideoPlaybackQuality().totalVideoFrames;` to start counting from zero after about here:
```js
video.srcObject = new MediaStream([track]);
await new Promise(r => video.onloadedmetadata = r);
```

vs. track.stats which count from once capture begins, e.g. after here:
```
await new Promise(r => transceiver.receiver.track.onunmute = r);
```

I.e. these counters will be different, either by some fixed offset in the simple case, or even wildly different depending how the application is passing the track around maybe reusing it in different video elements.

So maybe there is room for both?

It's _somewhat_ related to [track.stats](https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics) ([MediaStreamTrackVideoStats](https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackvideostats-interface) and [MediaStreamTrackAudioStats](https://w3c.github.io/mediacapture-extensions/#the-mediastreamtrackaudiostats-interface) w/some members lacking consensus), except right now stats are limited to _"microphone audio tracks"_ and _"camera and screenshare video tracks"_... who knows if that will change, but yes it's at least a competing surface already for those sources.

But getVideoPlaybackQuality() is presumably still useful for e.g. remote peer connection tracks, not covered by track stats (at least not currently).

And at least when it comes to replacing mozPaintedFrames (comment 13) I think there's value here in comming to some agreement.

I haven't read super-carefully but naively I'd expect `getVideoPlaybackQuality().totalVideoFrames` to start counting from zero after about here:
```js
video.srcObject = new MediaStream([track]);
await new Promise(r => video.onloadedmetadata = r);
```

vs. track.stats which count from once capture begins, e.g. after here:
```
await new Promise(r => transceiver.receiver.track.onunmute = r);
```

I.e. these counters will be different, either by some fixed offset in the simple case, or even wildly different depending how the application is passing the track around maybe reusing it in different video elements.

So maybe there is room for both?