This change achieves an Idle Wakeup savings of 200 Hz.
ModuleRtcRtcpImpl2 had Process() logic only active if TMMBR() is
enabled in RtcpSender, which it never is. Hence the Module
inheritance could be removed. The change removes all known
dependencies of the module inheritance, and any related mentions
of ProcessThread.
Fixed: webrtc:11581
Change-Id: I440942f07187fdb9ac18186dab088633969b340e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222604
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34358}
Apart from making the map smaller, a purpose of this is guaranteeing
that if a module has been deactived it will not receive new packets
from the pacer, which will be needed for deferred sequencing.
Bug: webrtc:11340
Change-Id: I171a13413c5b8d3fa569c2d56bd9a54bff7c7976
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208542
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33335}
DependencyDescriptor and vp9 wrapper understand key frame differently
when it comes to the first layer frame with spatial_id>0
This CL adds and use DD's interpretation of the key frame when deciding
if DD should be supported going forward.
Bug: webrtc:11999
Change-Id: I11a809a315e18bd856bb391576c6ea1f427e33be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202760
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33046}
This reverts commit f23e2144e86400e2d68097345d4b3dc7a4b7f8a4.
Reason for revert: Need further discussion on appropriate thread/tq requirements.
Original change's description:
> Add task queue to RtpRtcpInterface::Configuration.
>
> Let ModuleRtpRtcpImpl2 use the configured value instead of
> TaskQueueBase::Current().
>
> Intention is to allow construction of RtpRtcpImpl2 on any thread.
> If a task queue is provided (required for periodic rtt updates), the
> destruction of the object must be done on that same task queue.
>
> Also, delete ModuleRtpRtcpImpl2::Create, callers updated to use std::make_unique.
>
> Bug: None
> Change-Id: I412b7b1e1ce24722ffd23d16aa6c48a7214c9bcd
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/199968
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32949}
TBR=danilchap@webrtc.org,ilnik@webrtc.org,saza@webrtc.org,nisse@webrtc.org,srte@webrtc.org
Change-Id: I7e5007f524a39a6552973ec9744cd04c13162432
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201420
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32953}
Let ModuleRtpRtcpImpl2 use the configured value instead of
TaskQueueBase::Current().
Intention is to allow construction of RtpRtcpImpl2 on any thread.
If a task queue is provided (required for periodic rtt updates), the
destruction of the object must be done on that same task queue.
Also, delete ModuleRtpRtcpImpl2::Create, callers updated to use std::make_unique.
Bug: None
Change-Id: I412b7b1e1ce24722ffd23d16aa6c48a7214c9bcd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/199968
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32949}
Assume bitrate is evenly distributed between frames. This is wrong for
uneven frame sizes and will underestimate the overhead for simulcast.
However, it will be more correct than the current calculation,
especially for low bitrates when each frame is smaller than one packet.
This is also when overhead matters more since it is a larger fraction
of the total bitrate.
It is also unclear what will happen when using FEC.
Bug: b/166341943
Change-Id: I247b9d0fc7a8ad5daa9b577f55ec16c56efa34c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195221
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32725}
This is a reland of 19df870d924662e3b6efb86078d31a8e086b38b5
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 75fd127640bdf1729af6b4a25875e6d01f1570e0
>
> 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 19df870d924662e3b6efb86078d31a8e086b38b5.
Reason for revert: Downstream project failure
Original change's description:
> Reland "Allows FEC generation after pacer step."
>
> This is a reland of 75fd127640bdf1729af6b4a25875e6d01f1570e0
>
> 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 75fd127640bdf1729af6b4a25875e6d01f1570e0
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 75fd127640bdf1729af6b4a25875e6d01f1570e0.
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}
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}
worker_queue is used in many places and it can be confusing. This queue
is the send transport's worker queue. Rename to send_transport_queue to
reflect that.
Bug: none
Change-Id: I43c5c4cbddaee3dae1ff75aa38dc3ddee6585902
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176362
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31396}
When video frame encoding is done on an external thread (for example in
the case of hardware encoders), the WebRTC TaskQueueBase::Current() is
null; in this case use the worker queue instead to send transformed
frames.
Bug: chromium:1086373
Change-Id: I903ddc52ad6832557fc5b5f76396fe26cf5a88f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176303
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31388}
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}
RtpVideoSender now stores fec type and overhead instead of querying the
generator all the time. Setting of protection parameters and asking for
current bitrate is also now handled just by the VideoFecGenerator
instance, instead of going via RtpVideoSender.
Finally, adds method to query for RtpState in VideoFecGenerator
interface. This avoids an ugly cast that would have been even more
trouble after moving fec generation.
For context, see https://webrtc-review.googlesource.com/c/src/+/173708
Bug: webrtc:11340
Change-Id: Ia5e6cd919e71850c9cc5ed5a4f4417338d577162
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174203
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31166}
This caused at least one trial in RTPSender not to be properly parsed.
This CL also updates RtpVideoSender and RtpPayloadParams to use
WebRtcKeyValueConfig instead of the static field_trial methods, in
order to facilitate injectable behavior in the future.
Bug: webrtc:11508
Change-Id: I995939bd3e7c2f81e5050383c3e4daf933498520
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173705
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31108}
The transformer was previously moved into the config of the first stream
which resulted in incorrect behavior for simulcast. Use the transformer
in all the streams.
Pass the sender's ssrc on registring the transformed frame callback, to
associate separate transformer sinks for each sender.
Bug: chromium:1065838
Change-Id: I5c52dacb241c68268681b85f875257b24987849e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173332
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31050}
This reverts commit d926cf63b57128d9ea9a8d1054f853b4fe82e6dd.
Reason for revert: Breaks simulcast testing in Canary, to be relanded once the chrome part of the fix is landed as well.
Original change's description:
> [InsertableStreams] Fix simulcast: set frame transformer for all streams
>
> The transformer was previously moved into the config of the first stream
> which resulted in incorrect behavior for simulcast. Use the transformer
> in all the streams.
>
> Bug: chromium:1065838
> Change-Id: Iea340443da8cd4de32953bb24d3e6a07a275ae2a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173026
> Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
> Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31018}
TBR=mflodman@webrtc.org,marinaciocea@webrtc.org
Change-Id: Ib0f869ae617329eb2532b613741b6050bd3ba2a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1065838
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173181
Reviewed-by: Marina Ciocea <marinaciocea@webrtc.org>
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31033}
The transformer was previously moved into the config of the first stream
which resulted in incorrect behavior for simulcast. Use the transformer
in all the streams.
Bug: chromium:1065838
Change-Id: Iea340443da8cd4de32953bb24d3e6a07a275ae2a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173026
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31018}
--- Background ---
The webrtc::VideoSendStream::StreamStats are converted into
VideoSenderInfo objects which turn into "outbound-rtp" stats objects in
getStats() (or "ssrc" objects in legacy getStats()).
StreamStats are created for each type of substream: RTP media streams,
RTX streams and FlexFEC streams - each with individual packet counters.
The RTX stream is responsible for retransmissions of a referenced media
stream and the FlexFEC stream is responsible for FEC of a referenced
media stream. RTX/FEC streams do not show up as separate objects in
getStats(). Only the media streams become "outbound-rtp" objects, but
their packet and byte counters have to include the RTX and FEC counters.
--- Overview of this CL ---
This CL adds MergeInfoAboutOutboundRtpSubstreams(). It takes
StreamStats of all kinds as input, and outputs media-only StreamStats
- incorporating the RTX and FEC counters into the relevant media
StreamStats.
The merged StreamStats objects is a smaller set of objects than the
non-merged counterparts, but when aggregating all packet counters
together we end up with exact same packet and count as before.
Because WebRtcVideoSendStream::GetVideoSenderInfo() currently aggregates
the StreamStats into a single VideoSenderInfo (single "outbound-rtp"),
this CL should not have any observable side-effects. Prior to this CL:
aggregate StreamStats. After this CL: merge StreamStats and then
aggregate them.
However, when simulcast stats are implemented (WIP CL:
https://webrtc-review.googlesource.com/c/src/+/168120) each RTP media
stream should turn into an individual "outbound-rtp" object. We will
then no longer aggregate all StreamStats into a single "info". This CL
unblocks simulcast stats by providing StreamStats objects that could be
turned into individual VideoSenderInfos.
--- The Changes ---
1. Methods added to RtpConfig to be able to easily tell the relationship
between RTP, RTX and FEC ssrcs.
2. StreamStats gets a StreamType (kMedia, kRtx or kFlexfec) that
replaces the booleans (is_rtx, is_flexfec).
3. "referenced_media_ssrc" is added to StreamStats, making it possible
to tell which kRtx/kFlexFec stream stats need to be merged with which
kMedia StreamStats.
4. MergeInfoAboutOutboundRtpSubstreams() added and used.
Bug: webrtc:11439
Change-Id: Iaf9002041169a054ddfd32c7ea06bd1dc36c6bca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170826
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30869}
This is a reland of 49734dc0faa69616a58a1a95c7fc61a4610793cf
Patchset 2 contains a fix for the fuzzer set up. Since we now parse
an RtpPacket out of the fuzzer data, the header needs to be correct,
otherwise we fail before even reaching the FEC code that we actually
want to test.
Bug: webrtc:11340, chromium:1052323, chromium:1055974
TBR=stefan@webrtc.org
Original change's description:
> Reland "Refactors UlpFec and FlexFec to use a common interface."
>
> This is a reland of 11af1d7444fd7438766b7bc52cbd64752d72e32e
>
> Original change's description:
> > Refactors UlpFec and FlexFec to use a common interface.
> >
> > The new VideoFecGenerator is now injected into RtpSenderVideo,
> > and generalizes the usage.
> > This also prepares for being able to genera FEC in the RTP egress
> > module.
> >
> > Bug: webrtc:11340
> > Change-Id: I8aa873129b2fb4131eb3399ee88f6ea2747155a3
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168347
> > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30515}
>
> Bug: webrtc:11340, chromium:1052323
> Change-Id: Id646047365f1c46cca9e6f3e8eefa5151207b4a0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168608
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30593}
Bug: webrtc:11340, chromium:1052323
Change-Id: Ib8925f44e2edfcfeadc95c845c3bfc23822604ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169222
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30724}
