PSA: WebRTC M64 Release Notes

3542 views
Skip to first unread message

Anatoli Davidson

unread,
Dec 20, 2017, 7:30:44 AM12/20/17
to discuss...@googlegroups.com

M64

WebRTC M64 branch (cut at r20918)

Summary

WebRTC M64, currently available in Chrome's beta channel and as native libraries for Android and iOS, contains over 10 new features and over 40 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.

Important PSAs

PSA: getUserMedia() error values

Since Chrome M64, getUserMedia() returns error values in accordance with the Media Capture and Streams spec. More details can be found here.

PSA: addTrack(), removeTrack(), ontrack and getSenders()

Significant portions of the RTP Media API are shipping for spec-compliant ways of handling the streams and tracks of an RTCPeerConnection. The new APIs, while not fully featured yet (more details here), allow applications to move away from legacy addStream()/removeStream()/getLocalStreams().


Added to RTCPeerConnection: addTrack(), removeTrack(), getSenders() and ontrack.

New interface: RTCRtpSender (track attribute only).

New event: RTCTrackEvent (full support minus transceiver attribute).

PSA: video_frame_api split into two targets

As of commit pos 20913, api:video_frame_api_i420 in the C++ API has been split out of api:video_frame_api. Depend on the former if you include i420_buffer.h.

Features

Improved bandwidth estimation for screen capture streams

When send-side bandwidth estimation is enabled for a screen content stream, WebRTC will now better handle the fact that the encoder may not always make full use of the available bandwidth. In conjunction, the aggressiveness of the paced sender has been reduced. This may increase median latency, but should result in a significant reduction of large latency events.


No action (apart from negotiating send-side BWE) is required to use this feature.

Deprecations


Platform

Issue

Description

Component

Chrome

8472

GetHistogramName() implementation in WebRTC can be removed

Cleanup

Chrome

8493

Replace deprecated FFmpeg APIs

Video

Chrome

661350

Re-deprecate ffmpeg avcodec_decode_audio4 and avcodec_decode_video2

Blink>WebRTC, Internals>Media>FFmpeg

Chrome

789351

Remove unused WebRTC event logging API

Blink>WebRTC>Tools

Features and Bugfixes

Chrome


Type

Issue

Description

Component

Feature

7218

APM quality assessment toolbox

Audio

Feature

8569

Add relevant metrics for AEC3

Audio

Feature

8528

Add new CreateAudioDeviceWithDataObserver API without id to audio_device_data_observer.h

Audio

Feature

5118

Unify logging mechanisms.

Audio, Video

Feature

8479

BitrateAllocation should differentiate between 0 and an unsignaled bitrate.

BWE

Feature

8166

Reduce number of mechanisms to select the TaskQueue implementation to one

Internals

Feature

8289

Implement OpenSSLCertificate::GetChain

Network>DTLS

Feature

8313

Add interface that allows customizing stun messages sent by TurnPort

Network>ICE

Feature

8439

Application-specific Extension in RtpPacketReceived

Network>RTP

Feature

8347

Report 95th percentile of interframe delay to UMA

Stats, Video

Feature

8402

Make getStats report aggregated metrics over shorter interval on receive side.

Stats, Video

Feature

760107

Unflag addTrack, removeTrack, ontrack and RTCRtpSender with track

Blink>WebRTC>PeerConnection

Feature

425368

Mojofication of audio output stream control IPC.

Internals>Media>Audio

Bug

6622

The analog gain controller does not sufficiently reduce the gain for clipped echo

Audio

Bug

8397

AEC3 sometimes fails to detect a valid linear filter estimate in reverberant environments

Audio

Bug

8379

AEC3 fails to detect the echo path delay in reverberant environments with moderate echo return loss

Audio

Bug

8412

AEC3 is not sufficiently transparent for headsets and setup with echo paths with low gain

Audio

Bug

8411

AEC3 sometimes fails to cancel echoes for highly saturated echoe

Audio

Bug

8398

Too much echo suppression initially in the calls for AEC3

Audio

Bug

8495

BWE stuck after setting a high start bitrate after the call has started.

BWE

Bug

8388

SRTP failure when using multiple PeerConnectionFactory's

Network>RTP

Bug

778039

Intermittent TrackStartError when opening camera

Blink>GetUserMedia>Webcam

Bug

774868

Too much echo suppression initially in the calls for AEC3

Blink>WebRTC>Audio

Bug

778396

