It did not result in big quality improvements.
Bug: webrtc:12201
Change-Id: I9728469a388ee179d6069af8521bfc5571870bd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325533
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41087}
The change in the test failed to trigger an error on msan, but making
the change anyway out of an abundance of caution.
Bug: chromium:1496240
Change-Id: Ifa1b632f4e9ddb413f0eb23aba3f5b321b287b06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326080
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41083}
which is not doing anything specific to plan-b.
BUG=None
Change-Id: Ic214b10a9c3021a8ca93601453d6eb42b84f2d84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325529
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41082}
This CL is a follow-up of work done in
https://webrtc-review.googlesource.com/c/src/+/323882 where the goal
was to reduce the amount of FrameDropped error logs in
WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult.
The previous work avoids FrameDropped logs for a minimized window
being captured with WGC but we still se a large amount of these error
(or rather warning) logs. See [1] which comes from Canary.
This CL does two different things to improve the situation:
1) It adds kFramePoolEmpty to the existing
GetFrameResult::kFrameDropped enum to point out that the warning
comes from the frame pool not being able to return a valid new frame.
It also makes it more clear that it does not cause an outer/final
error as WgcCapturerResult::kFrameDropped. We still keep the inner
GetFrameResult::kFrameDropped but it is only produced when the frame
pool returns NULL and our external queue is empty. Hence, a real
frame-drop error. Note that, it is still easy to provoke
kFramePoolEmpty simply by asking for a high resolution at a high rate.
The example in [2] comes from a 4K screen @30fps. Hence, we have not
fixed anything yet.
2) It also increases the size of the internal frame pool from 1 to 2.
This does lead to an almost zero rate of kFramePoolEmpt
warnings at the expense of a slightly reduced max capture rate. BUT,
with 1 as size, we can "see" a higher max capture rate but it is not
a true rate since it comes with a high rate of kFramePoolEmpty
errors. Hence, we "emulate" a high capture rate by simply feeding
copies of the last frame that we had stored in the external queue.
Using 2 leads to a more "true" rate of what we actually can capture
in terms of *new* frames and also a substantially lower rate of
kFramePoolEmpty.
In addition, with 1 as size, if we ask at a too high rate and provide
a copy of the last frame, our CPU adaptation will not reduce its rate
since we think that things are OK when it is actually not.
Also, the samples in [3] and [4] both use 2 as numberOfBuffers
as well.
Let me also mention that with this small change, I a have not been
able to provoke any kFramePoolEmpty error messages.
Finally, geDisplayMedia can be called called with constraints where
min and max framerate is defined. The mechanism which maintains the
min rate is implemented via the RequestRefreshFrame API and it can
be sent to the source (DesktopCaptureDevice) back to back with a
previous timer interrupt for a capture request. Without this change,
these RRFs were also a source of a large amount of
kFramePoolEmpty error logs. With 2 buffers instead; this is no
longer the case.
[1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj
[2] https://paste.googleplex.com/4795680001359872
[3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp
[4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability
Bug: chromium:1314868
Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41079}
Speculative fix; replaces nullpointer following with test failure.
Bug: b/307520538
Change-Id: I294d5747c852a8cde43a0acad973dca12712c69e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326000
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41077}
To replace CreateTimeControllerBasedCallFactory
Update webrtc tests to use this new function
Bug: webrtc:15574
Change-Id: I2b74cd930ecc4f72dd1e7aa853764ca298b66ad8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325527
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41076}
Add test helper to inject fake media engine for those tests.
Bug: webrtc:15574
Change-Id: Iae4282d2d3b9804548ccadf58797f39508f07c6a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325880
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41075}
It's still doing the calculations in milliseconds, which will be updated
in follow-up CLs.
Bug: webrtc:15593
Change-Id: I7fb93d4687d58f409db182db40db720d82feb3dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325524
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41074}
Split from
https://webrtc-review.googlesource.com/c/src/+/318283
to reduce CL size. Takes a different and (hopefully) simpler
approach.
BUG=webrtc:15579
Change-Id: I8517ffbeb0f0a76db80e3e367de727fb6976211d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325023
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#41073}
This commit replaces the internal use of DurationMs, with millisecond
precision, to webrtc::TimeDelta, which uses microsecond precision.
This is just a refactoring. The only change to the public API is
convenience methods to convert between DurationMs and webrtc::TimeDelta.
Bug: webrtc:15593
Change-Id: Ida861bf585c716be5f898d0e7ef98da2c15268b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325402
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41062}
(NOTE: This and dependent CLs will be reverted in a few days after
data collection from the field is complete.)
This change introduces a new task queue concept, Voucher. They
are associated with a currently running task tree. Whenever
tasks are posted, the current voucher is inherited and set as
current in the new task.
The voucher exists for as long as there are direct and indirect
tasks running that descend from the task where the voucher was
created.
Vouchers aggregate application-specific attachments, which perform
logic unrelated to Voucher progression. This particular change adds
an attachment that measures time from capture to all encode operations
complete, and places it into the WebRTC.Video.CaptureToSendTimeMs UMA.
An accompanying Chrome change crrev.com/c/4992282 ensures survival of
vouchers across certain Mojo IPC.
Bug: chromium:1498378
Change-Id: I2a27800a4e5504f219d8b9d33c56a48904cf6dde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41061}
Update most of the webrtc tests to use EnableMediaWithDefaults instead of SetMediaEngineDefaults
Bug: webrtc:15574
Change-Id: I489a09e4ea3479dc26829ee0c1235e67bcbca7c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325485
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41059}
To ensure padding, we increase 1 bit instead of 1kbps to avoid that 1kbps adds up over time.
Not have unit test for this, but did manual/hamrit tests many times.
Bug: webrtc:12707
Change-Id: I9b3160ab1808cb3a21ff0609446359a4ec3a4949
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325520
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41056}
Build fix for H265 on Android so that https://webrtc-review.googlesource.com/c/src/+/325482 can land.
gn args:
target_os = "android"
proprietary_codecs = true
Bug: webrtc:15620
Change-Id: I8a134afbc50137ac17ce9a4a57d68dd3f3c6d52f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325483
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41053}
The OnFrameToEncode probe had no END in passthrough mode and it
resulted in infinitely long OnFrameToEncode TRACE events.
We now exclude the probes altogether in passthrough mode.
Bug: webrtc:15456
Change-Id: Ia96a5d2b1f5b5470527e904a3ab07de5aa712ca4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325401
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41051}
instead of requiring to pass in call_factory and media_engine
webrtc users should set media_factory member and media dependencies into PeerConnectionFactoryDependencies
Bug: webrtc:15574
Change-Id: I2dc584fe7afa41c9f170bdc51533396155cdcb06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325320
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41049}
This CL just moves the definition and adds a forward.
Actually using the new definition is left for later CLs.
Bug: webrtc:15622
Change-Id: I6d97ef45b98f9eb193c59dd7f8a89c99cfe0ba9a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325381
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41048}
The change is under field trial use_in_start_phase.
Bug: webrtc:12707
Change-Id: I2ba8245c5d126b3c8a2e54b826853d98aad6e4f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325184
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41047}
Increasing BWE by 1kbps should be safe/no-op in practice, and it ensures that padding in kIncreasing state will be triggered.
Bug: webrtc:12707
Change-Id: I82493d07a80abd60c93d9cff74baf0a55e77f2b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325286
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41046}
When a timer expires, it can optionally return a new expiration value.
Clearly, that value can't be zero, as that would make it expire
immediately again.
To simplify the interface, and make it easier to migrate to
rtc::TimeDelta, change it from an optional value to an always-present
value that - if zero - means that the expiration time should be
unchanged.
This is just an internal refactoring, and not part of any external
interface.
Bug: webrtc:15593
Change-Id: I6e7010d2dbe774ccb260e14fd6b9861c319e2411
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325281
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41045}
...for signaling and worker thread members in BaseChannel classes.
Bug: webrtc:15099
Change-Id: I83611ed2564e143aca19d0f12ce060b77eb9d2a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325260
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41041}
Before this change, a timer could have an optional max duration. Either
that value was present, and that limited the max duration of the timer,
or it was absl::nullopt, which represented "no limit".
To simplify the interface, this CL makes that value "not optional" by
having it always present. The previous "no limit" is now represented by
DurationMs::InfiniteDuration.
This is just a refactoring of internal interfaces - public interfaces
are left untouched.
Bug: webrtc:15593
Change-Id: I80df1d9b2f4d208411ce6cb5045db0a57865e3b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325280
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41040}
