Remove private members that are no longer used or always have same value
Use less allocations
Bug: None
Change-Id: I5430c2356f0039212baf8b248b92775e8852ce1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227765
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34665}
With this turned on, packets will be sequence number after the pacing
stage rather that during packetization.
This avoids a race where packets may be sent out of order, and paves
the way for the ability to cull packets from the pacer queue without
causing sequence number gaps.
For now, the feature is off by default. Follow-ups will enable it for
video and audio separately.
Bug: webrtc:11340, webrtc:12470
Change-Id: I6d411d8c85b9047e3e9b05ff4c2c3ed97c579aa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208584
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34661}
Schedule the frames to be decoded based on the pacing delay from the
last decode scheduled time. In the current implementation, multiple
threads and different functions in same thread can call
MaxWaitingTime(), thereby increasing the wait time each time the
function is called. Instead of returning the wait time for a future
frame based on the number of times the function is called, return the
wait time only for the next frame to be decoded. Threads can call the
function repeatedly to check the waiting time for next frame and wake
up and then go back to waiting if an encoded frame is not available.
Change-Id: I00886c1619599f94bde5d5eb87405572e435bd73
Bug: chromium:1237402
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226502
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34660}
The race can happen when an encoder thread is packetizing a video frame
and is calling RTPSender::AssignSequenceNumber() while the RtpRtcp
module is calling GeneratePadding() and querying
PacketSequencer::CanSendPaddingOnMediaSsrc().
The solution for now is to simply not call
PacketSequencer::CanSendPaddingOnMediaSsrc() from the RtpRtcp module,
as that parameter will be ignored anyway - RTPSender will query that
method internally while holding the send lock.
Once deferred sequencing is implemented, the
can_send_padding_on_media_ssrc parameter can be populated safely since
it is then always called on the pacer thread.
Bug: webrtc:11340, webrtc:12470
Change-Id: I9e90808166453d0e29746df89044e1d3bdffa286
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227767
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34655}
This prepares for deferred sequence numbering, and is (sort of)
extracted from
https://webrtc-review.googlesource.com/c/src/+/208584
Bug: webrtc:11340, webrtc:12470
Change-Id: I2f3695309e1591b9f7a1ee98556f4f0758de7f69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227352
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34643}
This CL is extracted from
https://webrtc-review.googlesource.com/c/src/+/208584
PacketSequencer now has its own unit tests. They are maybe somewhat
redundant with a few RtpSender unit tests, but will defer cleanup to
a later CL.
Bug: webrtc:11340, webrtc:12470
Change-Id: I1c31004b85ae075ddc696bdf1100d2a5044d4ef5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227343
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34638}
fill the audio level of the recovery packets from the main packet.
While not exact, this should be close enough. Without this,
the audio level in getStats() will be filled but the audio level
in getSynchronizationSources() will be empty.
In chrome this is easy to test, the audio level graph on
https://webrtc.github.io/samples/src/content/peerconnection/audio/
will be empty all the time prior to this fix.
BUG=webrtc:11640
Change-Id: Ia1e61fd1852445239021a76d08032120a92d83aa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226840
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34635}
Acts as a compile time annotation, with corresponding run-time check
only when DCHECKs are enabled, and built using absl or pthreads mutexes.
Bug: None
Change-Id: Ie044c1ea1e576df71d634301f7df9d75cdf10b1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226328
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34555}
The alternative new name proposed, NackTracker, is already in
use in audio_coding.
Fixed: webrtc:11594
Change-Id: I6a05fafc05fa7ddb18ea4f64886a135e5ef59f7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226744
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34539}
as there are encryption schemes that preserve the payload structure
well enough and do not require those extensions.
This improves consistency as the webrtc-encoded-transform API
(which does not use this synchronous codepath) does not require those
header extensions either.
BUG=webrtc:12995
Change-Id: If237ca5d92e8871ac71c3d48fdd05127206395e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226741
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34537}
As part of go/coil update code search links to not point to the
"master" branch.
Bug: chromium:1226942
Change-Id: I0ae9e84ecc660f789a69fe0b226f93bbc39a8a66
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226081
Commit-Queue: Tony Herre <toprice@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34531}
This CL completes the removal of assert() and relative headers from
the codebase (excluded
//examples/objc/AppRTCMobile/third_party/SocketRocket which is in a
third_party sub-directory).
Bug: webrtc:6779
Change-Id: I93ed57168d2c0e011626873d66529488c5f484f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225546
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34528}
NackModule2 creates repeating tasks, but as there are
many modules (one per receiver) these tasks execute out
of phase with each other, multipliying the amount of wakeups
caused.
Fix this by creating a single wakeup source that serves all
NackModule2 instances in a call.
Bug: webrtc:12989
Change-Id: Ia9c84307eb57349679e42b673474feb2cb43f08e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226464
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34527}
The only user of that function is only interested in the type of the
first rtcp message in the packet, which can be extracted in a simpler way
Bug: None
Change-Id: I96aeb8ed66099f94d506aa7d8d0d07378f6c952e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226543
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34515}
