zqz/platform-external-webrtc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Continue looking for frames after padding packets

Browse Source 
In H264, reordered packets can cause a frame following padding to become stuck in the packet buffer.
A minimal example:
_, P, 1  - padding packet p and frame 1. Frame 1 has not been returned because of missing packet 0
0, P, 1  - when packet 0 arrives, FindFrames will stop incrementing i when it sees padding packet P, and frame 1 will never be returned

Bug: webrtc:14216
Change-Id: I78b76df9709fa8593c5025d647e2b868af3749f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266465
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37357}
This commit is contained in:
Jared Siskin
2022-06-22 06:35:38 -07:00
committed by WebRTC LUCI CQ
parent db30009304
commit 3f659b1b3c
3 changed files with 39 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
modules/video_coding/packet_buffer.h
View File

@ -117,6 +117,8 @@ class PacketBuffer {
absl::optional<uint16_t> newest_inserted_seq_num_;
std::set<uint16_t, DescendingSeqNumComp<uint16_t>> missing_packets_;
std::set<uint16_t, DescendingSeqNumComp<uint16_t>> received_padding_;
// Indicates if we should require SPS, PPS, and IDR for a particular
// RTP timestamp to treat the corresponding frame as a keyframe.
bool sps_pps_idr_is_h264_keyframe_;