Stats for FlexFEC

[stefanh]

Hi,

I have a setup with one-way video between a webrtc sender and a Chrome browser. flexfec-03 is negotiated, and seems to be used.

However, the stats (collected in the browser) looks a bit odd. fecPacketsDiscarded is much much larger than fecPacketsReceived (a factor of about 1000), and I get no fecBytesReceived data.

Has anyone else seen this problem?

Br,

Stefan

[Philipp Hancke]

fecPacketsDiscarded is only implemented for audio from what I recall (and describes opus inband fec), are you looking at the right kind of inbound-rtp stats?

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d51f6553-b24e-4968-9e42-00b8c70bd531n%40googlegroups.com.

[[MSFT] Diego Perez Botero]

You'll want to look at the fecBytesReceived for the ssrc corresponding to the inbound-rtp's fecSsrc. Info:
stats: implement fecBytesReceived [42225568] - WebRTC
Specify fecBytesReceived by fippo · Pull Request #762 · w3c/webrtc-stats (github.com)
add rtxSsrc to inbound-rtp and outbound-rtp stats and fecSsrc to inbound-rtp by fippo · Pull Request #765 · w3c/webrtc-stats (github.com)

[stefanh]

I may very well be doing some mistakes, but this is what I get from two calls to getStats happening about 250 ms apart (only the inbound-rtp for video part):

{"id":"IT01V353680029","type":"inbound-rtp","kind":"video","mediaType":"video","ssrc":353680029,"transportId":"T01","jitter":0.004,"packetsLost":18,"packetsReceived":31088,"bytesReceived":22348872,"fecPacketsReceived":128,"fecSsrc":1755550773,"firCount":0,"framesAssembledFromMultiplePackets":5329,"framesDecoded":5329,"framesDropped":0,"framesReceived":5329,"freezeCount":1,"headerBytesReceived":883564,"jitterBufferDelay":29.112676,"jitterBufferEmittedCount":5329,"jitterBufferMinimumDelay":79.933314,"jitterBufferTargetDelay":79.933314,"keyFramesDecoded":2,"mid":"0","nackCount":4,"pauseCount":0,"pliCount":0,"rtxSsrc":1316601390,"totalAssemblyTime":27.940571,"totalDecodeTime":15.702703,"totalFreezesDuration":0.409,"totalInterFrameDelay":88.793,"totalPausesDuration":0,"totalProcessingDelay":45.325030999999996,"totalSquaredInterFrameDelay":1.8357829999999709,"trackIdentifier":"vidTrackName","codecId":"CIT01_102_level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f","frameHeight":768,"frameWidth":434,"framesPerSecond":60,"googTimingFrameInfo":"1078064220,-41,-41,-8,-7,-1,-41,-41,45086702,45086707,45086708,45086709,0,0,1","lastPacketReceivedTimestamp":1717404539681.376,"remoteId":"ROA353680029","retransmittedBytesReceived":81046,"retransmittedPacketsReceived":137,"qpSum":221,"fecPacketsDiscarded":126951}
{"id":"IT01V353680029","type":"inbound-rtp","kind":"video","mediaType":"video","ssrc":353680029,"transportId":"T01","jitter":0.005,"packetsLost":18,"packetsReceived":31206,"bytesReceived":22439375,"fecPacketsReceived":157,"fecSsrc":1755550773,"firCount":0,"framesAssembledFromMultiplePackets":5344,"framesDecoded":5344,"framesDropped":0,"framesReceived":5344,"freezeCount":1,"headerBytesReceived":886884,"jitterBufferDelay":29.203996999999998,"jitterBufferEmittedCount":5344,"jitterBufferMinimumDelay":80.151872,"jitterBufferTargetDelay":80.151872,"keyFramesDecoded":2,"mid":"0","nackCount":4,"pauseCount":0,"pliCount":0,"rtxSsrc":1316601390,"totalAssemblyTime":28.0291,"totalDecodeTime":15.745161,"totalFreezesDuration":0.409,"totalInterFrameDelay":89.043,"totalPausesDuration":0,"totalProcessingDelay":45.460423,"totalSquaredInterFrameDelay":1.8405349999999707,"trackIdentifier":"vidTrackName","codecId":"CIT01_102_level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f","frameHeight":768,"frameWidth":434,"framesPerSecond":60,"googTimingFrameInfo":"1078082220,-42,-42,-8,-8,-1,-42,-42,45086903,45086908,45086908,45086911,0,0,1","lastPacketReceivedTimestamp":1717404539931.585,"remoteId":"ROA353680029","retransmittedBytesReceived":81046,"retransmittedPacketsReceived":137,"qpSum":221,"fecPacketsDiscarded":155014}

So, no fecBytesReceived, but fecPacketsDiscarded (with values indicating it could represent fecBytesReceived and not fecPacketsDiscared). Chrome Version 125.0.6422.141

[[MSFT] Diego Perez Botero]

You've actually uncovered a bug in the current fecBytesReceived implementation, nice. Philipp should be able to share a chromium bug link soon ;)

Would be good to check whether Safari/WebKit suffers from the same bug.

[Philipp Hancke]

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.cc;l=204

-- looks like a copy paste regression here. I should have a fix shortly, thanks for catching that!

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a82a5f96-68f8-4608-b103-1a6c9e718759n%40googlegroups.com.

[stefanh]

Great!

Has there been any discussion on how to determine if (the current level of) FEC is currently useful or not? fecPacketsDiscarded could hint that either the transmission is perfect, or it is to bad for (current level of) FEC to be useful, but I understand it is not implemented.

Also, is the receiver supposed to _not_ send a nack if the missing packet could be re-created by FEC? And is this specced or implementation specific?

Br,

Stefan

[Philipp Hancke]

Am Sa., 8. Juni 2024 um 01:38 Uhr schrieb stefanh <ste...@gmail.com>:

Great!

Has there been any discussion on how to determine if (the current level of) FEC is currently useful or not? fecPacketsDiscarded could hint that either the transmission is perfect, or it is to bad for (current level of) FEC to be useful, but I understand it is not implemented.

That was simply to much work to wire up and nobody had time.

Frame assembly time is a pretty good metric for evaluation but obviously does not tell you how much you are wasting

Also, is the receiver supposed to _not_ send a nack if the missing packet could be re-created by FEC? And is this specced or implementation specific?

That is a great question, see also https://datatracker.ietf.org/doc/draft-majali-avtcore-rtcp-fb-timing-cfg/

I do not think there is any spec for how NACK and FEC interact - we understand both mechanisms in isolation but the interactions...

IMO such configuration is not necessary and one should wait "a bit longer" to NACK when FEC is negotiated but doing any tuning on WebRTC in the browser has to go through SDP because of the lack of proper knobs.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8d7a7681-b57b-4a1a-a24b-e4db30b9e6b0n%40googlegroups.com.

[stefanh]

Thanks for the tip Philipp, I'll evaluate use of frame assembly time.

I agree that waiting "a bit longer" to NACK when FEC is negotiated should be sufficient - hopefully implementations will do that.

BTW, is it possible to provide an estimation of when the bug  fix(fecPacketsDiscarded -> fecBytesReceived) will arrive in Chrome (stable).

Cheers,

Stefan

[Philipp Hancke]

https://chromiumdash.appspot.com/commit/5c4c0b77ecbd23f20ee03fcd4f5c3f4abfe24d2a shows as landed in M127 (thanks to Harald submitting it right away) so it should have made it before the branch cut which happens today!

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5a713688-dbd8-45b0-94b3-3311dbbd51bdn%40googlegroups.com.