[FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

Ivan Uskov ivan.uskov at nablet.com
Sun Jul 24 21:55:21 EEST 2016


Hello All,

I have discovered the following issue:
Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based h264 decoder uses.
The crash does appear inside the

int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
{
    H264Context *h = avctx->priv_data;
    return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
}

It is obvious, that casting to H264Context cannot be used for qsv decoder
because there is QSVH2645Context. Similar issue will appear for CUVID
decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
(MediaCodecH264DecContext uses), possible another cases existing.

The caller function is

static int has_decode_delay_been_guessed(AVStream *st)
{
    if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
    if (!st->info) // if we have left find_stream_info then nb_decoded_frames won't increase anymore for stream copy
        return 1;
#if CONFIG_H264_DECODER
    if (st->internal->avctx->has_b_frames &&
       avpriv_h264_has_num_reorder_frames(st->internal->avctx) == st->internal->avctx->has_b_frames)
        return 1;
#endif
    if (st->internal->avctx->has_b_frames<3)
        return st->nb_decoded_frames >= 7;
    else if (st->internal->avctx->has_b_frames<4)
        return st->nb_decoded_frames >= 18;
    else
        return st->nb_decoded_frames >= 20;
}
...which called by update_initial_timestamps()

Have anybody the idea how it can be correctly fixed?
Looks like has_decode_delay_been_guessed() should be corrected.
  

-- 
Best regards,
 Ivan                          mailto:ivan.uskov at nablet.com



More information about the ffmpeg-devel mailing list