Webrtc M96 release notes (SDP abolishes Plan B and supports opus red redundant coding)

https://groups.google.com/g/discuss-webrtc/c/Bp8OzBzipSc

Switch to M96 Branch

git checkout branch-heads/4664

PSAs

Plan B and Unified Plan

Plan B yes Chrome/Chromium Unique implementation ,Safari and Firefox Always support Unified Plan,Chrome stay M72 Has supported Unified Plan. To some extent, if it is redeveloped later WebRTC Not to be considered Plan B The support of , because Unified Plan Your support has been very good .

Plan B and Unified Plan Each have advantages and disadvantages , When there is only one way of audio and video, there is no difference between the two schemes , In multi-channel audio and video Unified Plan Every audio and video will have a Mline, This provides a lot of flexibility , Different capabilities can be negotiated for each channel of audio and video , For example, we have a camera and a screen to share , You can let the screen share av1 code , And the camera uses h264. As years with SDP Developers dealing with have to say SDP Sucks,SDP It's really a bad design , It is a standard, but it is also a relatively flexible standard , The implementation of each family may be different , Have to spend a lot of energy on SDP The adaptation of , If you haven't been SDP Your adaptation has plagued you in a sense that you may not fully understand WebRTC. But once standards are established , It's hard for others to shake it , Microsoft once made it ORTC Standard to shield SDP The question of consultation , Finally failed .

be used for SCTP Transmission of DcSCTP library

SCTP（Stream Control Transmission Protocol, Streaming control transport protocol ） RFC 4960

It is a transmission protocol , By default 5000 port , stay TCP/IP The location in the protocol stack and TCP、UDP similar , At the same time have TCP and UDP Characteristics of .
DcSCTP library for the SCTP transport used by WebRTC’s Data Channels
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.

--force-fieldtrials="WebRTC-DataChannel-Dcsctp/Enabled/“

Opus+Red Redundancy coding

Support for RFC 2198 redundancy
Audio redundancy for OPUS using RED is now available. See the PSA for details.

Before that WebRTC If you want to improve the weak network resistance of audio , What can be done is to increase NACK( Retransmission ) And on Opus Of FEC. Now we have more options , stay M96 Of WebRTC Supported the adoption of red To send audio redundancy packets to improve the resistance of audio weak network .RTP Of RED Norms existed long before , It was proposed more than 20 years ago , The basic idea is to send redundant packets , Use RED Put one or two redundant audio frames into each packet , Sometimes it's called “ Out of band FEC”.

Of course , There's a price to this , You can change your audio bit rate from 30kbps Add to 60kbps perhaps 90kbps, However, compared with video, these bit rate increases are not large , Very suitable for audio priority scenes .
Using RED to put one or two redundant audio frames into each packet would give much more resilience to packet loss than Opus FEC. It comes at a cost however, doubling or tripling the audio bitrate from 30kbps to 60kbps or 90kbps (with an additional 10 kbps for the header). Compared to more than one megabit per second of video data it does not seem so bad however.

stay M96 Through setCodecPreferences Method adjustment opus+red In order to open , Default Chrome Only one will be encoded in red Redundant packages , This can improve the weak network resistance without increasing the bandwidth . In addition, you can use WebRTC Encoded Insertable stream To adjust redundancy .

github There are already on how to use demo https://github.com/fippo/opus-fec, In addition, open source Janus The media server already supports .

opus+red Not on by default , Can pass setCodecPreferences Method to adjust the coding order , hold red Put it in opus Before .
opus+red is not active by default but can be activated through the setCodecPreferences API by changing the order of codecs such that red appears before opus. Note that in getStats opus+red will still be identified as “opus”.

webrtc::field_trial::FindFullName("WebRTC-Audio-Red-For-Opus");

m=audio 9 UDP/TLS/RTP/SAVPF 96 111 
a=rtpmap:96 red/48000/2 
a=rtpmap:111 opus/48000/2

1. First packet was Opus (payload type 111);
2. Second packet was RED (payload type 96), but “smallish”;
3. Other packets were RED as well, but all larger and similar in size.