tree a6594d1585d7b4a7328489b6dfafa15413ce575e
parent 4f2e9406c97d68c314c2cab19f86ada568d9bd8c
author Shyam Sadhwani <shyamsadhwani@fb.com> 1570062153 -0700
committer Commit Bot <commit-bot@chromium.org> 1570200965 +0000

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}