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

[Michael Niedermayer]

On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
> 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.

can you use git bisect to figure out when this issue appeared?

was the decoder used in libavformat previously also the hw instead of
sw decoder ?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160724/2030f8df/attachment.sig>