From: Andrea <audetto@tiscali.it>
To: Aidan Thornton <makosoft@googlemail.com>
Cc: video4linux-list@redhat.com
Subject: Re: A question about VIDIOC_DQBUF
Date: Fri, 11 Jul 2008 20:17:52 +0100 [thread overview]
Message-ID: <4877B1E0.70406@tiscali.it> (raw)
In-Reply-To: <c8b4dbe10807090704t4e98b8cu253fab39a9dd81d@mail.gmail.com>
Aidan Thornton wrote:
> Hi,
>
> On 7/8/08, Andrea <audetto@tiscali.it> wrote:
>
>> - Trying to dequeue a buffer without queuing it first is an error, and the
>> ioctl VIDIOC_DQBUF should
>> return -EINVAL.
>>
>
> Not sure; as far as I can tell, calling VIDIOC_DQBUF with no buffers queued is allowed, and the videobuf code has an explicit case to handle this, by waiting until a buffer is queued.
>
>
Basically, what I see a correct behviour (so far) is:
QBUF queues a buffer (counter++)
DQBUF dequeues a buffer (counter--)
STRAMOFF removes all buffers (couter = 0)
If at any time DQBUF is called and the counter is 0, it should return
EINVAL. Otherwise, if a buffer is available but not yet ready, it should
block.
>> <- end of question ->
>>
>> Now, about pwc: (if the above is correct).
>>
>> 1) VIDIOC_DQBUF blocks always until a buffer is ready, regardless of
>> O_NONBLOCK.
>> 2) VIDIOC_DQBUF does not check if a buffer has been previously queued.
>> Moreover VIDIOC_QBUF is
>> almost a no-op. It has no way to check if a buffer has been queued before
>> VIDIOC_DQBUF.
>>
>
> I doubt VIDIOC_QBUF is a no-op, unless the driver is seriously broken; it's supposed to hand the buffer back to the driver for it to put data in.
>
>
This is the code of VIDIOC_QBUF in pwc:
case VIDIOC_QBUF:
{
struct v4l2_buffer *buf = arg;
PWC_DEBUG_IOCTL("ioctl(VIDIOC_QBUF) index=%d\n",buf->index);
if (buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
if (buf->memory != V4L2_MEMORY_MMAP)
return -EINVAL;
if (buf->index < 0 || buf->index >= pwc_mbufs)
return -EINVAL;
buf->flags |= V4L2_BUF_FLAG_QUEUED;
buf->flags &= ~V4L2_BUF_FLAG_DONE;
return 0;
}
It does not do anything.
>> If I have understood correctly (very unlikely), this is the reason why
>> mplayer hangs while stopping
>> the stream with pwc:
>>
>> while (!ioctl(priv->video_fd, VIDIOC_DQBUF, &buf));
>>
>> This code should eventually return -EINVAL, while pwc just blocks waiting
>> for the next buffer (which
>> never arrives because VIDIOC_STREAMOFF has been called).
>>
>
> Hmmm... not sure about the interaction of STREAMOFF and DQBUF. I'm guessing the DQBUF should fail and return -EINVAL, though. (It certainly shouldn't succeed; the buffer queues are meant to be flushed by STREAMOFF, so there shouldn't be anything to dequeue.)
>
>
Agreed. Unless one requeues after calling STREAMOFF.
Andrea
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
prev parent reply other threads:[~2008-07-11 19:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 20:18 A question about VIDIOC_DQBUF Andrea
2008-07-08 22:14 ` Andrea
2008-07-10 21:02 ` Andrea
2008-07-11 7:31 ` Jean-Francois Moine
2008-07-11 20:03 ` Andrea
[not found] ` <c8b4dbe10807090704t4e98b8cu253fab39a9dd81d@mail.gmail.com>
2008-07-11 19:17 ` Andrea [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4877B1E0.70406@tiscali.it \
--to=audetto@tiscali.it \
--cc=makosoft@googlemail.com \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.