[FFmpeg-devel] [PATCHv3 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Mark Thompson]

On 04/08/17 09:46, Jorge Ramirez wrote:
> On 08/03/2017 01:53 AM, Mark Thompson wrote:
>>> +    }
>>> +
>>> +    ret = poll(&pfd, 1, timeout);
>> Can this poll be interrupted?
> yes. when that happens, we indicate no buffer available.
> I think the main program should set the necessary masks.

I was thinking this might violate the send/receive semantics without EINTR handling - consider a situation where send returns EAGAIN (e.g. by trying to send 9001 packets to a decoder all at once) so the caller does a receive but that then races with a signal such that poll returns EINTR, then receive would return EAGAIN as well which isn't allowed.

If you want to impose signal handling requirements on the caller then that would need to be documented somewhere.

>>> +    if (ret <=  0)
>>> +        return NULL;
>>> +
>>> +    memset(&buf, 0, sizeof(buf));
>>> +    buf.memory = bp->memory;
>>> +    buf.type = bp->type;
>>> +    if (V4L2_TYPE_IS_MULTIPLANAR(bp->type)) {
>>> +        memset(planes, 0, sizeof(planes));
>>> +        buf.length = VIDEO_MAX_PLANES;
>>> +        buf.m.planes = planes;
>>> +    }
>>> +    ret = ioctl(bp->fd, VIDIOC_DQBUF, &buf);
>>> +    if (ret) {
>>> +        if (errno != EAGAIN && errno != EINVAL) {
>> EINVAL is considered ok?
> 
> no any ioctl that returns non zero is a fault condition.
> EINVAL (just as EAGAIN) is just not an unrecoverable error (we will just return null indicating that there is no buffer available)

EINVAL usually indicates that the arguments were invalid somehow, but I think with this setup it's just going to call it again with pretty much arguments.  In what case can EINVAL be recoverable?

- Mark