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}
The helper function is updated to decide whether or not to log; in the
VP8 simulcast test we're expected to have ramped up already and want
the logging but in the VP9 test ramp up time is significant and we
don't want to log spam.
The kLongTimeoutForRampingUp time is increased from 20s to 30s because
we noticed that SVC is slower to ramp up than simulcast and we don't
want flaky bots. The value 30s is still 2-3 times longer than what was
needed locally, but we want the bots to have plenty of margins so we
update it "just in case" even if 20s may have been enough.
Bug: webrtc:14884
Change-Id: I4b3cea20b65b2601982edcaaa90af2ef949a23ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295507
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@{#39423}
Looked in to this some more and had a chat with Evan, and L1T3 being
reported in getStats() is a real sign that L1T3 is used. This CL updates
the comments of the VP9 simulcast test to reflect that this is what
we are getting, not SVC, even if layers are being dropped etc.
Bug: webrtc:14884
Change-Id: I15eac981625302480ce337879138537c0ad73664
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295540
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39421}
Resolution expectations:
- Expect that the resolution for each RID matches what is configured.
Parameters fix:
- Due to a bug in the VP9 Simulcast test, we were accidentally modifying
a copy of the encodings and SetParameters() was a NO-OP. This is now
fixed, which sadly revealed that the SVC fallback that is happening
is not reflected in `scalability_mode`.
Bug: webrtc:14884
Change-Id: I5127e7b874c59816fcf58ff354de8d77b74d4b3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295501
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@{#39416}
This adds a test that sets the required feedback mechanisms
to get NACK configured for video, connects, and then sets packet
loss to 100%.
The expected result is that the receiver sends NACK; this will cause
the test to set packet loss to 0%, so the next NACK sent should get
to the sender and cause retransmission.
This is explicating a problematic case in splitting media channel.
Bug: webrtc:13931
Change-Id: I0c23c4a89953976454d84b0211f0a7545bbb717a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293720
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39412}
in favor of the variant with (or returning) a Timestamp object.
BUG=webrtc:14813,webrtc:13756
Change-Id: I7b40f48f640a8be40a134b380a7a1b99cc99913b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294287
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39366}
This test verifies perkj's fixes in https://crbug.com/webrtc/14817.
I ran the test 6000 times locally and it didn't fail once.
Bug: webrtc:14817
Change-Id: I3f78f3ae2ca09b328cbfa12a89ad228d3de899c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294522
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39365}
verifying these are transferred to the individual m-lines.
Also verify that mixed usage both at session level as well as
media level is not allowed as described in
https://www.rfc-editor.org/rfc/rfc5285#section-6
BUG=None
Change-Id: Iade387817c9f31362d0a26c5f13a3012c72b51b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294360
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39363}
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}
This reverts commit 815522782a92e168b80edc760b2e53e4d0e4ea0d.
Reason for revert: Breaks a downstream project.
The internal investigation is still in-progress.
Original change's description:
> sdp: add rtcp-fb:* lines for common feedback
>
> which potentially allows switching to that pattern in the future.
> Video FEC mechanisms (ulpfec, flexfec-03, RED) that currently
> do not have any feedback parameters but will still be considered "common" and feedback may be sent for them.
>
> For audio this causes rtcp-feedback to be sent for G711 and G722 if negotiated.
>
> BUG=webrtc:14802
>
> Change-Id: I54852d39e176f918d4b36462526ceb40617b8fbe
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290702
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39224}
Bug: webrtc:14802
Change-Id: I4dc3c0c53ad1bc06050c0d73b088303312ac58b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293020
Owners-Override: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39296}
Call operators do not improve code clarity, and usage was moderate.
Bug: None
Change-Id: I8d86bd7d435ce88e99f4abee8ab95a336d47dc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292960
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39294}
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}
Today the default 3 encodings path for VP9 is to trigger legacy SVC,
which is tested by "SendingThreeEncodings_VP9_LegacySVC".
This CL adds another test that does not rely on the default
`scalability_mode` and instead explicitly asks for simulcast (3 x L1T3).
When VP9 simulcast is supported (https://crbug.com/webrtc/14884), this
API pattern will allow the app to ask for standard behavior while the
default path still exists for backwards-compatibility.
Because we don't support VP9 simulcast yet, this test still triggers
legacy fallback which is wrong so this test mostly serves to document
current behavior, but see Patch Set 1 for side-by-side comparison of
what we want to EXPECT and what we currently EXPECT.
In the meantime, this CL helps exercise code paths that are possible
to trigger as of M111. The TODOs will be addressed as part of
https://crbug.com/webrtc/14884.
Bug: webrtc:14884
Change-Id: Id901eea8f399223afd5a1731a3323e5134686134
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292720
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39281}
When asking for 3 encodings of VP9, which the spec says is simulcast,
you don't get simulcast but instead you get one RTP stream sending SVC.
This results in a single "outbound-rtp" but GetParameters() still says
3 encodings are used. We know we get SVC because the scalabilityMode
from getStats() says "L3T3_KEY".
In a future CL we will add simulcast VP9 support when
`scalability_mode` is specified in the API but we'll need to continue
to support the legacy SVC code paths until that has been deprecated
and removed (https://crbug.com/webrtc/14889).
Bug: webrtc:14884
Change-Id: Ibeca44b7a0b93097ad9525e45ebbca3b7663c686
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292581
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39278}
Explicitly configure VP8 and verify the codec and scalability mode makes
sense. In preparation for doing the same with VP9 when VP9 simulcast is
supported.
Bug: webrtc:14885, webrtc:14884
Change-Id: If0c89e9b5de4fc63a59e17412fe4f0317fd61229
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292580
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39272}
Previous tests only asserted that O/A succeeded and that the number of
encodings was as expected. This test goes further and also asserts that
bytesSent eventually becomes non-zero (after an initial ramp-up time).
Let's get testing straight before we add VP9 simulcast support.
Bug: webrtc:14885, webrtc:14884
Change-Id: Idccce66698a077264fa0df2c448c8474d2439aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291960
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39271}
addressing feedback from
https://github.com/w3c/webrtc-extensions/issues/130
and aligning the behavior with setCodecPreferences.
BUG=chromium:1051821
Change-Id: If0c29e1e16781b6898814e2f888ad08a079fc609
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286780
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39264}
In current state, the SDP parser in webrtc is not backward compatible with clients that might still be using RTP data channels.
Obviously, this isn't there is no such usecase in webrtc since the code is deleted, but in Meta we still use it and would like
to be able to negotiate between clients that offer RTP data channels.
Instead of erroring the parsing procedure, we can parse it as unsupported media in the client that no longer supports RTP data channels.
Replaced the existing test that expects parsing failures with a test that validates that the content was parsed as unsupported media.
Bug: webrtc:14872
Change-Id: I4c105cf55e33b8c19b2849e16148b8175053c40c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291190
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39252}
as described in https://w3c.github.io/webrtc-extensions/#modifications-to-existing-procedures-0
"For each RTP header extension "e" listed in
[[HeaderExtensionsToOffer]] where direction is not "stopped", an
"a=extmap" line, as specified in [RFC5285], section 5
This avoids including them in case they are stopped on one
transceiver but not the other. Also, this allows extensions to
be removed from a subsequent offer.
See also
https://github.com/w3c/webrtc-extensions/issues/140
BUG=chromium:1051821
Change-Id: I4d7462f939ce4cd5d8c2331bc038200fe18f70e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291703
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39242}
