[FFmpeg-trac] #6810(avformat:new): Wrong DTS guess when PTS is reordered for the input without DTS (wrong 'Non-monotonous DTS' fixup)

[FFmpeg]

#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