With these changes, we now often have 0 invokes and at most 1 when
calling SetLocalContent on a channel. Before we had at least 1 and
typically 2.
Summary of changes.
* Updating RtpExtension::DeduplicateHeaderExtensions to return a sorted
vector (+test) for easy detection of changes.
* Before updating the transport on the network thread, detect if
actual changes to the demuxer criteria or changes to the rtp header
extensions have been made.
* Consolidate both transport updates to a single call instead of two.
* Added DCHECK guards to catch regressions in number of invokes.
A possible upcoming improvement is to update the transport
asynchronously.
Bug: webrtc:13536
Change-Id: I71ef7b181635a796ffa1e3a02a0f661d28a4870c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244700
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35638}
This is a bit of refactoring to clear the way for some more upcoming
changes and fix little oddities here and there that are basically
artifacts of many small incremental changes throughout the years.
* Remove the CryptoOptions member variable and instead only keep around
the filter for rtp header extensions.
* Remove several member methods that only forwarded calls to
media_channel() and effectively reduced readability.
* Consolidated quite a bit of code related to UpdateRemoteStreams_w
and the copy/pasted code in the Video/Voice classes around calling it.
* UpdateRemoteStreams_w now returns an error when it's encountered.
Before, an error would still be returned in those cases but all
operations were unnecessarily performed.
Bug: none
Change-Id: I85a37b9e8f00584aa794abef11abfe89dec5d0a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244098
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35637}
This is a slight refactoring while doing some other changes, so not
strictly necessary, but the error param is always supplied in practice
so it made sense to update the tests to reflect that, test that error
values are reported in (at least) some cases and remove the additional
code that checks for whether or not error information is requested.
Bug: none
Change-Id: Ia5739a18ea2beb6970eabf9d809c24dfa43466b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244097
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35632}
Improve consistency between using DCHECK checkers and compile time.
For virtual methods, we were sometimes using both and in other cases
we could be using compile time checks but were using runtime.
Added annotation for last_send_params_, last_recv_params_ in
audio/video channel classes.
Also removing redundant logging for when registration with the
transport fails. This is already being logged in the demuxer.
Bug: webrtc:12230
Change-Id: I48e156c9996dec26a990151301dabc06673541d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244095
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35630}
Remove unnecessary optimization from BaseChannel,
previous_demuxer_criteria_, that I'm not seeing as providing value.
Previously it was used to avoid a thread hop if a reconfiguration
wasn't needed, but the way that was done, wasn't thread safe. So after
addressing that issue, the variable more represents increased complexity
in the code than runtime efficiency.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ic8e3e1d2f57e669a168cc7b5cf5d407133976e3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244093
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35628}
This also removes all internal usage of RemoveTrack, and changes
the replacement function to RemoveTrackOrError rather than RemoveTrackNew.
Bug: webrtc:9534
Change-Id: Idf7bb17495686de77c70428dcbfb12278328ce59
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244094
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35624}
BaseChannel::content_name() is consistently used as the mid throughout
the code and the mid is stored in the demuxer criteria. Furthermore
there's a chance that the two variables might not be in sync if the
mid needs to be truncated, so it's better to use one source of truth.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ia98443d8ee65fd0795651981acab27c29428ba0c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244092
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35622}
Field telemetry has shown the combination of min_fps = 0 and max_fps >
0 is unused in the wild. Therefore it's safe to turn the
WebRTC-ZeroHertzScreenshare field trial default on unless the field
trial is disabled.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: Iea701218aa178b569333087b004106ffe2e85133
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244086
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35621}
Make sure previous_demuxer_criteria_ is only accessed on the network
thread and add annotation.
Bug: webrtc:11993, webrtc:12230
Change-Id: I4700fe41c947a3b1cce9649642dcd38ed62f873d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244087
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35618}
Because of this (seemingly simple) change, I had to change the return
type of transport_name from `const std::string&` to `absl::string_view`
to handle the case when there's no transport assigned.
That in turn caused an avalanche of required updates.
Bug: webrtc:12230, webrtc:11993
Change-Id: I16ec6c6a5fc2f5f7c7de572355a3c6ca924bb9d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244084
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35617}
Add TODO for accessing `previous_demuxer_criteria_`, currently accessed
from two threads (unsafe).
Changed RtpDemuxerCriteria to be a class, all members private with
accessor methods instead of direct variable access. Moving forward
this can allow for things like checking for thread/sequence and state
consistency.
Bug: webrtc:12517, webrtc:11993
Change-Id: I21c1b3067e988494ce6f4c6c85c62165801883bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244083
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35616}
While the output should never be 0, in case it is, DetectNumberOfCores()
can crash because of an RTC_CHECK. Let's fall back on the default
value of 1 instead.
Bug: chromium:1282179
Change-Id: Ice083bff4222bbe7e92d789293a7c7b01b7fbd5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244088
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35614}
Moving the following TODO into a bug for tracking.
// TODO(holmer): Remove mutex_ once RtpVideoSender runs on the
// transport task queue.
Bug: webrtc:13517
Change-Id: Ie3deb1276c2edaf9894001501ce79409f5437dd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242368
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35612}
This simplifies the work that happens on the worker thread in
preparation of avoiding having to go to the worker at all.
Bug: webrtc:11993
Change-Id: I13f063bdecce8efdb978ef1976c819019f30e020
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244082
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35610}
This makes things slightly simpler for the time being as surrounding
code is being refactored. This also removes a PostTask which has the
effect of shrinking the window between the Pending/Complete
notifications slightly since there's no additional async task
for the 'complete' step.
Bug: webrtc:11993
Change-Id: Ia86779b21c6f87301f37d763f89ace722e06e563
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244081
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35609}
Removes a few constructors where similar ones existed.
Removes MediaConfig dependency from MediaChannel and fixes an iwyu.
Bug: none
Change-Id: I9e34a1da0852c3fb21222161fad315e70598db3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242966
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35608}
The frame cadence adapter ignores key frame processing that happens
before the point where zero-hertz mode is activated, which leads to
no refresh frame requests if the key frame request comes too early.
Fix this to register a pending refresh frame request that gets
serviced when zero-hertz mode is activated. The CL changes the
FrameCadenceAdapterInterface::ProcessKeyFrameRequest from returning
whether to request a refresh frame into the frame cadence adapter
actively doing so itself via a new Callback::RequestRefreshFrame
API.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I53c2dbf6468e883eb2a2e81498e7134b1b35c336
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242963
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35598}
Timestamps are currently dead-reckoned for repeated frames in
zero-hertz mode. This leads to an ever increasing
totalPacketSendDelay metric in chrome://webrtc-internals which is
bad.
Fix this by tracking the origin timestamp of the first delay and
measuring time's progression since then. A unit test was added
which fails with the previous version.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I8627b91424f9bc56305b1dbd6a4c0624b6b3669d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242863
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35595}
The QP value of encoded key frames is normally very large. However,
the zero-hertz mode is retaining quality convergence info, leading
to only a single short repeat on key frame request when idle
repeating.
Fix this by resetting quality convergence information on key frame
requests, ensuring zero-hertz mode goes back to idle repeating
only when quality has converged again.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: Ia1ad686cc98007f01c8aaef9162011837575938c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242862
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35594}
Careful analysis of logs related to the requesting of refresh
frames from the source revealed an uncomfortable truth:
zero-hertz mode activates first when the first frame has been
received in the VideoStreamEncoder, because the number of simulcast
layers can only be computed when frame dimensions are known. This
fact means that the currently implemented logic for requesting
refresh frames is noneffective.
Fix this by
1. Activating zero-hertz mode prior of knowing the final layer
count. This causes refresh frame requests to happen without any
frames received from the source.
2. Making layer count dynamically configurable. Zero-hertz mode
considers layer quality unconverged after such a reconfiguration.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I0ecea4d2a8442a00e3b79b146dd39a5f4ac561d9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242860
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35593}
Legacy code depended of setting VideoCodecVP8::frameDroppingOn to false
for screensharing since the reference frame management handles frame
dropping in the VP8 wrapper instead.
Now the frame dropping is instead configured based on what the
Vp8FrameBufferController instance in use signals.
This change unblocks relanding
https://webrtc-review.googlesource.com/c/src/+/242366
This CL also turns frame dropping on for H264 screenshare, which
should be desirable as it allows for quicker recovery from rate control
overshoots.
Bug: webrtc:9734
Change-Id: I34a29edcd41bb5fd07f7f9bf68660472a1570533
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242965
Reviewed-by: Markus Handell <handellm@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35592}
