These should be the last of the testis from rtp_sender_unittest.cc that
should be moved and refactored to just test RtpSenderEgress.
Bug: webrtc:11340
Change-Id: Id09d7bbade608dd7194dcd8843d4f2887842a372
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220140
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34118}
While the savings were positive in Media Servers, there was a regression
in some scenarios (crbug.com/webrtc/12718) so let's revert it.
This partially reverts commit 553fd3220b7b1a476af6759b27b3a274677d21e3.
Bug: webrtc:12718
Change-Id: If9252fd996ffc5efd7609eb4c7c0e7f001893676
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220103
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34117}
These tests were likely made back when PacketRouter was iterating over
the RTP modules to find the correct to send on. Now that this is just
a DCHECK, it's already implicitly covered by other tests that actually
test the respective packet type functionality. Let's thus just remove
these old tests.
Bug: webrtc:11340
Change-Id: I244ca7e365378f4e48a601464b5df0e1d07732be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219621
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34116}
for consistency with usrsctp_dumppacket which prefixes its output with a newline.
This makes the packets easier to grep and process with text2pcap.
BUG=webrtc:12614
Change-Id: I67bc2e0026250b21b030daf967ebc697640f2d7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220102
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Cr-Commit-Position: refs/heads/master@{#34114}
This CL refactors RtpSenderTest.SendPacketHandlesRetransmissionHistory,
moves some testing to rtp_ender_egress_unittest and adds test coverage
for a few cases.
Bug: webrtc:11340
Change-Id: Ic225d2af43c3926f69fe3ea45f41b18c29b8b4fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219796
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34111}
This check was important when header bytes were copied from source
packet to destination, but current implementation (new line 123) slices
the source packet, making capacity of the destination packet irrelevant.
Bug: b/189015462
Change-Id: I7e649cb7dfc6ba0fbe989c943e6515ab0da05fef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34110}
Instead, cap the final bandwidth estimate by the last received cap. This allows fast rampup after a REMB cap is lifted.
Bug: webrtc:12306
Change-Id: Ia99707134ce145275460524b3e46923876fdf62f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219696
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34109}
Today, there is no actual limit on how large a SACK chunk can be. And
having limits is good to be able to stay within the MTU.
This commit adds a limit to the number of reported duplicate TSNs as
well as the number of reported gap-ack-blocks in a SACK chunk. These
limits are never expected to be reached in a real-life situation.
Bug: webrtc:12614
Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34108}
ffmpeg is going to be hiding the implementation of AVPacket, so we can't
allocate them on the stack anymore. av_init_packet is marked deprecated
on TOT ffmpeg, so remove its use everywhere in favor of av_packet_alloc
and av_packet_free.
Bug: chromium:1211508
Change-Id: I154311071123110dd749c71dec1ec2a0452b3908
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217780
Commit-Queue: Ted Meyer <tmathmeyer@google.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34106}
This reverts commit 096ad02c02b4bc6c046282b8793ef84d041dd0d8.
Reason for revert: Including a fix for the test issue.
Original change's description:
> Revert "Fix race between enabled() and set_enabled() in VideoTrack."
>
> This reverts commit 5ffefe9d2d743c66f8a8bcbc5ad9662a3138840a.
>
> Reason for revert: Breaks Chromium Android browser tests on fyi bots.
>
> Original change's description:
> > Fix race between enabled() and set_enabled() in VideoTrack.
> >
> > Along the way I introduced VideoSourceBaseGuarded, which is equivalent
> > to VideoSourceBase except that it applies thread checks. I found that
> > it's easy to use VideoSourceBase incorrectly and in fact there appear
> > to be tests that do this.
> >
> > I made the source object const in VideoTrack, as it already was in
> > AudioTrack, and that allowed for making the GetSource() accessors
> > bypass the proxy thread hop and give the caller direct access.
> >
> > Bug: webrtc:12773, b/188139639, webrtc:12780
> > Change-Id: I022175c4239a1306ef54059c131d81411d5124fe
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219160
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#34096}
>
> TBR=mbonadei@webrtc.org,tommi@webrtc.org,landrey@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I16323d459c76eb6a87cc602a0048f6ee01c81626
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:12773
> Bug: b/188139639
> Bug: webrtc:12780
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219637
> Reviewed-by: Evan Shrubsole <eshr@google.com>
> Commit-Queue: Evan Shrubsole <eshr@google.com>
> Cr-Commit-Position: refs/heads/master@{#34101}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:12773
Bug: b/188139639
Bug: webrtc:12780
Change-Id: Ib35fe15a6c43de8f286d60aff02b19df1ab76925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219639
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34104}
This reverts commit 5ffefe9d2d743c66f8a8bcbc5ad9662a3138840a.
Reason for revert: Breaks Chromium Android browser tests on fyi bots.
Original change's description:
> Fix race between enabled() and set_enabled() in VideoTrack.
>
> Along the way I introduced VideoSourceBaseGuarded, which is equivalent
> to VideoSourceBase except that it applies thread checks. I found that
> it's easy to use VideoSourceBase incorrectly and in fact there appear
> to be tests that do this.
>
> I made the source object const in VideoTrack, as it already was in
> AudioTrack, and that allowed for making the GetSource() accessors
> bypass the proxy thread hop and give the caller direct access.
>
> Bug: webrtc:12773, b/188139639, webrtc:12780
> Change-Id: I022175c4239a1306ef54059c131d81411d5124fe
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219160
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34096}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,landrey@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I16323d459c76eb6a87cc602a0048f6ee01c81626
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:12773
Bug: b/188139639
Bug: webrtc:12780
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219637
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#34101}
This reverts commit e6ee8fab7eac915b2b6abc9b71b6d33ad086f3d1.
Reason for revert: Breaks downstream test
Original change's description:
> Deprecate microsecond timestamps in RTC event log.
>
> (Microsecond timestamps are only used in the legacy wire-format,
> and the clocks only have microsecond resolution on some platforms.)
>
> Also convert structs on the parsing side to use a Timestamp instead
> of a uint64_t to represent the log time.
>
> Bug: webrtc:11933
> Change-Id: Ide5a0217d99f13f2e243115b163f13e0525648c7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219467
> Commit-Queue: Björn Terelius <terelius@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34097}
TBR=terelius@webrtc.org,srte@webrtc.org,crodbro@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I478c9a4a1664b984891c4fcfc78f0ce9a51fe4c0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11933
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219636
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34100}
This simplifies some tests and removes dependency on RtpSenderEgress
for those tests in rtp_sender_unittest.
Bug: webrtc:11340
Change-Id: I37489875947b0ac48a1742d2e9945510ee002f99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219624
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34099}
This fixes the WebRTC roll in Chrome, which was failing because the
//third_party/nearby library was transively including Chromes //base/check
via WebRTC overrides by including
api/peer_connection_interface.h
which included api/proxy.h
which included rtc_base/event.h
which was overrided in webrtc_overrides.
This override contains an include to base/check.h.
Adding a temporary dependency on event.h fixes this for now. This can be
removed once https://crbug.com/1212611 is fixed.
Bug: None
Change-Id: Id372e0737664d4a94ade0f75ae5fcf21f3db929f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219630
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#34098}
(Microsecond timestamps are only used in the legacy wire-format,
and the clocks only have microsecond resolution on some platforms.)
Also convert structs on the parsing side to use a Timestamp instead
of a uint64_t to represent the log time.
Bug: webrtc:11933
Change-Id: Ide5a0217d99f13f2e243115b163f13e0525648c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219467
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34097}
Along the way I introduced VideoSourceBaseGuarded, which is equivalent
to VideoSourceBase except that it applies thread checks. I found that
it's easy to use VideoSourceBase incorrectly and in fact there appear
to be tests that do this.
I made the source object const in VideoTrack, as it already was in
AudioTrack, and that allowed for making the GetSource() accessors
bypass the proxy thread hop and give the caller direct access.
Bug: webrtc:12773, b/188139639, webrtc:12780
Change-Id: I022175c4239a1306ef54059c131d81411d5124fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219160
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34096}
With this CL, SimulcastEncoderAdapter no longer configures its encoder
as multi-layered if we only have a single active layer. Instead we
create a single single-layered encoder for that one and only active
layer. When using VP8 SW encoder this means that LibvpxVp8Encoder is
configured to only prepare a single video frame which avoids the cost of
scaling down to layers that we do not send. (A multi-layered
LibvpxVp8Encoder is required to scale even layers we don't encode.)
When profiling this CL I found very small but measurable gains for
representative downscale factors of 20.1 ms of 60 s profile. This is
just 0.0335% CPU so it's not much, but skipping a downscale might be
worth a lot more if we have to map/unmap buffers or do GPU round-trips
in the future (which I have not measured).
When downscaling to factors 4 and 2 due to libyuv having a
"fast-path" for these (i.e. no adaptation active), zero difference was
found for NV12. For I420 there was small regression of 16.1 ms
(0.026% CPU) for this one edge-case. It's possible to work around this,
but considering the tiny changes we're talking about, I really don't
think it's worth the additional complexity. I'll file a bug on libyuv
about scaling factors 2+2 vs 4 and leave it at that.
Bug: webrtc:12603
Change-Id: Id462140c6a829cf6b460baae868e94243f477db3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219683
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34092}
The current send queue implements SCTP_SS_FCFS as defined in
https://datatracker.ietf.org/doc/html/rfc8260#section-3.1, but that has
always been known to be a temporary solution. The end goal is to
implement a Weighted Fair Queueing Scheduler (SCTP_SS_WFQ), but that's
likely to take some time.
Meanwhile, a round robin scheduler (SCTP_SS_RR) will be used to avoid
some issues with the current scheduler, such as a single data channel
completely blocking all others if it sends a lot of messages.
In this first commit, the code has simply been renamed and is still
implementing first-come-first-served. That will be fixed in follow-up
CLS.
Bug: webrtc:12793
Change-Id: Idc03b1594551bfe1ddbe1710872814b9fdf60cc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219684
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34090}
The tests are now all gated behind a singe WEBRTC_HAVE_SCTP flag,
including the invocations, so the issue of configs that vary which
tests are included should have gone away.
This CL also clears out the remains of
DataChannelIntegrationTestWithFakeClock, which is no longer used.
Bug: webrtc:12525
Change-Id: Ie0133e3e84358e9238b8e7465200f000519b8765
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219783
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34085}
The retransmission timeout (RTO) value is updated on every measured
RTT and is a function of the RTT value and its stability. In reality,
the RTT is never constant - it fluctuates, which makes the RTO become
much larger than the RTT. But for extremely stable RTTs, which we get
in simulations, the RTO value can become the same as the RTT, and that
makes expiration timers be scheduled to the RTT value, and will race
with packets that are expected to stop the expiration timer. And that
race should be avoided in simulations.
So ensuring that the RTO value is always greater, if only be a single
millisecond, will work fine in these simulations.
Bug: webrtc:12614
Change-Id: I30cf9c97e50449849ab35de52696c618d8498128
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219680
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34084}
This allows callers to use timestamps generated from their own clocks
without worrying about converting to webrtc time.
No-Try because of lack of infra lack of capacity on macs.
No-Try: True
Bug: webrtc:11327
Change-Id: I7b1935654a2b23cf844c7b3622ed68763ced9da5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219785
Commit-Queue: Paul Hallak <phallak@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34076}
WebRTC is going to remove cricket::DtlsTransportState and switch to
webrtc::DtlsTransportState. This CL introduces a set of new methods to
allow to subscribe to DTLS transport state updates while WebRTC
internally migrates away from cricket::DtlsTransportState.
No-Try: True
Bug: webrtc:12762
Change-Id: I79cf48e2f7122cc76fde6e4fd1541382fd096d53
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218607
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34075}
This change prepares for a later change in Chromium that makes it
stop depending on headers exposed by WebRTC that require inclusion of
api/proxy.h.
No-Try because of lack of infra lack of capacity on macs.
No-Try: True
Bug: webrtc:12787
Change-Id: I628424fe49e873027595b80336be2b821c22245e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219688
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34072}
The timestamps returned by the clocks do not have an epoch. Each clock
should be able to convert a timestamp it returns to an NTP time.
The default implementation for querying for an NTP time is converting
the current timestamp.
This is favored over returning the offset between the relative and the
NTP time because there is a field trial that makes the real clock revert
to using system dependent methods for getting the NTP time.
Bug: webrtc:11327
Change-Id: Ia139b2744b407cae94420bf9112212ec577efb16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219687
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Paul Hallak <phallak@google.com>
Cr-Commit-Position: refs/heads/master@{#34071}
