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

12
modules/video_coding/packet_buffer_unittest.cc
View File

@ -719,6 +719,18 @@ TEST_P(PacketBufferH264ParameterizedTest, FindFramesOnPadding) {
EXPECT_THAT(packet_buffer_.InsertPadding(1), StartSeqNumsAre(2));
}
TEST_P(PacketBufferH264ParameterizedTest, FindFramesOnReorderedPadding) {
EXPECT_THAT(InsertH264(0, kKeyFrame, kFirst, kLast, 1001),
StartSeqNumsAre(0));
EXPECT_THAT(InsertH264(1, kDeltaFrame, kFirst, kNotLast, 1002).packets,
IsEmpty());
EXPECT_THAT(packet_buffer_.InsertPadding(3).packets, IsEmpty());
EXPECT_THAT(InsertH264(4, kDeltaFrame, kFirst, kLast, 1003).packets,
IsEmpty());
EXPECT_THAT(InsertH264(2, kDeltaFrame, kNotFirst, kLast, 1002),
StartSeqNumsAre(1, 4));
}
class PacketBufferH264XIsKeyframeTest : public PacketBufferH264Test {
protected:
const uint16_t kSeqNum = 5;