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 reverts commit 980cadd02c.
Reason for revert: Problematic code now fix.
Original change's description:
> Revert "Lets PacingController call PacketRouter directly."
>
> This reverts commit 848ea9f0d3.
>
> Reason for revert: Part of changes that may cause deadlock
>
> Original change's description:
> > Lets PacingController call PacketRouter directly.
> >
> > Since locking model has been cleaned up, PacingController can now call
> > PacketRouter directly - without having to go via PacedSender or
> > TaskQueuePacedSender.
> >
> > Bug: webrtc:10809
> > Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#31342}
>
> TBR=sprang@webrtc.org,srte@webrtc.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: webrtc:10809
> Change-Id: I1d7d5217a03a51555b130ec5c2dd6a992b6e489e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178021
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31563}
TBR=sprang@webrtc.org,srte@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10809
Change-Id: I8bea1a5b1b1f618b697e4b09d83c9aac08099593
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178389
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31600}
This reverts commit 848ea9f0d3.
Reason for revert: Part of changes that may cause deadlock
Original change's description:
> Lets PacingController call PacketRouter directly.
>
> Since locking model has been cleaned up, PacingController can now call
> PacketRouter directly - without having to go via PacedSender or
> TaskQueuePacedSender.
>
> Bug: webrtc:10809
> Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31342}
TBR=sprang@webrtc.org,srte@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10809
Change-Id: I1d7d5217a03a51555b130ec5c2dd6a992b6e489e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178021
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31563}
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}
TaskQueuePacedSender::MaybeUpdateStats() is intended to be called when
packets are sent or by a sequence of "scheduled" calls. There should
only be one scheduled call in flight at a time - and that one
reschedules itself if needed when it runs.
A bug however caused the "schedules task in flight" flag to
incorrectly be set to false, leading to more and more schedules tasks
being alive - eating CPU cycles.
This CL fixes that and also makes sure the queue time properly goes
down to zero before the next idle interval check, even if there are no
more packets to send.
Bug: webrtc:10809
Change-Id: I4e13fcf95619a43dcaf0ed38bce9684a5b0d8d5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176330
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31390}
Since locking model has been cleaned up, PacingController can now call
PacketRouter directly - without having to go via PacedSender or
TaskQueuePacedSender.
Bug: webrtc:10809
Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31342}
With an optional parameter this allows the task-queue based paced
sender to mimic the old behavior and coalesce sending of packets in
order to reduce thread wakeups and provide opportunity for batching.
This is done by simply overriding the minimum time the thread should
sleep. The pacing controller will already handle the "late wakup" case
and send any packets as if it had been woken at the optimal time.
Bug: webrtc:10809
Change-Id: Iceea00693a4e87d39b0e0ee8bdabca081dff2cba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175648
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31328}
The TaskQueuePacedSender today has some inefficiencies:
* Enqueuing a packet will trigger a MaybeProcessPackets() call, but it
won't actually run immediately even if it should - instead it will
schedule a new call in at least 1ms. This incurs delays and extra
CPU overhead.
* Sometimes thread wakeups are scheduled simply in order to do
book-keeping: ProcessPackets() will be called when the media debt has
gone down to 0 even if there is no packet in the queue, in order to
check if we should send padding.
This CL fixes that by called ProcessPackets() immediately if it is
actually time to do so, and by immediately determining when padding
should be sent without having a separate call to drain media debt.
Bug: webrtc:10809
Change-Id: I4870e86e6de2ce4197463fd5b788ad4717fc7177
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172842
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31010}
This is in preparation of an upcoming CL that will propagate this
information through the TransportFeedbackAdapter.
Bug: webrtc:10932
Change-Id: Ic2a026b5ef72d6bf01e698e7634864fedc659b4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168220
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30476}
This change renames TimeController's Sleep method to AdvanceTime, unifying
the same name with the same semantic as for downstream projects.
Bug: webrtc:11154
Change-Id: Id79bcf0eafcd0b47a76407ba220479d84df5a736
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161092
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29989}
