anyRTC官方提供M69源码下载 WebRTC M69 branch
概述
WebRTC M69, currently available in Chrome's beta channel contains over 10 new features and over 45 bug fixes, enhancements and stability/performance improvements. As with previous releases, we encourage all developers to run versions of Chrome on the Canary, Dev, and Beta channels frequently and quickly report any issues found. Please take a look at this page, for some pointers on how to file a good bug report. The help we have received has been invaluable!
The Chrome release schedule can be found here. Native libraries for Android and iOS are built on weekly basis and available on JCenter and CocoaPods; the Changelog is available here.
介绍
Update on Unified Plan transition
We are working on our commitment towards WebRTC 1.0. One of the biggest pieces of this is switching to the spec compliant SDP format called Unified Plan which is important for cross-browser compatibility, especially when multiple tracks of the same kind are signaled. The sdpSemantics configuration for controlling whether to use Unified Plan has been in Chrome since M65, but it's not until M69 that RTCRtpSenders and RTCRtpReceivers have been updated correctly to reflect the SDP. Also new in M69 are RTCRtpTransceivers, which represent the m= sections of the SDP, only available in Unified Plan. See the transition plan and keep an eye out for upcoming PSAs regarding the switch; your application may be affected by incompatibilities between the old and new format.
PSA: DataChannel closing procedure changing
The DataChannel closing procedure has been changed to match the standard. As a result, if you close a DataChannel from a new version of WebRTC, and the other endpoint is using an old version, it will be stuck in the "closing" state. This is already what happens if you close a DataChannel from Firefox and the other side is Chrome (as Firefox is already doing the correct procedure). See original PSA for more details.
特性
Added RTCRtpSender.getCapabilities() / RTCRtpReceiver.getCapabilities()
The static method getCapabilities() returns the most optimistic view of the capabilities of the system for sending or receiving media of the given kind. It does not reserve any resources, ports, or other state but is meant to provide a way to discover the types of capabilities of the browser including which codecs or RTP extensions may be supported. For more details see the original Intent to Implement and Ship on the blink-dev mailing list.
Per-layer maxBitrate support in RTCRtpSender.setParameters()
Setting maxBitrate now properly works for simulcast and allows setting bitrate limits per layer (RTCRtpEncodingParameters). Previously, the setting would only work for setting the maxBitrate to the RTCRtpSender as a whole. For more details see this PSA.
Added RTCRtpTransceiver and related APIs behind sdpSemantics:'unified-plan'
The following new APIs are supported when Unified Plan is used:
RTCRtpTransceiver
RTCPeerConnection.addTransceiver()
RTCPeerConnection.getTransceivers()
RTCTrackEvent.transceiver (RTCPeerConnection.ontrack fires with this attribute set)
These are enabled if {sdpSemantics:’unified-plan’} is passed to the RTCPeerConnection constructor or if command line flag --enable-blink-features=RTCUnifiedPlanByDefault is used. Unified Plan is the spec agreed-upon behavior and is different from Chrome’s current behavior (known as Plan B ). In particular, the SDP format and lifetime of senders and receivers are different, which may cause incompatibilities between clients with different SDP semantics. For more information, see PSA.
移除
Non-linear beamformer removed (PSA)
The nonlinear beamformer in the audio processing module is deprecated, to ease refactoring and because of its very low usage. This entails the following API changes.
Removed:
webrtc::AudioProcessingBuilder::SetNonlinearBeamformer
webrtc::Beamforming
modules/audio_processing/beamformer/
Marked deprecated:
*webrtc::ConfigOptionID::kBeamforming
Features and Bugfixes