PSA: WebRTC M55 Release Notes

3548 views
Skip to first unread message

Anatoli Davidson

unread,
Oct 28, 2016, 6:15:29 AM10/28/16
to discuss...@googlegroups.com

M55

WebRTC M55 branch (cut at r14500)


Summary

Chrome M55, currently available in Chrome's beta channel, contains over 20 new features and 35 bug fixes for WebRTC, including 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.

Important PSAs

Features

Renaming AppRTCDemo on Android and iOS to AppRTCMobile

While talking to the wider WebRTC community we realized that the name AppRTCDemo used previously for our mobile demo app is slightly confusing and doesn’t reflect the fact that it’s a mobile app, so we are changing its name to AppRTCMobile to address that concern.

Screen share for Chrome Android available behind flag

To use this feature, enable the flag "Experimental ScreenCapture android" in chrome://flags page and call getUserMedia with constraints "video: {'mandatory': {'chromeMediaSource':'screen'}}". The user needs to both approve system permission (first time) and allow sharing on a chrome infoBar (every time).

Android Screen Capturer in WebRTC

The screen content can now be captured with a new screen capturer implementation from native Android WebRTC.

CVO has been implemented for native iOS capturer

Coordination of video orientation (CVO) has been implemented for the iOS capturer in native iOS WebRTC. This avoids the current flash in the video when the iOS device is rotated, and also avoids reconfiguring the local encoder and remote decoder when the device is rotated.

Auto-focus and video stabilization on Camera2

When available, we now enable auto-focus and video-stabilization in android.hardware.camera2. The auto-focus algorithm continually attempts to modify the lens position to provide a constantly-in-focus image stream. The video-stabilization tries to compensate for motion blur due to small movements of the camera during capture.

Send-side Bandwidth Estimation

A new feedback message and header extension is now offered by Chrome. When both are negotiated Chrome will run all bandwidth estimation logic on the sending client, which in turn enables improved bitrate probing and better convergence time.

Deprecations


Issue 6390

Drop support for legacy camera2 devices.

Issue 6391

Android: Control cricket::VideoAdapter with Java VideoSource instead of VideoCapturer

Issue 6275

Delete QTKit related code

Issue 6318

Removal of capture control methods from VideoTrackSourceInterface.

Issue 6593

Removed receive side audio processing (link to the PSA)


Features and Bugfixes

Chrome


Feature

6274

Add periodic logging of video stats

Feature

6409

Add stats for end-to-end delay.

Feature

650113

Screen capture devices should suspend while there are no consumers

Feature

487935

Screen share for Chrome Android available behind flag

Feature

2347863003

H.264 codec: Check profile-level-id when matching

Feature

4173

Tracking bug for moving BWE logic to the send client

Bugfix

6238

BWE keeps increasing even if feedback isn't received.

Bugfix

6208

H.264 frames shouldn't be decoded if the corresponding SPS/PPS haven't been received.

Bugfix

6195

Outgoing audio packets missing from RtcEventLog

Bugfix

5740

Sort out video frame timestamping

Bugfix

6377

WebRtc H.264 Hardware decoding fails.

Bugfix

6380

signal the remote side to remove candidates when a port is pruned.

Bugfix

6342

Chrome 55 dev includes RFC violation in DTLS

Bugfix

6408

The log output from the level controller has a format that differs from the rest of the log and is hard to parse

Bugfix

5678

Tune QualityScaler for low-bitrate/low-performance use cases

Bugfix

6345

DCHECK hit in WebRtcVoiceMediaChannel::WebRtcAudioSendStream::OnData()

Bugfix

6253

Don't emit pacer delay when network is down

Bugfix

6371

Move encoder configuration/reconfiguration due to frame size change

Bugfix

648528

Regression: Black screen is seen while navigating to Camera

Bugfix

647886

Change WebMediaPlayerMS layers transparency dynamically

Bugfix

652068

Add disable switch for GpuMemoryBuffer backed VideoFrames in media streams

Bugfix

632995

desktopCapture: cursor bitmap too small when sharing a retina display

Bugfix

644526

VEAEncoder in MediaRecorder cannot handle frames sent from peer connection

Bugfix

645903

Expose the MediaDeviceInfo interface object

Bugfix

651426

4.4% regression in webrtc_perf_tests at 14367:14368

Bugfix

445320

HW VP8 encoding offload is not enabled by default on AOS

Bugfix

513633

WebRTC call in Chrome on Android will be cut off 1 min after screen off

Bugfix

640387

Android: video will freeze for a while after Chrome is brought to foreground

Bugfix

2119393002

Fixed time moving backwards in the AudioCodingModule

Bugfix

2334113004

2354843003

Audio delayed in comparison to video.


Native Android/iOS


Feature

6359

Rename AppRTCDemo on Android and iOS to AppRTCMobile.

Feature

6329

Optimize the UMA stats interface.

Feature

6313

Java wrapper for UMA stats macros.

Feature

6232

Add software fallback for MediaCodecVideoEncoder.

Feature

6334

Android CameraEventsHandler interface: Add onCameraDisconnected()

Feature

6325

New internal workings of camera events on Android

Feature

4081

iOS: Investigate iOS8 H/W encoder/decoder

Feature

6327

Android ThreadUtils: Propagate exceptions in invoke functions

Feature

6229

Add functionality in the AppRTC iOS demo client for creating aecdump diagnostic recordings

Feature

6148

New internal workings of camera APIs on Android

Feature

6398

Enable the -Wundef warning for clang

Feature

3968

Mac OS X version links against QTKit.framework - cannot be sent to App Store

Feature

