On Mon, Mar 23, 2020 at 12:30:31AM -0300, James Almer wrote: > On 3/22/2020 8:00 PM, Michael Niedermayer wrote: > > Fixes: assertion failure > > Fixes: > > 20390/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5683400772157440 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/cbs_h264_syntax_template.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/cbs_h264_syntax_template.c > > b/libavcodec/cbs_h264_syntax_template.c > > index 878d348b94..b7e796e9a8 100644 > > --- a/libavcodec/cbs_h264_syntax_template.c > > +++ b/libavcodec/cbs_h264_syntax_template.c > > @@ -1365,7 +1365,7 @@ static int FUNC(slice_header)(CodedBitstreamContext > > *ctx, RWContext *rw, > > pic_size = (sps->pic_width_in_mbs_minus1 + 1) * > > (sps->pic_height_in_map_units_minus1 + 1); > > max = (pic_size + pps->slice_group_change_rate_minus1) / > > - (pps->slice_group_change_rate_minus1 + 1); > > + (pps->slice_group_change_rate_minus1 + 1) + 1; > > The spec says > > "The value of slice_group_change_cycle is represented in the bitstream > by the following number of bits Ceil( Log2( PicSizeInMapUnits ÷ > SliceGroupChangeRate + 1 ) ) > > The value of slice_group_change_cycle shall be in the range of 0 to > Ceil( PicSizeInMapUnits ÷ SliceGroupChangeRate ), inclusive." > > Are you trying to change the amount of bits read, the max allowed value, > or both?
the bits, ill send a better patch thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
signature.asc
Description: PGP signature
_______________________________________________ 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".
