[FFmpeg-trac] #7687(avcodec:new): h264_omx can stall due to not handling fragmented frames correctly

[FFmpeg]

#7687: h264_omx can stall due to not handling fragmented frames correctly
-------------------------------------+-------------------------------------
             Reporter:  6by9         |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  avcodec      |                  Version:  git-
             Keywords:  h264_omx,    |  master
  omx                                |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug:
 Encoder h264_omx has a race condition in trying to collect all the buffers
 when the encoded frame is split over multiple IL buffers. This condition
 is more prevalent at high bitrates as frames are inherently larger.

 More details in https://github.com/raspberrypi/firmware/issues/1087

 Whilst running and having frames fed in, omx_encode_frame output buffer
 handling goes through the summarised loop:
 {{{
 while((!*got_packet && ret == 0 && !s->got_eos) {
   buffer = get_buffer(DON'T WAIT)
   if (!buffer)
      break;
   <Pass data from IL buffer to ffmpeg buffer>
   if (buffer->nFlags & OMX_BUFFERFLAG_ENDOFFRAME) {
     ...
     *got_packet = 1;
   }
   OMX_FillThisBuffer(buffer);
 }
 }}}

 The default on the Pi is 1 buffer of 64kB, so if the frame is over 64kB
 there is race from submitting the buffer with OMX_FillThisBuffer to
 getting back to the top and calling get_buffer. If IL hasn't filled and
 returned the buffer in that time, then you get the first  fragment
 returned as the complete encoded frame.
 The remaining fragment will be returned on the next call, but that's now
 left the next frame in the codec's output FIFO. Repeat a few times and you
 end up with the codec output FIFO totally full, and the codec stalls. The
 codec can't process an input ends up not being able to process an input
 buffer and therefore holds on to it, at which point FFmpeg stalls waiting
 for an input buffer.

 On older firmware this issue didn't get triggered for reasons that aren't
 100% clear, but a performance improvement made to the firmware in July
 2018 has exposed this error in h264_omx

 How to reproduce:
 {{{
 ffmpeg -c:v mpeg2_mmal -i sample.ts -c:v h264_omx -b:v 15M sample.mkv

 ffmpeg git-master
 built on Raspberry Pi
 }}}
 sample.ts is referenced in the Pi Github issue as
 https://www.dropbox.com/s/w7n9nn4eeeyq7qc/sample.ts?dl=1, but most 1080P
 clips will trigger the issue if encoded at this sort of bitrate.

 The issue has also been reported when encoding a 1080P webcam through
 h264_enc at 2fps and 1.4Mbit/s.

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