[FFmpeg-trac] #9565(undetermined:new): Missing key frame declaration in index list
FFmpeg
trac at avcodec.org
Wed Dec 22 14:37:26 EET 2021
#9565: Missing key frame declaration in index list
--------------------------------------+----------------------------------
Reporter: iakame | Type: defect
Status: new | Priority: normal
Component: undetermined | Version: 4.3.3
Keywords: dshow h264 | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+----------------------------------
'''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).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9565>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list