Fix potential race in PacketSequencer.
The race can happen when an encoder thread is packetizing a video frame and is calling RTPSender::AssignSequenceNumber() while the RtpRtcp module is calling GeneratePadding() and querying PacketSequencer::CanSendPaddingOnMediaSsrc(). The solution for now is to simply not call PacketSequencer::CanSendPaddingOnMediaSsrc() from the RtpRtcp module, as that parameter will be ignored anyway - RTPSender will query that method internally while holding the send lock. Once deferred sequencing is implemented, the can_send_padding_on_media_ssrc parameter can be populated safely since it is then always called on the pacer thread. Bug: webrtc:11340, webrtc:12470 Change-Id: I9e90808166453d0e29746df89044e1d3bdffa286 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227767 Reviewed-by: Tommi <tommi@webrtc.org> Commit-Queue: Erik Språng <sprang@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34655}
This commit is contained in:
committed by
WebRTC LUCI CQ
parent
35b1cb455f
commit
51e30837d5
@ -398,9 +398,12 @@ bool ModuleRtpRtcpImpl2::SupportsRtxPayloadPadding() const {
|
||||
std::vector<std::unique_ptr<RtpPacketToSend>>
|
||||
ModuleRtpRtcpImpl2::GeneratePadding(size_t target_size_bytes) {
|
||||
RTC_DCHECK(rtp_sender_);
|
||||
// `can_send_padding_on_media_ssrc` set to false but is ignored at this
|
||||
// point, RTPSender will internally query `sequencer_` while holding the
|
||||
// send lock.
|
||||
return rtp_sender_->packet_generator.GeneratePadding(
|
||||
target_size_bytes, rtp_sender_->packet_sender.MediaHasBeenSent(),
|
||||
rtp_sender_->sequencer_.CanSendPaddingOnMediaSsrc());
|
||||
/*can_send_padding_on_media_ssrc=*/false);
|
||||
}
|
||||
|
||||
std::vector<RtpSequenceNumberMap::Info>
|
||||
|
||||
Reference in New Issue
Block a user