PSA: Chrome M52 WebRTC Release Notes

[Christoffer Jansson]

M52

WebRTC M52 branch (cut at r12798)

Summary

Chrome M52, currently available in Chrome's beta channel, contains over 30 bug fixes, enhancements and stability 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.

Important PSAs

Features

H.264 Support

H.264 support is now available for all desktop platforms. Hardware encode support has been added for OS X. The software encode performance on Linux, CrOS and Windows is not on par with VP8, yet. We will continue to improve the performance of the H.264 software encoder in the next releases.

ECDSA-based Certificate Generation

The Elliptic Curve Digital Signature Algorithm (ECDSA) is now used as default for generating RTCCertificates. For more details, head over to the Web Fundamentals article.

Bugfixes and Features

• Issue 565278 Constructing RTCPeerConnection with an expired RTCCertificate should fail

• Issue 569005 RTCPeerConnection.generateCertificate: Parameter to decide when a certificate shall expire

• Issue 576624 Echo Cancellation not working as well as in prior versions of Chrome

• Issue 581354 Persistent storage of RTCCertificate with IndexedDB

• Issue 595308 RTCVideoEncoder not usable from non-construction thread

• Issue 597095 Starting chrome with --enable-webrtc-h2-h264-encoding flag results in unreliable framerate

• Issue 603411 Allow testing of new AEC tuning with a command line switch

• Issue 607179 Renderer can crash during an enumeration in debug builds while devices are added/removed

• Issue 611574 Remove extension only limitation for H264

• Issue 612366 Hangouts does hundreds of context switches per second when idle

• Issue 612992 H.264: dip in googAvailableSendBandwidth not the same as bitsSentPerSecond

• Issue 614181 Regression: Unable to join apprtc calls after leaving an existing call and joining a new room

• Issue 615272 [H264] Apprtc loopback call video freezes on device Big and Blaze with H264

• Issue 346021 Make it possible for JS to find out if optional constraints cannot be parsed.

• Issue 5675 RTX codec doesn't work properly when one side is configured to receive vp8+red+rtx and the other side only sends vp8+rtx.

• Issue 5762 webrtc can't enable audio nack in recvonly stream

• Issue 5772 Sending audio is stopped when AudioSendStreams are recreated

• Issue 5780 Potential division by zero in RtpToNtpMs()

• Issue 5783 Possible wrong rotation of remote video feed when remote side changes orientation

• Issue 5795 Switch default from RSA-1024 to ECDSA P256 for certificates

• Issue 5823 Send-side BWE sometimes reports a lot of packet reordering.

• Issue 5875 The delay agnostic AEC delay estimate is incorrectly updated when the farend is silent

• Issue 5909 usrsctp causes frequent wakeups on all devices, even when not in use

• Issue 5606 Reduce complexity for inactive receive audio channels

• Issue 5608 Implement NetEq muted state

• Issue 5609 Propagate muted state from NetEq to AudioConferenceMixer

• Issue 5645 Improve send/receive timestamps for bitrate prober.

• Issue 3377 Don't include "-1 stats"

• Issue 1161 Stable-state ICE checks now sent every 2500ms, not every 900ms.

• Issue 1015 Opus variable frame-size support

--

/Chris

[bl...@webrtc.org]

New features tracked in issues 5608 and 1015 deserve to be called out explicitly, too. NetEq supports now a so called muted state to save CPU cycles for inactive receive channels. Tests show that the CPU usage for a Hangout with 16 remote participants decreased by 8% on a MacBook Pro 13". We have also added receiver support of max frame length from 60ms to 120ms for Opus.