[FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs

Jorge Ramirez 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 
output queue.
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 mailing list