This is a follow-up to r34019. It adds checks for when padding can be
sent before media - and how timestamps are set on RTX padding.
Bug: webrtc:11340
Change-Id: I46fbd3c3eff9e308b5c65220718df749f2d9c46b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219162
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34041}
Specifically, use reference instead of pointer for out parameter
and place the out parameter last, for the following methods
ReadUInt8
ReadUInt16
ReadUInt32
ReadBits
PeekBits
ReadNonSymmetric
ReadSignedExponentialGolomb
ReadExponentialGolomb
Bug: webrtc:11933
Change-Id: I3f1efe3e29155985277b0cd18700ddea25fe7914
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218504
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34037}
Users of the mixer can use this information to determine which sources were included in the frame.
Bug: webrtc:12745
Change-Id: I11a8e3b1f4e8f95eb870336cad8dd082330bdf02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217768
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Chen Xing <chxg@google.com>
Commit-Queue: Doudou Kisabaka <doudouk@google.com>
Cr-Commit-Position: refs/heads/master@{#34035}
Reduce to testing what RTPSender is actually interested in: that
packets are actually forwarded to the pacer.
Partially the old test was verifying TransmissionOffset header extension,
add an explicit test for that at RtpRtcp-level instead.
Bug: webrtc:11340
Change-Id: I62be39e1d9d8c214c3277f4f1326db05b937674a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218845
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34023}
Simplifies the test so that it only tests the padding-related parts.
Header extensions for padding already has a dedicated test, as does
packet stats from RtpSenderEgress.
Bug: webrtc:11340
Change-Id: I88829409aac15f0aad0d4d634114731e819574bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218844
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34019}
Moves OnSendSideDelayUpdated and OnSendPacketUpdated out from
rtp_sender_unittest and into rtp_sender_egress_unittest and
rtp_rtcp_impl2_unittest. The former test now only tests the logic for
updating send-side-delay stats. The latter is now on a proper
RtpRtcp-level and also verifies that frame timestamps makes it to the
egress (as assumed by the first test).
Bug: webrtc:11340
Change-Id: I784042ad91eb66a4d1eebdbbc625f9522528bfb5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218502
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33996}
- The FEC receiver tracks maximum of 48 media packets at a time, and packet reordering can delay the FEC packet from its protected media packets by more than 48 sequences.
- Such FEC packets do not get purged until much later when newer FEC packets with much higher sequence mark them as old.
- Until that happens, they sit in the receiver queue, wasting CPU cycles.
- If the receiver maintains a larger queue size for the media packets, it increases possibility of having all media packets in the queue, thereby organically purging the FEC packet.
- More importantly, this also increases the efficacy of FEC decode for such packet, since media packets now remain relevant for longer and aid in lost packet recovery.
Bug: webrtc:12656
Change-Id: Id0058df9a23ea31839decf2c37e0670a54c947fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215882
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33989}
Previously this value was rounded up to a millisecond value.
This change is complementary to another change:
https://webrtc-review.googlesource.com/c/src/+/216398
Bug: webrtc:12722
Change-Id: I0fd2baceb4608132615fb6ad241ec863e343edb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217521
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33928}
Before this CL, timestamps of received packets were rounded
to the nearest millisecond and stored as int64_t. Due to the
rounding it sometimes happened that timestamps later in the
pipeline that are not rounded seem to occur even before the
video frame was received.
Change-Id: I92d8f3540b23baae2d4a1dc6a7cb3f58bcdaad18
Bug: webrtc:12722
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216398
Reviewed-by: Chen Xing <chxg@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33916}
We want to make this information available to RtpTransportControllerSend.
Bug: None
Change-Id: Id9237fe1a1fe65834cf2ac79155bc4502744e4db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216683
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33914}
libstdc++ does not allow incomplete type for T2 with std::pair<T1,T2>,
which is used by std::unordered_map. Include full definition of
TmmbrInformation, RrtrInformation and LastFirStatus.
Bug: chromium:957519
Change-Id: I00cad6d5e5a782791f5f64b4e38d7738b2c5ae87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217180
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33897}
New tests (transport sequence number plus newly added abs send time) now
test more of production code and less of rtp_sender_unittest.cc test
fixture code.
Bug: webrtc:11340
Change-Id: I8ec0022c3d18467a4144ce984996af1a452760dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216327
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33895}
In RTPSenderVideoFrameTransformerDelegate::TransformFrame(), the encoder
queue might still be null when a frame queued by a previous delegate
arrives. This could happen in the context of renegotiation that results
in a codec reset. In this case, the frame should be dropped.
Bug: webrtc:12691
Change-Id: Ib738ce31738cffc7e01053dbc82237f457fc2286
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216393
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33866}
In highly loaded media servers, ReceiveStatisticsImpl's use of std::map
attributes to ~0.32% CPU. It needs to be able to iterate through the
statisticians in order when reporting, but that is considered to be rare
compared to how often they are looked up. So this commit adds a separate
sorted set for just keeping track of the SSRCs, and letting the map of
SSRC to Statisticians, be unordered.
Bug: webrtc:12689
Change-Id: I69fe41d96bca31b2e8d669b58b5c7afabceaa6a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216385
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33864}
The test assumed a certain order in report blocks, which can have
changed with tasks to use unordered collections. This commit makes
the test more robust.
Bug: webrtc:12689
Change-Id: Ie0087dcb7dc955d70aa39208848bb99fd2f1750b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216386
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33863}
This is essentially replacing `new rtc::RefCountedObject` with
`rtc::make_ref_counted` in many files. In a couple of places I
made minor tweaks to make things compile such as adding parenthesis
when they were missing.
Bug: webrtc:12701
Change-Id: I3828dbf3ee0eb0232f3a47067474484ac2f4aed2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215973
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33852}
In highly loaded media servers, RTCPReceiver's use of std::map
attributes to ~0.5% CPU. It's mostly ::find and the [] operator, and
they are all keyed by SSRC, which is an unordered data type. This makes
these maps suitable as unordered maps, as they have constant time
complexity for lookups.
Bug: webrtc:12689
Change-Id: I7b305e233fcbed0e452632946ab0de5ee66f8dda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216321
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33850}
In highly loaded media servers, RTCPReceiver's use of std::set
attributes to ~0.87% CPU. It's mostly ::find and the [] operator and the
assignment operator.
* Removed locking of a mutex in `TriggerCallbacksFromRtcpPacket``
as it copied members that were already const.
* Switched the use of std::set for the list of registered local SSRCs
to an absl::InlinedVector, as the set is very small and it's not
expected that any more complicated container would be faster than a
linear search within a cache line.
Bug: webrtc:12689
Change-Id: I734578c22eeca2d9ba89fef77ecc689b72624567
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216322
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33849}
The extracts and refactors some test code from rtp_sender_unittest.cc
and puts it in a new target intended to only test RtpSenderEgress, and
do it as pure unit test, rather than the unholy
not-quite-unit-not-quite-integration-test thingy we have today.
Only a first test case is actually ported with this CL, but it's a
start...
Bug: webrtc:11340
Change-Id: Ie2cdde63a00a6ff6eba7b8d443eeb76ce2a527c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216180
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33841}
The eventual implementation of changing the status will be async so the
return value isn't that useful and was in fact only being used to log
a warning if an error occured.
This change is to facilitate upcoming changes related to media engine.
Bug: webrtc:11993
Change-Id: Ia7f85a9ea18b2648b511fa356918cf32a201461f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215975
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33825}
- Received FEC packets are purged from the queue if:
1. All media packets protected by the FEC packet are received.
2. All media packets protected by the FEC packet are recovered.
3. Newer FEC packet(s) with sequence number '0x3fff' larger than an old FEC packet is received.
- When FEC packets get separated from their protected media packets by more than 48, none of the first conditions ever delete that FEC packet, no matter how old/ irrelevant it gets.
- Under specific circumstances, the new FEC packet (condition 3) is not received before the media sequence number space wraps around, and incorrectly activates the old FEC packet, resulting in FEC decode for the wrong packet.
- This change purges such old FEC packets in time before the media sequence numbers wrap around.
Bug: webrtc:12656
Change-Id: I6ddf5382638c8c7e9a65724b2544dfbbc4803342
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215100
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33795}
This reverts commit a743303211.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
This prepares for ability to defer sequence number assignment to after
the pacing stage - a scenario where the RtpRtcp module rather than than
RTPSender class has responsibility for sequence numbering.
Bug: webrtc:11340
Change-Id: Ife88f60258b9b7cfd9dbd3326f02ac34da8f7603
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214967
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33702}
This is the result of compiling Chromium with
Wtautological-unsigned-zero-compare. For more details, see:
https://chromium-review.googlesource.com/c/chromium/src/+/2802412
Change-Id: I05cec6ae5738036a56beadeaa1dde5189edf0137
Bug: chromium:1195670
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213783
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33689}
There is only one NTP clock now.
Bug: webrtc:11327
Change-Id: I8c2808cf665f92bd251d68e32062beeffabb0f43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214132
Commit-Queue: Paul Hallak <phallak@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33657}
Note: google3 needs to set this clock before we can start using it.
Bug: webrtc:11327
Change-Id: I0436c6633976afe208f28601fdfd50e0f6f54d6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214480
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Paul Hallak <phallak@google.com>
Cr-Commit-Position: refs/heads/master@{#33653}
This helper method does not belong to the Clock class. Also, it's simple enough that it's not needed.
Bug: webrtc:11327
Change-Id: I95a33f08fd568b293b591171ecaf5e7aef8d413c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214123
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Paul Hallak <phallak@google.com>
Cr-Commit-Position: refs/heads/master@{#33652}
`RTCInboundRtpStreamStats.lastPacketReceivedTimestamp` must be a time
value in milliseconds with Unix epoch as time origin (see
bugs.webrtc.org/12605#c4).
This change fixes both audio and video `RTCInboundRtpStreamStats` stats.
Tested: verified from chrome://webrtc-internals during an appr.tc call
Bug: webrtc:12605
Change-Id: I68157fcf01a5933f3d4e5d3918b4a9d3fbd64f16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212865
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33547}
This patch adds support for sending zero video layer allocations
header extensions. This can be used to signal that a stream is
turned off.
Bug: webrtc:12000
Change-Id: Id18fbbff2216ca23179c58ef7bbe2ebea5e242af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212743
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33541}
Add missing members needed to surface `RTCRemoteOutboundRtpStreamStats`
via `ChannelReceive::GetRTCPStatistics()` - i.e., audio streams.
`GetSenderReportStats()` is added to both `ModuleRtpRtcpImpl` and
`ModuleRtpRtcpImpl2` and used by `ChannelReceive::GetRTCPStatistics()`.
Bug: webrtc:12529
Change-Id: Ia8f5dfe2e4cfc43e3ddd28f2f1149f5c00f9269d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211041
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33452}
`LastReceivedNTP()` does not need to be part of the public members of
`ModuleRtpRtcpImpl` and `ModuleRtpRtcpImpl2` since it is used only
once in the same class.
This change is requried by the child CL [1] which adds a public getter
needed to add remote-outbound stats.
[1] https://webrtc-review.googlesource.com/c/src/+/211041
Bug: webrtc:12529
Change-Id: I82cfea5ee795de37fffa3d759ce9f581ca775d55
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211043
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33420}
The mutex is removed from the old existing implementation and instead a wrapper is implemented that ensure thread-safety.
Both the thread-safe and unsafe version share the same implementation of the logic.
There are two ways of construction:
webrtc::ReceiveStatistics::Create - thread-safe version.
webrtc::ReceiveStatistics::CreateUnLocked -thread-unsafe
Bug: none
Change-Id: Ica375919fda70180335c8f9ea666497811daf866
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211240
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33419}
This CL refactors RtpSender and extracts handling of sequence number
assignment and timestamping of padding packets in a separate helper
class.
This is in preparation for allowing deferred sequencing to after the
pacing stage.
Bug: webrtc:11340
Change-Id: I5f8c67f3bb90780b3bdd24afa6ae28dbe9d839a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208401
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33316}
This remove webrtc-specific macro that has no reason to be webrtc specific
ABSL_DEPRECATED takes a message parameter encouraging to write text how class or function is deprecated.
Bug: webrtc:12484
Change-Id: I89f1398f91dacadc37f7db469dcd985e3724e444
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208282
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33314}
This is a reland of 5cc9957062
Original change's description:
> Batch assign RTP seq# for all packets of a frame.
>
> This avoids a potential race where other call sites could assign
> sequence numbers while the video frame is mid packetization - resulting
> in a non-contiguous video sequence.
>
> Avoiding the tight lock-unlock within the loop also couldn't hurt from
> a performance standpoint.
>
> Bug: webrtc:12448
> Change-Id: I6cc31c7743d2ca75caeaeffb98651a480dbe08e2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207867
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33291}
Bug: webrtc:12448
Change-Id: I7c5a5e00a5e08330ff24b58af9f090c327eeeaa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208221
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33296}
This reverts commit 5cc9957062.
Reason for revert: Seems this CL breaks the below test when being imported in google3
https://webrtc-review.googlesource.com/c/src/+/207867
Original change's description:
> Batch assign RTP seq# for all packets of a frame.
>
> This avoids a potential race where other call sites could assign
> sequence numbers while the video frame is mid packetization - resulting
> in a non-contiguous video sequence.
>
> Avoiding the tight lock-unlock within the loop also couldn't hurt from
> a performance standpoint.
>
> Bug: webrtc:12448
> Change-Id: I6cc31c7743d2ca75caeaeffb98651a480dbe08e2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207867
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33291}
Bug: webrtc:12448
Change-Id: I2547f946a5ba75aa09cdbfd902157011425d1c30
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208220
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/master@{#33294}
