Chrome M49 WebRTC Release Notes

3709 views
Skip to first unread message

Christoffer Jansson

unread,
Feb 1, 2016, 9:33:43 AM2/1/16
to WebRTC-discuss

M49

WebRTC M49 branch (cut at r11252)

Summary

Chrome M49, currently available in Chrome's beta channel, includes the top 3 most-requested WebRTC features, along with over 65 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

Deprecations

For the PeerConnection setLocalDescription / setRemoteDescription, we’ve added a deprecation warning if you call these functions without supplying an error handler. We expect to make this argument mandatory in M50; this is part of clearing the way for introducing promises on these functions.

Features

  • Certificate generation: We now support letting the user decide which types of certificate to use for a PeerConnection, per the certificate management section of the WebRTC specification. ECDSA and RSA certificates are supported; while RSA is currently the default, we plan to change to ECDSA in an upcoming version. Note that we have not yet implemented storing certificates to persistent storage.

  • RTC Event log: We now provide a new debug option in chrome://webrtc-internals for tracing internal details (e.g., BWE, jitter buffer state) for audio and video sessions. This option creates a log containing the timing and headers of packets as well as the timing of various internal events. We hope this will help resolve issues related to media transport and jitter buffers; attaching this log when reporting such issues will help us tremendously.

Bugfixes and Features

  • Issue 371804 WebRTC iceConnectionState transition from completed to completed

  • Issue 484159 Wrong RTP TS in first rtcp sender report

  • Issue 505838 WebRTC: MediaStreamTrack.getSources SourceInfo can't be serialized with JSON.stringify anymore

  • Issue 514873 Improved video renderer accuracy for WebRTC

  • Issue 526258 WebRTC: Update set of known root certificates

  • Issue 541679 Initialize AVFoundation only when needed

  • Issue 556396 chrome://media-internals shows bogus camera format information

  • Issue 560403 Storing a native webrtc log can cause further logging to not be allowed.

  • Issue 568139 Addition/removal of output-only audio devices are not reflected on MediaDevices.enumerateDevices() on mac

  • Issue 568734 DTLS-SRTP setup is bypassed when the channel has been writable

  • Issue 569369 Add support for cloning of remote audio tracks

  • Issue 569526 Fix forwarding of remote audio tracks in PeerConnection

  • Issue 578993 enumerateDevices() does not report any output device on ChromeOS and Android

  • Issue 121673 Hook up Web Audio API with WebRTC for audio processing

  • Issue 522661 Extract hard coded values from chrome/renderer/media/cast_rtp_stream.cc

  • Issue 553380 Improve how we log to WebRTC log from audio thread on Android

  • Issue 579687 Merge AecDump fix/revert into M49

  • Issue 332 voe_auto_test Automated Tests Report Valgrind Errors

  • Issue 1600 RTCP SR can be sent before the first RTP packet.

  • Issue 1695 Remove the old ViE API

  • Issue 2030 Issue in PhysicalSocket Accept

  • Issue 2136 Video fails to start again after being disabled

  • Issue 2192 Investigate/ Implement adding remote audio track/stream to a PeerConnection.

  • Issue 2250 Sending video without NACK should trigger keyframe requests when a whole frame is dropped

  • Issue 2617 Firefox NULL pointer dereference crash @ webrtc::Plane::Copy(int, int, unsigned char const*)

  • Issue 2782 failure to push down answer transport description after DTLS role change

  • Issue 3618 Changing remote DTLS fingerprint does not work

  • Issue 3849 Active TCP candidates should have port 9 instead of 0 according to RFC 6544

  • Issue 4312 Implement per packet RTCP feedback

  • Issue 4343 Check whether iOS gives temporary address

  • Issue 4525 streams not added on PeerConnection when other side initiates a datachannel first

  • Issue 4800 FEC packets generated that do not cover any media packets.

  • Issue 4897 Populate if HW/SW encoder/decoder is in use to the application

  • Issue 4917 If we receive an error to a TURN CreatePermission request, mark the associated connection as dead

  • Issue 5063 Pin WebRTC repo to Android API level 16-22

  • Issue 5096 NetworkManager signals networks changed unexpectedly

  • Issue 5105 peerConnection.localDescription has empty ice-ufrag/ice-pwd a-lines that break the peer's PeerConnection

  • Issue 5116 webrtc should handle error messages from turn-requests

  • Issue 5120 Do not delete the turn port entry when a turn connection is deleted

  • Issue 5125 Compilation errors in libvpx_new for armv7

  • Issue 5138 Better handling ICE candidates and credentials re-ordering

  • Issue 5150 RTCCertificate.expires_timestamp_ns() returning actual expiration timestamp (SSLIdentity/SSLCertificate expires field)

  • Issue 5158 Implement stand-alone tracing outside of Chromium

  • Issue 5166 iOS crash on audio_device_ios.mm

  • Issue 5167 Add more tracing

  • Issue 5178 Turn port does not refresh permission request.

  • Issue 5209 Chrome incorrectly generates webrtc candidate priority when multiple TURN servers are present

  • Issue 5214 Temporal up switch field not set correctly for VP9 flexible mode.

  • Issue 5223 Large amount of printouts of "Failed to deliver RTCP packet." when running AppRTCDemo in loopback on iOS

  • Issue 5227 neteq_impl.cc has overly verbose LS_VERBOSE logs

  • Issue 5228 OnDataChannel never triggered in C++

  • Issue 5237 AECM (mobile) does not work on some devices

  • Issue 5251 InitDecode is called twice for HW H.264 on Android.

  • Issue 5262 VideoCapturerAndroid produce too dark frames in low lightning conditions.

  • Issue 5277 cpplint: Fix all C++ lint warnings in webrtc/modules/rtp_rtcp/

  • Issue 5282 Error prone code in VideoCapturerAndroid

  • Issue 5291 copy remote candidates across generations

  • Issue 5303 Error in scaling CNG48kHz in webrtc/modules/audio_coding/neteq/timestamp_scaler.cc

  • Issue 5365 opensslstreamadapter.cc has a type error

  • Issue 5354 Remove the dependency on ProcessingComponent in the voice activity detector

  • Issue 5355 Remove the dependency on ProcessingComponent in the level estimator

  • Issue 5356 Remove the dependency on ProcessingComponent in the noise suppressor

  • Issue 5357 Remove the dependency on ProcessingComponent in the high-pass filter

  • Issue 5375 Android - local video is black and white or green

  • Issue 5388 Assert error in turnport.cc

  • Issue 5398 Fix unused-function warning for CreateFakeNativeHandleFrame in libjingle code.

  • Issue 705 Make the FEC properly set the transmission time offset and handle rtp extension header.

  • Issue 4112 Plumb an adaptation reason to GetStats when scaling down due to bitrate constraints

  • Issue 5309 Lint fix Video Coding module

  • Issue 5310 Lint fix Remote Bitrate Estimator module

  • Issue 5316 Add video/ to lint presubmit check

  • Issue 2381 Allow DTLS identity control from PeerConnection constraint

