Also, make the iOS audio unittests not run on the simulator by default,
and if someone wants to run the tests one can do
by using the WEBRTC_IOS_RUN_AUDIO_TESTS environment variable.
Bug: webrtc:7812
Change-Id: Ie9fc70872c6617516e2f2c21039489df309b85fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292621
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39306}
I am updating Chrome Remote Desktop to apply a scale factor when using
curtain mode (i.e. a loopback RDP session) and I've found that while
the changes are applied and the desktop is scaled, DXGI stops
producing frames.
This is essentially the same issue as crbug.com/1307357 except this
issue is occurring when the DPI is changed rather than the desktop
size.
The fix is to look at the effective DPI for the source being
captured (or the primary monitor when capturing the full desktop)
and then signaling an environment change when the DPI differs.
Bug: webrtc:14894,b:154733991
Change-Id: Id768d4a384434ba59e7396bc919d0ba30d0f6acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292791
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#39305}
PostDelayedTask doesn't guarantee task execution order. For example,
if you post two tasks, A and B, back-to-back using the same delay
there is no guarantee that A will be executed before B.
Re-implemented pacing using sleep(). Changed pacer to compute task
scheduled time instead of delay. Sleep time is calculated right before
task start. This provides better accuracy by accounting for any delays
that may happen after pacing time is computed and before task queue is
ready to run the task.
It is tricky to implement pacer tests using simulated clocks. The test
use system time which make them flacky on low performance bots. Keep
the test disabled by default.
Bug: b/261160916, webrtc:14852
Change-Id: I88e1a2001e6d33cf3bb7fe16730ec28abf90acc8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291804
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39302}
This reverts commit 815522782a92e168b80edc760b2e53e4d0e4ea0d.
Reason for revert: Breaks a downstream project.
The internal investigation is still in-progress.
Original change's description:
> sdp: add rtcp-fb:* lines for common feedback
>
> which potentially allows switching to that pattern in the future.
> Video FEC mechanisms (ulpfec, flexfec-03, RED) that currently
> do not have any feedback parameters but will still be considered "common" and feedback may be sent for them.
>
> For audio this causes rtcp-feedback to be sent for G711 and G722 if negotiated.
>
> BUG=webrtc:14802
>
> Change-Id: I54852d39e176f918d4b36462526ceb40617b8fbe
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290702
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39224}
Bug: webrtc:14802
Change-Id: I4dc3c0c53ad1bc06050c0d73b088303312ac58b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293020
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39296}
Call operators do not improve code clarity, and usage was moderate.
Bug: None
Change-Id: I8d86bd7d435ce88e99f4abee8ab95a336d47dc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292960
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39294}
When I run these tests locally, Gmock complained about the incorrect
mock function call and caused the test to fail.
Bug: None
Change-Id: I37c9168650471b171a5d7f7b4e3a4c6c6225d618
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292920
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39292}
Also move the frame_transformer_factory_unittest build target into the
if(rtc_include_tests) block, so it's not compiled without the mock.
Bug: chromium:1414370
Change-Id: I12653b173b419ec20bfad904e24a4d965e7e7830
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292863
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39288}
The elements of the fps_allocation vector are fractions of the maximum
frame rate. Each fraction is represented as an 8-bit unsigned integer,
where 0 = 0% and 255 = 100%.
The original code (added in
https://webrtc-review.googlesource.com/c/src/+/201384) sets the elements
of the fps_allocation vector to frame rates rather than frame rate
fractions. Perhaps fps_allocation could be renamed to avoid this kind of
confusion.
modules_unittests --gtest_filter=LibaomAv1EncoderTest.*
Tested:
Change-Id: Icd050da3b3c2cff31913c3430f7b6b6e9829b9fa
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292784
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39286}
During code review, kFullFramerate was renamed kMaxFramerateFraction but
the uses of kFullFramerate in a comment were not updated. See
https://webrtc-review.googlesource.com/c/src/+/117900/3..4
Change-Id: I6b3c06b4c5b302e8ba40bde4ba722b94aab191eb
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292801
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Wan-Teh Chang <wtc@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39285}
This allows MediaChannel to know whether it's being used
for sending, receiving, or both. This is a preparatory CL
for landing the split of MediaChannel usage into sending and
receiving objects.
Bug: webrtc:13931
Change-Id: If518c8b53d5256771200a42e1b5f2b3321d26d8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292860
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39283}
Today the default 3 encodings path for VP9 is to trigger legacy SVC,
which is tested by "SendingThreeEncodings_VP9_LegacySVC".
This CL adds another test that does not rely on the default
`scalability_mode` and instead explicitly asks for simulcast (3 x L1T3).
When VP9 simulcast is supported (https://crbug.com/webrtc/14884), this
API pattern will allow the app to ask for standard behavior while the
default path still exists for backwards-compatibility.
Because we don't support VP9 simulcast yet, this test still triggers
legacy fallback which is wrong so this test mostly serves to document
current behavior, but see Patch Set 1 for side-by-side comparison of
what we want to EXPECT and what we currently EXPECT.
In the meantime, this CL helps exercise code paths that are possible
to trigger as of M111. The TODOs will be addressed as part of
https://crbug.com/webrtc/14884.
Bug: webrtc:14884
Change-Id: Id901eea8f399223afd5a1731a3323e5134686134
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292720
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39281}
When asking for 3 encodings of VP9, which the spec says is simulcast,
you don't get simulcast but instead you get one RTP stream sending SVC.
This results in a single "outbound-rtp" but GetParameters() still says
3 encodings are used. We know we get SVC because the scalabilityMode
from getStats() says "L3T3_KEY".
In a future CL we will add simulcast VP9 support when
`scalability_mode` is specified in the API but we'll need to continue
to support the legacy SVC code paths until that has been deprecated
and removed (https://crbug.com/webrtc/14889).
Bug: webrtc:14884
Change-Id: Ibeca44b7a0b93097ad9525e45ebbca3b7663c686
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292581
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39278}
If we are notified of the destruction of the window before a
CaptureFrame call can fail, then we may end up attempting to destroy the
underlying WGC object inside it's own event handler. This can be
problematic, as the class itself may want to run other code. Instead,
we just unsubscribe and signal that any future CaptureFrame calls should
reject.
This also removes setting "is_capture_started_=false" in the item closed
handler, as all that served to do is cause the WgcCapturerWin code to
attempt to restart the capturer, and somewhat muddies up our metrics.
Bug: chromium:1413005
Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39275}
Explicitly configure VP8 and verify the codec and scalability mode makes
sense. In preparation for doing the same with VP9 when VP9 simulcast is
supported.
Bug: webrtc:14885, webrtc:14884
Change-Id: If0c89e9b5de4fc63a59e17412fe4f0317fd61229
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292580
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39272}
Previous tests only asserted that O/A succeeded and that the number of
encodings was as expected. This test goes further and also asserts that
bytesSent eventually becomes non-zero (after an initial ramp-up time).
Let's get testing straight before we add VP9 simulcast support.
Bug: webrtc:14885, webrtc:14884
Change-Id: Idccce66698a077264fa0df2c448c8474d2439aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291960
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39271}
This will be used by third_party/blink/renderer/platform/peerconnection/webrtc_video_track_source.cc to provide capture_time_identifier_ms_ from
media::VideoFrame.
This identifier would then be passed to webrtc::EncodedFrame and
webrtc::TransformableVideoSenderFrame (in the future CLs) to be used as
an identifier for encoded frames.
Bug: webrtc:14878
Change-Id: I1d8a27891323d86fdc2f014988a8da572df84119
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291805
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#39270}
In the previous commit, I changed to modify deps_content,
but it was no-op since the content was already written to the DEPS file.
Bug: None
Change-Id: I278fbbb628422a42e616708f00529e935d75cd1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292660
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Christoffer Jansson <jansson@google.com>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39268}
By making this change, we ensure that these variables are not outdated.
Also, remove unnecessary list calls to python generators.
Bug: None
Change-Id: I53babe03da1cb78cf5dc127b7e1f753b63be20de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#39267}
This allows callers to modify an encoded video frame's SSRC via the
setMetadata() call, which we'd like to do from Chrome, to allow using
an encoded frame from one PC on a different one.
Bug: webrtc:14709
Change-Id: Ia6b33761a3f63038f6eabbcd848916877e24454b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292380
Auto-Submit: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39266}
Absolute capture time extension did not work in tests that use test_audio_device. This change add capture timestamp to test audio device so absolute capture timestamp extensions can be sent in tests.
This make it possible to write tests for absolute header extension in Hamrit, and possible other test platforms as well.
Bug: None
Change-Id: Ie237f516ce0cccf43c32fe40da76a9d31f9fba53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292340
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39265}
addressing feedback from
https://github.com/w3c/webrtc-extensions/issues/130
and aligning the behavior with setCodecPreferences.
BUG=chromium:1051821
Change-Id: If0c29e1e16781b6898814e2f888ad08a079fc609
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286780
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39264}
Also added an enum for unknown reason.
New value uses a macro-like name rather than a constant-like name for consistency.
Bug: chromium:1369096, webrtc:14131
Change-Id: Ib315584ec40d8c1cd9a6f0ff44587c0d92c735d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292341
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39262}
This verifies that receiving two RTCP SR packets is enough to get
a defined capture start time stat.
Bug: webrtc:13931
Change-Id: Ib5f7c2954eab6500917f25c44f523d3aedae5e94
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291520
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39261}
