Missing key frame declaration in index list

[iakame]

Context :
OS :

Windows with DirectShow

Camera :

Encoding USB camera
This camera has 2 available pins (we want to record the h264) :

1 : mjpeg or raw
2 : h264

Steps taken :

Record h264 camera stream :

The output container (here .avi) doesn't matter (as in the bug still occurs with any other container).

 % ffmpeg -f dshow -video_pin_mode 1 -i video="USB Camera" -t 10 -vcodec copy -copyinkf camera_capture.avi

Bug description :
The output file is usable and can be read.
However, when reading the through a media player, you should notice that when making jumps in the video (with the progress bar), the display either freezes for a short time, contains artefacts or goes blank with artefacts (depending on the media player) before retrieving normal display.

Analysis :
The video can be fixed by making go through ffmpeg one more time.

 % ffmpeg -i camera_capture.avi -vcodec copy fixed_camera_capture.avi

fixed_camera_capture.avi doesn't have the bug described above.

Both files give the same output when probed with ffprobe but both files are binary different:

 % diff camera_capture.avi fixed_camera_capture.avi
 Binary files camera_capture.avi and fixed_camera_capture.avi differ

Through the following steps we've compared the differences:

 % xxd camera_capture.avi camera_capture.hex
 % xxd fixed_camera_capture.avi fixed_camera_capture.hex
 % vimdiff camera_capture.hex fixed_camera_capture.hex

A screenshot of the results is provided as an attachment.
We can see one change in the file header (although we've deduced it had no impact) and multiple changes in the trailer.
Applying the fixed trailer through a hex editor does make the video jumpable.

Addendum :
We've noticed this only on windows whereas linux works fine (Both use the same ffmpeg version aka 4.3).
As said previously, the video container doesn't change the behaviour.

We tested this on two windows device, both showing the error in the trailer.

Somewhat off-topic but we've also noticed that one of our devices only had a single key frame (verified with ffprobe) at the begining whereas the other had multiple periodically.
The two devices had mismatched DirectX versions, although we have not confirmed that it is the culprit.

Single key frame -> DirectX 12
Multiple keyframes -> DirectX 11

The provided example came from an implementation of ffmpeg's source code in c++ (aka the various libav*) but we have deduced the problem didn't come from the implementation itself as the bug still occurs with the standard ffmpeg tool.

Assumption :
This seems to be an index issue as in the key frames are not declared as such in the index list.

You can see that a single bit is set to 1 periodically and we deduce this represents the key frames (Through ffprobe we can see that there is a key frame every second or 30 frames).

[iakame]

Hex differences between the original captured video and the fixed one

[iakame]

After working around with ffmpeg's source code, I've noticed that packets read with av_read_frame() don't have their flags attributes set to AV_PACKET_FLAG_KEY even when they are a key frame (checked with ffprobe).
The context is the same as stated before.

[Balling]

Only master is supported here. Please check it and change version to git-master.