Previously, this script hardcoded deployment targets for device,
simulator, and Catalyst builds. This commit turns those into minimums
and allows callers to pass a higher version with --deployment-target.
Bug: None
Change-Id: I9398a8466dfa35ebac5e198aef6ec4f521054cc6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314420
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40506}
Store Detectos in a map by value instead of by unccessary pointer
Bug: None
Change-Id: Iab9904aafca02d9f9ae6633c87de860a5bd62ac7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313621
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40499}
In the past, only encodings.size() == 1 was considered singlecast. But
it's possible to have singlecast via {active,inactive,inactive} too so
this condition should be updated.
This CL ignores x-goog-max-bitrate if maxBitrate was specified on *any*
encoding. This fixes the case of {active,inactive,inactive} resolving
the singlecast inconsistency, but it also takes things one step further
and ignores x-goog-max-bitrate in simulcast cases as well (if any
active encoding has a maxBitrate), as it is not clear why simulcast
should behave differently from singlecast with regards to this flag.
Bug: webrtc:15390
Change-Id: If89a488249239a6bd10fdd56c599ccd2e6ec26fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313540
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40494}
WebRTC unconditionally enables ARC for Objective-C code. Chromium is
now enabling this globally, so change WebRTC to only enable it if it's
not already enabled.
Bug: chromium:733237
Change-Id: I0d5694d0640bb79ae83209aa0bdd36e099b85042
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314180
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40493}
This is a reland of commit 86cfe50c0e3549544ca4a7ec097feac44f0e8437
The fix was to add a backwards compatible #include + build dep.
They will be removed once Chromium is migrated.
Original change's description:
> Extract HasIPv4Enabled/HasIPv6Enabled.
>
> Bug: b/292167110
> Change-Id: Idafa4ef23e87951bdd0276c29dee3e7f8be68476
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312580
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40478}
Bug: b/292167110
Change-Id: I9797f52adf15aba57e114d0a1efec0f757ead278
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313264
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40491}
Similar to earlier CL https://webrtc-review.googlesource.com/c/src/+/169683. While this is a rather specific use case and solution, currently these macros are using a mix of styles ever since https://webrtc-review.googlesource.com/c/src/+/184934. By switching to ::rtc we can ensure that the right namespace is used.
Bug: webrtc:11400
Change-Id: Id06f09b5224a399bd6b43bf0237422b24b5adfb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40490}
EncoderStreamFactory has two code paths for creating a stream: the
"simulcast path" and the "default path". Only the former cares about
encoding paramter's maxBitrate. The latter assumes that
`encoder_config.max_bitrate_bps` already encompasses the maxBitrate of
the first encoding, but this is not always the case.
As of M113, when scalability mode is specified, {active,inactive} does
not count as simulcast stream but as a default stream represented by
encoding[0].
The problem is that `encoder_config.max_bitrate_bps` only includes
`encodings[0].max_bitrate_bps` when `encodings.size() == 1` which isn't
the case here.
This CL fixes the problem by making the "create default stream" code
path look at the first encoding's maxBitrate and remove existing
assumptions that `encoder_config.max_bitrate_bps` encompasses
`encodings[0].max_bitrate_bps`. This is a step in the right direction
since we're trying to remove all special cases and have encodings map
1:1 with SSRCs, so the "max bps of entire stream" should indeed be a
separate limit than the per-encoding limits and it was confusing that
sometimes it included and sometimes it excluded encoding[0]'s limit.
This issue did not happen in {inactive,active} since that code path
counts as "simulcast stream", so "default stream" is only ever
applicable for index 0.
TESTED=Simulcast Playground, see https://crbug.com/1455962.
Bug: chromium:1455962
Change-Id: I7c44925b780623b5979751e8959e972293648a3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313282
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40482}
The following can lead to ODR violations with symbols present in the
app and in the test module:
gn path out/Perf //:webrtc_perf_tests_module //sdk:helpers_objc
//:webrtc_perf_tests_module --[public]-->
//:webrtc_perf_tests_module_loadable_module --[private]-->
//test:google_test_runner_objc --[private]-->
//test:test_support_objc --[private]-->
//sdk:helpers_objc
After this CL:
gn path out/Debug/ //:webrtc_perf_tests_module //sdk:helpers_objc
No non-data paths found between these two targets.
Bug: b/292472934
Change-Id: If8a6ecab9b34bea0f52fe91b3404d1afeca685fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313520
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40481}
ReconfigureEncoder() is supposed to recreate the send stream when
switching between legacy and standard API paths to ensure that the
upper and lower layers agree on the number of streams that exist
(legacy = 3 encodings but 1 stream, standard = same as encodings).
This successfully happened when going from standard to legacy but due
to a bug in the condition this did not happen when going from legacy to
standard because `scalability_mode_used` is always false here (even
though the standard path does use a scalability mode).
As a consequence, SetRtpParameters()'s call to UpdateSendState()
resulted in a DCHECK-crash. In release builds we still avoid IOOB
because active_modules.size() < rtp_streams.size() but to avoid mistakes
like this happening again in the future, the DCHECK is promoted to a
CHECK.
The fix is to remove the scalability mode condition which didn't make
sense anyway - changing scalability mode does not require recreation but
recreation is necessary when number of streams change, whether or not
scalability mode changed.
TESTED = Using Simulcast Playground and switching back and forth
between standard and legacy and changing scalability modes and
confirming from stats, see https://crbug.com/1467455.
Bug: chromium:1467455
Change-Id: Ide29742972ba83f2e0a11f135ab9b39c39d4eb49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313280
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40477}
This CL also adds the prefix RTC_TESTING to `ios_internal_pure_release_bot_arm64` in order to avoid ODR
violations.
Bug: b/292472934
Change-Id: If63020e679c8670b4c797217eb38fc8c2954d422
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313240
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40476}
remove some of the templating around the Codec-derived types and
use more modern C++ loops.
BUG=webrtc:15214
Change-Id: I2710628741deca647e7ae88f5966ec7c7f12669a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311260
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40475}
since this may contain sensitive data, just like the address.
BUG=None
Change-Id: I3faa1512a15467cd5cc4bcbcaebadb736f1bae07
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313040
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@{#40473}
This CL does 2 things:
- Change the DCHECK for payload_type_frequency to a CHECK (so that
this error will be a crash not a divide-by-zero)
- Change the replay helper that was used by the fuzzer to set the
frequency of the packets to the video value (90K).
Bug: chromium:1466826
Change-Id: I39941f250b1782b36a3bcddfd347a016591466ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312700
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40468}
It was discovered that if libvpx reported a scalability mode in getStats
(e.g. L3T3_KEY) and we then changed encoder implementation to an
RTCVideoEncoder (such as MediaFoundationVideoEncodeAccelerator),
getStats continued to report the old scalability mode value.
This CL makes sure to clear the scalability mode on encoder
implementation change or if the `codec_info` is missing.
We should update MediaFoundation to report L1T1 as well, but in the
meantime we should clear any old scalability modes values when the
implementation changes (if the scalability mode is not known it is
better to report nothing than to report an old misleading value).
Bug: chromium:1426440
Change-Id: I1b5f324c4d29a00a6c73404cbee0faa2ae9cd843
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312900
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40467}
Make sure the callback is reset when tearing down the PipeWireSession
and that there is no concurrent access to it, which can potentially lead
to a crash.
Bug: webrtc:15386
Change-Id: I0b09002fe0479dc1cd946c80684bcc5d8754d54a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311546
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40464}
test.webrtc.org is gone and webrtc-internals got some updates which make
it more clear which dump is used
BUG=None
No-Try: true
Change-Id: I040e54398ced78148345804a4ab4922f67de133d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312360
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40463}
