FID SSRC group meaning for video streams

333 views
Skip to first unread message

Michal Śledź

unread,
Oct 23, 2023, 10:55:08 AM10/23/23
to discuss-webrtc
Hi,
when generating SDP offer in Google Chrome, video mlines include FID ssrc-group consisting of two different SSRC values. I assume this is because of RTX extension but I cannot find an RFC with the official explanation. 

To be more specific, this code

pc = new RTCPeerConnection();
pc.addTransceiver("video");
await pc.createOffer();

results in the following mline

m=video 9 UDP/TLS/RTP/SAVPF 96 97 102 103 104 105 106 107 108 109 127 125 39 40 45 46 98 99 100 101 112 113 114
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:kjd2
a=ice-pwd:msZ0QxszHXStn4gY7qpbzVBY
a=ice-options:trickle
a=fingerprint:sha-256 EF:84:08:5D:3D:56:3E:09:D5:7C:8B:9B:8C:A9:7A:F1:32:5A:DA:4E:7F:CD:2D:16:54:0C:87:C7:2D:87:40:B7
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:- 697eaa9c-8746-4e4f-9adf-28523da04eb0
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=102
a=rtpmap:104 H264/90000
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:105 rtx/90000
a=fmtp:105 apt=104
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=106
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:125 rtx/90000
a=fmtp:125 apt=127
a=rtpmap:39 H264/90000
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=fmtp:39 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f
a=rtpmap:40 rtx/90000
a=fmtp:40 apt=39
a=rtpmap:45 AV1/90000
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=rtpmap:46 rtx/90000
a=fmtp:46 apt=45
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:112 red/90000
a=rtpmap:113 rtx/90000
a=fmtp:113 apt=112
a=rtpmap:114 ulpfec/90000
a=ssrc-group:FID 3183563836 1316502212
a=ssrc:3183563836 cname:SFiuHr8gf6parQlB
a=ssrc:3183563836 msid:- 697eaa9c-8746-4e4f-9adf-28523da04eb0
a=ssrc:1316502212 cname:SFiuHr8gf6parQlB
a=ssrc:1316502212 msid:- 697eaa9c-8746-4e4f-9adf-28523da04eb0

How do I know which SSRC is for the RTX stream?

I checked RFC 5576, RFC 8829, RFC 3388 and RFC 4588 but I couldn't find exact meaning.

Philipp Hancke

unread,
Oct 23, 2023, 1:05:21 PM10/23/23
to discuss...@googlegroups.com
Why "FID" was chosen is not explained by
but the description in
reads like "this is a different codec so you need FID".

The first SSRC is the primary (for media), the second one should be used for sending RTX packets.

--
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/bdcde6a4-c68c-4ce2-9242-10f2620a9170n%40googlegroups.com.

Michal Śledź

unread,
Oct 24, 2023, 2:59:18 AM10/24/23
to discuss-webrtc
Thanks!

But the fact that the first SSRC is the primary one and the second SSRC is for RTX packets is not stated directly in this RFC, is it?
Would it be suitable to add one more example there? Current examples only show session level FID group so how to logically group multiple mlines. I think it would be nice to include RTX example showing how FID can be used to signal multiple SSRC values for a single mline. I would be happy to submit PR.

Philipp Hancke

unread,
Oct 25, 2023, 8:21:21 AM10/25/23
to discuss...@googlegroups.com
Am Di., 24. Okt. 2023 um 08:59 Uhr schrieb Michal Śledź <michal...@swmansion.com>:
Thanks!

But the fact that the first SSRC is the primary one and the second SSRC is for RTX packets is not stated directly in this RFC, is it?

Bear with me. RFC 3388 defines FID for multiple m-lines but as a grouping mechanism between m-lines. The right spec is
which defines ssrc-group. This then mingles with
which defines FID for RTX (but does not have a grouping mechanism inside a m-line which is only provided by the newer RFC 5576)

Both "plans" use the FID group as we do today
but it isn't clear where that is actually described in detail :-)

Would it be suitable to add one more example there? Current examples only show session level FID group so how to logically group multiple mlines. I think it would be nice to include RTX example showing how FID can be used to signal multiple SSRC values for a single mline. I would be happy to submit PR.

RFCs (even if we figured out the right one) are cast in stone so updating it is way more involved than a simple pull request :-(
 
Reply all
Reply to author
Forward
0 new messages