Philipp Hancke

unread,
Feb 1, 2016, 11:48:14 PM2/1/16
to discuss...@googlegroups.com

  • RTC Event log: We now provide a new debug option in chrome://webrtc-internals for tracing internal details (e.g., BWE, jitter buffer state) for audio and video sessions. This option creates a log containing the timing and headers of packets as well as the timing of various internal events. We hope this will help resolve issues related to media transport and jitter buffers; attaching this log when reporting such issues will help us tremendously.


While i'm pretty excited about the other features, this one is a gem for debugging. Much better than trying to get a normal user to install wireshark and make dumps!
What does this restriction mean?
Recording in multiple tabs or multiple recordings in the same tab is currently not supported

Justin Uberti

unread,
Feb 2, 2016, 2:39:53 PM2/2/16
to discuss-webrtc
The log is a global. You can only do one recording at a time. 

mparis

unread,
Feb 3, 2016, 6:50:11 AM2/3/16
to discuss-webrtc
Hello, I have tested the Event Log with demo [1] and the generated file seems to be binary, how can I read/interpret it?

Refs:
[1] https://webrtc.github.io/samples/src/content/peerconnection/pc1/

Philipp Hancke

unread,
Feb 3, 2016, 9:23:02 AM2/3/16
to discuss...@googlegroups.com
2016-02-03 3:50 GMT-08:00 mparis <mpari...@gmail.com>:
Hello, I have tested the Event Log with demo [1] and the generated file seems to be binary, how can I read/interpret it?

mparis

unread,
Feb 4, 2016, 3:53:12 AM2/4/16
to discuss-webrtc
OK, thanks for this utility ;).

andj222

unread,
Apr 4, 2016, 8:56:03 AM4/4/16
to discuss-webrtc
I've tried using the Event Log feature in a recent build of chromium on Linux (b657c9 to be exact), and despite checking the event log box in chrome://webrtc-internals and placing a video-only recvonly call, no log is produced. The file I specified for the log file doesn't even exist after placing the call. Is there a known issue with this functionality?
...

