| Message ID | 20210808183837.1485-1-jamrial@gmail.com |
|---|---|
| State | Accepted |
| Commit | ce4a31cd1ff0348d279af74d49556d0315171e94 |
| Headers | show |
| Series | [FFmpeg-devel] avcodec/h264_slice: clear old slice POC values on parsing failure | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On 8/8/2021 3:38 PM, James Almer wrote: > 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 <jamrial@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); Will apply.
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 <jamrial@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? - Andreas
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 <jamrial@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-request@ffmpeg.org with subject "unsubscribe". >
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);
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 <jamrial@gmail.com> --- libavcodec/h264_slice.c | 3 +++ 1 file changed, 3 insertions(+)