On Fri, 2 Dec 2016 13:51:24 +0100 Timo Rothenpieler <t...@rothenpieler.org> wrote:
> 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 That looks ok, but: can someone explain to me why Libav does apparently not need this shitshow? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel