Upstream commit: https://webrtc.googlesource.com/src/+/17ffd365a244ac3f01f4b713d7bcf8b554f89769
Remove IntKeyTypeFamilyToKeyType
which is no longer used. Also the blink::WebRTCKeyType it refers
to no longer exists either
BUG=None
Change-Id: I8236ed906b5712d11173dfcf181f556b1ff597f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362387
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43038}
Upstream commit: https://webrtc.googlesource.com/src/+/825e4f19ce38e839d74d865b01dbe86abbec3df3
VideoAdapter: Interpret requested resolution as max restriction.
The `requested_resolution` API must not change aspect ratio, example:
- Frame is 60x30
- Requested is 30x30
- We expect 30x15 (not 30x30!) as to maintain aspect ratio.
This bug was previously fixed by making VideoAdapter unaware of the
requested resolution behind a flag: this seemed OK since the
VideoStreamEncoder ultimately decides the resolution, whether or not
the incoming frame is adapted.
But this is not desired for some non-Chrome use cases. This CL attempts
to make both Chrome and non-Chrome use cases happy by implementing the
aspect ratio preserving restriction inside VideoAdapter too.
This allows us to get rid of the "use_standard_requested_resolution"
flag and change the "VideoStreamEncoderResolutionTest" TEST_P to
TEST_F.
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I1dfd10963274c5fdfd18d0f4443b2f209d2e9a4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362720
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43037}
Upstream commit: https://webrtc.googlesource.com/src/+/098c128a159bfc2848f19b3816f632bab77f0872
Explicitly use the Opus DTX encoder state.
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}
Upstream commit: https://webrtc.googlesource.com/src/+/d153de6d33a79d450c626b9b8e9613df33947282
Add payload type assignment to offer/answer generation.
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}
Upstream commit: https://webrtc.googlesource.com/src/+/4b51217ef6d247d03128dedd272ee5f02552fbfd
Make purple bots happy: Shorten TEST_P names.
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}
Upstream commit: https://webrtc.googlesource.com/src/+/59d592ebac8f22d44fd48d7af7a5335fca21563f
Replace list usage with set for files accumulation in PRESUBMIT to
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}
Upstream commit: https://webrtc.googlesource.com/src/+/18486c55745d8c90ebd758fe8ff7d97e745c94df
Make GetSourcesVideo test wait for two frames
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}
Upstream commit: https://webrtc.googlesource.com/src/+/cbf5122333ce2e34572dfba1c3c0e32304362adc
Avoid signaling requested_resolution back to the adapting source.
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}
Upstream commit: https://webrtc.googlesource.com/src/+/6e312e51d7982ee94f2a79c468c6cc4c3f78bf03
install libsrtp log handler
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}
Upstream commit: https://webrtc.googlesource.com/src/+/2b5f7cb4b34e5d218a3f12e8b04dd537585198c0
Adjust `requested_resolution` to match frame's aspect ratio.
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}
Default pushes to Lando eventually fails because the push-to-Lando
functionality utilizes mozilla-unified, which does not contain
a reference to elm.
Differential Revision: https://phabricator.services.mozilla.com/D229414
When using MFT for the color conversion, it can only do NV12 to RGB. But
CallVideoProcessorBlt supports all YUV formats to RGB, which is better.
Differential Revision: https://phabricator.services.mozilla.com/D229718
StackMacroAssembler can only be stack-allocated on the main thread, so we need to be able to use a different MacroAssembler that can enforce GC safety off-thread (similarly to IonHeapMacroAssembler).
I wanted to put a StackMacroAssembler as a member of BaselineInterpreterGenerator, to avoid having to allocate one at the call site. However, it was uninitialized in the BaselineCodeGen construtor, because derived class fields are initialized after calling the superclass constructor.
Differential Revision: https://phabricator.services.mozilla.com/D229850
And all its callers, e.g. AnimationCollection/TimelineCollection, and
nsAnimationManager/nsTransitionManager.
We will add the data field for view-transitions in Bug 1921116.
Differential Revision: https://phabricator.services.mozilla.com/D229565
Even though we don't support CSS Transitions on view transition
pseudo-elements, it's better to use PseudoStyleRequest for consistency
and avoid allocating unnecessary objects.
Also, make sure we use the correct element to retrieve the transition
collection.
Differential Revision: https://phabricator.services.mozilla.com/D228229
Just like what we do for EffectSet. Also, we will update
ElementAnimationData later, so for now only change the APIs of
AnimationCollection and TimelineCollection (and their callers).
Differential Revision: https://phabricator.services.mozilla.com/D228227
Use `PseudoStyleRequest` in the APIs of EffectSet. We would like to
store the animation in the originating element, so need to use
`PseudoStyleRequest`.
Differential Revision: https://phabricator.services.mozilla.com/D228226
