PSA: WebRTC M83 Release Notes
Anatoli Davidson
WebRTC M83 Release Notes
WebRTC M83 branch (cut at r30987)
Summary
WebRTC M83, currently available in Chrome's beta channel, contains over 10 new features and over 35 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.
Also see the Chromium blog post about Chrome 83 beta release which includes several WebRTC features.
PSAs
Flag to test removal of DTLS 1.0
In accordance with the removal of support for DTLS 1.0, we are providing a command line flag to let users test the effect that removing DTLS 1.0 support from WebRTC will have on their service. No modern service should be affected.
The flag is --force-fieldtrials="WebRTC-LegacyTlsProtocols/Disabled/"
See the PSA for more details.
New restrictions to ice-ufrag and ice-pwd syntax
Starting in M81 the accepted syntax for ICE ufrag/pwd fields has been tightened to match the grammar defined in the ICE spec. Please see this PSA sent to discuss-webrtc for more details. To help some deployed services comply with the new restrictions, some additional characters are being temporarily allowed -- see the PSA for more details.
Features
Insertable Streams Origin Trial
Insertable streams is an experimental feature available as an origin trial that allows Web applications to apply custom processing to the data flowing through a WebRTC peer connection. It aims to support adding end-to-end encryption to applications that transmit audio/video data through an intermediate server. Read more in the explainer. Registration for the origin trial can be found here.
RTCPeerConnection.canTrickleIceCandidates
You can now tell whether or not a remote site supports trickling ICE candidates. This is interesting in some interoperability scenarios.
RTCRtpEncodingParameters.maxFramerate
This encoding parameter allows developers to limit the framerate on a video layer before sending. Use RTCRtpSender.setParameters() to set the new framerate, which takes effect after the current picture is complete. read it back using RTCRtpEncodingParameters.maxFramerate. Setting maxFramerate to 0 freezes the video on the next frame.
RTCRtpSendParameters.degradationPreference
A new attribute for RTCRtpSendParameters called degradationPreference allows developers to control how quality degrades when constraints such as bandwidth or CPU prevent encoding at the configured frame rate and resolution. For example, on a screen share app, users will probably prefer screen legibility over animations. On a video conference users likely prefer a smooth frame rate over a higher resolution. Valid values for degradationPreference are "maintain-framerate", "maintain-resolution", and "balanced".
Deprecations
Features and Bugfixes
Craig Falls
Philipp Hancke
--
---
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/64865d54-e8f1-4b16-8446-819215149691%40googlegroups.com.
Kyle Foley
That link to Jitsi is not correct, it tries to have you install crapware. This is the correct link to Jitsi https://meet.jit.si/
Craig Falls
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/EieMDYtQ9sg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiLZo8LT9RZ2gON5_XukhbMv9GrrqwPeGC6oge_aPEZhOA%40mail.gmail.com.