and modify DEPS files accordingly.
This is done in support of the decision to encourage AbslStringify.
Bug: None
Change-Id: I26fee77978d1dd21be6d2ef011c4dfd78a7b43e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367204
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43338}
Increased the number of errors the automation is fixing to 150 from
75 in this commit.
Bug: webrtc:370878648
Change-Id: If6e6a5f40db7eb54c27c1a85fb7031838e478c70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366205
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#43337}
It is used to distinguish between audio/video packets and everything else (retransmit/padding/fec), so naming it is_media makes more sense.
This is a follow up to https://webrtc-review.googlesource.com/366644
Bug: b/375148360
Change-Id: Ia53f4d707ceb85f059688d86bc5dcc2d57908d88
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366424
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43319}
It works in the same way as the first packet received callback and can be used for latency measurements.
One important detail is that RTCP and probe packets are excluded from triggering the callback.
Bug: b/375148360
Change-Id: I5f99b565f96b622e864669cf227be5534aab0fc7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366644
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43309}
This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd
The reason for the revert was a downstream use of
`rtc::VideoSinkWants::requested_resolution`, so in this reland we don't
rename this field, it's fine just to rename the one in
RtpEncodingParameters for now.
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
NOTRY=True
Bug: webrtc:375048799
Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43304}
This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd.
Reason for revert: Break downstream projects
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
Bug: webrtc:375048799
Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43301}
This is a pure refactor/rename CL without any changes in behavior.
This field is called scaleResolutionDownTo in the spec and JavaScript.
Let's make C++ match to avoid confusion.
In order not to break downstream during the transition a variable with
the old name being a pure reference to the renamed attribute is added.
This means we have to add custom constructors, but we can change this
back to "= default" when the transition is completed, which should only
be a couple of CLs away.
Bug: webrtc:375048799
Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43300}
This fixes the bug where scaleResolutionDownTo must be specified even
on inactive encodings (scaleResolutionDownTo is the JavaScript name for
what is called requested_resolution inside WebRTC).
Bug: chromium:375048792
Change-Id: I3206ef7de09eaba24a5b4305d888ec4904617e58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366522
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43292}
This is similar to MatchesRtpCodec but not an exact match of parameters, unspecified parameters are treated as default. Use IsSameRtpCodec for comparison when codec is configured via encodings.
Bug: b:299588022
Change-Id: I0ea800e50af6f5666e3e867a928e15b0aa044635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365142
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43272}
Compiling webrtc with `-Werror=unused-parameters` is failling duo to
those parameters.
Also, it shouldn't harm us to put those in comment for code readability as
well.
NOTE: This time I made sure to iterate over the C files in the
audio_processing folder and compile them using gcc.
On the original CL that was reverted - that failed with the same error
Danil mentioned. This time it seems fine.
I'll make sure to run the same script on the rest of my CLs for sanity
Bug: webrtc:370878648
Change-Id: I83cea3a08777e21d26a95bcad503a2d1b74566eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364537
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#43249}
We should use the Timestamp type, rather then int64, to store timestamps. In https://webrtc-review.googlesource.com/c/src/+/365001/ an additional int64 timestamp was added (last_sender_report_timestamp_ms).
This CL fixes the new timestamp, as well as other similar timestamps in MediaReceiverInfo (last_sender_report_utc_timestamp_ms and last_sender_report_remote_utc_timestamp_ms).
Bug: webrtc:372393493
Change-Id: I0e473730e85a69ec595b421e2c3db920364008eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43248}
The split shows that some places don't need it at all. Most other
places will depend on both send and receive stream targets.
Bug: webrtc:373151158
Change-Id: I788136a2ee84180c16345a7929b7f7bf3f97507b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365460
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43230}
std::optional<T>::emplace() without a value is broken
on clang++ with gnu libstdc++. this workarounds the bug
by using the assignment operator instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227
Bug: None
Change-Id: I6fd096ff4d632259e6eab776e318c1d7b15e4bd5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365400
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43229}
This is in preparation for making a matcher that checks the parameters
when all payload types come from the same number space.
Bug: webrtc:360058654
Change-Id: Ibcf4fee8d882eb0fa7f83faf0278bc6757761e18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365361
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43223}
Use the same code in PayloadTypePicker as in Codec.Matches()
Bug: webrtc:360058654
Change-Id: I549ed24860648cfdb6a173a19773daf01db827b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365102
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43217}
This CL is a pure move; later CLs will try to increase consistency
between the functions.
Bug: webrtc:360058654
Change-Id: I6662b3d35f8e2dab60c2778a4755454fe3029fe2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365100
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43210}
Some TODOs with an old from where added in https://webrtc-review.googlesource.com/c/src/+/363946.
This CL updates the TODO comments to the current form.
Bug: None
Change-Id: Id61dca5a0f4d705f4dfe74f6523dae3e357d49ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365140
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43209}
Add an environment clock timestamp to SenderReportStats and make it visible in rtc_stats_collector.cc. This make it possible to use the pc->GetConfiguration().stats_timestamp_with_environment_clock() flag to decide which timestamp to use when creating a RTCRemoteOutboundRtpStreamStats object.
This CL is the third (and possible the last) of a series of CLs that aim to replace the UTC timestamps in RTCStats objects to Environment clock timestamps. The other CLs where https://webrtc-review.googlesource.com/c/src/+/363946 and https://webrtc-review.googlesource.com/c/src/+/364782.
When Chromium and Google internal uses of RTCStats are updated to set the stats_timestamp_with_environment_clock configuration, the flag can be deleted.
Bug: chromium:369369568
Change-Id: Ic0b07d7b012505267bd6516f19a9ba90df4cafab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365001
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43206}
I missed one timestamp in https://webrtc-review.googlesource.com/c/src/+/363946, meaning that the config flag that was added do not yet work for all timestamps in RTCStats objects. The RTCRemoteOutboundRtpStreamStats still has UTC timestamps even if the config flag is set.
I will solve this by saving both an UTC (existing) and env (to be added) timestamp, and then let rtc_stats_collector choose timestamp based on the value of the config flag (just like RTCRemoteInboundRtpStreamStats is done in the 363946 commit).
Before adding the new env_ timestamp I want to make this change. I rename the existing timestamp to show what epoch it uses (NTP or UTC). This will later make it clear which timestamp is which.
So this CL will make no logical change, just renaming members.
I only need to rename the last_sender_report_timestamp_ms, but opted to rename the remote timestamp as well, to be consistent with the naming convention I add in this CL.
Bug: chromium:369369568
Change-Id: Icfe7cf274995b39799e1478a1bb8cdf5134f0b16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364782
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43194}
I have implemented that adds multiple codec settings to RtpConfig and
passes them down to the lower layers from WebRtcVideoSendChannel.
Bug: webrtc:362277533
Change-Id: I088d6583f7dcbd4de5deb1e9e08c80a6dc10494f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364440
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43166}
Compiling webrtc with `-Werror=unused-parameters` is failling duo to
those parameters.
Also, it shouldn't harm us to put those in comment for code readability as
well.
Bug: webrtc:370878648
Change-Id: I0ab2eafd26e46312e4595f302b92006c9e23d5d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364340
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43157}
Add media config for using environment monotonic timestamps (i.e. not UTC) in RTCStats constructor, and implemented the usage of the flag.
Bug: chromium:369369568
Change-Id: Ia93d048742c28af201164fe7b2152b791bb6d0b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363946
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43156}
When AdaptFrameResolution() applies the requested resolution as a
restriction (max width and max height) it does so on the "input" size
rather than on the "output" size. While this results in the correct
output size anyway, it also produces cropping which results in the image
looking zoomed in (see https://crbug.com/webrtc/369865055 for repro).
To fix this issue the restrict logic is moved and applied on the
"output" instead. The logic is updated to take alignment into account
since the resulting size is the final output.
Bug: webrtc:369865055
Change-Id: I2d5476929432c45173a57c0f4964ab9a38518189
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364163
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43138}
A number of unit tests assume that payload types will be assigned
without generating an offer. These are flushed out by running tests
with the --force_fieldtrials=WebRTC-PayloadTypesInTransport argument.
Bug: webrtc:360058654
Change-Id: I17cd5bfa275904a9630068190b1cd246e9ce8741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362500
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43127}
Level asymmetry is implicitly enabled for HEVC. When comparing two
codec params to see if they match, we only compare profile & tier,
similar as H.264.
Bug: chromium:41480904
Change-Id: I9e9debdf1b34f33986da9344b9fee14071b1ed60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363205
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43069}
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}
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}
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}
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}
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}
