-
Notifications
You must be signed in to change notification settings - Fork 16
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
Migrate capture metrics from RTCAudioSourceStats to MediaStreamTrack method #96
Comments
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: w3c/webrtc-stats#741
The text was updated successfully, but these errors were encountered: