This is a reland of e6ee8fab7eac915b2b6abc9b71b6d33ad086f3d1
Original change's description:
> Deprecate microsecond timestamps in RTC event log.
>
> (Microsecond timestamps are only used in the legacy wire-format,
> and the clocks only have microsecond resolution on some platforms.)
>
> Also convert structs on the parsing side to use a Timestamp instead
> of a uint64_t to represent the log time.
>
> Bug: webrtc:11933
> Change-Id: Ide5a0217d99f13f2e243115b163f13e0525648c7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219467
> Commit-Queue: Björn Terelius <terelius@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34097}
Bug: webrtc:11933
Change-Id: I295be966ee96b50719ceb4690dad7e7ce958dbac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221361
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34321}
This builds on a few other CLs that avoid recreating the audio receive
streams on config changes and removes redundant config state in
WebRtcAudioReceiveStream, constructs the embedded receive stream in the
initializer list and keeps it const.
Bug: webrtc:11993
Change-Id: Iad28e0170bee6bf1e08713a89af7c81435b4265e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222100
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34317}
it is not required because during construction members can be set on
wrong thread, and in some corner cases it may even cause a crash.
Bug: none
Change-Id: I37d7f2a7772b6ab5e574077d3f53bca2529f9ae1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222651
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34315}
This reverts commit 10814873c584df17e560462adcc2b72e488ada91.
Reason for revert: Breaks down stream project
Original change's description:
> Avoid video stream allocation on configuration change after timeout.
>
> This is to prevent the video stream to get in a state where it is
> allocated but there is no activity.
>
> Bug: b/189842675
> Change-Id: I0793bd4cbf2a4faed92cf811550437ae75742102
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221618
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34276}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: b/189842675
Change-Id: If930360000f5ca290100920a4f215358b8c3e644
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222652
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34314}
Add logging of DTLS handshake retransmission,
either when it happens or when it fails.
Note that is only for the handshake messages,
which are retransmitted with exponential back off.
This patch aim to help rare DTLS hanging problems.
BUG=None
Change-Id: Iae808190711dd80dd8a43ff22757dd69919d63ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222647
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34304}
The previous approach was that the caller was responsible for ensuring
that any buffer passed in to the Bounded IO wrappers, and that any
offset from where sub-readers were created were valid. The called would
always do a validation of the data and return proper error messages
if they were not.
This didn't pan out. https://crbug.com/1216758 found an overflow that
fooled the validation logic and the fuzzer could read out-of-bounds,
although it would always crash in that particular case.
There was already bounds checking, but under DCHECKs. This CL changes
that so that any bounds checking is done with CHECKS, as would've been
done in Rust. It's better to crash than to read arbitrary memory.
Bug: chromium:1216758
Change-Id: I89b52f0758495b5fe46f926c142870a263b96314
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221743
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34303}
This method has been deprecated since 2018-07:
https://webrtc-review.googlesource.com/c/src/+/88368/
It is never called by WebRTC itself.
Custom `VideoDecoderFactory` implementations overriding this method can
switch to the overload accepting a `VideoCodecInfo` object.
This is also adding a `toString()` implementation to `VideoCodecInfo`,
to make logging of the value more useful.
Bug: webrtc:7925
Change-Id: I70ec07a0cd4ffa07d165c9851e393439fcc5870b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221960
Commit-Queue: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34302}
Also applies sanitizing to prflx candidates, not just local ones.
Also add tests for the port allocator Sanitize function.
Bug: chromium:1218346
Change-Id: Ifbc7843cd6e289c09ca72b6ec610a34bbbf7e04e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222581
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34292}
If a bundle is established, then per JSEP, the offerer is required to
include the new track in the bundle, and per BUNDLE, the answerer has
to either accept the track as part of the bundle or reject the track;
it cannot move it out of the group. So we will never need the transport.
Bug: webrtc:12837
Change-Id: I41cae74605fecf454900a958776b95607ccf3745
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221601
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34290}
it.second in JsepTransportCollection::IsConsistent() is of type
std::unique_ptr, which has no operator<< in libstdc++. Even if it
would exist, it would just return the pointer value and not the
content.
Bug: chromium:957519
Change-Id: I17c75db47d63f42b33a551ee2b7afbf5c9a3cfde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222401
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34289}
This is a consistent way to get to common config parameters for
all receive streams and avoids storing a copy of the extension
headers inside of Call. This is needed to get rid of the need of
keeping config and copies in sync, which currently is part of why
we repeatedly delete and recreate audio receive streams on config
changes.
Bug: webrtc:11993
Change-Id: Ia356b6cac1425c8c6766abd2e52fdeb73c4a4b4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222040
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34285}
Also including common Rtp config members.
Follow up changes will remove the ReceiveRtpConfig class in Call
and copy of extension headers, instead use the config directly
from the receive streams and not require stream recreation for changing
the headers.
Bug: webrtc:11993
Change-Id: I29ff3400d45d5bffddb3ad0a078403eb102afb65
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221983
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34283}
This is to be consistent with how things work on the video side but
also much less drastic than the current implementation. Aim is to
remove RecreateAudioReceiveStream(), which would improve efficiency
as well as allow for specific handling of the cases that currently
trigger recreation.
Bug: webrtc:11993
Change-Id: Ia81a5e66d44e41ea4eb2bff800e0b1583821c96a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221860
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34282}
This is to prevent the video stream to get in a state where it is
allocated but there is no activity.
Bug: b/189842675
Change-Id: I0793bd4cbf2a4faed92cf811550437ae75742102
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221618
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34276}
Previous implementation assumes that though RepeatingTask is owned by
the task queue, it will stay alive until RepeatingTaskHandler stops it.
That assumption doesn't hold by one of downstream TaskQueue implementaions.
That TaskQueue implementation shortly before destruction deletes
pending delayed tasks because it doesn't plan to run them,
and then runs remaining regular tasks.
Bug: None
Change-Id: Ic95fec2e9961b3f05727ff6fbdaf0664434a995b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221984
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34274}
