[FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
jorge.ramirez-ortiz at linaro.org
Sun Sep 3 19:54:19 EEST 2017
On 09/03/2017 02:27 AM, Mark Thompson wrote:
>> +/* in ffmpeg there is a single thread could be queueing/dequeuing buffers so a
>> + * timeout is * required when retrieving a frame in case the driver has not received
>> + * enough input * to start generating output.
>> + *
>> + * once decoding starts, the timeout should not be hit.
> This seems like it could introduce a significant delay on startup for no good reason. Can you instead just queue packets until either you run out of input buffers or a nonblocking dequeue succeeds?
> (I might need to think more about how the semantics of this work.)
if the decoder needs 4 blocks, the delay is 200ms, if it is 10 blocks,
that is 500ms which doesn't seem too significant? when I test I barely
notice the difference with respect to using the h264 codec (or any of
the others in fact)
the best solution would be to be able to block until the capture queue
has frames ready but for that we would need another thread inputting
independently on the other queue...does ffmpeg allow for this? separate
threads for input and output?
More information about the ffmpeg-devel