PSA: WebRTC M80 Release Notes

6309 views
Skip to first unread message

Anatoli Davidson

unread,
Jan 15, 2020, 9:49:39 AM1/15/20
to discuss...@googlegroups.com

WebRTC M80 Release Notes


WebRTC M80 branch (branch id: 3987, cut at r30022)

Summary


WebRTC M80, currently available in Chrome's beta channel, contains 5 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.

PSAs

Changes in WebRTC branch names

Starting from Dec 02, 2019, WebRTC switched over to daily branching in order to improve the overall Chrome branching process (see crbug.com/1020605). The branch names are now matching the Chromium’s branch names, so rather than being refs/branch-heads/m$MILESTONE (where $MILESTONE is the Chromium milestone, for example M79), branches will now be refs/branch-heads/$BRANCH_NUMBER (where $BRANCH_NUMBER is a monotonically increasing number, for example 3987 which is associated with the M80 Chromium branch), just like chromium/src. You can find more details in this PSA.

Deprecating binary mobile libraries

The webrtc.org open source repository contains platform implementations for Windows, Mac, iOS and Android. These are primarily utilized for automated testing. Browsers and other applications that embed WebRTC often have developed their own highly optimized platform code with custom capture/render components matching the applications architecture.

We have decided to discontinue the distribution of precompiled libraries for Android and iOS. The script for creating the AAR library can be found here, the build script for iOS is located here.

Features

setLocalDescription() and setRemoteDescription() with “rollback”

The ability to “rollback” an offer is one of the cornerstones to supporting Perfect Negotiation, a pattern allowing two-way offer-answer exchanges that abstracts away the signaling between peers, without risk of glare (an offer coming in outside of “stable” state). Rolling back an offer means to undo effects of setLocalDescription(offer) or setRemoteDescription(offer). In M80, “rollback” is supported through three different means:

  • Explicit SLD “rollback”: pc.setLocalDescription({type:’rollback’}), rolls back to “stable” signaling state.

  • Explicit SRD “rollback”: pc.setRemoteDescription({type:’rollback’}), which has the same effect as the above.

  • Implicit SRD “rollback”: pc.setRemoteDescription(incomingOffer) when in the has-local-offer state. Prior to M80 this would have thrown an exception. In M80, this rolls back the local offer and applies the remote offer, all in one operation (avoiding possible races with other signaling messages).

Rollback issue: https://crbug.com/980875. Perfect Negotiation issue (ongoing): https://crbug.com/980872.

Parameterless setLocalDescription()

Now RTCPeerConnection.setLocalDescription() can be invoked without arguments. This implicitly creates and offer or answer (depending on signalingState) that is set. This avoids a possible race with handling incoming offers while creating an offer, which can happen if you do “pc.setLocalDescription(await pc.createOffer())” instead. This is part of ongoing efforts to support Perfect Negotiation. See https://crbug.com/980872.

Deprecations


Issue

Description

Component

9878

Remove pointer-to-submodule interfaces of webrtc::AudioProcessing

Audio

10998

Delete support for non-standard GTURN relay servers

Network>ICE

Features and Bugfixes


Type

Issue

Description

Component

Feature

11120

Add ExponentialMovingAverage

Network>ICE

Feature

11140

Estimate Connection RTT based on EventBasedExponentialMovingAverage

Network>RTP

Feature

11042

Add AV1 rtp packetization

Network>RTP

Bug

11145

Packet loss concealment duplicates audio across channels in stereo

Audio

Bug

11083

Stereo and mono signals are incorrectly upmixed to surround in the audio coding module

Audio

Bug

11131

The analog AGC gain is reset to zero at re-initializations

Audio

Bug

11150

AEC3: The number of render signals is incorrectly inferred on the echo audibility estimator.

Audio

Bug

11151

AEC3: For multiple render channels the AEC3 is slower to track nonlinearities in the echo paths

Audio

