[FFmpeg-devel] [PATCH 2/3] avcodec/cbs_h2645: Do not shorten reserved and unspecified NAL units in H264

James Almer jamrial at gmail.com
Wed Dec 11 23:38:43 EET 2019


On 12/11/2019 6:03 PM, Michael Niedermayer wrote:
> Its unclear if shortening these NAL units would have no effect on them
> 
> Fixes: assertion failure
> Fixes: 19286/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5707990724509696
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> ---
>  libavcodec/cbs_h2645.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 5f71d80584..b38b1d99ef 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -564,11 +564,16 @@ static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>          const H2645NAL *nal = &packet->nals[i];
>          AVBufferRef *ref;
>          size_t size = nal->size;
> +        int shorten = 1;
> +
> +        // Do not shorten reserved and unspecified NALs
> +        if (ctx->codec->codec_id == AV_CODEC_ID_H264) {
> +            shorten = nal->type > 0 && nal->type < 23;
> +        }
>  
>          // Remove trailing zeroes.
> -        while (size > 0 && nal->data[size - 1] == 0)
> +        while (shorten && size > 0 && nal->data[size - 1] == 0)
>              --size;
> -        av_assert0(size > 0);

So this is a NAL unit with a bunch of zero bytes? How did it go through
the filter in h2645_parse? It's supposed to skip any NAL like this.

>  
>          ref = (nal->data == nal->raw_data) ? frag->data_ref
>                                             : packet->rbsp.rbsp_buffer_ref;
> 



More information about the ffmpeg-devel mailing list