PSA: WebRTC M55 Release Notes

[Anatoli Davidson]

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]

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]

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]

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

[PhistucK]

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]

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]

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]

We still support recv-side bandwidth estimation using REMB. The abs-send-time header extension will likely be deprecated though.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/62d9fe95-9eb3-4d58-9075-485f5e3d11f3%40googlegroups.com.

[pablo platt]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/62d9fe95-9eb3-4d58-9075-485f5e3d11f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/62d9fe95-9eb3-4d58-9075-485f5e3d11f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

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

[裴以明]

How did "Bitrate probing" work before M55? Does this indicate a probe triggered by the ProbeController?