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}
This ensures that adding features by SDP munging gets a review
by people who understand how this works in the community.
Bug: none
Change-Id: I36feb0e3c7896d4f7bec81078109d7914c349a0d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291339
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39229}
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}
Breaking this dependency is required for using FakePortAllocator in chromium tests to make the windows component build work.
Bug: chromium:1408420
Change-Id: I4215b92c1d1430156107605e5b054926b30f83f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291114
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39180}
Creating a data channel or negotiating it can make the SCTP transport
name go from nothing (empty string) to something. Inside the
RTCStatsCollector this is relevant because which transports we have
affect which certificates we should cache, so this is an instance of
having to call ClearStatsCache().
The bug is that we don't. This CL fixes the bug.
I tried to create unittests to cover this, but I was unable to
reproduce the race in a testing environment (if I did it would have
hit an RTC_DCHECK). Not ideal... but I hope we can land it anyway since
the fix is trivial and clearing the cache in response to API calls is
worst case harmless.
Bug: webrtc:14844
Change-Id: Ia7174cde040839e5555237db6de285297120b123
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291112
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39160}
Certificates being missing is a sign of a bug (e.g. webrtc:14844, to be
fixed separately) which is why we have a DCHECK. But this DCHECK does
not protect against accessing the invalid iterator if it is a release
build. This CL makes that safe.
Bug: chromium:1408392
Change-Id: I97a82786028e41c58ef8ef15002c3f959bbec7f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291109
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39159}
This is a reland of commit b8023690d9f0e150cfe698cd68b477903ac66178
Original change's description:
> Ensure RTCRtpSenders are always created with one encoding
>
> It is possible to have AddTransceiver calls with an empty array
> of encodings or AddTrack calls. In both cases, before negotiation,
> the sender's encodings array would be empty and it was not possible
> to update any value.
>
> Now, a default entry should be created in those cases, allowing to
> update the configuration before negotiation.
>
> Bug: webrtc:10567
> Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994
> Auto-Submit: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39126}
Bug: webrtc:10567
Change-Id: I558a95f7b587302b5e95f6ec26d1eb1fedf3dbed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39150}
This reverts commit fc5d627cef71f906e921476c2e6b1e01d07732fe.
Reason for revert: Breaks upstream WPT tests
Original change's description:
> Reland "Ensure RTCRtpSenders are always created with one encoding"
>
> This is a reland of commit b8023690d9f0e150cfe698cd68b477903ac66178
>
> Original change's description:
> > Ensure RTCRtpSenders are always created with one encoding
> >
> > It is possible to have AddTransceiver calls with an empty array
> > of encodings or AddTrack calls. In both cases, before negotiation,
> > the sender's encodings array would be empty and it was not possible
> > to update any value.
> >
> > Now, a default entry should be created in those cases, allowing to
> > update the configuration before negotiation.
> >
> > Bug: webrtc:10567
> > Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994
> > Auto-Submit: Florent Castelli <orphis@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Commit-Queue: Florent Castelli <orphis@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39126}
>
> Bug: webrtc:10567
> Change-Id: I2d52fa5b1d7cfdc9dce279fcf9faf1e0129c9008
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291140
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39145}
Bug: webrtc:10567
Change-Id: If9b5adb5debb7c87a15662a8d0f232405a0e8136
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291221
Auto-Submit: Evan Shrubsole <eshr@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39147}
This is a reland of commit b8023690d9f0e150cfe698cd68b477903ac66178
Original change's description:
> Ensure RTCRtpSenders are always created with one encoding
>
> It is possible to have AddTransceiver calls with an empty array
> of encodings or AddTrack calls. In both cases, before negotiation,
> the sender's encodings array would be empty and it was not possible
> to update any value.
>
> Now, a default entry should be created in those cases, allowing to
> update the configuration before negotiation.
>
> Bug: webrtc:10567
> Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994
> Auto-Submit: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39126}
Bug: webrtc:10567
Change-Id: I2d52fa5b1d7cfdc9dce279fcf9faf1e0129c9008
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291140
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39145}
This reverts commit b8023690d9f0e150cfe698cd68b477903ac66178.
Reason for revert: Breaking WPT tests in Chrome. Example build https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1263191/overview
Original change's description:
> Ensure RTCRtpSenders are always created with one encoding
>
> It is possible to have AddTransceiver calls with an empty array
> of encodings or AddTrack calls. In both cases, before negotiation,
> the sender's encodings array would be empty and it was not possible
> to update any value.
>
> Now, a default entry should be created in those cases, allowing to
> update the configuration before negotiation.
>
> Bug: webrtc:10567
> Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994
> Auto-Submit: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39126}
Bug: webrtc:10567
Change-Id: Ib8931b38182251baac616540788a02a5fafaf670
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291120
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Auto-Submit: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39132}
It is possible to have AddTransceiver calls with an empty array
of encodings or AddTrack calls. In both cases, before negotiation,
the sender's encodings array would be empty and it was not possible
to update any value.
Now, a default entry should be created in those cases, allowing to
update the configuration before negotiation.
Bug: webrtc:10567
Change-Id: I1271e2965e1a97c1e472451e0ab8867fc24f6c2b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290994
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39126}
This is done by allowing implementations of AudioDeviceModule to
implement the GetStats() method. The default implementation returns
nullopt, in which case RTCAudioPlayoutStats will not be visible in the
stats.
Bug: webrtc:14653
Change-Id: I8e4aa6f1b8fcfa47a30f633d28a4013191752e20
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290563
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Fredrik Hernqvist <fhernqvist@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39115}
With this cl, a packet is only parsed once in RtpTransport::DemuxPacket and the metadata is reused.
Extensions are still identified twice- one for demuxing based on mid. The second time in Channel::OnReceivedPacket in order to use extensions specific to that mid.
Bug: webrtc:7135, webrtc:14795
Change-Id: I50e3814af92ca4378f148876b20a54bcfac1e146
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290540
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39058}
Unsignaled SSRCs are only applicable for the receiver case (not sender).
This CL updates the receievr's GetParameters() and GetSources() methods
to lookup parameters/sources by the current SSRC (whether or not it was
signaled) instead of only looking at the signaled SSRC.
To clarify that the `ssrc_` variable inside the [Audio/Video]RtpReceiver
is the signaled ssrc (and not set if the current ssrc is unsignaled),
we rename this variable to `signaled_ssrc_`.
By the looks of it, other APIs like setting volume or packetizers also
have a dependency on the assumptions that the SSRC is signaled. We will
not address that in this CL, but this CL makes that more clear.
Bug: webrtc:14811
Change-Id: I32c93d264ab441ade23a4078639744d25b791742
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290573
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39051}
Keeping the headers to allow compatibility with current users
that expect the headers to be in that target before they are
also updated.
Bug: webrtc:9838
Change-Id: I8b1e88850958e92c043686587a37791f01860220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290569
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39031}
and clean up the stats collector a bit, using auto for unique_ptr
BUG=webrtc:14807
Change-Id: I3c699bf89275f5c06de6f47a2935a453a60116ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290572
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@{#39027}
DeliverRtpPacket use a parsed RTP packet as argument where the RTP extensions are supposed to be known.
This method is implemented in webrt::Call and temporary used by the exising method Call::DeliverRtp, but the idea is to instead avoid extra packet parsing by forwarding a RtpPacketReceived from RtpTransport::DemuxRtpPacket via WebrtcVideoChannel::OnPacketReceived and WebrtcVoiceChannel.
DeliverRtcpPacket is also implemented in Call and is directly used in PeerConnection::InitializeRtcpCallback.
Bug: webrtc:14795, webrtc:7135
Change-Id: Ib6ffe8e1229ac07fa459ee2fc9a0af8455a23bac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290401
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39015}
This is a reland of commit 81aab488781c1a736c9d85ff1532631be2989523
See diff between Patch Set 1 and latest Patch Set.
The original CL broke this WPT[1] because getStats() with the receiver
as the selector stopped working in the event of unsignalled SSRCs due
to the receiver not knowing what the SSRC was.
This fix is to query media_channel_ for the unsignalled SSRC in the
event that the receiver does not know the SSRC.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/simulcast/setParameters-active.https.html
Original change's description:
> Remove 'trackId' dependency in stats selector algorithm.
>
> In preparation for the deletion of deprecated 'track' stats, the
> stats selector algorithm needs to be rewritten not to use 'trackId'.
>
> This is achieved by finding RTP stats by their SSRC, as obtained via
> getParameters(). This unfortunately adds a block-invoke (in the sender
> case the block-invoke happens inside GetParametersInternal and in the
> receiver case the block-invoke is explicit at the calling place), but
> it can't be helped and it's just once per getStats() call and only if
> the selector argument is used.
>
> Bug: webrtc:14175
> Change-Id: If0e14cdbdc76d141e0042e43757970893bf32119
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289101
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38981}
Bug: webrtc:14175, webrtc:14811
Change-Id: I0d16724af4efeb93d50e36dbfcc798564daff5c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290600
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39010}
