[FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
jorge.ramirez-ortiz at linaro.org
Sun Sep 3 20:21:37 EEST 2017
On 09/03/2017 02:27 AM, Mark Thompson wrote:
>> + return 0;
>> +static int v4l2m2m_send_frame(AVCodecContext *avctx, const AVFrame *frame)
>> + V4L2m2mContext *s = avctx->priv_data;
>> + V4L2Context *const output = &s->output;
>> + return ff_v4l2_enqueue_frame(output, frame);
>> +/* Send and receive frame happen on the same thread, hence the need for a polling timeout */
> Maybe this should only block if there isn't any space to queue more input?
as it happens on the decoding side, the issue is the same.
before being able to receive frames from the capture queue
(encoded/decoded) the user needs to push a number of buffers to the
this number varies from IP to IP...I guess also depend on the formats.
so yeah, if we knew before hand this number then it would be easy to
make sure we have queued enough input buffers to get the pipe going and
then just block for data safely.
you proposed that this number is calibrated (ie, track the timeout);
however it makes me feel unsafe not having a fallback option (ie, if the
pipe blocks, then we are stuck)....
having said that, I will post the calibrated solution if you'd rather
have that....we can easily go back to a timeout if needed.
More information about the ffmpeg-devel