- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Feb 2022 17:12:18 +0000
- To: public-webrtc-logs@w3.org
Both ways seem fine to me and equally deterministic in the case you're talking about which sounds like an established connection, but right now we have vendors exposing stats ahead of _negotiation_ which I hope we can agree is unnecessary. In an established connection, we're just talking about whether absence equals zero bytes, which seems easy enough to infer for apps that don't care about the difference: ```js const stats = await pc.getStats(); const inbound = findMine([...stats.values()].filter(({type}) => type == "inbound-rtp")); console.log(`Received ${inbound?.bytesReceived || 0} bytes.`); ``` But this seems wrong to bake into the API, especially when `bytesReceived` is only one of [67](https://w3c.github.io/webrtc-stats/#ref-for-dom-rtcstatstype-inbound-rtp-3) `"inbound-rtp"` members, none of which have prose today for what value they should hold ahead of having seen a relevant rtp (or rtcp) packet: timestamp type id ssrc kind transportId codecId packetsReceived packetsLost jitter packetsDiscarded packetsRepaired burstPacketsLost burstPacketsDiscarded burstLossCount burstDiscardCount burstLossRate burstDiscardRate gapLossRate gapDiscardRate framesDropped partialFramesLost fullFramesLost receiverId remoteId framesDecoded keyFramesDecoded frameWidth frameHeight frameBitDepth framesPerSecond qpSum totalDecodeTime totalInterFrameDelay totalSquaredInterFrameDelay voiceActivityFlag lastPacketReceivedTimestamp averageRtcpInterval headerBytesReceived fecPacketsReceived fecPacketsDiscarded bytesReceived packetsFailedDecryption packetsDuplicated perDscpPacketsReceived nackCount firCount pliCount sliCount totalProcessingDelay estimatedPlayoutTimestamp jitterBufferDelay jitterBufferEmittedCount totalSamplesReceived totalSamplesDecoded samplesDecodedWithSilk samplesDecodedWithCelt concealedSamples silentConcealedSamples concealmentEvents insertedSamplesForDeceleration removedSamplesForAcceleration audioLevel totalAudioEnergy totalSamplesDuration framesReceived decoderImplementation Likewise, `bytesSent` is only one of [49](https://w3c.github.io/webrtc-stats/#ref-for-dom-rtcstatstype-outbound-rtp-3) `"outbound-rtp"` members, none of which have prose today for what value they should hold ahead of having seen a relevant rtp (or rtcp) packet: timestamp type id ssrc kind transportId codecId packetsSent bytesSent rtxSsrc mediaSourceId senderId remoteId rid lastPacketSentTimestamp headerBytesSent packetsDiscardedOnSend bytesDiscardedOnSend fecPacketsSent retransmittedPacketsSent retransmittedBytesSent targetBitrate totalEncodedBytesTarget frameWidth frameHeight frameBitDepth framesPerSecond framesSent hugeFramesSent framesEncoded keyFramesEncoded framesDiscardedOnSend qpSum totalSamplesSent samplesEncodedWithSilk samplesEncodedWithCelt voiceActivityFlag totalEncodeTime totalPacketSendDelay averageRtcpInterval qualityLimitationReason qualityLimitationDurations qualityLimitationResolutionChanges perDscpPacketsSent nackCount firCount pliCount sliCount encoderImplementation So you'd be asking for a significant spec change here, if I even understand correctly what change you're proposing. Also, SSRCs can have collisions, so using them to correlate data isn't sound to begin with. This is why [mid](https://w3c.github.io/webrtc-stats/#dom-rtcrtptransceiverstats-mid) and [rid](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-rid) were added to the spec, as the preferred ways to correlate what someone will or won't send (sadly not implemented anywhere yet 😕). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/619#issuecomment-1028162210 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 February 2022 17:12:20 UTC