This adds the final piece, which makes the socket and the retransmission
queue generate the callbacks.
Bug: webrtc:5696
Change-Id: I1e28c98e9660bd018e817a3ba0fa6b03940fcd33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264125
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37455}
This allow to remove the testonly from the rtc_event_log_visualizer
binary and the implicit dependency on the path of the default
conversational speech file.
The binary size of event_log_visualizer passes from 2.1 MB to 4.0 MB.
Bug: b/237526033
Change-Id: I71cf647f039f26f30c792c49c752cff5c5b329a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267663
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37453}
This helper suppose to replace ToQueuedTask when calls to TaskQueueBase interfaces are converted to PostTask variants that take absl::AnyInvocable.
Bug: webrtc:14245
Change-Id: I590a6ca068cf5e682ffb34770bd54cf5ce37d826
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267706
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37449}
For all messages where the last fragment was _not_ put on the wire, the
send queue is responsible for generating lifecycle events, but once all
fragments have been put on the wire, it's the retransmission queue that
is responsible. It does that by marking the final fragment of a message
with the lifecycle identifier, and once that message has been fully
acked by the cumulative ack TSN, it's clear that the peer has fully
received all fragments of the message, as the last fragment was acked.
For abandoned messages - where FORWARD-TSNs are sent, those will be
replied to by a SACK as well, and then we report abandoned messages
separately, to later trigger `OnLifecycleMessageExpired`.
This CL adds support in OutstandingData, which doesn't generate the
callbacks itself, but just reports them in the AckInfo.
Bug: webrtc:5696
Change-Id: I64092f13bcfda685443b7df9967b04d54aedd36a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264124
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37448}
This is a reland of commit 3afb8e24311dc1297150d4011894b6cb00841735
Patchset 1 is the original CL. Patchset 2 contains a fix:
Depending on call site, the number of spatial layers for VP9 might be
signalled in three different ways. One of them was afaict only used in
out perf tests, and resulted in the max bitrate being incorrectly
capped.
The fix now checks that field too.
Original change's description:
> When VP9 SVC is used, use SvcConfig to set max bitrate for the stream.
>
> Currently, a default max bitrate is determined within WebRtcVideoEngine,
> which maxes out at 2.5Mbps - and that limits the max bitrate deteremined
> by SvcConfig for resolutions above 720p.
>
> This does not affect simulcast, as WebRtcVideoEngine already knows to
> trust the rate allocation in simulcast.cc instead.
>
> Bug: webrtc:14017
> Change-Id: I0c310a6fd496e9e5a10eae45838900068aa1ae2d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267160
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37370}
Bug: webrtc:14017, webrtc:14234
Change-Id: Idcaf4321a20c917e4049522c577336ddcfc7ffbb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267860
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37446}
Intended to be used in downstream code when deleting deleting this
attribute.
Bug: webrtc:11607
Change-Id: I39417997a2ec2e72d726da476b5bce88abe267b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267843
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37445}
Also move ScalabilityModeToString to api and add RTC_EXPORT so that
Chromium can use it.
Bug: chromium:986069
Change-Id: I5dbbb6de9b14ca20f3ae0630552dcd44595ad5ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267780
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#37444}
This reverts commit 3afb8e24311dc1297150d4011894b6cb00841735.
Reason for revert: Causes some unexpected perf regressions.
Original change's description:
> When VP9 SVC is used, use SvcConfig to set max bitrate for the stream.
>
> Currently, a default max bitrate is determined within WebRtcVideoEngine,
> which maxes out at 2.5Mbps - and that limits the max bitrate deteremined
> by SvcConfig for resolutions above 720p.
>
> This does not affect simulcast, as WebRtcVideoEngine already knows to
> trust the rate allocation in simulcast.cc instead.
>
> Bug: webrtc:14017
> Change-Id: I0c310a6fd496e9e5a10eae45838900068aa1ae2d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267160
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37370}
Bug: webrtc:14017
Change-Id: I1e45ee3f78deb50a9057d648146b1a6360782aa3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267800
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37438}
This CL duplicates a few lines of utility code from
//modules/audio_processing:audioproc_test_utils (which contains more
testonly things) and allows the possibility to remove testonly from
the unpack_aecdump tool.
Bug: b/237526033
Change-Id: If2e1dd4cc825429c496091cf8640c67069fb6e6f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267701
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37437}
The default values are zero, for consistency with the memset of VideoCodec. Except for numberOfTemporalLayers; This cl sets
numberOfTemporalLayers to 1 by default. The intention is to be able to
delete exlpicit setting of .numberOfTemporalLayers = 1 in downstream
code, to ease replacing it with a scalability mode.
Bug: webrtc:11607
Change-Id: I9de442f1893d474ea360f9b33364a00627f6c3be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267662
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37430}
We should have done this a long time ago.
Let's do the same for stats_types.h in a separate CL because that file
is part of the api/ folder and needs some special care (typedefs and
temporarily include helper to avoid breaking downstream projects).
Bug: webrtc:14180
Change-Id: Id9c71ebd53dd97dd238bdf7527c36d7cf0e91f85
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37426}
In the modern getStats implementation, we currently do two
block-invokes when we trigger stats collection, once for
signaling -> worker and once for signaling -> network inside, both take
place inside the "prepare" method:
RTCStatsCollector::PrepareTransceiverStatsInfosAndCallStats_s_w_n.
For comparison, the legacy stats collector currently require 4 block
invokes to operate.
Bug: webrtc:14247
Change-Id: Ie739cbcf29d87041484183b520aeba520aafcaba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267660
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37424}
The send queue is responsible for generating lifecycle events for all
messages that are still in the queue. Because, if they are still in the
queue, that means that the last fragment of the message hasn't been sent
yet (because then it would have been in the retransmission queue
instead). And if the last fragment hasn't been sent, the send queue is
responsible for generating the
`OnLifecycleMessageExpired(/*maybe_sent=*/false)` event.
Bug: webrtc:5696
Change-Id: Icd5956d6aa0f392cae54f2a05bd20728d9f7f0a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264144
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37419}
RID is defined for multiple usages in RFC 8851, but we only support
usage with a=simulcast as specified in RFC 8853.
Bug: chromium:1341043
Change-Id: Ie72074c5b394bdc41865938a86ec9c7629e1f5e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267628
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37417}
According to Xcode 14 documentation [1]:
> Xcode no longer builds bitcode by default and generates a warning
> message if a project explicitly enables bitcode: “Building with
> bitcode is deprecated. Please update your project and/or target
> settings to disable bitcode.” The capability to build with bitcode
> will be removed in a future Xcode release. IPAs that contain bitcode
> will have the bitcode stripped before being submitted to the App
> Store. Debug symbols for past bitcode submissions remain available
> for download. (86118779)
[1]: https://developer.apple.com/documentation/Xcode-Release-Notes/xcode-14-release-notes
Bug: webrtc:14237
Change-Id: I39fb618409e1978f8e7b42aa71208e00ed69d85f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267407
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37415}
Instead of creating a TaskQueue from packet_sender, create a rtc::Thread
in test_controller so that test_controller instantiates a SocketServer,
eliminating the use of rtc::Thread::socketserver().
Also did various cleanups, such as adding threading annotations, and
ensuring that all network operations are done in dedicated threads.
Bug: webrtc:13145
Test: Unittest, and manually verified using Android clients and Linux servers
Change-Id: I05ebe5e29bd80f14a193c9ee8b0bf63a1b6b94d7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263321
Commit-Queue: Daniel.l Lee <daniel.l@hpcnt.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37411}
This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
Reason for revert: It breaks a test while rolling into Chromium,
see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
Original change's description:
> Wait for frames to arrive in WgcCapturer instead of returning nothing.
>
> We're seeing a high instance of "first capture failed" in Chromium when
> using WGC. We can reduce this by waiting for frames to arrive if there
> are none in the frame pool instead of returning a temporary error.
>
> I've set the maximum time to wait for a frame to 50ms. If no frame
> arrives before 50ms has elapsed, we will return a temporary error.
> Added a new test, FirstCaptureSucceeds, to verify that this is working
> as expected.
>
> As part of this I updated the name of the `kCreateFreeThreadedFailed`
> enum value to `kCreateFramePoolFailed`. The value remains the same
> since they both report failures in frame pool creation.
>
> I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> store two frames. This should prevent us from having to wait on the
> event as frequently. This will increase the latency between capture
> and display, however. High frame rate applications should not be
> noticeably affected.
>
> Additionally, we uncovered a bug in the OS that prevents window capture
> when there are displays attached, but none of them are active. Added
> a new check to `IsWgcSupported` to cover this scenario.
>
> Finally, some issues with other WGC tests blocked moving the TryBots
> to a newer version of Windows. This CL fixes those issues and updates
> the TryBot configuration.
>
> bug: chromium:1314868
> Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37404}
Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37408}
