PSA: Chrome M50 WebRTC Release Notes

Skip to first unread message

Christoffer Jansson

Mar 22, 2016, 5:05:50 AM3/22/16
to WebRTC-discuss


WebRTC M50 branch (cut at r11765)


Chrome M50, currently available in Chrome's beta channel, contains over 60 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


For the PeerConnection createOffer and createAnswer methods, we’ve made the error handler argument mandatory. This is part of clearing the way for introducing promise-based versions of these functions.


Support for Multiple RTX Codecs

Along with the fix for issue 4024 to support RTX for multiple codecs, we had to add a few temporary workarounds to simultaneously support talking to old, incorrect Chrome versions (<M50) while still being able to have the correct behavior when talking to newer versions. Old Chrome versions had bugs where it assumed that the underlying codec was RED when it had negotiated RED and RTX associated with VP8. It also could not handle negotiating two or more RTX codecs associated with different codecs. See the CL description for details of the behavior in M50.

Bandwidth Estimation Improvements

With M50 we have significantly improved the bandwidth estimation and congestion control of WebRTC (issue 4711). WebRTC endpoints will now better share the bottleneck link capacity between each other which is important especially for the mesh conference scenario. In addition, WebRTC will now better compete for bandwidth with TCP flows, meaning that someone watching YouTube at the same time as you are having a meeting won't deteriorate your video quality the same way it may have before.

Opus upgrade to v1.1.2

Opus has been upgraded from v1.1 to v1.1.2 (issue 580524). This brings in many optimizations (both architecture dependent and independent) and bug fixes. See more details here.

H.264 behind a flag

Chrome is now able to encode and decode WebRTC video chats using the popular H.264 format. So far, this is an experimental feature behind a flag; instructions on how to enable it are in this PSA.

Bugfixes and Features

  • Issue 472857 Distortion to top of window while waiting to project entire screen.

  • Issue 491247 Right and bottom cut off a tiny bit when projecting entire desktop

  • Issue 501318 ICE completes but no media passes on recent Linux builds

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

  • Issue 570038 Inaccurate, high values reported for googFrameRateSent and googFrameRateInput

  • Issue 570837 Hard cut-off in NaCl audio recording time length. ( NaCl Audio_Encoded )

  • Issue 571594 VP8 encoder crashes when encoded resolution is extremely small

  • Issue 574524 crash while simulating a WebRTC ICE restart

  • Issue 575990 WebRTC/Mac: Unable to select window of a fullscreen app via 'Share your screen' dialog

  • Issue 578277 Remove QTKit support after Chrome stops supporting OS X older than 10.9

  • Issue 582372 CombinedDesktopMediaListTest hangs on Valgrind bots

  • Issue 582916 Assertion failure in blink::RTCPeerConnection::didChangeICEGatheringState

  • Issue 585165 Local video turns black after snapshot

  • Issue 585181 "Failed to parse audio codecs correctly" error thrown in /dtmf/ page

  • Issue 585861 Audio disruptions during peerconnection audio only call on device Tricky and Stumpy

  • Issue 586573 Regression: Remote audio starts from 74:33:55 for G722 codec

  • Issue 588173 Mac_trunk builds are failed to compile on official.desktop.continuous.

  • Issue 588225 FrozenFrames threshold overreach: got 22 > 10 allowed

  • Issue 589951 Android MIPS builder broken

  • Issue 589962 Regression: gUM local video is green

  • Issue 591951 WebRTC doesn't specify what revision of transport sequence number it has implemented.

  • Issue 541561 Add wave header to diagnostic mic input file

  • Issue 554512 Add browser_tests and content_browsertests utilizing the VP9 codec

  • Issue 560371 Use audio render timestamp information to adjust accordingly in clients that wishes so

  • Issue 560378 Mix WebRTC audio in the Chrome mixer

  • Issue 576794 Remove switches::kForceDirectShowVideoCapture

  • Issue 585351 Add OS input glitch UMA stats on Mac

  • Issue 4325 iOS prefers WWAN over WiFi

  • Issue 4898 AsyncTCPSocket stops writing if any packet was partially sent.

  • Issue 4989 Frame rate drops after running AppRTC on iOS for a few minutes

  • Issue 5042 Add encode_time_ms to EncodedFrameObserver

  • Issue 5249 Receiving (for decode) an externally supported encode-only codec causes a CHECK failure + crash

  • Issue 5250 "Default" remote streams stop working on second offer/answer exchange.

  • Issue 5264 H264 with FEC+NACK requires retransmissions of FEC packets which have already been dropped

  • Issue 5413 Offset from CSRCs not properly accounted for.

  • Issue 5424 VCMEncodedFrame::VerifyAndAllocate should allocate 64 additional bits at the end and zero-init them

  • Issue 5427 H264 ffmpeg decoder: FFmpeg initialization thread-safe and behind a flag

  • Issue 5428 H264 ffmpeg decoder: Use a frame buffer pool

  • Issue 5460 Lint fix pacing module

  • Issue 5463 Capture timestamps borked on mac

  • Issue 5473 producer_fec_fuzzer build failure on Windows

  • Issue 5543 The test EndToEndTest.RestartingSendStreamPreservesRtpState has been disabled due to flakiness

  • Issue 5610 WebRTC doesn't specify what revision of transport sequence number it has implemented.

  • Issue 2450 Refactor RTCPSender::PrepareRTCP

  • Issue 4171 Tracking bug for screenshare quality improvements

  • Issue 4711 Improved WebRTC self- and TCP-fairness.

  • Issue 5263 Hook up audio to send-side BWE.

  • Issue 4024 Only one rtx payload type can be registered with webrtc

  • Issue 1665173002: Adapt video encoding CPU usage to number of CPU cores on Mac.  Make CPU usage goal interval consistent with available scaling factors.



Mar 24, 2016, 6:08:58 AM3/24/16
to discuss-webrtc

WebRTC will now better compete for bandwidth with TCP flows

Is that relevant for RTP only or SCTP as well? 

Stefan Holmer

Mar 24, 2016, 9:09:12 AM3/24/16
to discuss-webrtc

On Thu, Mar 24, 2016, 11:09 Shachar <> wrote:

WebRTC will now better compete for bandwidth with TCP flows

Is that relevant for RTP only or SCTP as well? 

These improvements should only affect rtp streams. The sctp streams should already compete fairly with TCP.


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
To view this discussion on the web visit
For more options, visit
Reply all
Reply to author
0 new messages