[FFmpeg-trac] #7687(avcodec:new): h264_omx can stall due to not handling fragmented frames correctly
FFmpeg
trac at avcodec.org
Thu Jan 17 17:57:09 EET 2019
#7687: h264_omx can stall due to not handling fragmented frames correctly
---------------------------------------+-----------------------------------
Reporter: 6by9 | Owner:
Type: defect | Status: new
Priority: normal | Component: avcodec
Version: git-master | Resolution:
Keywords: h264_omx, omx | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
---------------------------------------+-----------------------------------
Comment (by 6by9):
Options for solving this:
* Fix the OMX_BUFFERFLAG_ENDOFFRAME handling such that get_buffer waits if
it has had one buffer through without OMX_BUFFERFLAG_ENDOFFRAME set.
GStreamer has the same issue (https://gitlab.freedesktop.org/gstreamer
/gst-omx/issues/4) and they have been reluctant to adopt that approach as
some implementations don't handle the flag correctly.
Does FFmpeg care about other IL implementations, or should this be
hidden behind the existing CONFIG_OMX_RPI config flag? I do have a fairly
simple patch to implement this, but may not understand all the
ramifications.
* Ask for more buffers from IL. The client is entitled to set nBufferCount
to a number greater than nBufferCountMin, therefore ask for more buffers
and there is a reasonable expectation that the codec will have filled them
in time. Again, does this need to be conditional on being on a Pi (the bug
in theory will affect all IL implementations).
Any views? I see that h264_omx hasn't had any significant development for
a good while, so does anyone still act as maintainer?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7687#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list