3417

Add local capture to OSX AppRTCDemo

Feature

2280873002

Move getSupportedFormats from capturer interface to camera enumerator.

Feature

2276593003

Add Android Screen Capturer

Feature

2271583003

Implement CVO for iOS capturer

Feature

2317443003

Optimize Android NV12 capture

Bugfix

6357

Enable auto-focus and video stabilization on Camera2.

Bugfix

6347

libjingle: (network.cc:842): Connect failed with 101

Bugfix

6404

Fix a dead lock issue in stopCapture in CameraCapturer

Bugfix

5931

iOS fails to decode video from hw accel h264 Chromium

Bugfix

6428

AppRTCDemo crashes on iOS 10 on camera/microphone access

Bugfix

6411

Texture frames are not returned when dropping frames in CameraCapturer

Bugfix

6397

Switching camera on session based capturing causes onCameraFreezed event to be fired.

Bugfix

6120

Video Orientation Extension not working for back camera

Bugfix

6350

Android AppRTCDemo: eglMakeCurrent fails on some Jelly Bean devices

Bugfix

2295493002

Add a switch to redetermine role when ICE restarts

Bugfix

2350103002

Improves resolution when logging audio rates.

Bugfix

2349263004

Ensures that ADM for Android and iOS uses identical states when stopping audio


Regards
Anatoli

Philipp Hancke

unread,
Oct 28, 2016, 6:54:38 AM10/28/16
to discuss...@googlegroups.com

Send-side Bandwidth Estimation

A new feedback message and header extension is now offered by Chrome. When both are negotiated Chrome will run all bandwidth estimation logic on the sending client, which in turn enables improved bitrate probing and better convergence time.


I do not see any information how this improvement is measured in the bug at all. How exactly is this improvement measured?

Stefan Holmer

unread,
Nov 1, 2016, 9:34:50 AM11/1/16
to discuss...@googlegroups.com
Bitrate probing is more reliable when applied on the send-side since we now know what packets were sent as part of a probe and what packets were not, and don't have to guess. It basically means that a larger percentage of calls have immediate ramp-up to high quality than before.

We've measured that the reliability is higher, but I don't have any numbers to share.

/Stefan

--

---
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/CADxkKi%2BFe2DgdjS2z_PcsZpAD0wiv%2BqivHM0tHx_JkrvSLFxdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Abhimanyu Gangwar

unread,
Nov 19, 2016, 2:33:21 AM11/19/16
to discuss-webrtc
I am facing issues with the latest build of webrtc in video rotation. As soon as the call gets connected, the video rotated 90 degrees. Here are the attached screenshots -

IMG_0002 contains the old behavior which I had with the webrtc built on 22 August.

IMG_0001 contains the new behavior with the latest webrtc built after the cvo related changes.

Thanks,
Abhimanyu
IMG_0002.PNG
IMG_0001.PNG

PhistucK

unread,
Nov 19, 2016, 3:21:24 AM11/19/16
to WebRTC-discuss
You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.
Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.



PhistucK

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4afdda2f-e154-4127-a78e-71f45697e5c4%40googlegroups.com.

Abhimanyu Gangwar

unread,
Nov 26, 2016, 4:22:05 AM11/26/16
to discuss...@googlegroups.com
The issue is now resolved. It was related to the extmap(for video orientation) attribute of sdp not being passed in tact to the other endpoint and as a result improper rendering of orientation. Sorry for inconvenience.

Thanks,
Abhimanyu 

--

---
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/BqqFMSR6s1E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CABc02_%2Bhox9dL-qxFCq%3DcVRTJZbX03gqSC3vaaf1EG8rYZbF_A%40mail.gmail.com.

Danail Kirov

unread,
Dec 6, 2016, 7:17:06 PM12/6/16
to discuss-webrtc
How the send-side bandwidth estimation will work when the remote receive-side is not webrtc based and does not support the new feedback message and header extension?
/Danail

Stefan Holmer

unread,
Dec 9, 2016, 4:50:15 AM12/9/16
to discuss-webrtc
We still support recv-side bandwidth estimation using REMB. The abs-send-time header extension will likely be deprecated though.

pablo platt

unread,
Dec 9, 2016, 7:09:19 AM12/9/16
to discuss...@googlegroups.com
Please don't deprecate the abs-send-time header extension as long as you support receive side REMB.
When using a server in a large conference, the cost of calculating send-side bandwidth for each participant might be too high.
We invested a lot of time implementing receive side bandwidth estimation and we would like to avoid changing it.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAEdus3Le_72XeiB3_fJ8_U7iLh0mkR-2r-dC5kK5ZVbtvK7vdQ%40mail.gmail.com.

OscarD

unread,
Dec 9, 2016, 11:40:56 AM12/9/16
to discuss-webrtc
I'd agree  as well. As long as we keep REMB supported, we should keep abs-send-time as well, as it was included with REMB for a reason. 
Servers (and services) supporting WebRTC may have a nice amount of momentum using and leveraging recv-side bandwidth estimation in their design.

--

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

Philipp Hancke

unread,
Dec 9, 2016, 11:55:38 AM12/9/16
to discuss...@googlegroups.com
2016-12-09 17:40 GMT+01:00 OscarD <os...@tokbox.com>:
I'd agree  as well. As long as we keep REMB supported, we should keep abs-send-time as well, as it was included with REMB for a reason. 
Servers (and services) supporting WebRTC may have a nice amount of momentum using and leveraging recv-side bandwidth estimation in their design.

Not to forget browsers -- Firefox and Edge (insider version).
Reply all
Reply to author
Forward
0 new messages