PSA: Chrome M48 WebRTC Release Notes
Christoffer Jansson
M48
WebRTC M48 branch (cut at r10622)
Summary
Chrome M48, currently available in Chrome's beta channel, includes over 37 bugfixes and new features, including a variety of WebRTC enhancements. 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. The help we have received has been invaluable!
For some pointers on how to file a good bug report, please take a look at this page.
Important PSAs
The WebRTC bug tracker has now moved from googlecode to monorail; more details in this PSA.
Chrome M48 will start deployment of a change to how IP addresses are gathered. Applications without getUserMedia permission will only be allowed to access IP addresses that can be gathered from the default network path, which will ensure ISP addresses are not disclosed to ordinary web pages when using a VPN. This may result in changes to p2p routing in certain circumstances; more details below.
MediaStreamTrack.getSources() is now deprecated in favor of navigator.mediaDevices.enumerateDevices; see issue 550981 for more details.
Features
We are happy to announce that the Chrome M48 release supports the new VP9 codec, without a flag, across all platforms. VP9 allows video calls to deliver the same high quality at 40% lower bitrate (compared to VP8 or H.264), at the cost of 15% additional CPU. This means that you can now do HD video calling at SD bitrates - or deliver even higher video quality at the same bitrate.
Currently, Chrome will still use the VP8 codec by default. However, applications can select VP9 by promoting VP9 to be the first codec in the offer message generated by Chrome. To show off what VP9 can do, we've updated our official sample application, AppRTC, to prefer VP9 - you can try it out with Chrome M48 at https://appr.tc (hit the 'i' key to show the codec in use).
We will continue to improve VP9 in the next several Chrome releases. This release incorporates the proposed standard RTP packetization for VP9, which was co-designed and developed with Vidyo, Inc., and we will attempt to maintain backwards compatibility from M48 onward. We're excited about the future of VP9, and we invite developers to experiment and provide feedback.
Chrome M48 will also gradually enable a new policy with regard to how IP addresses are gathered for WebRTC. Only applications with microphone/camera permission will be permitted to enumerate and use all network interfaces. Applications without this permission will only be able to access and use candidates associated with the default network path. Specifically, in this case, if the user is using a VPN, and Internet traffic is being routed through the VPN, WebRTC will only gather IP addresses using the VPN and will not gather any ISP IP addresses.
While we have designed this policy carefully to have minimal impact on applications, we would love to get feedback. To try the new policy before it rolls out, run Chrome with the --enforce-webrtc-ip-permission-check flag.
Users can also control the IP gathering behavior with the WebRTC Network Limiter Extension, which allows more fine-grained control of which IP addresses are used even when microphone/camera permissions have been obtained.
More details about how IP gathering is done can be found in this IETF document.
A first version of the MediaStream Recording API was released in Chrome 47 behind the experimental Web Platform features flag. In M48, we have added buffering support, as well as support for the VP9 codec. This is still an early experimental version, but the API can be used with lots of different applications. A demo is available here; more details are also available in this discuss-webrtc announcement. We would love to hear your feedback on what additional features would be useful.
Bugfixes and Features
Issue 418540 Implement MediaStreamTrack::remote()
Issue 498484 Screen capture of an application (Chrome) may end when switching the captured application in and out of fullscreen mode
Issue 513098 Window capture on CrOS is drawing the mouse cursor in the wrong position
Issue 520101 WebRTC should not collect local address unless mic/camera permission is granted.
Issue 528089 Peer Connections: renegotiation fails when opposite direction to original offer/answer
Issue 534306 sink ID for media elements is forgotten when src changes.
Issue 539521 Screen sharing displays the wrong window in picker
Issue 541232 GetUserMedia video capture: crashes when an unsupported video resolution is requested through Camera2 API
Issue 542765 WebRTC should use enum instead of booleans for its routing policy settings
Issue 543087 setSinkId() fails on elements without src
Issue 545855 A9F0 AVR:NULL+EVEN chrome.exe!chrome_child.dll!blink::WebVector<...>::{ctor}
Issue 549744 Mac Capture Timestamp Irregularity
Issue 555104 Overriding the minimum starting volume of the AGC is not possible
Issue 555575 Heap-use-after-free in webrtc::PeerConnection::OnSessionStateChange
Issue 550981 Deprecate MediaStreamTrack.getSources() (still usable but warning is printed to console)
Issue 2920 Support ability to fall back to built-in codec factory when external codecs develop issues
Issue 3765 Kinect device is not listed in google chrome
Issue 4210 Delete iSAC-fb
Issue 4742 [Android] Feature request: allow to use different GLSurfaceViews for rendering different video streams
Issue 4972 Provide RSA modulus-size argument in order to support RFC
Issue 4986 browser_tests failing in WebRTC Win7 Tester bot
Issue 5039 Failure to accept compliant DataChannel SDP
Issue 5045 Remove SCHANNEL code from WebRTC.
Issue 5049 Build fails if using external OpenSSL
Issue 5054 onaddstream triggered for recvonly streams
Issue 5058 iOS audio device layer failure with bluetooth headset
Issue 5060 SimulcastEncoderAdapter doesn't implement VideoEncoder::SupportsNativeHandle()
Issue 5061 WebRTC should expose the single default local address used by http traffic even if permission is denied
Issue 5062 Make |buffer| argument const-ref instead of by-value in AndroidVideoCapturer::OnIncomingFrame()
Issue 5067 AppRTCDemo crashes in MediaCodecVideoEncoder
Issue 5070 GN: Make WebRTC standalone not having to specify build_with_chromium=false
Issue 5101 Decrease of loss-based bandwidth estimate can trigger more than once per loss report.
Issue 5102 FEC bitrate uses codec max bitrate instead of global max bitrate
Issue 5108 Set VP9 denoising off by default for now in AppRTC
Issue 5111 webrtc should delete all connections that are receiving but have timed out on writing.
Issue 5119 PortAllocatorSession is not stopped if ICE restart when the channel is writable
Issue 5127 Opus gives intermittent noise during DTX when microphone muted
Issue 5171 ICE does not send stun ping response when the ping is from unknown address
Leighton Carr
Christoffer Jansson
On Tuesday, December 15, 2015 at 8:00:12 AM UTC+1, Leighton Carr wrote:
Nice work! I have a couple of questions:1) The MediaStreamRecorder demo is currently broken due to (I think) an argument change on the factory. Last time I tested, it was still decoding the WebRTC frames then re-encoding them in VP8 before encapsulating and writing to disc. Is this still the case? If so, is there any plans to allow MediaStreamRecorder implementation to access the raw frames to avoid this decode/encode overhead? Not sure if this is helped or hindered by the new RTP packetisation, but it's a fairly important feature for recording multiple HD video streams.
2) Audio recording wasn't enabled in MediaStreamRecorder last release - did that make it into this release? There was some word about waiting for AudioTrackInterface (?) updates to be filled out before that could be done.
3) Desktop capture is still hidden behind the extension API - any thoughts about moving that to a similar permissions framework using webcam / microphone?
...