[FFmpeg-trac] #5000(undetermined:reopened): Skipping frames for GoPro videos recorder with Ambarella

[FFmpeg]

#5000: Skipping frames for GoPro videos recorder with Ambarella
-------------------------------------+-------------------------------------
             Reporter:  Den-ffmpeg   |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  important    |                Component:
              Version:  git-master   |  undetermined
             Keywords:  h264         |               Resolution:
  regression                         |               Blocked By:
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by alex_hitman):

 Hi everyone!

 I'v done some research of this bug.

 Sample video has 988 video frames, but h264 decoder outputs only 741
 (every 4th is dropped).
 Header has VUI parameters with bitstream restrictions, where
 num_reordered_frames == 1.
 But pts is differ from dts by 2. So decoder drops frames because it does
 not increase reordered buffer to 2 due to bitstream restrictions.

 h264.c:decode_postinit()

 {{{
     } else if(h->avctx->has_b_frames < out_of_order &&
 !sps->bitstream_restriction_flag){
         av_log(h->avctx, AV_LOG_INFO, "Increasing reorder buffer to %d\n",
 out_of_order);
         h->avctx->has_b_frames = out_of_order;
     }
 }}}

 Here has_b_frames == num_reordered_frames because
 bitstream_restriction_flag is set.

 After dropping VUI bitstream restrictions decoder outputs all frames.

 So, the question is what to do.

 h264 standard says that VUI parameters are optional and in our case they
 are probably wrong.
 But may exists other cases where it can be helpful.

 May be decoder can do more soft checking. For example, use
 max_dec_frame_buffering. From standard:
 {{{
 The value of num_reorder_frames shall be in the range of 0 to
 max_dec_frame_buffering,
 inclusive. When the num_reorder_frames syntax element is not present,
 the value of num_reorder_frames value shall be inferred to be equal
 to max_dec_frame_buffering.
 }}}
 So we can trace warning but drop the frames only after reaching
 max_dec_frame_buffering.

 Or may be don't use num_reordered_frames at all. Seems player are not
 using ffmpeg for decoding (wmp, quicktime), don't pay much attention to
 bitstream restrictions.

 Reuploaded file: https://www.datafilehost.com/d/7d7b159e

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5000#comment:16>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker