[FFmpeg-devel] [PATCHv6 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
Jorge Ramirez
jorge.ramirez-ortiz at linaro.org
Mon Aug 28 11:12:21 EEST 2017
On 08/25/2017 05:35 PM, wm4 wrote:
>> +static V4L2Buffer* context_ops_dequeue_v4l2buf(V4L2Context *ctx, unsigned int timeout)
>> +{
>> + struct v4l2_plane planes[VIDEO_MAX_PLANES];
>> + struct v4l2_buffer buf = { 0 };
>> + V4L2Buffer* avbuf = NULL;
>> + struct pollfd pfd = {
>> + .events = POLLIN | POLLRDNORM | POLLPRI, /* default capture context */
>> + .fd = ctx->fd,
>> + };
>> + int ret;
>> +
>> + if (ctx->num_queued < ctx->min_queued_buffers)
>> + return NULL;
>> +
>> + if (V4L2_TYPE_IS_OUTPUT(ctx->type))
>> + pfd.events = POLLOUT | POLLWRNORM;
>> +
>> + for (;;) {
>> + ret = poll(&pfd, 1, timeout);
> Why does this have a timeout? This makes no sense: either a frame will
> be decoded/packet can be encoded, or you need to give it more input
> frames or packets, or an error happened.
>
yes, it does makes no sense when we consider only the capture buffers in
a decoding scenario (those don't time out for the reasons that you
pointed out);
however we also should look into how the output buffers are handled (in
the same decoding case...see context_ops_getfree_v4l2buf).
every time a new output buffer is required to input data to the driver,
we poll (with a timeout) until we have recovered _all_ the buffers that
are no longer needed in the driver.
I dont think this is an issue.
More information about the ffmpeg-devel
mailing list