webrtc-stats
webrtc-stats copied to clipboard
Impact of Stereo input and output on metrics
What happens if the source is stereo? We should be consistent in all the audio metrics on how stereo audio streams are handled.
E.g. if you have one or two channels, does this affect the rate of increase of...
- Sample counters
- Duration counters
Or are the counters the same regardless of channel count
@o1ka doesn't think that that we count stereo as twice as many samples or duration... do we have a repro?
even source mic is stereo, webrtc default will not use stereo audio(opus), user should mung sdp to activate stereo audio. add real channel numbers(both sender and play side) to stats may help hint user whether stereo audio is ativite or not of a call ?
From what I've tested, the channels in RTCCodecStats
is giving me the correct value for how many channels are being used.
when channles is 2 , the call maybe also pseudo stereo, there is no way stats whether the mic is true stereo.
From what I've tested, the channels in
RTCCodecStats
is giving me the correct value for how many channels are being used.
the channels in 'RTCCodecStats' maybe wrong, it's always 2 from my test for opus codec, but it's not stereo.
I think by default we negotiate mono and SDP munging is needed to enabled stereo. https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-786118846 is a long discussion but I think the bottom line was that we wanted to change from mono-by-default to stereo-by-default and let the control surface for stereo or mono be the track's settings (applyConstraints if you care about this) but Justin mentions some blocking issues to make this reality.
My memory is hazy, I haven't re-read all of this, but I would imagine that RTCCodecStats should reflects what we negotiated (currently mono-by-default), not what the mic is capable of.
Is getStats() lying to us?
it seems the channels stats in RTCCodecStats is get from opus codec sdp fmt line, according opus rfc 7587 , the number of channels MUST be 2. but It does't reflect stereo is actived or 2 channels is used. we can't use this stats for stereo metrics.
The codec stats should reflect the codec information from the SDP. For current usage, there is media-source where MediaStreamTrack information is exposed and outbound-rtp where encoder and RTP information is exposed. (Or inbound-rtp for decoder/RTP/track on the receive side)
It's not clear to me if we need more metrics to reflect current usage or if https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-786118846 should be resolved and then you don't need metrics because you can just look at track.getSettings().channelCount
https://w3c.github.io/webrtc-stats/#terminology already says that when we talk about audio samples what we're really talking about are audio frames