Closed henbos closed 10 months ago
The new version of the PR is #117
From the October interim minutes, conclusion: "Overall approach makes sense, flesh out the details in the editors meeting"
Let's not close this issue until #119 has been resolved, latency metrics also need to move (and have been approved by multiple Virtual Interim meetings)
All PRs have now merged so it would be safe to remoev the capture metrics from RTCAudioSourceStats now. Closing this one and following up on webrtc-stats
The RTCAudioSourceStats contains capture related metrics that are better suited for a MediaStreamTrack method than RTCPeerConnection.getStats() since you may be capturing for a non-WebRTC context.
This was covered in the April 18, 2023 Virtual Interim and the Working Group input was supportive: Moving them to the track is the right direction, and no strong opinions on the name of the method.
There was even preference to rename track.getFrameStats() to track.getStats() expressed and this would be a good opportunity to do so, before the video capture stats are implemented.
Original issue over on the WebRTC stats spec: https://github.com/w3c/webrtc-stats/issues/741