[FFmpeg-trac] #5404(avcodec:new): Missing output frames in h264 decoder with stream already demuxed from MPEGTS

[FFmpeg]

#5404: Missing output frames in h264 decoder with stream already demuxed from
MPEGTS
-------------------------------------+-------------------------------------
             Reporter:  pcabarat     |                     Type:  defect
               Status:  new          |                 Priority:  critical
            Component:  avcodec      |                  Version:  git-
             Keywords:  h264 MPEGTS  |  master
  missing frames                     |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:

 .yuv direct output from .ts and .yuv output from demuxed .ts to .h264 are
 different when decoding.

 FFmpeg version info :
 {{{
 ffmpeg version N-79243-g54c9146 Copyright (c) 2000-2016 the FFmpeg
 developers
   built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010
   configuration:
   libavutil      55. 20.100 / 55. 20.100
   libavcodec     57. 33.100 / 57. 33.100
   libavformat    57. 29.101 / 57. 29.101
   libavdevice    57.  0.101 / 57.  0.101
   libavfilter     6. 40.102 /  6. 40.102
   libswscale      4.  1.100 /  4.  1.100
   libswresample   2.  0.101 /  2.  0.101

 }}}

 The h264 stream was obtained from the .ts this way
 {{{
 % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.ts -vcodec copy -an -f h264
 -copyts 5_OldTownCross_544p50_AVC_QP23.h264
 }}}

 Here is how the .yuv output was directly obtained from the .ts file
 {{{
 % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.ts oldtown_ts.yuv
 }}}

 Here is how the .yuv output was obtained from the demuxed h264 stream
 {{{
 % ./ffmpeg -i 5_OldTownCross_544p50_AVC_QP23.h264 oldtown_h264.yuv
 }}}

 Size of . yuv files aren't the same and when trying to compare files
 {{{
 % cmp oldtown_h264.yuv oldtown_ts.yuv
 }}}

 I compared both output results with the JM reference software output and
 the correct one is oldtown_ts.yuv

 After a quick analysis,I realized that frames 1 2 and 3 in display order
 (starting from 0) have gone missing in oldtown_h264.yuv

 Logs are to long to be reported here, since the bug seems reproducible,
 the stream I used is available here :

 [http://www.datafilehost.com/d/998fef61]

 The problem seems to be related to buffer reordering which does not occur
 when directly decoding from .ts

 {{{
 [h264 @ 0x2fd8560] Increasing reorder buffer to 1
 [h264 @ 0x2fd8560] no picture
 [h264 @ 0x2fd8560] Increasing reorder buffer to 2
 [h264 @ 0x2fd8560] no picture ooo
 [h264 @ 0x2fd8560] Increasing reorder buffer to 3
 [h264 @ 0x2fd8560] no picture ooo
     Last message repeated 1 times
 }}}

 (ooo) seems to mean a picture is out_of _order, in h264.c

 I think it has to do with h264 decoder way of handling its frame
 unreferencing at the beginning of decoding but I can't find the reason it
 works when decoding from the .ts and don't from the stream.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5404>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker