This avoid overflow when handling large input sizes, e.g.2016x1512, or 2592x1944.
Bug: webrtc:15030
Change-Id: I97d5fa163ce0fac4c47f21826656819e652efafe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300240
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39774}
which describe the existing behavior that necessitated the revert
b396e2b159b060791954495d68278a55e8f72092
Also change the fake media engine audio clockrate to 8000 instead
of 0 and the fake media engine video payload type to something but
0 as this value seems to be treated specially by the video engine
and is a payload type reserved for PCMU.
BUG=chromium:1051821
Change-Id: Ib0a345d59baba50a565f01685d240e41584367e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299000
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39699}
This CL is partly a test to see if there's an impact on binary size:
- Not a big difference for binaries (decrease): -776b to -4Kb
- For libraries (libwebrtc.a) it actually increases the size: +40Kb
Secondarily this CL is basically to introduce this pattern to the
code base. In terms of LOC, this makes things slightly more compact.
From:
class Foo {
public:
Foo() {
checker_.Detach();
}
private:
SequenceChecker checker_;
};
To:
class Foo {
public:
Foo() = default;
private:
SequenceChecker checker_{SequenceChecker::kDetached};
};
Bug: none
Change-Id: I59fc34ccea10847e13455a349851ce9a0af458e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299020
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39664}
This makes "WebRTC-AllowDisablingLegacyScalability" enabled-by-default,
meaning any app can opt-in to spec-compliant simulcast when
scalabilityMode is specified.
The opt-in criteria is also made more restricitve: you now have to
specify both scalabilityMode and scaleResolutionDownBy to get simulcast,
otherwise you continue to get legacy "single stream" path.
The reason for this is not to cause any surprises in use cases like
[{scalabilityMode:"L1T1", active:true}, {active:false}, {active:false}]
In cases like this where scaleResolutionDownBy is not specified, it
defaults to 4:2:1 if simulcast is used but the legacy path caps it to
one stream, meaning full resolution. By restricing simulcast only to
cases that set scaleResolutionDownBy, we remove the risk of an app
getting a different resolution than expected due to opt-in.
Bug: webrtc:14884, webrtc:15005
Change-Id: I5efb87af60afaeb1e3ff76698d887aaa1f9d63a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298922
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39660}
Attempting to ship "WebRTC-AllowDisablingLegacyScalability" revealed a
DCHECK that happens when negotiating 3 VP9 streams prior to the
setParameters() call:
1. By default, `scalability_mode` is missing, so those 3 streams
defaulted to legacy SVC, meaning only a single stream is used.
2. Then, setParameters() was called to make
`encodings[0].scalability_mode = "L2T2_KEY"` and
`encodings[1-2].active = false`. The inactive streams were just
dummies and never expected to exist.
Without simulcast support this is OK, because both 1) and 2) are
interpreted to have a single stream. But with simulcast support, 1) is
interpreted as single stream and 2) as three streams (1 active, 2
inactive). This should be roughly the same setup, but our code treats
them differently.
The DCHECK crash was a mismatch in number of streams in one of the
layers.
The fix is to re-create the streams when the number of streams change
for this reason. The new test revealed other issues and fixes too:
- Support for multiple spatial layers (e.g. "L2T2_KEY") when multiple
encodings exist but only one encoding is active.
- Allow inactive layers not to have a scalability mode set.
A laundry list (https://crbug.com/webrtc/15028) has been created to
update known places doing "if streams == 1" that need to do "if
active streams == 1" instead.
Credit:
The RecreateWebRtcStream() fix is based on eshr@'s POC from
https://webrtc-review.googlesource.com/c/src/+/298565.
Bug: webrtc:15016
Change-Id: I909a3f83a4ef53562894549ade0a870b208cec7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298443
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#39651}
This avoids a couple of layers of error code conversion, reduces
dependency on cricket error types and allows us to preserve error
information from dcsctp. Along the way remove SendDataResult.
Bug: none
Change-Id: I1ad18a8f0b2fb181745b19c49f36f270708720c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298305
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39619}
This reverts commit 75990b9a8f98ea2d597a31472fb778ec4d55f698.
Reason for revert: Breaks downstream, a use case of having three VP9
encodings, scalability mode only specified on the first layer
(L2T2_KEY) and the other two layers not having a scalability mode but
also being active=false appears to trigger a DCHECK in
call/rtp_video_sender.cc:501. More investigation needed
Original change's description:
> Ship ability to opt-in to VP9/AV1 simulcast.
>
> With this unflagging, an app can opt-in to simulcast when using multiple
> encodings by specifying RTCRtpEncodingParameters.scalabilityMode. This
> ensures backwards-compat with apps relying on 3 encodings to mean SVC
> who traditionally have not specified scalabilityMode.
>
> It fixes the spec/API bug of asking for simulcast and not getting
> simulcast. The field trial exists only as a kill-switch with a TODO to
> remove it.
>
> This ships initial support, however note that the VP9/AV1 simulcast uses
> SimulcastRateAllocator (just like VP8/H264 simulcast). This rate
> allocator uses more kbps than SvcRateAllocator. This should be revisited
> to avoid significant higher bitrates, for example when comparing VP9
> simulcast to VP9 SVC.
>
> Shipping the ability for apps to opt-in makes it easier to exercise
> these new code paths and allows initial feedback from developers, but
> due to the high bitrate (= same bitrate as VP8/H264 simulcast today)
> many apps may find that VP9 SVC is still more beneficial for BW reasons.
>
> Bug: webrtc:14884, webrtc:15005
> Change-Id: I748aae1adb47acc8a6b79b5852cff6aa47a46f5d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298046
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Evan Shrubsole <eshr@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39601}
Bug: webrtc:14884, webrtc:15005
Change-Id: Ic8f77e6a2971f493d6cd8c23faecd435058a8847
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298440
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39605}
With this unflagging, an app can opt-in to simulcast when using multiple
encodings by specifying RTCRtpEncodingParameters.scalabilityMode. This
ensures backwards-compat with apps relying on 3 encodings to mean SVC
who traditionally have not specified scalabilityMode.
It fixes the spec/API bug of asking for simulcast and not getting
simulcast. The field trial exists only as a kill-switch with a TODO to
remove it.
This ships initial support, however note that the VP9/AV1 simulcast uses
SimulcastRateAllocator (just like VP8/H264 simulcast). This rate
allocator uses more kbps than SvcRateAllocator. This should be revisited
to avoid significant higher bitrates, for example when comparing VP9
simulcast to VP9 SVC.
Shipping the ability for apps to opt-in makes it easier to exercise
these new code paths and allows initial feedback from developers, but
due to the high bitrate (= same bitrate as VP8/H264 simulcast today)
many apps may find that VP9 SVC is still more beneficial for BW reasons.
Bug: webrtc:14884, webrtc:15005
Change-Id: I748aae1adb47acc8a6b79b5852cff6aa47a46f5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298046
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39601}
Because the adapter has a passthrough mode, it can already handle both
singlecast and simulcast cases, meaning the proxy is no longer providing
value. Let's delete.
Bug: webrtc:15001
Change-Id: I480eaba599448e9b82b8cf7f829dc35ad6ce0434
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297740
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39579}
This struct only contains two member variables now and there isn't
much value added by having it.
Low-Coverage-Reason: No change in coverage, CL modifies uncovered RTC_LOG lines.
Bug: none
Change-Id: I924d450f4c8f8e49b1cfeabaebee9fd5235a90cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297360
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39563}
The goal of the VP9 simulcast project is that when `scalability_mode`
is set, multiple encodings are always interpreted as simulcast, even
if VP9 or AV1 is used. This CL makes this so, but only if the flag
"WebRTC-AllowDisablingLegacyScalability" is "/Enabled/". This allows us
to make "SendingThreeEncodings_VP9_Simulcast" EXPECT VP9 simulcast.
When we are ready to ship we will remove the need to use the field
trial, but before we ship this we'll want to revisit if
SvcRateAllocator can be updated to support simulcast. (Today if we use
SvcRateAllocator when VP9 simulcast is used, all encodings except the
first one get bitrate=0, causing the test to fail because media is not
flowing on all layers.) For now, a TODO is added.
Bug: webrtc:14884
Change-Id: Ie20ae748b0c0405162f3a1b015ab94956ef83dae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297340
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39552}
Encoders that do not support simulcast in the first place does not
expect to have to handle simulcast configurations, and as such may not
necessarily return
WEBRTC_VIDEO_CODEC_ERR_SIMULCAST_PARAMETERS_NOT_SUPPORTED from
InitEncode().
This CL updates EncoderSimulcastProxy to respect this info to avoid
silent errors when LibvpxVp9Encoder (which does not support simulcast)
is attempted to be used in simulcast.
Alternatively we can try to get rid of EncoderSimulcastProxy altogether
since SimulcastEncoderAdapter already has a passthrough mode. A TODO is
added to get rid of the proxy.
Bug: webrtc:14884
Change-Id: Id3703f1768b0aebf617b7d9b935914cd5f1b0f52
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296885
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39541}
Instead there are direct member variables for the various relevant
states, some weren't needed, some can be const but the `id` member
in particular needs special handling and can't be const.
For dealing with the stream id, we now have SctpSid. A class that does range validation, checks thread safety, handles the special `-1` case (for what's essentially an unsigned 16 bit int). Using a special type
for this also has the effect that range checking happens more
consistently (although I'm not modifying the structs in api/).
With upcoming steps of avoiding thread hops, the ID may need to
migrate to the network thread, which the thread checks will help with.
Along the way, update SctpSidAllocator to use flat_set instead of std::set and moving some of the sctp data channel code to the cc file
to help with more accurately tracking code coverage.
Bug: webrtc:11547
Change-Id: Iea6e7647ab8f93052044c5afbcc449115206b4e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296444
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39539}
This reverts commit 18c869bc36b342cd4a79947067e52a93a04a7808.
Reason for revert: Added a field trial that allows landing the code without affecting performance in prod.
This CL also incorporates subsequent CLs that also had to be reverted.
Original change's description:
> Revert "Use two MediaChannels for 2 directions."
>
> This reverts commit 8981a6fac3d665beac4a58b9453e6c39988a024f.
>
> Reason for revert: Quality regression detected.
>
> Original change's description:
> > Use two MediaChannels for 2 directions.
> >
> > This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
> >
> > The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
> >
> > Bug: webrtc:13931
> > Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39340}
>
> No-Try: true
> Bug: webrtc:13931
> Change-Id: I791997ad9eff75c3ac9cd2e4bbacf5bc6c3a3a79
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295663
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39445}
Bug: webrtc:13931
Change-Id: I1318910a685188e2b846c9040e1efc04c2c894ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296080
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39494}
Under the combined network/worker thread project, tasks
are unnecessarily posted to the same thread. Avoid this
by posting only if invoked on a diffferent sequence.
TESTED=presubmit + local Meet calls.
Bug: webrtc:137439
Change-Id: Ic5dd99e5fbb843ad4c54d4466138135ae81596cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295867
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39471}
This reverts commit 8981a6fac3d665beac4a58b9453e6c39988a024f.
Reason for revert: Quality regression detected.
Original change's description:
> Use two MediaChannels for 2 directions.
>
> This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
>
> The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
>
> Bug: webrtc:13931
> Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39340}
No-Try: true
Bug: webrtc:13931
Change-Id: I791997ad9eff75c3ac9cd2e4bbacf5bc6c3a3a79
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295663
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39445}
This reverts commit a087f6f1c842f1d70ad207b44c48321ab60d2d95.
Reason for revert: Needed to roll back other CL
Original change's description:
> Add plumbing for video NACK to be coupled between channels.
>
> Bug: webrtc:13931, webrtc:14920
> Change-Id: I451869e295e099a1d08c0c80e481decd53149f1b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294382
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39373}
Bug: webrtc:13931, webrtc:14920
Change-Id: I19e176e75630313da470542e7ff1e89b6d717fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295664
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39432}
Currently, send stats update `last_stats_log_ms_` causing receive stats
to never be logged.
This behavior was introduced in https://webrtc-review.googlesource.com/c/src/+/288750
Bug: b/270519075
Change-Id: Ie781082cfb212c1c903cbada5e393d2e7aa6150f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294743
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39381}
following the removal of ISAC from the code base.
BUG=webrtc:14450
Change-Id: I6faab5391bf0ef563c5dcce0bd5d8a653a87d9c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294523
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39378}
Also update the tests that depend on FakeMediaEngine.
Bug: webrtc:13931
Change-Id: Ia608c4ce68a29e45174b68ba0103af31e9a7d3d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294280
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39345}
This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
Bug: webrtc:13931
Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39340}
As part of go/unblocking-vp9-simulcast (Step 1), EncodedImage is being
upgraded to be able to differentiate between what is a simulcast index
and what is a spatial index.
In order not to break existing code assuming that "if codec != VP9,
SpatialIndex() is the simulcast index", SimulcastIndex() has fallback
logic to return the value of spatial_index_ in the event that
SetSimulcastIndex() has not been called. This allows migrating external
code from (Set)SpatialIndex() to (Set)SimulcastIndex(). During this
intermediate time, codec gates are still necessary in some places of
the code, see TODOs added.
In a follow-up CL, after having fixed dependencies, we'll be able to
remove the fallback logic and rely on SimulcastIndex() and
SpatialIndex() actually being the advertised index and "if codec..."
hacks will be a thing of the past!
Bug: webrtc:14884
Change-Id: I70095c091d0ce2336640451150888a3c3841df80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293343
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39318}
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}
This is used when an unsignaled stream with a known payload type is received and later a RTX packet is received.
Bug: webrtc:14817
Change-Id: I29f43281cec17553e1ec2483e21b8847714d2931
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291328
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39243}
These configurations are no longer used by call. Header extensions are identified once when demuxing packets in WebrtcVideoEngine::OnPacketReceived and WebrtcVoiceEngine::OnPacketReceived.
Change-Id: I49de9005f0aa9ab32f2c5d3abcdd8bd12343022d
Bug: webrtc:7135
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291480
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39236}
This reverts commit 897ea04db5db2e591e28bd884191be58d9bcdc63.
Reason for revert: Speculative revert as it could be the reason why perf tests started failing: https://ci.chromium.org/p/webrtc/g/perf/console?limit=200
Original change's description:
> Delete PacketReceiver::DeliverPacket from all implementations
>
> And fix tests that still depend on extensions to be known by the receiver.
>
> Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3
>
> Bug: webrtc:7135,webrtc:14795
> Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290996
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39184}
Bug: webrtc:7135,webrtc:14795,b/266658815
Change-Id: I9d03f4952938d176ffee110a707acadc1846457c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291400
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39189}
And fix tests that still depend on extensions to be known by the receiver.
Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3
Bug: webrtc:7135,webrtc:14795
Change-Id: I62227829af81af07769189e547f1cdb8ed4d06b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290996
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39184}
This ensure transport feedback is sent for RTX packets that are received before media payload packets.
Bug: webrtc:14795, webrtc:14817
Change-Id: I6a2579b87c8863e003decb2b2559ef51a852cadb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291119
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39174}
also refactor the code to have FillSendCodecStats/FillReceiveCodecStats
methods for similarity with the video engine code.
BUG=webrtc:14808
Change-Id: Ib0687f36a4b4a71c849e0b4918e50592d7772ff8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290891
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39172}
