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}
The field is unused and the way it's currently laid out in the code,
it maps to a state in the RtpSenderEgress class - which in turn puts
unnecessary threading restrictions on that class.
Bug: webrtc:11581
Change-Id: I41a4740c3277317f33f8e815d8c12c70b355c1db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177426
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31577}
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}
Also removing some related code that appears to be unused.
This is a part of simplifying the RtpRtcpInterface implementation.
Bug: webrtc:11581
Change-Id: I580bfdc1b821d571cb7437d7713a49ee4de2d19a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176568
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31464}
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}
The method is being used externally to create instances
of the deprecated internal implementation.
Instead, I'm moving how we instantiate the internal implementation into
the implementation itself and move towards keeping the interface
separate from a single implementation.
Change-Id: I743aa86dc4c812b545699c546c253c104719260e
Bug: webrtc:11581
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176404
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31420}
This ended up with needing to fork the current implementation
in order to not break downstream projects that were inheriting
from it. While those get updated, we'll move on with the forked
class.
Bug: webrtc:11581,b/8278269
Change-Id: I05b596cbda71aa5b72894c31a7119d17d4761883
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175500
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31334}
ModuleRtpRtcpImpl::Process seems to be called as many
times as 200 times a second (kRtpRtcpMaxIdleTimeProcessMs == 5).
This CL changes it so that LastReceivedReportBlockMs() is called
once a second instead of potentially every time Process() runs.
This should result in grabbing locks fewer times, however there
are still other call sites for the same lock.
Bug: webrtc:11581
Change-Id: I4c2fd9aa43343fdac2763250ae7f4d2545e98ec2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175350
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31298}
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 reverts commit c623495fd1.
Reason for revert: Need to look into failure in remoting_unittests in Chrome (Webrtc/ConnectionTest.SecondCaptureFailed/0). It looks like the order FrameBuffer2 calls into VCMTiming while receiving frames and updating playout delay values, needs to be synchronized better.
Original change's description:
> Remove playout delay lock.
> Now update the playout delay and related stats on the worker thread.
>
> This was previously reviewed here:
> https://webrtc-review.googlesource.com/c/src/+/172929/
>
> With the exception of reducing unnecessarily broad
> lock scope in one function in rtp_rtcp_impl.cc
> and added comments in rtp_streams_synchronizer.h
>
> Bug: webrtc:11489
> Change-Id: I77807b5da2accfe774255d9409542d358f288993
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174200
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31193}
TBR=tommi@webrtc.org,sprang@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11489
Change-Id: I9149025d2fc10686314e6d4e89d1b92125650c36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174757
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31197}
Now update the playout delay and related stats on the worker thread.
This was previously reviewed here:
https://webrtc-review.googlesource.com/c/src/+/172929/
With the exception of reducing unnecessarily broad
lock scope in one function in rtp_rtcp_impl.cc
and added comments in rtp_streams_synchronizer.h
Bug: webrtc:11489
Change-Id: I77807b5da2accfe774255d9409542d358f288993
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174200
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31193}
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}
This allows trading off some potential media quality for CPU usage.
Bug: webrtc:8975
Change-Id: I447a03f596e9e711ba5d7038fe71f27bd80bf795
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172085
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30936}
This is a reland of 4f68f5398d
Original change's description:
> Remove PlayoutDelayOracle and make RtpSenderVideo guarantee delivery
>
> The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
> header extension was successfully propagated to the receiving side. Once
> it was determined that the receiver had received a frame with the new
> delay tag, it's no longer necessary to propagate.
>
> The issue with this implementation is that it is based on max
> extended sequence number reported via RTCP, which makes it often slow
> to react, could theoretically fail to produce desired outcome (max
> received > X does not guarantee X was fully received and decoded), and
> added a lot of code complexity.
>
> The guarantee of delivery can in fact be accomplished more reliably and
> with less code by making sure to tag each frame until an undiscardable
> frame is sent.
>
> This allows containing the logic fully within RTPSenderVideo.
>
> Bug: webrtc:11340
> Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
> 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@{#30473}
TBR=stefan@webrtc.org
Bug: webrtc:11340
Change-Id: I2fdd0004121b13b96497b21e052359e31d0c477a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168305
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30479}
This reverts commit 4f68f5398d.
Reason for revert: Breaks downstream project
Original change's description:
> Remove PlayoutDelayOracle and make RtpSenderVideo guarantee delivery
>
> The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
> header extension was successfully propagated to the receiving side. Once
> it was determined that the receiver had received a frame with the new
> delay tag, it's no longer necessary to propagate.
>
> The issue with this implementation is that it is based on max
> extended sequence number reported via RTCP, which makes it often slow
> to react, could theoretically fail to produce desired outcome (max
> received > X does not guarantee X was fully received and decoded), and
> added a lot of code complexity.
>
> The guarantee of delivery can in fact be accomplished more reliably and
> with less code by making sure to tag each frame until an undiscardable
> frame is sent.
>
> This allows containing the logic fully within RTPSenderVideo.
>
> Bug: webrtc:11340
> Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
> 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@{#30473}
TBR=sprang@webrtc.org,stefan@webrtc.org,srte@webrtc.org
Change-Id: Ide922e680ae36bb69b95e58002482cf5ed57e254
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11340
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168304
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30475}
The PlayoutDelayOracle was responsible for making sure the PlayoutDelay
header extension was successfully propagated to the receiving side. Once
it was determined that the receiver had received a frame with the new
delay tag, it's no longer necessary to propagate.
The issue with this implementation is that it is based on max
extended sequence number reported via RTCP, which makes it often slow
to react, could theoretically fail to produce desired outcome (max
received > X does not guarantee X was fully received and decoded), and
added a lot of code complexity.
The guarantee of delivery can in fact be accomplished more reliably and
with less code by making sure to tag each frame until an undiscardable
frame is sent.
This allows containing the logic fully within RTPSenderVideo.
Bug: webrtc:11340
Change-Id: I2d1d2b6b67f4f07b8b33336f8fcfcde724243eef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168221
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@{#30473}
Some clients will not count audio packets into the bandwidth estimate
despite negotiating e.g. abs-send-time for that SSRC.
If padding is sent on such an RTP module, we might get stuck in a low
resolution.
This CL works around that by preferring to send padding on video SSRCs.
Bug: webrtc:11196
Change-Id: I1ff503a31a85bc32315006a4f15f8b08e5d4e883
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161941
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30066}
This is a reland of 96f3de0945
Downstream test is fixed, this is a pure reland.
TBR=danilchap@webrtc.org,srte@webrtc.org
Original change's description:
> Use just a lookup map of RTP modules in PacketRouter
>
> Since SSRCs of RTP modules are now set at construction time, we can
> use just a simple unordered map from SSRC to module in packet router.
>
> Bug: webrtc:11036
> Change-Id: I0b3527f17c9ee2df9253c778e5b9e3651a70b355
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155965
> 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@{#29510}
Bug: webrtc:11036
Change-Id: I0731339dfd0781cc7f2f7ca78ac903539f25ff9c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157304
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29514}
This reverts commit 96f3de0945.
Reason for revert: Downstream test is borked.
Original change's description:
> Use just a lookup map of RTP modules in PacketRouter
>
> Since SSRCs of RTP modules are now set at construction time, we can
> use just a simple unordered map from SSRC to module in packet router.
>
> Bug: webrtc:11036
> Change-Id: I0b3527f17c9ee2df9253c778e5b9e3651a70b355
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155965
> 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@{#29510}
TBR=danilchap@webrtc.org,sprang@webrtc.org,srte@webrtc.org
Change-Id: I31330fd68ab809ff3951573791e9a79b81599958
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11036
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157281
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29511}
Since SSRCs of RTP modules are now set at construction time, we can
use just a simple unordered map from SSRC to module in packet router.
Bug: webrtc:11036
Change-Id: I0b3527f17c9ee2df9253c778e5b9e3651a70b355
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155965
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@{#29510}
This CL sets the RTP stats callback on construction, by adding a field
next to the other observers in RtpRtcp::Configuration.
We can then remove the RegisterCallback() methods and the unused
GetCallback() method.
Bug: webrtc:11036
Change-Id: I4eb86ea63b4b2ebeff60b311ddf3bed06b279ce4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157169
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29504}
This is a reland of 17608dc459
Downstream test now fixed.
As a precaution, also avoid DCHECKS for non-zero SSRC.
First patch set is reland, second makes checks more lenient.
Original change's description:
> RtpRtcp modules and below: Make media, RTX and FEC SSRCs const
>
> Downstream usage of SetSsrc() / SetRtxSsrc() should now be gone. Let's
> remove them, make the members const, and remove now unnecessary locking.
>
> Bug: webrtc:10774
> Change-Id: Ie4c1b3935508cf329c5553030f740c565d32e04b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155660
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29475}
Bug: webrtc:10774
Change-Id: I540b49a31a31e98d87f02ae04083d5206e71c1b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157100
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29491}
This was just checked in all places were it was used, moving the check
into RtpRtcp reduces the boiler plate required at the call sites.
Also changing to always register and unregister extensions by URI to
synchronize the code in AudioSendStream with the code in RtpVideoSender.
This prepares for reducing the scope of ChannelSend.
Bug: webrtc:9883
Change-Id: Ia64d79f20eb98f46cbbbe8318770e4fcf9caa1ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155620
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29490}
This is a reland of 17608dc459
Downstream fixed, relanding.
Original change's description:
> RtpRtcp modules and below: Make media, RTX and FEC SSRCs const
>
> Downstream usage of SetSsrc() / SetRtxSsrc() should now be gone. Let's
> remove them, make the members const, and remove now unnecessary locking.
>
> Bug: webrtc:10774
> Change-Id: Ie4c1b3935508cf329c5553030f740c565d32e04b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155660
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29475}
TBR=nisse@webrtc.org
Bug: webrtc:10774
Change-Id: I759bed3ff1909857696c6d1b13df595a5e552f03
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157049
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29486}
Downstream usage of SetSsrc() / SetRtxSsrc() should now be gone. Let's
remove them, make the members const, and remove now unnecessary locking.
Bug: webrtc:10774
Change-Id: Ie4c1b3935508cf329c5553030f740c565d32e04b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155660
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29475}
This method sends arbitrary number rtp::RcpPackets into one or more IP packets.
It is implemented both in RtcpTranceiver and in RtpRtcp.
Change-Id: I00424ee2f1730ff98626f768846f4ac1ad864933
BUG: webrtc:10742
Change-Id: I00424ee2f1730ff98626f768846f4ac1ad864933
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156240
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29430}
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}
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}
Cname callback is used only on receive side, and statistics (soon)
only on the send side.
Bug: webrtc:10679
Change-Id: I122e9cafaea93cd0ba75dc955a652d9d4bddc379
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147867
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28767}
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 adds the RemoteEstimate rtcp packet and wires it up to GoogCC where
it's used to improve congestion controller behavior.
The functionality is negotiated using SDP.
It's added with a field trial that allow disabling the functionality in
case there's any issues.
Bug: webrtc:10742
Change-Id: I1ea8e4216a27cd2b00505c99b42d1e38726256c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146602
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28654}
