[FFmpeg-trac] #10534(undetermined:new): Incorrect frame order when muxing H.264 stream with B-frames
FFmpeg
trac at avcodec.org
Thu Aug 24 17:54:27 EEST 2023
#10534: Incorrect frame order when muxing H.264 stream with B-frames
--------------------------------------+----------------------------------
Reporter: wdzierzan | Type: defect
Status: new | Priority: normal
Component: undetermined | Version: 6.0
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+----------------------------------
Summary of the bug: The order of frames in an MP4 file is incorrect when
an H.264 stream containing B-frames is muxed.
How to reproduce:
{{{
% ffmpeg -i blob.h264 -vcodec copy blob.h264.mp4
% ffmpeg -i blob.h264 -vcodec copy -bsf:v dts2pts blob.h264.pts.mp4
ffmpeg version 6.0
libavutil 58. 2.100 / 58. 2.100
libavcodec 60. 3.100 / 60. 3.100
libavformat 60. 3.100 / 60. 3.100
libavdevice 60. 1.100 / 60. 1.100
libavfilter 9. 3.100 / 9. 3.100
libswscale 7. 1.100 / 7. 1.100
libswresample 4. 10.100 / 4. 10.100
libpostproc 57. 1.100 / 57. 1.100
}}}
Without the dts2pts filter, the initial I-frame is missing in the muxed
file. pts_time as shown by ffprobe are non-monotonic (in decoding instead
of presentation order?). Playback in `QuickTime` and popular web browsers
is affected.
AFAIU, the dts2pts filter is supposed to help for this case. It helps to
some extent: the initial I-frame is preserved and pts_time are ''almost''
monotonic. The issue is that they are not exactly monotonic (the order is
broken around the middle and end of the file).
Meanwhile, the output of
{{{
% MP4Box -add blob.h264 blob.h264.mp4box.mp4
}}}
seems fine.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10534>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list