Fixed issue with H264 packet buffer where it was not detecting presence of sps/pps for idr frames
This issue happens for default case sps_pps_idr_is_h264_keyframe_ is false
The way PacketBuffer::FindFrames works for H264 is it keeps on skipping the packets till it finds a packet which has last=1
This is checked here : if (sequence_buffer_[index].frame_end)
Inside this block there is a loop, to go back and scan all the packets till start of the frame.
Since the scan is backwards, the sequence of nalus in this scan is IDR -> PPS -> SPS.
Once IDR is detected if (h264_header->nalus[j].type == H264::NaluType::kIdr) , the code will has_h264_idr = true.
When it scans the previous packets, it skips those as has_h264_idr is true. These packets have the SPS / PPS and hence has_h264_sps / pps flags were never set to true.
This resulted in warning as no SPS/PPS has been found for IDR.
Test plan : verified loopback call on IOS simulator using H264 codec and the warning log "Received H.264-IDR frame..." is not present anymore
Bug: webrtc:11006
Change-Id: Icbe8a393e3679a8d621af6c76e4999fd60db04a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155420
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Shyam Sadhwani <shyamsadhwani@fb.com>
Cr-Commit-Position: refs/heads/master@{#29386}
diff --git a/modules/video_coding/packet_buffer.cc b/modules/video_coding/packet_buffer.cc
index 1ca488d..7f0266d 100644
--- a/modules/video_coding/packet_buffer.cc
+++ b/modules/video_coding/packet_buffer.cc
@@ -336,7 +336,7 @@
if (!is_h264 && sequence_buffer_[start_index].frame_begin)
break;
- if (is_h264 && !is_h264_keyframe) {
+ if (is_h264) {
const auto* h264_header = absl::get_if<RTPVideoHeaderH264>(
&data_buffer_[start_index].video_header.video_type_header);
if (!h264_header || h264_header->nalus_length >= kMaxNalusPerPacket)
