Re: [webrtc-stats] WPT tests are wrong about when "outbound-rtp" and "inbound-rtp" stats appear (#619)

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