The echo canceller 3 sometimes changes delay estimates when it should not

Blink>WebRTC>Audio

Bug

774867

AEC3 sometimes fails to detect a valid linear filter estimate in reverberant environments

Blink>WebRTC>Audio

Bug

778396

The echo canceller 3 sometimes changes delay estimates when it should not

Blink>WebRTC>Audio

Bug

7806

Deadlock in AudioDeviceLinuxALSA?

Audio

Bug

8410

FEC Packets can cause NetEq to incorrectly detect a frame length change

Audio

Bug

8381

Frame length changes can cause increased target buffer level in NetEq

Audio

Bug

8548

Windows audio device excessive logging

Audio

Bug

8468

Remote ntp time estimation is way off sometimes.

Network>RTP

Bug

8473

SetRemoteDescription: Unify callbacks into one place

PeerConnection

Bug

8436

In SrtpTransport, send_rtcp_session_ should call SetSend rather than SetRecv

PeerConnection

Bug

8550

Wrong codec parameters are inserted into SDP answer

PeerConnection

Bug

8435

Add networkType to RTCIceCandidateStats

Stats

Bug

8375

Sent framerate statistics could be incorrect.

Video

Bug

8484

VideoDecoderSoftwareFallbackWrapper should handle any InitDecode() failure

Video

Bug

8433

CPU adaptation doesn't work in chrome for screenshare.

Video

Bug

8527

Injectable SW codecs does not have ulpfec, red, or flexfec

Video

Bug

765302

Do not cache device ID salts

Blink>GetUserMedia

Bug

778035

[Desktop Capture] wrong cursor position during Window sharing on Linux

Blink>GetUserMedia>Desktop

Bug

778049

[Desktop Capture] Inaccurate mouse cursor position when sharing window on Mac with retina screen

Blink>GetUserMedia>Desktop

Bug

760351

Add I420 format option to CopyOutputRequest

Blink>GetUserMedia>Tab

Bug

782492

Add pcm/float32 support to MediaRecorder

Blink>MediaRecording

Bug

705901

RTCPeerConnection: Support remote MediaStreamTrack being added and removed from MediaStream and pc/sender/receiver

Blink>WebRTC>Network

Bug

774164

WebRTC MediaStreamTrack not created after renegotiation when remote peer adds track to existing stream

Blink>WebRTC>PeerConnection

Bug

765170

RTCPeerConnection: RTP Media API UseCounters

Blink>WebRTC>PeerConnection

Bug

777999

RTCPeerConnection, MediaStream and MediaStreamTrack events should fire in the right order

Blink>WebRTC>PeerConnection

Bug

8549

Mac OS X Playout device init fails when using a multi-output device

Audio

Bug

8426

Incorrect resampler mode in Resampler::Reset() which causes invalid pointer access

Audio

Bug

780863

New RTC event logs can override existing files

Blink>WebRTC>Tools

Bug

783129

Data race in media::AudioOutputDevice::Initialize

Internals>Media>Audio


Native Android/iOS


Type

Issue

Description

Component

Bug

8505

RTCCameraVideoCapturer does not respect format

Mobile (iOS)

Bug

7313

WebRTC causes Android to route non-WebRTC audio in undesirable ways, even when nothing is playing

Audio, Mobile (Android), PeerConnection

Bug

8556

Generated JNI code fails for nested enums

Mobile (Android)

Bug

8459

Android: HardwareVideoEncoderFactory reports incorrect profile level

Mobile (Android)

Bug

8401

Define Codec name NSString constants in a central place for iOS SDK.

Mobile (iOS)

Bug

8466

Objc interface for peer connection factory does not allow external audio device module to be used.

PeerConnection (iOS)

Bug

8492

iOS 11 UIDeviceOrientationFaceUp resets video orientation

Mobile (iOS), Video

Bug

8403

No IceCandidates are created for Wifi P2p (aka Wifi-Direct) addresses

Network>ICE, Mobile (Android)

Bug

8498

RTCEAGLVideoView crashing when created in background (iOS SDK)

Video, Mobile (iOS)

Bug

8342

RTCAudioSession is not using a KVO context

Mobile (iOS)


Eric M

unread,
Dec 20, 2017, 8:15:32 AM12/20/17
to discuss-webrtc
So............fast

在 2017年12月20日星期三 UTC+8下午8:30:44,Anatoli Davidson写道:

Philipp Hancke

