-force_key_frames source causes pkt->flags to have AV_PKT_FLAG_KEY set incorrectly

[David Johansen]

Summary of the bug:
How to reproduce:

% ffmpeg -i test.mp4 -c:v libx264 -force_key_frames source -f dash video.xml
ffmpeg version n7.0.1-42-g67eec16150 Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --disable-shared --enable-static --enable-debug --disable-doc --disable-ffplay --enable-gpl --enable-libfdk_aac --enable-libx264 --enable-libx265 --enable-librsvg --enable-openssl --enable-nonfree --extra-libs=-lpthread
libavutil      59.  8.100 / 59.  8.100
libavcodec     61.  3.100 / 61.  3.100
libavformat    61.  1.100 / 61.  1.100
libavdevice    61.  1.100 / 61.  1.100
libavfilter    10.  1.100 / 10.  1.100
libswscale      8.  1.100 /  8.  1.100
libswresample   5.  1.100 /  5.  1.100
libpostproc    58.  1.100 / 58.  1.100

Setting -force_key_frames source causes pkt->flags to have AV_PKT_FLAG_KEY set incorrectly on the 3rd frame even though it shouldn't be set. I've checked the reading of the data and pkt->flags is correct, then then it's being set on the 3rd frame even though that was not the case on the input

[David Johansen]

This problem didn't happen with 4.4.5 and started with 5.0.1 so I'm running a bisect to try and identify the cause

[Balling]

set incorrectly on the 3rd frame

Recovery SEI behind that frame exists? If it does then it is key frame

[David Johansen]

The bisect identified ​this commit as the cause and if I revert it on a current version, then the issue doesn't happen

Replying to Balling:

set incorrectly on the 3rd frame

Recovery SEI behind that frame exists? If it does then it is key frame

I'm not sure. How do I check for this?

[Balling]

-use_tfdt 0 should fix it. Try it.

As to how to see Recovery SEI ffmpeg.exe -an -i your.mp4 -c copy -bsf:v trace_headers -f null -

and search for SEI that is of type recovery.

[MasterQuestionable]

͏    E.g. ​https://trac.ffmpeg.org/attachment/ticket/8063/123.avi.xml

[David Johansen]

Unfortunately, it appears this issue is in the encoder or something further down the line and using -use_tfdt 0 doesn't resolve the issue.

Here's an example video that results in 12 keyframes when the input has 10:
​https://drive.google.com/file/d/1WxOrSi-GNB45nLUUiR4PT7c4H2VurtKk/view?usp=sharing

And this command to generate the output:
ffmpeg -use_tfdt 0 -i input.mp4 -c:v libx264 -force_key_frames source output.mp4

And then this command to see how many keyframes there are:
ffprobe -show_entries frame=pict_type,pts_time,pkt_pos -of csv=p=0 -i output.mp4 | grep I

[David Johansen]

Closing since this is happening in the encoder and ffmpeg is handling things correctly

[MasterQuestionable]

͏    Might be muxer (container) problem..?