On 8/10/2021 12:04 PM, Andreas Rheinhardt wrote:
James Almer:
If a slice header fails to parse, and the next one uses different Sequence and
Picture parameter sets, certain values may not be read if they are not coded,
resulting in the previous slice values being used.
Signed-off-by: James Almer <jamr...@gmail.com>
---
libavcodec/h264_slice.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 41338fbcb6..a31e804620 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1897,6 +1897,8 @@ static int h264_slice_header_parse(const H264Context *h,
H264SliceContext *sl,
if (nal->type == H264_NAL_IDR_SLICE)
get_ue_golomb_long(&sl->gb); /* idr_pic_id */
+ sl->poc_lsb = 0;
+ sl->delta_poc_bottom = 0;
if (sps->poc_type == 0) {
sl->poc_lsb = get_bits(&sl->gb, sps->log2_max_poc_lsb);
@@ -1904,6 +1906,7 @@ static int h264_slice_header_parse(const H264Context *h, H264SliceContext *sl,
sl->delta_poc_bottom = get_se_golomb(&sl->gb);
}
+ sl->delta_poc[0] = sl->delta_poc[1] = 0;
if (sps->poc_type == 1 && !sps->delta_pic_order_always_zero_flag) {
sl->delta_poc[0] = get_se_golomb(&sl->gb);
Does this patch actually change anything when all SPS use
pic_ordering_cnt_type 0?
No, all these fields are zero initialized by the decoder, and inferred
to 0 when not present.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
