PSA: WebRTC M66 Release Notes
Anatoli Davidson
WebRTC M66 Release Notes
WebRTC M66 branch (cut at r22215)
Summary
WebRTC M66, 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.
PSAs
Fix for long delays when Opus was used with DTX
A bug was found in the audio jitter buffer (NetEq) that caused the buffer to apply too long delay when a codec with internal DTX/CNG (discontinuous transmission mode with comfort noise) was used. The only codec supporting this as open-source is Opus, and it only hits when DTX is actually used. The bug would manifest itself as excessive delay for some time after each period of silence (when the codec would send CNG). The added delay got higher with bad network conditions, and the elevated delay lasted in the order of seconds. The most apparent effect is poor audio/video sync with the audio lagging after the video from time to time during a call. The bug was fixed behind a flag in the M64 branch, and is now permanently fixed in the M66 branch. Note that Chrome users will get the fix from M64, since the flag is now default enabled from that version.
Changes to RTCDTMFSender
Chrome’s previous implementation of DTMF support in WebRTC involved using the createDTMFSender() call on an RTCPeerConnection. This approach has been replaced in the spec with a “dtmf” attribute on an RTCRtpSender. See details in the original PSA.
MediaStreamTrack.getCapabilities()
A new method on the MediaStreamTrack interface called getCapabilities() returns a MediaTrackCapabilities object, which specifies the values or range of values supported for each constrianable property. Capabilities vary by device.
Deprecations
Issue | Description | Component |
Get rid of packet loss stuff from videoprocessor | Video | |
Remove custom MD5 / SHA-1 implementations | Cleanup, Internals | |
Remove deprecated RTCAVFoundationVideoSource. | Mobile | |
Remove ThreadUtils.waitUninterruptibly | Mobile |
Features and Bugfixes
Type | Issue | Description | Component |
Feature | Add RelayPortFactoryInterface that allows for custom relay (e.g turn) ports | Network>ICE | |
Feature | Send application-specific bytes from RtpSender through Transport | Network>RTP | |
Feature | Make RTCP interval configurable. | Network>RTP | |
Feature | RTCRtpEncodingParamers.active for each simulcast stream for RTPSender | PeerConnection | |
Feature | Verify signaling state in CreateAnswer | PeerConnection | |
Feature | Generate stats with PeerConnection in Unified Plan semantics | PeerConnection | |
Feature | Implement PeerConnection::GetRemoteAudioSSLCertificate | PeerConnection | |
Feature | Additional metrics for dropped video frames | Stats, Video | |
Feature | Make current fec controller plug-able | Video | |
Feature | Enable PeerConnectionFactory uses external fec controller | Video | |
Feature | VoE API Refactoring Tracking Bug | Audio | |
Feature | Add configurable STUN binding request interval and collect stats of STUN binding requests | Network>ICE | |
Feature | Structured ICE logging via RtcEventLog | Network>ICE | |
Bug | NetEq introduces delay when codec-internal DTX is used | Audio | |
Bug | During audio pipeline issues, delay estimation realignment causes echo leakage when AEC3 is used | Audio | |
Bug | The WebRTC echo canceller 3 would benefit from being informed that the setup used has clock drift | Audio | |
Bug | The AEC3 delay estimator sometime is slow at tracking audio path changes | Audio | |
Bug | The AEC3 look window is too short to cover the very long audio buffer delays seen on some platforms | Audio | |
Bug | The look window in AEC3 for the nonlinear mode was shortened too much | Blink>WebRTC>Audio | |
Bug | The AEC3 look window is too short to cover the very long audio buffer delays seen on some platforms | Blink>WebRTC>Audio | |
Bug | The AEC3 delay estimator sometime is slow at tracking audio path changes | Blink>WebRTC>Audio | |
Bug | The new fast delay AEC3 alignment may trigger a reset cycle | Blink>WebRTC>Audio | |
Bug | During audio pipeline issues, delay estimation realignment causes echo leakage when AEC3 is used | Blink>WebRTC>Audio | |
Bug | AEC3 sometimes fails to cancel echoes during the first seconds in a call | Blink>WebRTC>Audio | |
Bug | On systems with frequent audio path glitches AEC3 leaks more echoes than necessary | Blink>WebRTC>Audio | |
Bug | Missing audio data with getUserMedia | Blink>WebRTC>Audio | |
Bug | Software fallback doesn't trigger for wrapped media::VideoFrames | HardwareCodec | |
Bug | Stop using unsupported POSIX APIs under OS_FUCHSIA | Internals>PlatformIntegration | |
Bug | Adds voice concealment periods reporting to neteq_rtpplayback | Audio | |
Bug | Make EchoController an injectable module in Audio Processing Module | Audio | |
Bug | InsertDTMF() doesn't return an error when the channel is not connected | Audio | |
Bug | AEC3 sometimes fails to cancel echoes during the first seconds in a call | Audio | |
Bug | On systems with frequent audio path glitches AEC3 leaks more echoes than necessary | Audio | |
Bug | The look window in AEC3 for the nonlinear mode was shortened too much | Audio | |
Bug | The new fast delay AEC3 alignment may trigger a reset cycle | Audio | |
Bug | Echo saturations makes the echo alignment less accurate in AEC3 | Audio | |
Bug | AEC3 should report when it detects issues in the external audio pipeline | Audio | |
Bug | Before the render and capture signals have been aligned AEC3 may leak echo | Audio | |
Bug | Native AEC code on Windows is not being exercised | Audio | |
Bug | Analog gain not updated | Audio, Mic | |
Bug | Echo saturations makes the echo alignment less accurate in AEC3 | Blink>WebRTC>Audio | |
Bug | networkType in RTCIceCandidateStats doesn't identify VPN interfaces | Blink>WebRTC>Network | |
Bug | Lots of work done in rtc::LogMessage for dropped log messages | Internals | |
Bug | Make RTCCertificateStats work for certificate chains | Network>DTLS, Stats | |
Bug | Handle lifetime shorter than 2 minutes for turn allocations | Network>ICE | |
Bug | Fix RTT calculation when incoming receiver report has both report block with and without fields for rtt. | Network>RTP | |
Bug | Packets may become unretransmittable during very high bitrate usage | Network>RTP | |
Bug | H264 codecs "match" even if packetization-mode is different. | PeerConnection | |
Bug | RtpSenderInterface::SetParameters should fail with RTCError, not bool | PeerConnection | |
Bug | RTCRtpTransceiver API | SpecConformance | |
Bug | Stats are not generated before connection | Stats | |
Bug | Reported sent bitrate higher than target bitrate | Stats | |
Bug | RTP header can be incorrectly copied to RED packets containing FEC, when PlayoutDelay RTP header extension is used | Video | |
Bug | Jitter buffer drops around 3% of frames even in ideal network conditions. | Video | |
Bug | nanosleep(0) is very slow on some Android devices after app was minimizing | Video | |
Bug | Artifacts Observed When Alpha Channel Is On | Video | |
Bug | Multiplex Codec should consider the necessary Padding when using H264. | Video | |
Bug | WebRTC cannot decode an SPS with scaling lists | Video | |
Bug | googFrameWidthSent stats are incorrect for VP9 | Video | |
Bug | WebRTC RTPSender should support "dtmf" attribute | Blink>WebRTC>PeerConnection |
Dag-Inge Aas
https://www.chromium.org/audio-video/autoplay autoplay will be
enforced from M66, yet there is no information about this in the
release notes (as promised).
The bug I was asked to follow
https://bugs.chromium.org/p/chromium/issues/detail?id=804091 is marked
as fixed, but it doesn't seem like this is included in the notes here.
The related code change
https://chromium.googlesource.com/chromium/src.git/+/ef28e2a3c5bceaeff46da187529966bdeb194394
is also not included as far as I can see.
>
> ---
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/CACxSdkGMtgQN30RsCVtYc2%3DjUP7PYRpAJ8MA19LCUDGME3QOKQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Dag-Inge Aas
CTO Confrere
https://meet.confrere.com/daginge
Huib Kleinhout
How will autoplay affect WebRTC usage in M66? According to
https://www.chromium.org/audio-video/autoplay autoplay will be
enforced from M66, yet there is no information about this in the
release notes (as promised).
The bug I was asked to follow
https://bugs.chromium.org/p/chromium/issues/detail?id=804091 is marked
as fixed, but it doesn't seem like this is included in the notes here.
The related code change
https://chromium.googlesource.com/chromium/src.git/+/ef28e2a3c5bceaeff46da187529966bdeb194394
is also not included as far as I can see.
> email to [email protected].
Philipp Hancke
On Wednesday, March 21, 2018 at 3:55:07 PM UTC+1, Dag-Inge Aas wrote:How will autoplay affect WebRTC usage in M66? According to
https://www.chromium.org/audio-video/autoplay autoplay will be
enforced from M66, yet there is no information about this in the
release notes (as promised).There is no special treatment for WebRTC based media streams so the same restrictions apply.
We encourage you to test the new policy in M66 and file bugs if there are any further problems with the implementation.
Dag-Inge Aas
2018-03-23 8:26 GMT+01:00 'Huib Kleinhout' via discuss-webrtc <[email protected]>:On Wednesday, March 21, 2018 at 3:55:07 PM UTC+1, Dag-Inge Aas wrote:How will autoplay affect WebRTC usage in M66? According to
https://www.chromium.org/audio-video/autoplay autoplay will be
enforced from M66, yet there is no information about this in the
release notes (as promised).There is no special treatment for WebRTC based media streams so the same restrictions apply.
Now I also hear that audiocontext which is used quite some sites to measure the mic level is affected by the autoplay stuff as well.There is a nice console warning:The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page. https://goo.gl/7K7WLuand documentation even. WebRTC is not mentioned on that page. Why?