Bug

11153

For multiple channels the way that AEC3 chooses the signals to do delay estimation is error-prone

Audio

Bug

11180

A user-defined copy constructor is needed for the config struct in AudioProcessing

Audio

Bug

9535

Refactor and improve APM API and configuration

Audio

Bug

700037

Desktop Capture Media Picker does not allow sharing of UWP applications.

Blink>GetUserMedia>Desktop

Bug

1027117

During a call, when playing out mono audio on a surround setup device, there is full echo

Blink>WebRTC>Audio

Bug

1029707

AEC3: The number of render signals is incorrectly inferred on the echo audibility estimator.

Blink>WebRTC>Audio

Bug

1029717

AEC3: For multiple render channels the AEC3 is slower to track nonlinearities in the echo paths

Blink>WebRTC>Audio

Bug

1029740

For multiple channels the way that AEC3 chooses the signals to do delay estimation is error-prone

Blink>WebRTC>Audio

Bug

1030179

AEC3: The high-pass filter is not turned on by default when AEC3 is active

Blink>WebRTC>Audio

Bug

1019222

addIceCandidate to use the PeerConnection's Operations Chain

Blink>WebRTC>PeerConnection

Bug

980885

setLocalDescription() that implicitly creates the offer or answer

Blink>WebRTC>PeerConnection

Bug

980875

setRemoteDescription() with "rollback"

Blink>WebRTC>PeerConnection

Bug

11133

Add ability to remove detailed logging from RTC_CHECKs

Build

Bug

11015

Disabled by bw layers and streams should be counted as bw limited quality in GetStats

GetUserMedia, Video

Bug

11078

Re-update scoped_refptr from chromium so that move works

Internals

Bug

11154

Rename TimeController::Sleep to AdvanceTime

Internals

Bug

11053

MemoryLogWriter sometimes drops parts of the log

Internals

Bug

11125

Make logging optional in WebRTC

Internals

Bug

9085

OpenSSLAdapter Should Inject Session Cache Not Factory

Network

Bug

10750

Don't use mutable RTP extensions in FEC.

Network, Video

Bug

11038

Remote mDNS candidates must not be paired with local relay candidates

Network>ICE

Bug

11019

Implement PeerConnection operation chain

PeerConnection

Bug

11059

Do not use turn server as stun server

PeerConnection

Bug

6857

peerconnection_client tool not working

PeerConnection, SampleApps, Video

Bug

11108

Add totalInterFrameDelay to RTCInboundRTPStreamStats

Stats

Bug

10744

RTCInboundRtpStreamStats.fractionLost should be missing if RTCP is disabled

Stats

Bug

10525

Stats: bytesSent/bytesReceived should not include header and padding

Stats

Bug

11064

Return status instead of CHECKing in event log parser

Tools

Bug

11025

WebRTC does not provide correct width/height for H.264 streams which have NALUs before SPS

Video

Bug

11000

SimulcastEncoderAdapter should support partial software fallback

Video


Thomas Barthélémy

