Handle padded audio packets correctly

Handle padded audio packets correctly

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}
Committed: https://chromium.googlesource.com/external/webrtc/+/b8c55b15a3e1b5a4c71f4444208b15c9874a3db4

[hlundin-webrtc, 2017-05-09 12:33:51]

henrik.lundin@webrtc.org changed reviewers:
+ minyue@webrtc.org, stefan@webrtc.org

[hlundin-webrtc, 2017-05-09 12:33:52]

PTAL

stefan: rtp_rtcp
minyue: audio_coding

Thanks!

[stefan-webrtc, 2017-05-09 14:25:46]

lgtm

[minyue-webrtc, 2017-05-09 21:04:07]

Good work. I will check with loopback call tomorrow. Take a look at my comments
first.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/acm2/audio_coding_module.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1079: int
AudioCodingModuleImpl::IncomingPacket(const uint8_t* incoming_payload,
will this affect DTX sync packets?

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1088: rtp_header,
reading rtc::ArrayView i think it is safe to just use 1087-1089

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:214: bool is_red) {
I'd like to see explicit treatment of 0 and early return.

if (payload_length == 0) {	
  return data_callback_->OnReceivedPayloadData(nulltpr, 0, nullptr)
}

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:237:
RTC_DCHECK_GE(payload_length, (4 * n) + 2);
check (not dcheck) outside the loop

RTC_CHECK_GE(payload_length, number_of_events > 0 ? 0 : (4 * number_of_events) -
2)

but doesn't

size_t number_of_events = payload_length / 4;

make the check trivial

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:290: if (payload_length > 0
&& is_red && !(payload_data[0] & 0x80)) {
payload_length != 0 feels to me easier to read

but early return will make this no need.

[hlundin-webrtc, 2017-05-10 08:57:23]

See replies inline, and a small change.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/acm2/audio_coding_module.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1079: int
AudioCodingModuleImpl::IncomingPacket(const uint8_t* incoming_payload,
On 2017/05/09 21:04:06, minyue-webrtc wrote:
> will this affect DTX sync packets?

Aren't they 1 or 2 bytes? 
https://cs.chromium.org/chromium/src/third_party/webrtc/modules/audio_coding/...

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1088: rtp_header,
On 2017/05/09 21:04:06, minyue-webrtc wrote:
> reading rtc::ArrayView i think it is safe to just use 1087-1089
> 

I don't think so. If we construct an ArrayView with a non-null data pointer, but
a size==0, we will use the ctor at
https://cs.chromium.org/chromium/src/third_party/webrtc/base/array_view.h?typ....
This has a DCHECK at line 149, which says that if size==0, the data must be
nullptr.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:214: bool is_red) {
On 2017/05/09 21:04:06, minyue-webrtc wrote:
> I'd like to see explicit treatment of 0 and early return.
> 
> if (payload_length == 0) {	
>   return data_callback_->OnReceivedPayloadData(nulltpr, 0, nullptr)
> }

We must forward the actual WebRtcRTPHeader, can't use a nullptr for that. And,
we would be missing the setting of frameType and isCNG in the WebRtcRTPHeader on
lines 271-272 below if we did early return.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:237:
RTC_DCHECK_GE(payload_length, (4 * n) + 2);
On 2017/05/09 21:04:06, minyue-webrtc wrote:
> check (not dcheck) outside the loop
> 
> RTC_CHECK_GE(payload_length, number_of_events > 0 ? 0 : (4 * number_of_events)
-
> 2)
> 
> but doesn't
> 
> size_t number_of_events = payload_length / 4;
> 
> make the check trivial

The DCHECK is for documentation purposes, since it is a bit complicated to
verify that the array is long enough for the index being read. That's why I
chose to have it inside the loop, when we know exactly how far we will read that
time.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:290: if (payload_length > 0
&& is_red && !(payload_data[0] & 0x80)) {
On 2017/05/09 21:04:06, minyue-webrtc wrote:
> payload_length != 0 feels to me easier to read
> 
> but early return will make this no need.

Done.

[kwiberg-webrtc, 2017-05-10 09:22:51]

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:237:
RTC_DCHECK_GE(payload_length, (4 * n) + 2);
On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > check (not dcheck) outside the loop
> > 
> > RTC_CHECK_GE(payload_length, number_of_events > 0 ? 0 : (4 *
number_of_events)
> -
> > 2)
> > 
> > but doesn't
> > 
> > size_t number_of_events = payload_length / 4;
> > 
> > make the check trivial
> 
> The DCHECK is for documentation purposes, since it is a bit complicated to
> verify that the array is long enough for the index being read. That's why I
> chose to have it inside the loop, when we know exactly how far we will read
that
> time.

I agree that having a simple DCHECK inside the loop is better than having a
complicated DCHECK outside the loop. (Approximate truth: DCHECKs are by
construction not relevant to performance, so readability is pretty much the only
thing you have to consider.)

[minyue-webrtc, 2017-05-10 09:44:12]

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/acm2/audio_coding_module.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1079: int
AudioCodingModuleImpl::IncomingPacket(const uint8_t* incoming_payload,
On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > will this affect DTX sync packets?
> 
> Aren't they 1 or 2 bytes? 
>
https://cs.chromium.org/chromium/src/third_party/webrtc/modules/audio_coding/...

Yes. Thanks

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1088: rtp_header,
On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > reading rtc::ArrayView i think it is safe to just use 1087-1089
> > 
> 
> I don't think so. If we construct an ArrayView with a non-null data pointer,
but
> a size==0, we will use the ctor at
>
https://cs.chromium.org/chromium/src/third_party/webrtc/base/array_view.h?typ....
> This has a DCHECK at line 149, which says that if size==0, the data must be
> nullptr.

But shouldn't incoming_payload be a null?

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:214: bool is_red) {
On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > I'd like to see explicit treatment of 0 and early return.
> > 
> > if (payload_length == 0) {	
> >   return data_callback_->OnReceivedPayloadData(nulltpr, 0, nullptr)
> > }
> 
> We must forward the actual WebRtcRTPHeader, can't use a nullptr for that. And,
> we would be missing the setting of frameType and isCNG in the WebRtcRTPHeader
on
> lines 271-272 below if we did early return.

I still prefer early return, since no need to read the parsing to know what is
going on. and the frame type should be kEmptyFrame IMO.

[hlundin-webrtc, 2017-05-10 11:19:30]

PTAL again.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/acm2/audio_coding_module.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/acm2/audio_coding_module.cc:1088: rtp_header,
On 2017/05/10 09:44:11, minyue-webrtc wrote:
> On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> > On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > > reading rtc::ArrayView i think it is safe to just use 1087-1089
> > > 
> > 
> > I don't think so. If we construct an ArrayView with a non-null data pointer,
> but
> > a size==0, we will use the ctor at
> >
>
https://cs.chromium.org/chromium/src/third_party/webrtc/base/array_view.h?typ....
> > This has a DCHECK at line 149, which says that if size==0, the data must be
> > nullptr.
> 
> But shouldn't incoming_payload be a null?

Done.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:214: bool is_red) {
On 2017/05/10 09:44:12, minyue-webrtc wrote:
> On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> > On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > > I'd like to see explicit treatment of 0 and early return.
> > > 
> > > if (payload_length == 0) {	
> > >   return data_callback_->OnReceivedPayloadData(nulltpr, 0, nullptr)
> > > }
> > 
> > We must forward the actual WebRtcRTPHeader, can't use a nullptr for that.
And,
> > we would be missing the setting of frameType and isCNG in the
WebRtcRTPHeader
> on
> > lines 271-272 below if we did early return.
> 
> I still prefer early return, since no need to read the parsing to know what is
> going on. and the frame type should be kEmptyFrame IMO.

Done.

https://codereview.webrtc.org/2870043003/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:237:
RTC_DCHECK_GE(payload_length, (4 * n) + 2);
On 2017/05/10 09:22:50, kwiberg-webrtc wrote:
> On 2017/05/10 08:57:23, hlundin-webrtc wrote:
> > On 2017/05/09 21:04:06, minyue-webrtc wrote:
> > > check (not dcheck) outside the loop
> > > 
> > > RTC_CHECK_GE(payload_length, number_of_events > 0 ? 0 : (4 *
> number_of_events)
> > -
> > > 2)
> > > 
> > > but doesn't
> > > 
> > > size_t number_of_events = payload_length / 4;
> > > 
> > > make the check trivial
> > 
> > The DCHECK is for documentation purposes, since it is a bit complicated to
> > verify that the array is long enough for the index being read. That's why I
> > chose to have it inside the loop, when we know exactly how far we will read
> that
> > time.
> 
> I agree that having a simple DCHECK inside the loop is better than having a
> complicated DCHECK outside the loop. (Approximate truth: DCHECKs are by
> construction not relevant to performance, so readability is pretty much the
only
> thing you have to consider.)

Acknowledged.

[minyue-webrtc, 2017-05-10 13:03:18]

https://codereview.webrtc.org/2870043003/diff/60001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/60001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:215: if (payload_length ==
0) {
I tried it, and I am afraid OnReceivedPayloadData(nullptr, 0) will never be
called.

For a quick hack, you need if (payload_length ==
rtp_header->header.paddingLength)

But this put me into great doubt about how the whole padding should work with
neteq. We should be receiving some garbage for current implementation (I
actually hear some burst of noise in video_loopback test and wondered why)

[hlundin-webrtc, 2017-05-10 13:25:54]

Description was changed from

==========
Make NetEq handle empty/probing packets

When empty audio packets are used for network probing, these packets
are today 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 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
==========

to

==========
Handle padded audio packets correctly
////////////////////////////////////////////////////////////////////////////////
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
==========

[hlundin-webrtc, 2017-05-10 13:26:09]

Description was changed from

==========
Handle padded audio packets correctly
////////////////////////////////////////////////////////////////////////////////
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
==========

to

==========
Handle padded audio packets correctly

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

[minyue-webrtc, 2017-05-10 13:37:04]

lgtm

nit and suggest add webrtc:7625 to Bug id.

https://codereview.webrtc.org/2870043003/diff/80001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/80001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:216: size_t
payload_data_length =
nit const

[hlundin-webrtc, 2017-05-10 13:46:23]

Description was changed from

==========
Handle padded audio packets correctly

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

to

==========
Handle padded audio packets correctly

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

[hlundin-webrtc, 2017-05-10 13:47:19]

https://codereview.webrtc.org/2870043003/diff/80001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc (right):

https://codereview.webrtc.org/2870043003/diff/80001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc:216: size_t
payload_data_length =
On 2017/05/10 13:37:03, minyue-webrtc wrote:
> nit const

Done.

[hlundin-webrtc, 2017-05-10 13:47:26]

The CQ bit was checked by henrik.lundin@webrtc.org

[hlundin-webrtc, 2017-05-10 13:47:26]

The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org,
minyue@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2870043003/#ps100001 (title:
"const size_t")

[commit-bot: I haz the power, 2017-05-10 13:47:32]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-05-10 14:38:02]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1494424046173950,
"parent_rev": "423a288a12f22e4a0d0377a40778ebf3da3d587c", "commit_rev":
"b8c55b15a3e1b5a4c71f4444208b15c9874a3db4"}

[commit-bot: I haz the power, 2017-05-10 14:38:07]

Description was changed from

==========
Handle padded audio packets correctly

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

to

==========
Handle padded audio packets correctly

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}
Committed:
https://chromium.googlesource.com/external/webrtc/+/b8c55b15a3e1b5a4c71f44442...
==========

[commit-bot: I haz the power, 2017-05-10 14:38:08]

Committed patchset #6 (id:100001) as
https://chromium.googlesource.com/external/webrtc/+/b8c55b15a3e1b5a4c71f44442...