unread,
Dec 20, 2017, 12:06:46 PM12/20/17
to WebRTC-discuss


2017-12-20 13:30 GMT+01:00 Anatoli Davidson <anat...@webrtc.org>:

M64

[...] 

PSA: addTrack(), removeTrack(), ontrack and getSenders()

Significant portions of the RTP Media API are shipping for spec-compliant ways of handling the streams and tracks of an RTCPeerConnection. The new APIs, while not fully featured yet (more details here), allow applications to move away from legacy addStream()/removeStream()/getLocalStreams().


Added to RTCPeerConnection: addTrack(), removeTrack(), getSenders() and ontrack.

New interface: RTCRtpSender (track attribute only).

New event: RTCTrackEvent (full support minus transceiver attribute).


I am a bit disappointed by the apparent lack of understanding of what is in the spec and what hbos implemented.
describes the difference. What is shipping in Chrome 64 is "stage 2" -- the track based API. While this API is still in the spec, the underlying model changed quite a bit.
Most notably, the following fiddle behaves different in Chrome 64 and Firefox 59 (which just shipped transceivers):
The spec-compliant console output is an array with one receiver (see stage 3). Chrome returns an empty array and is thus far from being spec-compliant.

Harald Alvestrand

unread,
Dec 20, 2017, 12:09:56 PM12/20/17
to WebRTC-discuss
Yes, the RTCRtpReceiver interface is among the missing features.


--

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

sung young son

unread,
Dec 21, 2017, 11:17:29 AM12/21/17
to discuss-webrtc
Good. Maybe Chrome team did a lot of hard work. Passion.

Alexandre GOUAILLARD

unread,
Dec 21, 2017, 7:07:07 PM12/21/17
to discuss...@googlegroups.com
Thanks to the chrome team for the hard work.

It's nice to see chrome catching up, and almost reaching the level (stage 2) where firefox still was a release ago.

On Thu, Dec 21, 2017 at 12:16 AM, sung young son <musi...@gmail.com> wrote:
Good. Maybe Chrome team did a lot of hard work. Passion.
--

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

For more options, visit https://groups.google.com/d/optout.



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

Alexander Abagian

unread,
Jan 26, 2018, 7:06:55 PM1/26/18
to discuss-webrtc
v64 canceled accept H.264 packetization-mode=0. Moreover, the following behavior breaks RFC3264 "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer."

offer Remote Description:

a=rtpmap:103 H264/90000
a=fmtp:103 profile-level-id=42c01f;packetization-mode=0;level-asymmetry-allowed=1;max-fs=12288;x-google-start-bitrate=800;x-google-min-bitrate=30;x-google-max-bitrate=1300

a=rtpmap:104 H264/90000
a=fmtp:104 profile-level-id=42c01f;packetization-mode=1;level-asymmetry-allowed=1;max-fs=12288;x-google-start-bitrate=800;x-google-min-bitrate=30;x-google-max-bitrate=1300

answer Local Descrition:

setLocalDescription
a=rtpmap:103 H264/90000
a=fmtp:103 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

It accepts offer' 104 H264 data, but sets up payload type 103.

Taylor Brandstetter

unread,
Jan 26, 2018, 7:38:29 PM1/26/18
to discuss-webrtc

--

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

Alexander Abagian

unread,
Jan 30, 2018, 12:08:41 PM1/30/18
to discuss-webrtc
Wrong answer is the second problem.

The main question is, what's happened with packetization-mode 0 in Chrome 64 ? It is completely canceled. But rfc3984 says :

6.2. Single NAL Unit Mode

This mode is in use when the value of the OPTIONAL packetization-mode
   MIME parameter is equal to 0, the packetization-mode is not present,
   or no other packetization mode is signaled by external means.  All
   receivers MUST support this mode.





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

Harald Alvestrand

unread,
Jan 30, 2018, 12:49:31 PM1/30/18
to WebRTC-discuss
I think the SDP negotiation part never got written. The actual encoding into mode 0 got finished, I think.

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/06332ca1-f83e-4ad3-a28d-2058d4ce3e83%40googlegroups.com.

Alexander Abagian

unread,
Jan 30, 2018, 2:21:34 PM1/30/18
to discuss-webrtc
Mode 0 encoding is a half of the problem. The second one is the mode 0 decoding, the lack of which makes problems to us now.

Harald Alvestrand

