These paths can be taken when the actual underlying codec is not h264,
but the user forces, for example via ffmpeg command line, a specific
input decoder that happens to be a h264 decoder.
In that case, the codecpar codec_id is set to h264, but the internal
avctx is the one of, for example, an mpeg2 decoder, thus crashing in
this function.
Checking for the codec actually being h264 is not strictly neccesary to
fix the crash, but a precaution to catch potential other unexpected
codepaths.
Fixes #5985
---
libavformat/utils.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 345bbfe5fe..8e23c0c6ec 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -966,11 +966,14 @@ static int is_intra_only(enum AVCodecID id)
static int has_decode_delay_been_guessed(AVStream *st)
{
- if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
+ if (st->codecpar->codec_id != AV_CODEC_ID_H264 ||
+ st->internal->avctx->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 &&
+ if (st->internal->avctx->codec &&
!strcmp(st->internal->avctx->codec->name, "h264") &&
+ st->internal->avctx->has_b_frames &&
avpriv_h264_has_num_reorder_frames(st->internal->avctx) ==
st->internal->avctx->has_b_frames)
return 1;
#endif
--
2.11.0.rc2
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
