These fixes are automatically created by various analysis tools, but have been manually triggered to be applied.
* the 'empty' method should be used to check for emptiness instead of 'size' (3 times)
* using decl 'Return' is unused (4 times)
* using decl '_' is unused (3 times)
* using decl 'DoAll' is unused (2 times)
* using decl 'SetArgPointee' is unused
* using decl 'Dlrr' is unused
* using decl 'IsEmpty' is unused
* redundant get() call on smart pointer
* using decl 'Invoke' is unused (2 times)
* using decl 'SizeIs' is unused (3 times)
* using decl 'make_tuple' is unused
* using decl 'NiceMock' is unused
* using decl 'SaveArg' is unused (2 times)
* using decl 'AtLeast' is unused
* using decl 'ElementsAre' is unused
* using decl 'Gt' is unused
Bug: None
Change-Id: I97658fb0e94620b8319d7c3da29b15e27ec23188
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151133
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29056}
There are a few reasons for making this test only:
* The code is only used by tests and utilities.
* The pure interface has only a single implementation so an interface isn't really needed.
(a followup change could remove it altogether)
* The implementation always incorporates locking regardless of how the class gets used.
See e.g. previous use in the Packet class.
* The implementation is a layer on top of RtpUtility::RtpHeaderParser which is
sufficient for most production cases.
Change-Id: Ide6d50567cf8ae5127a2eb04cceeb10cf317ec36
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150658
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29010}
Previously the kDontRetransmit value was used to indicate packets that
should not be retransmitted but were put in the RtpPacketHistory anyway
as a temporary storage while waiting for a callback from PacedSender.
Since PacedSender now always owns the delayed packets directly, we can
remove all usage of StorageTye in RtpPacketHistory, and only put
packets there after pacing if RtpPacketToSend::allow_retransmission()
returns true.
Bug: webrtc:10633
Change-Id: I003b76ba43bd87658cc2a39e908fd28ebcd403f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150521
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28974}
This CL removes the old non-paced code path and instead uses a helper
class to just immediately pass the packet through the same code path as
when an actual pacer is used.
Bug: webrtc:10633
Change-Id: Id9a3ee4719829ad07710f5468e5452aa4bc8570b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150530
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28963}
The methods are no longer in use, this CL cleans away references and
updates any tests using them.
Bug: webrtc:10633
Change-Id: I2db301e0a021a2f85a8b9a74e409303baba407da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150520
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28956}
This flag has been default-off since Jul 24th (m77 branch) and apart
from a bug fixed on Aug 5th, there have been no reports of issues, so
let's remove it and start cleaning away the old code path.
Most of the usage within RtpSender/PacingController and their
respective unit tests are removed with this CL, but there will be
several more to follow.
Bug: webrtc:10633
Change-Id: I1986ccf093434ac8fbd8d6db82a0bb44f50b514e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149838
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28930}
The name media_send_ssrc makes less sense when used mostly for the
RtcpReceiver functionality.
The old member is still there and used as a fallback. That will be
cleaned away after downstream code is fixed.
Bug: webrtc:10774
Change-Id: I4ec18db76910f31dfe76bc9b137ffe89220d3fa8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149836
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28923}
This is a race that can happen if a nack arrives before media is
disabled, but the packet is not processed until after the disabling
is complete.
Bug: webrtc:10633, b/138636698
Change-Id: Ic90462b815163ab58c324e5cdb95c8d199c0b772
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147277
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28718}
That method will be retired, but some new tests managed to sneak in
usage again.
Bug: webrtc:10774
Change-Id: I354b4f5193625c8ddc75d54a252360810c3f60c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146983
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28697}
These RTP header extensions are used for Unified Plan SDP / BUNDLE and
replace SSRC signaling.
Previously, the RTPSender would attach these header extensions to every
packet when configured. Now, the header extensions will be attached to
every packet until the an RTCP RR is received on that SSRC which
indicates the receiver knows what MID/RID the SSRC is associated with.
This should reduce overhead by 2-4 bytes per packet when the MID header
extension is used and by 4-8 bytes when both header extensions are used.
Bug: webrtc:10078
Change-Id: I5fa3ce28a75224adf11d2792bf4ff8dc76e46d99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146480
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28685}
This interface is intended to only handle packet-sending parts of the
paced sender.
See https://webrtc-review.googlesource.com/c/src/+/145212 for context
Bug: webrtc:10809
Change-Id: I93f0b40e1865665c2d436db67021350a0ed0687b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145216
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28662}
If the SSRC of an RTP module is changed at runtime, we may get conflicts
with packets already there. Eg:
* Put seq# 123 in the history for SSRC 1.
* Change the SSRC to 2.
* Send a NACK for seq# 123 from SSRC 2.
Currently, we will respond with the packet belonging to SSRC 1 (and not
if the NACK specifies SSRC 1, to boot).
We can gen similar issues if the sequence number is changed, where
half frame are left in the buffer.
In these cases, the stream is likely being reset so we should just
clear the packet history too.
Bug: webrtc:10794
Change-Id: I28147c2532cf1c78840d4808c4366d4a647541f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145729
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28658}
This CL fixes two issues related to the TransmissionOffset header
extension and the new (not yet active) pacer mode.
Previously capture time (if unset) would be populated when put into the
packet history before entering the pacer. Since the pacer now owns the
packets, this does not occur until packet is actually sent, if at all.
Capture has really nothing to do with the packet history, this should
be set by the RtpSender pre-pacing instead.
Furthermore, for retransmissions the old path would take the capture
time from the original packet, build the RTX-wrapped retransmission and
set the toffset extension of the RTX packet using that captured capture
time. Since RTX packets are now fully built before the pacer, this does
not work, and we need to transfer the capture time from the original to
the RTX packet instead.
Bug: webrtc:10633
Change-Id: I031e8b6cc4ab20fb094dbd46720829b78951e7f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146218
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28657}
This CL removes the field trial left in place as a kill-switch in case
there were any regressions related to selecting payload padding based
on the likelihood of being useful instead of matching size.
It also removes the functionality that was only enabled with the
kill-switch active.
The feature has been default-on since June 23rd 2019:
https://webrtc.googlesource.com/src.git/+/214f54365ec210db76218a35ead66c9ce23e068e
Since we have not observed any issues, let's clean this code up.
Bug: webrtc:8975
Change-Id: I7f49fe354227b3f6566a250332e56b6d70fe2f09
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145821
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28616}
This CL fixes two things related to the (not yet active) new
PacedSender code path:
1. Make sure BWE header extensions are properly populated for all
padding packets.
2. When generating padding, don't hold the RtpSender critsect when
accessing the RtpPacketHistory as this may lead to a lock order
inversion.
Bug: webrtc:10633
Change-Id: I8650fbf5dafddbeae61837d2137338163e1c48ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145723
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28613}
This reverts commit 11820502b8.
Reason for revert: The culprit was https://webrtc-review.googlesource.com/c/src/+/133169.
Original change's description:
> Revert "Make new pacer padding more like old one"
>
> This reverts commit bb7727211c.
>
> Reason for revert: Speculative revert (some perf test are failing)
>
> Original change's description:
> > Make new pacer padding more like old one
> >
> > The (currently unused) new pacer code path was implemented with what
> > was intended as a more careful padding strategy.
> > Unfortunately this doesn't work as well as expected due to the fact
> > that the padding budget cannot build up underuse.
> >
> > I made another CL that could fix that, but I think it adds complexity
> > for dubious gains. It also will make it more difficult to find any
> > potential regression when switching to the new path, should one occur.
> > See https://webrtc-review.googlesource.com/c/src/+/144563
> >
> > Therefore, this CL makes the new code path choose RTX payload in the
> > same way as is currently done.
> >
> > Bug: webrtc:10633
> > Change-Id: If2115d4fa7463add959faa77c63101286c27e0f5
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145202
> > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#28537}
>
> TBR=sprang@webrtc.org,stefan@webrtc.org
>
> Change-Id: I99b72858414e0a245da596d94694449da88fd626
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:10633
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145324
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28550}
TBR=mbonadei@webrtc.org,sprang@webrtc.org,stefan@webrtc.org
Change-Id: I1fff79d75dc888921c6fbfc7f3980395a67e1c1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10633
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145403
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28565}
This reverts commit 66147e892d.
Reason for revert: The culprit was https://webrtc-review.googlesource.com/c/src/+/133169.
Original change's description:
> Revert "Optimize PacketRouter/RTPSender interactions."
>
> This reverts commit 6f129b3b76.
>
> Reason for revert: Speculative revert (some perf test are failing)
>
> Original change's description:
> > Optimize PacketRouter/RTPSender interactions.
> >
> > The legacy code-path uses a hashmap as cache in order to speed up
> > finding the right rtp module to send on. The new path should use that
> > as well.
> > In addition, there are checks that verify if an RTP module can send
> > padding, in some cases payload based. These result in a number of
> > calls to methods in RTPSender requiring its lock to be taken. This CL
> > introduces a combined SupportsPadding() check method which performs
> > all those checks in one go.
> >
> > Bug: None
> > Change-Id: I2d18d0d6e7d8cfe92c81d08cef248a4daa7dcd4b
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144780
> > Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#28535}
>
> TBR=asapersson@webrtc.org,sprang@webrtc.org,srte@webrtc.org
>
> Change-Id: I8499dc0fd6e6d0b9fa7a0886c8754655e5589780
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: None
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145326
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28552}
TBR=mbonadei@webrtc.org,asapersson@webrtc.org,sprang@webrtc.org,srte@webrtc.org
Change-Id: I3bff3ecb2b776e30f77c1884f6faa72b21788017
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145401
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28563}
This reverts commit 6f129b3b76.
Reason for revert: Speculative revert (some perf test are failing)
Original change's description:
> Optimize PacketRouter/RTPSender interactions.
>
> The legacy code-path uses a hashmap as cache in order to speed up
> finding the right rtp module to send on. The new path should use that
> as well.
> In addition, there are checks that verify if an RTP module can send
> padding, in some cases payload based. These result in a number of
> calls to methods in RTPSender requiring its lock to be taken. This CL
> introduces a combined SupportsPadding() check method which performs
> all those checks in one go.
>
> Bug: None
> Change-Id: I2d18d0d6e7d8cfe92c81d08cef248a4daa7dcd4b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144780
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28535}
TBR=asapersson@webrtc.org,sprang@webrtc.org,srte@webrtc.org
Change-Id: I8499dc0fd6e6d0b9fa7a0886c8754655e5589780
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145326
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28552}
This reverts commit bb7727211c.
Reason for revert: Speculative revert (some perf test are failing)
Original change's description:
> Make new pacer padding more like old one
>
> The (currently unused) new pacer code path was implemented with what
> was intended as a more careful padding strategy.
> Unfortunately this doesn't work as well as expected due to the fact
> that the padding budget cannot build up underuse.
>
> I made another CL that could fix that, but I think it adds complexity
> for dubious gains. It also will make it more difficult to find any
> potential regression when switching to the new path, should one occur.
> See https://webrtc-review.googlesource.com/c/src/+/144563
>
> Therefore, this CL makes the new code path choose RTX payload in the
> same way as is currently done.
>
> Bug: webrtc:10633
> Change-Id: If2115d4fa7463add959faa77c63101286c27e0f5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145202
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28537}
TBR=sprang@webrtc.org,stefan@webrtc.org
Change-Id: I99b72858414e0a245da596d94694449da88fd626
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10633
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145324
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28550}
The (currently unused) new pacer code path was implemented with what
was intended as a more careful padding strategy.
Unfortunately this doesn't work as well as expected due to the fact
that the padding budget cannot build up underuse.
I made another CL that could fix that, but I think it adds complexity
for dubious gains. It also will make it more difficult to find any
potential regression when switching to the new path, should one occur.
See https://webrtc-review.googlesource.com/c/src/+/144563
Therefore, this CL makes the new code path choose RTX payload in the
same way as is currently done.
Bug: webrtc:10633
Change-Id: If2115d4fa7463add959faa77c63101286c27e0f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145202
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28537}
The legacy code-path uses a hashmap as cache in order to speed up
finding the right rtp module to send on. The new path should use that
as well.
In addition, there are checks that verify if an RTP module can send
padding, in some cases payload based. These result in a number of
calls to methods in RTPSender requiring its lock to be taken. This CL
introduces a combined SupportsPadding() check method which performs
all those checks in one go.
Bug: None
Change-Id: I2d18d0d6e7d8cfe92c81d08cef248a4daa7dcd4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144780
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28535}
This CL makes the new code path for paced sending functionally complete.
By default, the field trial WebRTC-Pacer-ReferencePackets is Enabled,
meaning that there is no behavior change unless the field trial is
forced to Disabled. This is done in tests, and can be done on the
command line for manual testing.
Bug: webrtc:10633
Change-Id: I0d66c94ef83b5847dee437a785018f09ba3f828d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144050
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28497}
Patch set 1 is identical to original CL. Next one adds fix for
backwards compatibilit.
Original cl: https://webrtc-review.googlesource.com/c/src/+/144037
Bug: webrtc:10774
Change-Id: Ib72e3723c7a07e9ee83f97560a85367becd868a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144601
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28485}
Unlike TimeToSendPadding(), the new GeneratePadding() method will
generate RTP packets and put them in the pacer queue, which will be
responsible for actually sending them.
A slight difference from previous logic is that we do not use a lower
bound of 50bytes for getting payload packets, instead we always try and
then abort if the next padding packet is larger than the current
available budget.
Since we're not sending the packets immediately, we don't need to worry
about twcc sequence numbering or updating the stats, that will be
handled by the general SendPacket() codepath. We can also omit the
PacingInfo struct and the return value of bytes sent, as that will
be handled when taking the packets out of the queue.
Bug: webrtc:10633
Change-Id: I066c292805a0bf76c59f68e66c21ea23fdb56c03
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143794
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28403}
This CL allows for FEC protection of packets with VideoTimingExtension by
zero-ing out data, which is changed after FEC protection is generated (i.e
in the pacer or by the SFU).
Actual FEC protection of these packets would be enabled later, when all
modern receivers have this change.
Bug: webrtc:10750
Change-Id: If4785392204d68cb8527629727b5c062f9fb6600
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143760
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28396}
RtpPacketSender interface will be removed when downstream projects have
been updated.
Bug: webrtc:10633
Change-Id: Ie127b9814f39bd213d00ded0f7b98380f2f01084
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143175
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28350}
This CL also improves test coverage and fixes an issue where the
(until now) unused code path for useful padding did not respect the
lower bound packet sizes.
Bug: webrtc:8975
Change-Id: I065745ca7ac9f7098d796c6a015cd96f052ee94f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142801
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28343}
This method will be called when PacedSender is using the new code path
that directly owns the packets to be sent.
It can be seen as combining a few features of the old code path:
* It checks if this is the correct RTP module and then sends, without
the need for PacketRouter to poll multiple methods for SSRC etc first.
* It partly corresponds to TimeToSendPacket(), but RTX encapsulation
now happens pre-pacer and FEC does not need to have a packet history,
so most of that method is not used.
* It implements most of PrepareAndSendPacket(), such as updating header
extensions, reporting stats and of course forwards to Transport. It
now also handles the history a bit differently, since media packets
will only be stored for potential retransmission post-pacer.
Bug: webrtc:10633
Change-Id: Ie97952eeef6e56e462e115d67f7c7929f36c1817
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142165
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28298}
This is a standardized metric. Spec:
https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-totalpacketsenddelay
It is meant to replace the legacy googBucketDelay. The average
packet delay over any interval can be calculated as the delta
totalPacketSendDelay divided by the delta packetsSent between two
calls to getStats().
Bug: webrtc:10506
Change-Id: I3d6c6d66e5a06937d0ea8d182a82cd255084ad19
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137044
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27979}
This CL introduces three-value enum, in order to be able to distinguish
between send success, send failure, and invalid states such as missing
packet or invalid ssrc.
The behavior is unchanged in this CL, a follow-up will change the pacer
to not consume media budget on invalid states.
Bug: webrtc:8052,webrtc:8975
Change-Id: I1c9e2226f995356daa538d3d3cf44945f35e0133
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135165
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27923}
The main purpose right now of this CL is to avoid the situation
where multiple retransmissions are queued for sending (normally after
network glitch with increased pacer queue length), and some of those
fail sending because the can't be retrieved from the packet history
due to too short time since last sent.
Bug: webrtc:8975, webrtc:10607
Change-Id: I9f6369d83f0b8208e5f57b2dc2fd3f2db7c6fea1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135164
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27884}
With this change, both the normal RTP and the transport-wide sequence
numbers are propagated with with AddPacket() call via a new
RtpPacketSendInfo struct, replacing the previous set of parameters.
The intent with this is that SendTimeHistory can hold a mapping from
transport-wide to rtp sequence numbers, and then via callbacks let the
RTP modules know when packets have been received by the remote end.
Bug: webrtc:8975
Change-Id: I6a24fc6282cbb041393752d39593c2867b242192
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133021
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27708}
Semi-automatically created with:
git grep -l " testing::" | xargs sed -i "s/ testing::/ ::testing::/g"
git grep -l "(testing::" | xargs sed -i "s/(testing::/(::testing::/g"
git cl format
After this, two .cc files failed to compile and I have fixed them
manually.
Bug: webrtc:10523
Change-Id: I4741d3bcedc831b6c5fdc04485678617eb4ce031
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132018
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27526}
This is not used in practice as there's functionality on
other levels that serves the same purpose.
Bug: None
Change-Id: I0488dc42459b07607363eba0f2b06f4c50f7cda4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125520
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27061}
The idea is to let the RtpRtcp and RTPSender classes be responsible for
media-agnostic RTP transport, and move out the media-specific processing,
such as packetization and media-specific headers.
Bug: webrtc:7135
Change-Id: Ib0ce45bf06713b3eb6c06acd91c5168856874e4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/123187
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26954}
Replaces use of field trials in RtpSender and RtpVideoSender with injectable WebRtcKeyValueConfig.
Implementation still defaults to field trials.
BUG: webrtc:10335
Change-Id: I5fc6d327ee5d011ccc41385734b38344df172627
Reviewed-on: https://webrtc-review.googlesource.com/c/123447
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26795}
The discardability flag denotes whether the frame may be dropped by
the decoder with no effect on the decodability of subsequent frames.
Bug: webrtc:10214
Change-Id: I3654951d8863b50effe9670b8d1d7eb051240039
Reviewed-on: https://webrtc-review.googlesource.com/c/122241
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26763}
This reverts commit 4f36b7a478.
Reason for revert: Failing tests fixed.
Original change's description:
> Revert "Delete test/constants.h"
>
> This reverts commit 389b1672a3.
>
> Reason for revert: Causes failure (and empty result list) in CallPerfTest.PadsToMinTransmitBitrate
>
> Original change's description:
> > Delete test/constants.h
> >
> > It's not possible to use constants.h for all RTP extensions
> > after the number of extensions exceeds 14, which is the maximum
> > number of one-byte RTP extensions. This is because some extensions
> > would have to be assigned a number greater than 14, even if the
> > test only involves 14 extensions or less.
> >
> > For uniformity's sake, this CL also edits some files to use an
> > enum as the files involved in this CL, rather than free-floating
> > const-ints.
> >
> > Bug: webrtc:10288
> > Change-Id: Ib5e58ad72c4d3756f4c4f6521f140ec59617f3f5
> > Reviewed-on: https://webrtc-review.googlesource.com/c/123048
> > Commit-Queue: Elad Alon <eladalon@webrtc.org>
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#26728}
>
> TBR=danilchap@webrtc.org,kwiberg@webrtc.org,eladalon@webrtc.org,sprang@webrtc.org
>
> Bug: webrtc:10288, chromium:933127
> Change-Id: If1de0bd8992137c52bf0b877b3cb0a2bafc809d4
> Reviewed-on: https://webrtc-review.googlesource.com/c/123381
> Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
> Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26744}
TBR=danilchap@webrtc.org,oprypin@webrtc.org,kwiberg@webrtc.org,eladalon@webrtc.org,sprang@webrtc.org
Change-Id: I65e391325d3a6df6db3c0739185e2002e70fb954
Bug: webrtc:10288, chromium:933127
Reviewed-on: https://webrtc-review.googlesource.com/c/123384
Reviewed-by: Elad Alon <eladalon@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26750}
This reverts commit 389b1672a3.
Reason for revert: Causes failure (and empty result list) in CallPerfTest.PadsToMinTransmitBitrate
Original change's description:
> Delete test/constants.h
>
> It's not possible to use constants.h for all RTP extensions
> after the number of extensions exceeds 14, which is the maximum
> number of one-byte RTP extensions. This is because some extensions
> would have to be assigned a number greater than 14, even if the
> test only involves 14 extensions or less.
>
> For uniformity's sake, this CL also edits some files to use an
> enum as the files involved in this CL, rather than free-floating
> const-ints.
>
> Bug: webrtc:10288
> Change-Id: Ib5e58ad72c4d3756f4c4f6521f140ec59617f3f5
> Reviewed-on: https://webrtc-review.googlesource.com/c/123048
> Commit-Queue: Elad Alon <eladalon@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26728}
TBR=danilchap@webrtc.org,kwiberg@webrtc.org,eladalon@webrtc.org,sprang@webrtc.org
No-Presubmit: True
Bug: webrtc:10288, chromium:933127
Change-Id: If1de0bd8992137c52bf0b877b3cb0a2bafc809d4
Reviewed-on: https://webrtc-review.googlesource.com/c/123381
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26744}
It's not possible to use constants.h for all RTP extensions
after the number of extensions exceeds 14, which is the maximum
number of one-byte RTP extensions. This is because some extensions
would have to be assigned a number greater than 14, even if the
test only involves 14 extensions or less.
For uniformity's sake, this CL also edits some files to use an
enum as the files involved in this CL, rather than free-floating
const-ints.
Bug: webrtc:10288
Change-Id: Ib5e58ad72c4d3756f4c4f6521f140ec59617f3f5
Reviewed-on: https://webrtc-review.googlesource.com/c/123048
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26728}
