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}
This commit is contained in:

committed by
Commit Bot

parent
4f2e9406c9
commit
2b84dad18c
@ -336,7 +336,7 @@ std::vector<std::unique_ptr<RtpFrameObject>> PacketBuffer::FindFrames(
|
||||
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)
|
||||
|
Reference in New Issue
Block a user