This reverts commit 2d3b294e49027607c80766c50f1c3c8d7d4b38b9.
Reason for revert: The CL was believed to make AV1 always available
but it turned out that the import bots still failed due to not
having AV1, so it is better to use the built in factories than
to make custom test-only ones.
Original change's description:
> Ensure AV1 is always available in PeerConnectionSimulcastTests.
>
> Unblocks a WebRTC import where a bot without AV1 support would
> otherwise have been running and failing during setting codec
> preferences.
>
> # Non-chromium bots passed, no need to wait for chromium to land.
> # Want to unblock importer.
> NOTRY=True
>
> Bug: webrtc:15005
> Change-Id: I93c6a0ce5591a057c3a0ee49f6dbaef3676c0e1d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298021
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#39592}
Bug: webrtc:15005
Change-Id: I8f0850852edb0d0234000b2d956e2648a9adf904
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298120
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39596}
This reverts commit c8ab6c449c84f17fabf8da58456d396bdb5da762.
Reason for revert: new test fails to run upstream
Original change's description:
> Exercise AV1 simulcast paths in tests.
>
> This is something we get "for free" with the
> "WebRTC-AllowDisablingLegacyScalability" field trial that has been
> wired up to support VP9 simulcast.
>
> This test works and passes, however the ramp-up time is pretty bad.
> - VP9 simulcast takes approximately 4 seconds to ramp up.
> - VP9 SVC takes approximately 16 seconds to ramp up.
> - AV1 simulcast takes approximately 22 seconds to ramp up.
>
> A TODO is added (webrtc:15006) and the test is given extra timeout,
> a full minute to get bytes flowing on all layers.
>
> Despite ramp-up being bad, it's important to test that AV1 simulcast
> is in fact working to avoid regressions due to obsolete assumptions
> about which codec do or do not support simulcast. AV1 simulcast is an
> opt-in feature so there is no harm in the API not being perfect yet.
>
> Bug: webrtc:15005, webrtc:15006
> Change-Id: If0158d172647f0462bd6db802406249d93e01871
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297982
> 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@{#39586}
Bug: webrtc:15005, webrtc:15006
Change-Id: I7da6df8bb51219e7d0acfd3b62b4ec08e25bfdc7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298049
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39595}
Unblocks a WebRTC import where a bot without AV1 support would
otherwise have been running and failing during setting codec
preferences.
# Non-chromium bots passed, no need to wait for chromium to land.
# Want to unblock importer.
NOTRY=True
Bug: webrtc:15005
Change-Id: I93c6a0ce5591a057c3a0ee49f6dbaef3676c0e1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39592}
This is something we get "for free" with the
"WebRTC-AllowDisablingLegacyScalability" field trial that has been
wired up to support VP9 simulcast.
This test works and passes, however the ramp-up time is pretty bad.
- VP9 simulcast takes approximately 4 seconds to ramp up.
- VP9 SVC takes approximately 16 seconds to ramp up.
- AV1 simulcast takes approximately 22 seconds to ramp up.
A TODO is added (webrtc:15006) and the test is given extra timeout,
a full minute to get bytes flowing on all layers.
Despite ramp-up being bad, it's important to test that AV1 simulcast
is in fact working to avoid regressions due to obsolete assumptions
about which codec do or do not support simulcast. AV1 simulcast is an
opt-in feature so there is no harm in the API not being perfect yet.
Bug: webrtc:15005, webrtc:15006
Change-Id: If0158d172647f0462bd6db802406249d93e01871
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297982
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@{#39586}
Following https://webrtc-review.googlesource.com/c/src/+/297100
it seems that sctp_data_channels_ gets modified while we're iterating
through it. This temporary fix creates a copy of the array and iterates
through the copy instead of sctp_data_channels_. A follow-up CL (or CLs)
will provide more clarity, testing and regression guards.
Bug: webrtc:15004
Change-Id: I0cb5dfb6829d36b51328875c8c9cfa392ff393a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297981
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39584}
Since AddTrack now has an implicit init_encodings value, it will also
have a StableState saved when associating a transceiver.
That state may not have a saved mid and mline_index, and so on a
rollback, it could blindly reset the mid and mline_index of an
associated transceiver.
This is wrong, the mid and mline_index of associated transceivers
should only be updated when the StableState objects actually
have one saved.
Bug: chromium:1424238
Change-Id: I8e80a04cd072d90200ca7643de892c0ef29b1f1a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297920
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39577}
All tests do this already except for RTCStatsCollectorTest.
Bug: none
Change-Id: I318f45a2c79b3d07ca6c92902ebb4f0622ec3200
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297862
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39576}
This removes the behavior of not requesting datachannel if the first
datachannel is closed before the offer is created.
Bug: chromium:1423562
Change-Id: I90eab0f908507e65d9ee3dff51842ee6d61a8aa9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297860
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39570}
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}
This includes:
* SignalDataChannelTransportWritable_s
* SignalDataChannelTransportReceivedData_s
* SignalDataChannelTransportChannelClosing_s
* Removing sigslot::has_slots<> inheritance from SctpDataChannel
Instead, we use the existing sctp_data_channels_ vector of channels
known to the DCC to deliver the callbacks.
Bug: webrtc:11943, webrtc:11547
Change-Id: I7935d7505856eedf04981b8ba665ef8419166c1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39557}
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}
This removes one sigslot and also simplifies the teardown procedure
of a data channel when the channel is closed by the transport.
In this case we no longer need an additional async teardown task that
releases the last remaining reference to the channel.
Bug: webrtc:11943, webrtc:11547
Change-Id: I1c170349a6cbb3cb3c5a47d284e3a3d416c92b11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296981
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39551}
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}
The test was assuming that after all thee layers have bytesSent > 0 we
would have fully ramped up to the expected resolutions. But there are
reasons why this may not be true, such as if adaptation kicks in.
This CL attempts to de-flake by using kLongTimeoutForRampUp when
checking the resolutions as well.
// Just increasing a timeout...
NOTRY=True
Bug: webrtc:14884
Change-Id: I5ef57ec3e3cc99552c9ae32a6fdf07889ff06ee1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296883
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39534}
Instead, just use the posted task to release the reference to a
pending data channel object.
Bug: none
Change-Id: I34f0bfd604cab88587a892eaa218856c890fc907
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296767
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39527}
If a data channel object was closed (via calling Close()) right after
construction and before attaching to a transport, it would never
transition to the `kClosed` state. This addresses that corner case,
which caused a DCHECK to trigger but might also cause a situation
whereby more than one DC instance existed for a given sctp sid.
Bug: chromium:1421534
Change-Id: Id757c0528f929f2e2daa5343236d7f62e309f6cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296341
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39513}
following the updates from
https://github.com/w3c/webrtc-extensions/pull/142
BUG=chromium:1051821
Change-Id: I2d561bad1ddffb412bdd7e66cf62a3cb5fc73791
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296480
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Markus Handell <handellm@google.com>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39500}
to RTCInboundRtpStreamStats and RTCOutboundRtpStreamStats respectively
which follows the camel-casing convention used elsewhere.
The old name is kept around as an alias for a limited amount of time
to allow upgrading dependencies.
BUG=webrtc:14973
Change-Id: Ibf4e65933fd6cc2e7e89955042f6f8fb0f6c7853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39497}
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}
This test (and binary) will be used to verify that the field trial
for enabling split-MediaChannel works in both "off" and "on" modes,
so that it can be run as a field trial. It is intended to be deleted
once the conversion to split-MediaChannel is complete.
Bug: webrtc:13931
Change-Id: If62d19be9b2f205067b86dc859946279442fdd58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296322
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39493}
following spec updates from
https://github.com/w3c/webrtc-extensions/pull/142
BUG=chromium:1051821
Change-Id: I1fd991a5024d38ac59ebe510ea1a48fd6f42d23b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296321
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39491}
making RTCOutboundRtpStreamStats inherit from RTCSentRtpStreamStats
as defined in
https://www.w3.org/TR/webrtc-stats/#outboundrtpstats-dict*
This removes the duplicated definitions of packetsSent and bytesSent.
BUG=webrtc:14948
Change-Id: I184998b65d59dbd0d1288733d55d8a884e6de970
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295660
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@{#39481}
Previously we did this on the worker thread, but are transitioning
network traffic away from thread hopping and this is one step.
Bug: webrtc:11547
Change-Id: Ia6fd6540f31a5383c70bb2bf46695e0ee526c4f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39478}
Attempting to SVC can fail for two reasons:
1. If codec preferences does not contain a codec that supports SVC,
setParameters() rejects, leaving scalabilityMode undefined.
2. If codec preferences does contain a codec that support SVC,
setParameters() accepts the scalabilityMode, but if a codec is
configured in response to negotiation that does not support SVC,
fallback happens.
In the 1) path, undefined scalabilityMode results in VP8 L1T1.
In the 2) path, SVC fallback results in scalabilityMode being set to
L1T2, resulting in VP8 L1T2.
Whether we fail late or early resulting in different configurations may
not be obvious so its good to test these.
Bug: webrtc:14884
Change-Id: Ic5502b90c1628310a7a78ade2ad9fa0d81d91502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295872
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39474}
This test does not change any parameters.
Bug: webrtc:14884
Change-Id: Ic315c1b10e729f1f179570350028eef604d714b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296041
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39473}
RTCStatsCollector internally keeps track of open data channels but
does not need (or want) to interact directly with those channels,
hence uintptr_t was used instead of pointers to the channel objects.
This changes that to use void* to avoid having to do the cast.
This is a follow-up action item to
https://webrtc-review.googlesource.com/c/src/+/295781
This CL also changes the container type:
std::set -> webrtc::flat_set
Bug: webrtc:12689
Change-Id: I13d3f4a41ef83dab38411193187e872b9d6d3cff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295871
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39468}
This moves SctpDataChannel construction a step closer to RAII by moving the error checks out of SctpDataChannel::Init() and not construct an SctpDataChannel instance unless error checks have been done first in SctpDataChannel::Create.
Ideally the Init() method shouldn't be needed but there is test code that constructs an SctpDataChannel instance without running the Init()
steps but they're required by the SctpDataChannel::Create() path.
Bug: none
Change-Id: I8498693063c28355f901d27c4fe7bd45b7d4be26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295860
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39467}
Due to recent confusion about when to use L1T1, L1T2 or L1T3 and
different paths triggering different configurations for these, let's
make the simulcast tests more explicit about which scalability mode we
are getting for each setup.
Bug: webrtc:14884
Change-Id: I6ac20768a1fa9db08fdef032d07b4794a3e66d81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295873
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39465}
DataChannelController used WeakPtr to clear outstanding references
upon destruction - except for the case of SctpDataChannel where we
had a pointer+flag for the same purpose. This change updates
SctpDataChannel and FakeDataChannelController to use a consistent
approach.
Bug: none
Change-Id: I0248471c241365a2c0de76afbb37302115650194
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295820
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39464}
It turns out that there were several sigslot instances across data
channel, pc and stats classes that in practice only served as means
to update two counters in RTCStatsCollector. There's already a
notification path that's suitable.
This also fixes a case where the PC instance sat in the middle
of notifications from datachannels to the datachannel controller.
Bug: webrtc:11943
Change-Id: Ic60b76021584019f82085f6651230fe2fe82d465
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295781
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39456}
which is only used in tests.
BUG=None
Change-Id: If215ad84e6756af2ee90777a27376400f8f4d8e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294721
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39450}
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 is a follow-up to
https://webrtc-review.googlesource.com/c/src/+/295724.
Test is still failing sometimes. Add additional constraint.
Bug: webrtc:14952
Change-Id: Iddc2733459733c0f3e40aea303752f055cb865c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295665
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39441}
The test may sometimes fail because the round trip time has not been
estimated. Wait until the report contains the round trip time before
proceeding, or fail after 10 s.
Fixed: webrtc:14952
Change-Id: I9127b8ee6afa7454d061de96f002422d7d4af428
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295724
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39438}
I don't quite understand why this is flaking but I beleive it is a
test-only problem, see description in https://crbug.com/webrtc/14947
how I have trouble understanding if "frames received" is measured
correctly.
Bug: webrtc:14947, webrtc:14909
Change-Id: I667306b7cd33687645ad6a9294364330075434ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295700
Reviewed-by: Markus Handell <handellm@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39433}
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}
The test only exists #if defined(WEBRTC_USE_H264) because H264 is not
available in all testing environments (e.g. Android bots fail without
these guards).
Bug: webrtc:14884
Change-Id: Ic1ff6b16f49f6666df042304ee98d826778da122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295508
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39424}