unread,
Jan 23, 2020, 3:52:49 AM1/23/20
to discuss-webrtc
Hey (=

[Deprecating binary mobile libraries]

Would you have some comment on possible consequences of this deprecation and the "reasons" mentioned in the release note:

These are primarily utilized for automated testing.
 
Browsers and other applications that embed WebRTC often have developed their own highly
optimized platform code with custom capture/render components matching the applications architecture.

Is there any chance that support of Android and iOS implementation in this repository would be discontinue in a near future?

Would you suggest to start implementing our own platform code for mobile apps if we were relying on webrtc.org implementation for iOS and Android "as-is"?

Thanks in advance for your answer,

Thomas.

Alexandre GOUAILLARD

unread,
Jan 23, 2020, 5:56:42 AM1/23/20
to discuss...@googlegroups.com, kthel...@webrtc.org

Is there any chance that support of Android and iOS implementation in this repository would be discontinue in a near future?


Im not working for google, but as long as chrome needs to run on those platforms, you can expect to have a webrtc build. Practically, as long as you see a dedicated build bot you re good.

see the specific webrtc-in-chromium waterfall (the iOS builds are within the macOS builds)

and the webrtc standalone builds:
 
Would you suggest to start implementing our own platform code for mobile apps if we were relying on webrtc.org implementation for iOS and Android "as-is"?

There are 3 different things:
- libwebrtc
- the app level code (like what was in the iOS framework, and/or what is shipped in appRTC in addition to libwebrtc)
- the rebuild binary packages of the above

they are just removing the convenience of the rebuild binary package, while leaving the iOS and android source code and the build tools available. up to you to recreate the package if you want. or at least that's how I read It. Maybe @kthel...@webrtc.org can tell us more?

--

---
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/3e85a1eb-597c-49d8-9c73-62251bb8e656%40googlegroups.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

Huib Kleinhout

unread,
Jan 24, 2020, 5:40:10 AM1/24/20
to discuss-webrtc

While keeping up with WebRTC milestones gives you the latest features and security fixes, it does require further work from app developers to quality control each release for their app. This post gives an idea of what would be a typical approach for that.

The process for creating custom mobile binaries from the webrtc source code is outlined in this documentation. App developers can continue to build the mobile libraries themselves. The possibility to build mobile apps based on webrtc.org source code is not going away.

Huib Kleinhout
Product Manager @ Google

Alexandre GOUAILLARD

unread,
Jan 24, 2020, 9:02:08 AM1/24/20
to discuss...@googlegroups.com
are you sure the documentation you pointed to is up to date?
this is what the android and iOS sections state, is it correct?

"

WebRTC Android development

Prebuilt libraries

The easiest way to get started is using the official prebuilt libraries available at JCenter. These libraries are compiled from the tip-of-tree and are meant for development purposes only.

"


"

WebRTC iOS development

Using Cocoapods

The WebRTC framework is published on cocoapods.org. The framework is built from tip-of-tree.

"


--

---
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.

Alexandre GOUAILLARD

unread,
Jan 24, 2020, 9:37:36 AM1/24/20
to discuss...@googlegroups.com
in any case, Google is already giving us a lot by just making all of this code for free with a very permissive license. If we need more I believe it's better to rise to the opportunity to make a project or a product.

When developing the Temasys IE and safari plugin back in 2014, I quickly realised that my dev was stuck spending 90% of his time dealing with libwebrtc and NOT with what he should  be spending his time on, the plugin. I jumped in and created cmake code to fetch and patch the code, drive depot_tool (gn, ninja), import the unit tests and run them, along with added tests, and package the result. Quickly, the engineers working on the plugin and on apps went back to spending 80% of their time on our app. 

[And don't get me started on toolchain updates (compilers, libraries, C++ version, ) or even versions naming convention changes (without m, with m, hash, ...) ....]
Slides here (skip to #12 directly) https://www.slideshare.net/alexpiwi5/testing-and-packaging-webrtc-stack

I think developers expectations are the same today: Spend time building one's app and getting to market, not struggling with compiling, testing, integrating, and updating WebRTC.
That's why we created the cosmo libwebrtc packages:

For App, SDK Developers and DevOps who:
- Do not want to deal with fetching, building, and validating libwebrtc
- Want to harness the strengths of WebRTC and easily link libwebrtc into their project (not digging in the depot_tool code for compiler flags or DEFINEs)
- Want to rebase/update libwebrtc easily when a new version is out. (migration guides, example code, UML diagrams)

So we do the heavy lifting on a crazy matrix of configurations so that others don't have to (actively from 69 to m79, win/linux/mac/ios/android). We cover most of the options google does, and some they don't (openssl, H264 royalty free, AV1, End-to-end-encryption, ....). See the screenshot attached. It does not work for everyone, but for many, it s going to save you months of work.

All the code is there on the table, but it's not easy. Ask yourself how much is your time worth, and where you would rather spend it.
Screen Shot 2020-01-24 at 10.11.09 PM.png

Philipp Hancke

unread,
Jan 25, 2020, 3:30:50 AM1/25/20
to discuss...@googlegroups.com
Am Fr., 24. Jan. 2020 um 11:40 Uhr schrieb Huib Kleinhout <hu...@webrtc.org>:

While keeping up with WebRTC milestones gives you the latest features and security fixes, it does require further work from app developers to quality control each release for their app. This post gives an idea of what would be a typical approach for that.

The process for creating custom mobile binaries from the webrtc source code is outlined in this documentation. App developers can continue to build the mobile libraries themselves. The possibility to build mobile apps based on webrtc.org source code is not going away.

Things have been said in the past (2015?) about "100% open source" and I always had the impression that there was at least some effort made to keep it that way.

Can you update the position on that? In particular after the (horrible) website update that changed
  WebRTC is a free, open project
to something non-commital about an "open-source standard" (which is bullshit; there are open standards and there is open source)


Danilo

unread,
Jan 27, 2020, 4:41:23 AM1/27/20
to discuss-webrtc
On Friday, January 24, 2020 at 3:37:36 PM UTC+1, Alexandre GOUAILLARD wrote:
When developing the Temasys IE and safari plugin back in 2014, I quickly realised that my dev was stuck spending 90% of his time dealing with libwebrtc and NOT with what he should  be spending his time on, the plugin. I jumped in and created cmake code to fetch and patch the code, drive depot_tool (gn, ninja), import the unit tests and run them, along with added tests, and package the result.

Here is another approach, using Docker, in order for the build process to be repeatable: https://github.com/threema-ch/webrtc-build-docker

Cheers,
Danilo

Alexandre GOUAILLARD

unread,
Jan 27, 2020, 7:00:52 AM1/27/20
to discuss...@googlegroups.com
Hi danilo,

there are a lot of approaches, some that I actually list in my slides, as I think it's polite to give credit to people, but many are reductive in nature, i.e. works only for one environment, or one target,... etc. If you re only interested in building, on android and linux, and are not testing, nor packaging, nor integrating, the repo you mentioned is sufficient.

What we wanted to achieve, was to have a system that would:
- work on all the OS webrtc builds on (we did not go for fuchsia, but we support UWP build, and all kind of options)
- arbitrary patches
- run exactly the same tests as google does,
- packages into os specific installers (PackageMaker on mac, NSIS on windows, .......) with licence, warning, etc
- ship with CMAKE build scripts that would allow to pass along the toolchain info as well as the compiler arguments, DEFINEs, .....) since CMake is almost the defect C++ build tool (QT 6 is cmake only, MSVC uses cmake, all of linux is more or less cake-based, ...)
- test POST install, with complete apps (because that's often where problems occur, not during the self-contained build itself)
- have the equivalent of google waterfall,

all that with simpler tools, that would more used than google depot tools (hence the cmake/ctest/cdash/cpack choice), and in a way that a single ressource could handle it on max 50% FTE. The idea was that angry bird was developed by a single vietnamese in his garage, and given the build system of libwebrtc that would not be possible. You should be able to use libwebrtc without having the equivalent of google infra team (and GOMA) behind you.

On android and linux, as many messages on this mailing list will show, just compiling is not enough. NDK / SDK mismatches plus standard libraries mismatches are a headache. In our package, we redistribute the entire toolchain that was used for android, as well as all the arguments of the compilers, linkers, and other tools, to make sure that there is no such mismatch. For now it makes big packages, but at least, it just works (TM) :-)

Anyway, there are many ways to reach one's goal.
We're not trying to convince people to use our approach, we are just mentioning it exists in the case people would be interested. 

Cheers.

--

---
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.

Danilo

unread,
Jan 27, 2020, 7:16:01 AM1/27/20
to discuss-webrtc
Hello Alexandre


On Monday, January 27, 2020 at 1:00:52 PM UTC+1, Alexandre GOUAILLARD wrote:
there are a lot of approaches, some that I actually list in my slides, as I think it's polite to give credit to people, but many are reductive in nature, i.e. works only for one environment, or one target,... etc. If you re only interested in building, on android and linux, and are not testing, nor packaging, nor integrating, the repo you mentioned is sufficient.

Sure, I never claimed that this repo is a general solution, just an idea how building can be done in a slightly more reproducable way than "ensure that your development computer is set up correctly". We do packaging and testing separately.

Danilo

Alexandre GOUAILLARD

unread,
Jan 27, 2020, 8:11:08 AM1/27/20
to discuss...@googlegroups.com
fair enough. Still, how do you do for windows or mac builds with docker?

Here is some heuristics we use, if it helps anyone.
- We're still struggling with automatic installation of MSVC (especially the additional libs), but I plan to corner some of the MS guys next IETF for that :-) Anybody who has scripts to do that, and would be willing to share, we would love to get them.

This is own we do it today:

curl -kLRO https://xxxxxxxxx.com/download/win/vs_community.exe -f --retry 5 -C -

curl -kLRO https:/xxxxxxxxxx.com/download/win/winsdksetup.exe -f --retry 5 -C -


vs_community.exe ^

--add Microsoft.VisualStudio.Workload.NativeDesktop ^

--add Microsoft.VisualStudio.Component.VC.ATLMFC ^

--includeRecommended --passive --norestart --force


winsdksetup.exe /features + /q --


del vs_community.exe

del winsdksetup.exe


- right now we have build bot images that contains dev env for each OS, and a huge pile of mac minis for MacOS and ios.
- We're taking the CONAN path for otherwise managing the toolkits and build artefacts.
- We have hardened the cmake scripts to exit with a nice comprehensive message anytime the dev env is wrong, as a safety net. Lots of hour saved NOT looking into depot_tools.

if( WIN32 )

# and if msvc 2019 16.3+

  add_definitions( -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH )

endif()


#----------------------------------------------------------------------------

# Linux only: Check if libc++ is available by compiling a small program

if( UNIX AND NOT APPLE )

  include( CheckCXXSourceCompiles )

  check_cxx_source_compiles("

    #include <iostream>     // std::cout

    #include <algorithm>    // std::count_if

    #include <vector>       // std::vector


    bool IsOdd (int i) { return ((i%2)==1); }


    int main () {

      std::vector<int> myvector;

      for (int i=1; i<10; i++) myvector.push_back(i); // myvector: 1 2 3 4 5 6 7 8 9


      int mycount = count_if (myvector.begin(), myvector.end(), IsOdd);

      return 0;

    }" LIBCXX_FOUND )

  if( NOT LIBCXX_FOUND )

    MESSAGE( STATUS "ERROR: libc++ not found" )

    MESSAGE( FATAL_ERROR "ERROR: please install packages libc++-dev and libc++abi-dev" )

  endif()

endif()


--

---
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.

Anatoli Davidson

unread,
Jan 29, 2020, 2:08:16 AM1/29/20
to discuss...@googlegroups.com
Thanks Alexandre for flagging this, and thanks Philipp Hancke for submitting a CL that fixes the text on those pages (by removing sections about prebuilt libraries)! This is fixed now.

-Anatoli

Philipp Hancke

unread,
Feb 5, 2020, 7:29:39 AM2/5/20
to discuss...@googlegroups.com
late PSA since there were now two bugs filed:

  RTCPeerConnection.close() does not fire events anymore.

See https://bugs.chromium.org/p/chromium/issues/detail?id=1023736 for the fix and links to the specification.

--

---
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.
Reply all
Reply to author
Forward
0 new messages