Christoffer Jansson

unread,
Apr 5, 2016, 4:46:53 AM4/5/16
to discuss-webrtc
On Mon, Apr 4, 2016 at 2:56 PM andj222 <andj...@gmail.com> wrote:
I've tried using the Event Log feature in a recent build of chromium on Linux (b657c9 to be exact), and despite checking the event log box in chrome://webrtc-internals and placing a video-only recvonly call, no log is produced. The file I specified for the log file doesn't even exist after placing the call. Is there a known issue with this functionality?
Nice catch, it does work if you start if after the call (peerconnection) has been initiated, but not when starting before.

This should however work, filed a bug, please star it to follow progress.

Thanks for letting us know!

/Chris 
--

---
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/93f5642c-f290-434a-8883-041928ef0398%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
/Chris

andj222

unread,
Apr 5, 2016, 8:12:13 AM4/5/16
to discuss-webrtc
Oddly, It doesn't work for me even if I do start the capture after having started a call. I'm not sure why that is.
...

Christoffer Jansson

unread,
Apr 6, 2016, 4:15:50 AM4/6/16
to discuss-webrtc
That's strange. Could you check that chrome has permissions to write in the directory you are saving to? Could you try using  AppRTC (https://appr.tc/?debug=loopback) ?

--

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

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

Andrew J

unread,
Apr 6, 2016, 5:38:37 AM4/6/16
to discuss...@googlegroups.com
It doesn't work with apprtc work if you pass "audio=false" in the url. My app is video only, so that's why is wasn't working for me there either.
It does work as expected if you use the default apprtc parameters and leave out audio=false.

Is it intended that this capture feature only work when audio is enabled? I was hoping to be able to use it with my video-only application.

--

---
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/mcApW-3YADI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAdOTUOQwOTxRMzebtV8wX9Xk-hGmKZCKzbkih%3DmP5dyTZtvbQ%40mail.gmail.com.

andj222

unread,
Apr 12, 2016, 6:42:38 AM4/12/16
to discuss-webrtc
Just wondering if you were able to reproduce my issue? (rtc event capture doesn't work with audio=false)


On Wednesday, April 6, 2016 at 2:38:37 AM UTC-7, andj222 wrote:
It doesn't work with apprtc work if you pass "audio=false" in the url. My app is video only, so that's why is wasn't working for me there either.
It does work as expected if you use the default apprtc parameters and leave out audio=false.

Is it intended that this capture feature only work when audio is enabled? I was hoping to be able to use it with my video-only application.
...

andj222

unread,
Apr 21, 2016, 9:18:18 AM4/21/16
to discuss-webrtc
I ended up opening a bug for this issue:


On Tuesday, April 12, 2016 at 3:42:38 AM UTC-7, andj222 wrote:
Just wondering if you were able to reproduce my issue? (rtc event capture doesn't work with audio=false)

On Wednesday, April 6, 2016 at 2:38:37 AM UTC-7, andj222 wrote:
It doesn't work with apprtc work if you pass "audio=false" in the url. My app is video only, so that's why is wasn't working for me there either.
It does work as expected if you use the default apprtc parameters and leave out audio=false.

Is it intended that this capture feature only work when audio is enabled? I was hoping to be able to use it with my video-only application.
On Wed, Apr 6, 2016 at 1:15 AM, 'Christoffer Jansson' via discuss-webrtc <discuss-webrtc@googlegroups.com> wrote:
That's strange. Could you check that chrome has permissions to write in the directory you are saving to? Could you try using  AppRTC (https://appr.tc/?debug=loopback) ?

...

Christoffer Jansson

unread,
Apr 21, 2016, 9:24:31 AM4/21/16
to discuss-webrtc
Thanks!

On Thu, Apr 21, 2016 at 3:18 PM andj222 <andj...@gmail.com> wrote:
I ended up opening a bug for this issue:


On Tuesday, April 12, 2016 at 3:42:38 AM UTC-7, andj222 wrote:
Just wondering if you were able to reproduce my issue? (rtc event capture doesn't work with audio=false)

On Wednesday, April 6, 2016 at 2:38:37 AM UTC-7, andj222 wrote:
It doesn't work with apprtc work if you pass "audio=false" in the url. My app is video only, so that's why is wasn't working for me there either.
It does work as expected if you use the default apprtc parameters and leave out audio=false.

Is it intended that this capture feature only work when audio is enabled? I was hoping to be able to use it with my video-only application.
--

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

For more options, visit https://groups.google.com/d/optout.
--
/Chris
Reply all
Reply to author
Forward
0 new messages