unread,
Jan 30, 2018, 5:55:15 PM1/30/18
to WebRTC-discuss
Mode 0 decoding should just work. Everything that is legal in mode 0 is also legal in mode 1.

Bug

8527

<td style="border

Alexander Abagian

unread,
Jan 31, 2018, 5:03:41 PM1/31/18
to discuss-webrtc
Should, but doesn't. Try "Munge sdp" WebRTC sample - Chrome 64 never answers with packetization-mode=0 to any of modes on the offer. If you stay a single H264 packetization-mode=0 in the offer, the answer will anyway contain packetization-mode=1. If I'm replacing the mode in my client offer by brutal force (the stream is actually mode 0, but signed as mode 1), I have no incoming video in Chrome 64. We had to urgently restrict mode 0 in the server to Chrome 64 be workable, but this breaks some other type of clients.

Harald Alvestrand

unread,
Jan 31, 2018, 5:12:36 PM1/31/18
to WebRTC-discuss
The answer that is wrong is because of the failure to implement SDP negotiation.
The failure to play a Mode 0 stream is worrisome. Is it possible to create a copy of the stream in a file and attach it to a bug, so that the video folks can look at it?


--

---
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/03098825-9af7-47ea-b726-fb85ee3c1563%40googlegroups.com.

Albert Gu

unread,
Feb 8, 2018, 3:17:38 AM2/8/18
to discuss-webrtc
Very limited update on Mobile (iOS & Android).

Are we facing bottleneck now? Thanks a lot for your work on WebRTC!

chandra...@gmail.com

unread,
Feb 15, 2018, 5:07:34 AM2/15/18
to discuss-webrtc

We are currently researching some development options using WebRTC. Part of the solution we would like develop is the ability to shift audio and video out of sync, e.a. deliberately create ‘lipsync’ issues with the video presented.

 

We want modify the existing google AppRTC code so that video playback in the browser is 500 milliseconds or more behind the audio playback. This is to be achieved by modifying relevant timestamps only but not sure how to do that


can any one help us?

Harald Alvestrand

unread,
Feb 15, 2018, 6:02:32 AM2/15/18
to WebRTC-discuss
If you want to delay audio compared to video, the simplest way that requires no change to existing interfaces is to connect the audio track of your WebRTC stream to a WebAudio DelayNode (https://developer.mozilla.org/en-US/docs/Web/API/DelayNode) and connect that node to your audio output.

If you want to delay video compared to audio, I don't have a solution at present.


--

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

Silvia Pfeiffer

unread,
Feb 15, 2018, 3:31:03 PM2/15/18
to discuss...@googlegroups.com
For video: paint it into a canvas. That delays the video, though it's hard to control by how much.

Cheers,
Silvia.

...

Raviram Chandran

unread,
Feb 16, 2018, 3:30:37 AM2/16/18
to discuss...@googlegroups.com
We want modify the time stamps so that video is half a second behind the audio! .. but don't know how to do that

On Fri, Feb 16, 2018 at 2:00 AM, Silvia Pfeiffer <silviap...@gmail.com> wrote:
For video: paint it into a canvas. That delays the video, though it's hard to control by how much.

Cheers,
Silvia.

--

---
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/fIWg5n67xHo/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/CAHp8n2nvMzgP257X1YgP2iAEvLGjOJgPZwmdritsQZmJ%2BVb2qA%40mail.gmail.com.

Raviram Chandran

unread,
Feb 16, 2018, 3:34:13 AM2/16/18
to discuss...@googlegroups.com
Thank you Harald, we have achieve that but we want delay video !

--

---
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/fIWg5n67xHo/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/CAOqqYVFrdcY6CQeC3U0h-aLu%3DQydKnJAZGGf%2BnCKYKXeco-5Ag%40mail.gmail.com.

allenf...@gmail.com

unread,
Feb 23, 2018, 6:33:48 AM2/23/18
to discuss-webrtc
Can anyone point me to which issues/bugs are related with "Improved bandwidth estimation for screen capture streams" ?

On Wednesday, December 20, 2017 at 8:30:44 PM UTC+8, Anatoli Davidson wrote:

Anatoli Davidson

unread,
Mar 6, 2018, 5:22:01 AM3/6/18
to discuss-webrtc

Raviram Chandran

unread,
Mar 6, 2018, 11:56:14 AM3/6/18
to discuss...@googlegroups.com
Any help to modify the time stamps so that video is half a second behind the audio! .

--

---
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/fIWg5n67xHo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages