[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 23:18:38 EEST 2016


Hello Michael,

Sunday, July 24, 2016, 11:11:32 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> 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.

MN> this code is not new, this is in git since 4 years
MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
MN> Date:   Mon Jul 2 23:16:59 2012 +020

MN> why does it cause a problem now ?

MN> why does libavformat use hw h264 decoding ?
I do not know that is reason why I'm asking.
I just run ffmpeg like
ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv -vcodec h264_qsv -y ./result.mp4
..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)

When I replace
#if CONFIG_H264_DECODER
to
#if 0
...all working fine.

I can not say when exactly the issue appeared, about several weeks ago all
worked correct. But current build is broken at this place.


MN> this seems like a bad idea to me, as libavcodec would use
MN> hw decoding too potentially resulting in multiple hw decoders
MN> running at the same time for no good reason.

MN> the one in libavformat is just used to parse a few header values
MN> ideally that should be done in the AVParser for h264 ...

MN> [...]




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



More information about the ffmpeg-devel mailing list