b8c55b15a3
RTP packets can be padded with extra data at the end of the payload. The usable payload length of the packet should then be reduced with the padding length, since the padding must be discarded. This was not the case; instead, the entire payload, including padding data, was forwarded to the audio channel and in the end to the decoder. A special case of padding is packets which are empty except for the padding. That is, they carry no usable payload. These packets are sometimes used for probing the network and were discarded in RTPReceiverAudio::ParseAudioCodecSpecific. The result is that NetEq never sees those empty packets, just the holes in the sequence number series; this can throw off the target buffer calculations. With this change, the empty (after removing the padding) packets are let through, all the way down to NetEq, to a new method called NetEq::InsertEmptyPacket. This method notifies the DelayManager that an empty packet was received. BUG=webrtc:7610, webrtc:7625 Review-Url: https://codereview.webrtc.org/2870043003 Cr-Commit-Position: refs/heads/master@{#18083}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
Development
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://chromium.googlesource.com/external/webrtc
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: http://build.chromium.org/p/client.webrtc