[FFmpeg-trac] #6810(avformat:new): Wrong DTS guess when PTS is reordered for the input without DTS (wrong 'Non-monotonous DTS' fixup)
FFmpeg
trac at avcodec.org
Tue Nov 7 12:32:42 EET 2017
#6810: Wrong DTS guess when PTS is reordered for the input without DTS (wrong
'Non-monotonous DTS' fixup)
------------------------------------+------------------------------------
Reporter: perexg | Owner:
Type: defect | Status: new
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: mkv dts | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+------------------------------------
Comment (by perexg):
Value 4 (has_b_frames) is sufficient. It looks like H264 decoder issue.
The H264 SPS has not set bitstream_restriction_flag . The
sps->num_reorder_frames is correctly set in
ff_h264_decode_seq_parameter_set() - comment: derive it based on the level
. The problem is that h264_select_output_frame() checks for strict
settings so code 'h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames,
sps->num_reorder_frames);' is not executed by default. Adding "-strict 1"
option fixes the issue completely:
ffmpeg -strict 1 -i a.mkv -c:v copy -c:a copy /tmp/a.mkv
So the "bug" is in the H264 decoder.
The primary source of the strict check is in the commit:
{{{
commit fb19e1443bc45e192545d3485ddb9c76e7d77855
Author: Michael Niedermayer <michaelni at gmx.at>
Date: Sat Jul 19 16:16:00 2008 +0000
Take the brain amputated spec literally if the user asks for it
(-strict 1).
That is, add 16 frames delay, cache trashing and av desync.
fixes at least the following reference bitstreams:
CABA3_Sony_C.jsv
CACQP3_Sony_D.jsv
CAMANL1_TOSHIBA_B.264
CANL3_Sony_C.jsv
CVBS3_Sony_C.jsv
CVMANL1_TOSHIBA_B.264
Originally committed as revision 14308 to
svn://svn.ffmpeg.org/ffmpeg/trunk
}}}
I believe that the original purpose of the check was obsoleted with the
new code in ff_h264_decode_seq_parameter_set() - comment: derive it based
on the level , so I would propose to remove the condition in
h264_select_output_frame() like :
{{{
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 35dcabd611..3b50d12fa4 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1286,10 +1286,7 @@ static int h264_select_output_frame(H264Context *h)
cur->mmco_reset = h->mmco_reset;
h->mmco_reset = 0;
- if (sps->bitstream_restriction_flag ||
- h->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
- h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames,
sps->num_reorder_frames);
- }
+ h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames,
sps->num_reorder_frames);
for (i = 0; 1; i++) {
if(i == MAX_DELAYED_PIC_COUNT || cur->poc < h->last_pocs[i]){
}}}
The mkv source is really the valid live H264 broadcast and the processing
should not require additional (hard to determine / find) option for
ffmpeg.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6810#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list