Use the DTX state from inside the Opus encoder instead of trying to
mimic the logic outside.
Bug: None
Change-Id: I852044fee261a5b7f9255c557a27adfd0b1701bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362640
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Lionel Koenig <lionelk@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43034}
This adds payload types to the codecs at the time when offer
is being generated, if they are unassigned at that point.
Bug: webrtc:360058654
Change-Id: I231ed057ebaf7fb0fffaf6ff5d600b064ba21f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362282
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43033}
They are now passed as part of the Environment
Bug: webrtc:362762208
Change-Id: I02868e9f41533a546f62fe30fdc6f3a7708eb346
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362084
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43032}
This will help to reduce redundant ScalabilityMode to temporal layer
count mapping in blink.
Bug: chromium:40763991
Change-Id: Ida3e6abb91383e27465eb1b697ad9431935cf9ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362486
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43031}
The recently added tests resulted in some .log file on some bots being
too long:
video_engine_tests_exe-VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_RequestedResolutionInWrongAspectRatioAndSourceIsAdapting_0-1.log
This CL makes the test names significantly shorter.
# Trivial and believed to fix purple bots, let's land ASAP
NOTRY=True
Bug: webrtc:367066321
Change-Id: I831911947af9d5639d1edb559470f1c9ae702d6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362721
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43030}
prevent duplication
Wherever we don't include any extra information about the issue (e.g
file *and line number*), there's no need to return a presubmit result
with the file duplicated (it spams the console for no reason...)
bug: none
Change-Id: I11968f97f7c927b01f5cda6e56ea03e3ff47dfca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362621
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#43029}
When it waits for only one frame, the test is flaky.
When it waits for two frames, it is not.
# Relying on triviality for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:367205682, webrtc:42220900
Change-Id: I14963b7a86961f438fd511aba8f29525e1f19750
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362583
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43025}
When requested_resolution uses a different aspect ratio than the source
the encoder will restrict the frame without changing its aspect ratio,
e.g. a 60x30 input frame that is restricted to 30x30 results in 30x15,
not 30x30.
While this logic works correctly in isolation, if the source also adapts
the frame size based on the sink_wants.requested_resolution that is
signaled back to the source, then the source will produce stretched
30x30 prior to the encoder which happily sends 30x30 not knowing any
wiser.
This is incompatible with the spec[1] and makes this WPT[2] fail. The
correct behavior is to NOT signal the requested_resolution back to the
source, the encoder already configures the correct resolution so this
isn't actually needed and the source shouldn't need to know this API.
In order not to break downstream projects, the new behavior is landed
behind a flag and both behaviors are tested with TEST_P.
This unblocks launching scaleResolutionDownTo API on Web. Migrating
from old to new code path and deleting the flag is a follow-up AI:
webrtc:366284861.
[1] https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto
[2] https://chromium-review.googlesource.com/c/chromium/src/+/5853944
# Relying on previous green runs for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I7fd1016e9cc6f0b0b9b8c23b0708e521f8e12642
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362541
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43024}
The class itself and its unit test remains, for now, but will be removed
later.
Bug: webrtc:14867
Change-Id: I36cec8fca7913663f63c53622ed2760e5e048c2f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362580
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43023}
which may show useful debug logging.
Also document that we need to forward-declare the internal srtp_ctx_
struct instead of srtp_t.
BUG=webrtc:361372443
Change-Id: I76b1a4fb385af0fc1532f0ce6d0692b804f003dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360182
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43022}
This API should not modify the aspect ratio of the frame, e.g. if the
frame is 1280x720 and requested_resolution is 1280x360, the result
should be 640x360, not a streched out 1280x360 frame. The spec version
of this API calls this "maxWidth" and "maxHeight" which is the right
way to think about it rather than a forced width and height.
VideoAdapter continues to be used to apply adaptation restrictions, but
we now make sure to calculate the correct frame size BEFORE applying
restrictions. Prior to this CL, the VideoAdapter was also used to apply
requested_resolution restrictions. This is actually wrong and would
cause strange scaling factors in some cases, e.g. f=1280x720 + r=720x405
would result in 640x360 instead of 720x405. Now we make f=720x405 first
and only adjust further if restrictions or alignments require us to.
Since this is a change in behavior a WebRtcVideoChannelTest is updated.
Encodings integration test is also added, both for aspect ratio (new
behavior) and orientation agnosticism (old behavior still passing).
Bug: webrtc:366067962
Change-Id: I4e8dc27da5a84d73238b8ab74ef197eb5ee8072a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43020}
This allows detecting if it has been set reliably.
0 is a valid payload type.
Bug: webrtc:360058654
Change-Id: Ic3646abe20d0247592145ad27549fa46ddb7ec90
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43016}
Checks if the DirtyRegionMode property is present in GraphicsCaptureSession and logs a boolean histogram with the result.
Detecting support for this property means that the WGC API supports
dirty regions and it can be utilized to improve the capture
performance and the existing zero-herz support.
See also https://issues.chromium.org/issues/347991512 for more details
on how to detect support for dirty regions in WGC.
Bug: chromium:40259177
Change-Id: Ia316c4ece54bd93cfef1fa23c199675c64143f76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362240
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43015}
Note: Does not include code for the actual late allocation
of PTs.
Bug: webrtc:360058654
Change-Id: Iaa6bd2db2f974aad84fe1ae9c1aca5aea5d1d25e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362320
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43014}
This CL makes `requested_resolution`, which is the C++ name for what
the spec calls scaleResolutionDownTo, align with the latest PR[1].
The PR says to ignore scaleResolutionDownBy when scaleResolutionDownTo
is specified as to be backwards compatible with scaleResolutionDownBy's
default scaling factors (e.g. 4:2:1). Ignoring is different than what
the code does today which is to throw an InvalidModificationError.
We don't want to throw or else get+setParameters() would throw by
default due to 4:2:1 defaults so the app would have to remember to
delete these attributes every time even though it never specified them
(Chrome has a bug here but fixing that would expose this problem, see
https://crbug.com/344943229).
[1] https://github.com/w3c/webrtc-extensions/pull/221
Bug: none
Change-Id: I21165c9b9f9ee7259d88b89f9ae58b862ea4521e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362260
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43002}
* IWYU export <sys/socket.h> from rtc_base/net_helpers.h.
* Add a presubmit check to ensures that <sys/socket.h> is included through net_helpers.h (expect if there is a IWYU pragma or a no-presubmit-check).
* Clean up existing includes of <sys/socket.h>
Change-Id: I4bc6cce045c046287f8f74f89edfc9321293b274
Bug: b/236227627
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362082
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#42996}
AV1E_SET_MAX_CONSEC_FRAME_DROP_MS_CBR was added in https://aomedia-review.googlesource.com/c/aom/+/192402. It allows to configure max number of consecutive frame drops using time units. Use it instead of AV1E_SET_MAX_CONSEC_FRAME_DROP_CBR.
Bug: webrtc:351644568
Change-Id: I73265d5258d681926eb5b65e32c2a61b26c310ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360842
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42995}
This entails passing in a PayloadTypeSuggester as a dependency. PT suggesting is still done according to the old method, but with new code.
Bug: webrtc:360058654
Change-Id: I12a7d2aa6aa482fb62ff3dfb34b9761ebb7dddef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361200
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42989}
