The config flag will be removed once downstream usage is gone.
Bug: webrtc:11340
Change-Id: Iee8816660009211540d9b09bb3cba514455d709b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228431
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34757}
With this turned on, packets will be sequence number after the pacing
stage rather that during packetization.
This avoids a race where packets may be sent out of order, and paves
the way for the ability to cull packets from the pacer queue without
causing sequence number gaps.
For now, the feature is off by default. Follow-ups will enable it for
video and audio separately.
Bug: webrtc:11340, webrtc:12470
Change-Id: I6d411d8c85b9047e3e9b05ff4c2c3ed97c579aa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208584
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34661}
This is a reland of f5e261aaf6
This CL disables RTC_NO_UNIQUE_ADDRESS on MSan builds since
there have been some issues.
Original change's description:
> Introduce RTC_NO_UNIQUE_ADDRESS.
>
> This macro introduces the possibility to suggest the compiler that a
> data member doesn't need an address different from other non static
> data members.
>
> The usage of a macro is to maintain portability since at the moment
> the attribute [[no_unique_address]] is only supported by clang
> with at least -std=c++11 but it should be supported by all the
> compilers starting from C++20.
>
> Bug: webrtc:11495
> Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32246}
Bug: webrtc:11495, webrtc:12218
Change-Id: I4e6c7cc37d3daffad2407c9a2acfa897fa5b426a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189968
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32668}
This reverts commit f5e261aaf6.
Reason for revert: Breaks downstream projects.
Original change's description:
> Introduce RTC_NO_UNIQUE_ADDRESS.
>
> This macro introduces the possibility to suggest the compiler that a
> data member doesn't need an address different from other non static
> data members.
>
> The usage of a macro is to maintain portability since at the moment
> the attribute [[no_unique_address]] is only supported by clang
> with at least -std=c++11 but it should be supported by all the
> compilers starting from C++20.
>
> Bug: webrtc:11495
> Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32246}
TBR=mbonadei@webrtc.org,kwiberg@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11495
Change-Id: Ice318d1b11ca3dff09c190187a0b0a32ca945fe3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186944
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32335}
This macro introduces the possibility to suggest the compiler that a
data member doesn't need an address different from other non static
data members.
The usage of a macro is to maintain portability since at the moment
the attribute [[no_unique_address]] is only supported by clang
with at least -std=c++11 but it should be supported by all the
compilers starting from C++20.
Bug: webrtc:11495
Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32246}
This is a reland of 19df870d92
Patchset 1 is the original.
Subsequent patchset changes threadchecker that crashed with downstream
code.
Original change's description:
> Reland "Allows FEC generation after pacer step."
>
> This is a reland of 75fd127640
>
> Patchset 2 contains a fix. Old code can in factor call
> RtpRtcpImpl::FetchFec(). It should only be a noop since deferred fec
> is not supported there - we shouldn't crash.
>
> Original change's description:
> > Allows FEC generation after pacer step.
> >
> > Split out from https://webrtc-review.googlesource.com/c/src/+/173708
> > This CL enables FEC packets to be generated as media packets are sent,
> > rather than generated, i.e. media packets are inserted into the fec
> > generator after the pacing stage rather than at packetization time.
> >
> > This may have some small impact of performance. FEC packets are
> > typically only generated when a new packet with a marker bit is added,
> > which means FEC packets protecting a frame will now be sent after all
> > of the media packets, rather than (potentially) interleaved with them.
> > Therefore this feature is currently behind a flag so we can examine the
> > impact. Once we are comfortable with the behavior we'll make it default
> > and remove the old code.
> >
> > Note that this change does not include the "protect all header
> > extensions" part of the original CL - that will be a follow-up.
> >
> > Bug: webrtc:11340
> > Change-Id: I3fe139c5d53968579b75b91e2612075451ff0f5d
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177760
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#31558}
>
> Bug: webrtc:11340
> Change-Id: I2ea49ee87ee9ff409044e34a777a7dd0ae0a077f
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177984
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31613}
Bug: webrtc:11340
Change-Id: Ib741c8c284f523c959f8aca454088d9eee7b17f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178600
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31619}
This reverts commit 19df870d92.
Reason for revert: Downstream project failure
Original change's description:
> Reland "Allows FEC generation after pacer step."
>
> This is a reland of 75fd127640
>
> Patchset 2 contains a fix. Old code can in factor call
> RtpRtcpImpl::FetchFec(). It should only be a noop since deferred fec
> is not supported there - we shouldn't crash.
>
> Original change's description:
> > Allows FEC generation after pacer step.
> >
> > Split out from https://webrtc-review.googlesource.com/c/src/+/173708
> > This CL enables FEC packets to be generated as media packets are sent,
> > rather than generated, i.e. media packets are inserted into the fec
> > generator after the pacing stage rather than at packetization time.
> >
> > This may have some small impact of performance. FEC packets are
> > typically only generated when a new packet with a marker bit is added,
> > which means FEC packets protecting a frame will now be sent after all
> > of the media packets, rather than (potentially) interleaved with them.
> > Therefore this feature is currently behind a flag so we can examine the
> > impact. Once we are comfortable with the behavior we'll make it default
> > and remove the old code.
> >
> > Note that this change does not include the "protect all header
> > extensions" part of the original CL - that will be a follow-up.
> >
> > Bug: webrtc:11340
> > Change-Id: I3fe139c5d53968579b75b91e2612075451ff0f5d
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177760
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#31558}
>
> Bug: webrtc:11340
> Change-Id: I2ea49ee87ee9ff409044e34a777a7dd0ae0a077f
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177984
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31613}
TBR=sprang@webrtc.org,srte@webrtc.org
Change-Id: I3b2b25898ce88b64c2322f68ef83f9f86ac2edb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11340
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178563
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31614}
This is a reland of 75fd127640
Patchset 2 contains a fix. Old code can in factor call
RtpRtcpImpl::FetchFec(). It should only be a noop since deferred fec
is not supported there - we shouldn't crash.
Original change's description:
> Allows FEC generation after pacer step.
>
> Split out from https://webrtc-review.googlesource.com/c/src/+/173708
> This CL enables FEC packets to be generated as media packets are sent,
> rather than generated, i.e. media packets are inserted into the fec
> generator after the pacing stage rather than at packetization time.
>
> This may have some small impact of performance. FEC packets are
> typically only generated when a new packet with a marker bit is added,
> which means FEC packets protecting a frame will now be sent after all
> of the media packets, rather than (potentially) interleaved with them.
> Therefore this feature is currently behind a flag so we can examine the
> impact. Once we are comfortable with the behavior we'll make it default
> and remove the old code.
>
> Note that this change does not include the "protect all header
> extensions" part of the original CL - that will be a follow-up.
>
> Bug: webrtc:11340
> Change-Id: I3fe139c5d53968579b75b91e2612075451ff0f5d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177760
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31558}
Bug: webrtc:11340
Change-Id: I2ea49ee87ee9ff409044e34a777a7dd0ae0a077f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177984
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31613}
This is part of moving calls to GetSendRates() to the worker.
Change-Id: Ifb93096a863ddf2669237e7f44af296d0e086b20
Bug: webrtc:11581
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177661
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31582}
On the way remove need for lock for
rtp_sequence_number_map_ and timestamp_offset_.
Change-Id: I21a5cbf6208620435a1a16fff68c33c0cb84f51d
Bug: webrtc:11581
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177424
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31581}
The timer fired a Notify call that goes to an object that already
receives callbacks for every packet from RtpSenderEgress.
Further optimizations will be realized by moving ownership
of the stats to the worker thread and then be able to remove
locking in a few classes that currently are tied to those
variables and the callbacks that previously did not come
from the same thread consistently.
We could furthermore get rid of one of these callback interfaces
and just use one.
Bug: webrtc:11581
Change-Id: I56ca5893c0153a87a4cbbe87d7741c39f9e66e52
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177422
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31575}
This reverts commit 75fd127640.
Reason for revert: Breaks downstream test
Original change's description:
> Allows FEC generation after pacer step.
>
> Split out from https://webrtc-review.googlesource.com/c/src/+/173708
> This CL enables FEC packets to be generated as media packets are sent,
> rather than generated, i.e. media packets are inserted into the fec
> generator after the pacing stage rather than at packetization time.
>
> This may have some small impact of performance. FEC packets are
> typically only generated when a new packet with a marker bit is added,
> which means FEC packets protecting a frame will now be sent after all
> of the media packets, rather than (potentially) interleaved with them.
> Therefore this feature is currently behind a flag so we can examine the
> impact. Once we are comfortable with the behavior we'll make it default
> and remove the old code.
>
> Note that this change does not include the "protect all header
> extensions" part of the original CL - that will be a follow-up.
>
> Bug: webrtc:11340
> Change-Id: I3fe139c5d53968579b75b91e2612075451ff0f5d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177760
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31558}
TBR=sprang@webrtc.org,srte@webrtc.org
Change-Id: Ie714e5f68580cbd57560e086c9dc7292a052de5f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11340
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177983
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31559}
Split out from https://webrtc-review.googlesource.com/c/src/+/173708
This CL enables FEC packets to be generated as media packets are sent,
rather than generated, i.e. media packets are inserted into the fec
generator after the pacing stage rather than at packetization time.
This may have some small impact of performance. FEC packets are
typically only generated when a new packet with a marker bit is added,
which means FEC packets protecting a frame will now be sent after all
of the media packets, rather than (potentially) interleaved with them.
Therefore this feature is currently behind a flag so we can examine the
impact. Once we are comfortable with the behavior we'll make it default
and remove the old code.
Note that this change does not include the "protect all header
extensions" part of the original CL - that will be a follow-up.
Bug: webrtc:11340
Change-Id: I3fe139c5d53968579b75b91e2612075451ff0f5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177760
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31558}
The 'Module' part of the implementation must not be
called via the RtpRtcp interface, but is rather a part of
the contract with ProcessThread. That in turn is an
implementation detail for how timers are currently implemented
in the default implementation.
Along the way I'm deprecating away the factory function which
was inside the interface and tied it to one specific implementation.
Instead, I'm moving that to the implementation itself and down the
line, we don't have to go through it if we just want to create an
instance of the class.
The key change is in rtp_rtcp.h and the new rtp_rtcp_interface.h
header file (things moved from rtp_rtcp.h), the rest falls from that.
Change-Id: I294f13e947b9e3e4e649400ee94a11a81e8071ce
Bug: webrtc:11581
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176419
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31440}
When FEC generation is moved to egress, we'll need to poll bitrates from
there instead of the RtpVideoSender. In preparation, refactoring some
getter methods.
For context, see https://webrtc-review.googlesource.com/c/src/+/173708
Bug: webrtc:11340
Change-Id: Ibc27362361ee9640d9fce676fc8e1093a579344f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174202
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31214}
This interface has a couple of issues. Primarily for me, it makes it
difficult work with the paced sender as we need to either temporarily
release a lock or force a thread-handover in order to avoid a cyclic
lock order.
For video in particular, its behavior is also falky since header sizes
can vary not only form frame to frame, but from packet to packet within
a frame (e.g. TimingInfo extension is only on the last packet, if set).
On bitrate allocation, the last reported value is picked, leading to
timing issues affecting the bitrate set.
This CL removes the callback interface and instead we simply poll the
RTP module for a packet overhead. This consists of an expected overhead
based on which non-volatile header extensions are registered (so for
instance AbsoluteCaptureTime is disregarded since it's only populated
once per second). The overhead estimation is a little less accurate but
instead simpler and deterministic.
Bug: webrtc:10809
Change-Id: I2c3d3fcca6ad35704c4c1b6b9e0a39227aada1ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173704
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ali Tofigh <alito@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31185}
The post-pacing part of the RTP sender has been moved from RTPSender
into the new RtpSenderEgress class. However, that class is not directly
used and instead a subset of method calls are passed through RTPSender.
This CL prepares for removing dependencies between RTPSender and
RtpSenderEgress. All current behavior is preserved, and unit tests are
unchanged to verify this.
For more context, see patch set 2.
Change-Id: If795f2603aeb6302ac1565d9efaea514af240dc7
Bug: webrtc:11036
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158020
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29616}
Post-pacer code now contained in RtpSenderEgress class.
For now, this is a member of RTPSender. More refactoring is needed to
make clean split.
Bug: webrtc:11036
Change-Id: I95264d013de120601784f130ba81c7b234446980
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157172
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29519}
