A question about VIDIOC_DQBUF

A question about VIDIOC_DQBUF

[Andrea]

Hi,

I would like to understand better the way VIDIOC_DQBUF works.

I've read the documentation at
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r8849.htm

and some tutorial at
http://lwn.net/Articles/240667/

I'm trying to check the implementation of pwc of the 2 ioctl VIDIOC_DQBUF and VIDIOC_QBUF.

Is the following correct?

- First, an application queues a buffer, then it dequeues the buffer.
- Then again, a buffer is queued and then dequeued.
- Dequeuing a buffer blocks is the buffer is not ready (unless device opened with O_NONBLOCK).
- Trying to dequeue a buffer without queuing it first is an error, and the ioctl VIDIOC_DQBUF should 
return -EINVAL.

<- 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.

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).

I've read that video-buf should simplify the handling of buffers. Should I try it?

Andrea

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: A question about VIDIOC_DQBUF

[Andrea]

Andrea wrote:
> Hi,
> 
> I would like to understand better the way VIDIOC_DQBUF works.
> 
...
> Is the following correct?
> 
> - First, an application queues a buffer, then it dequeues the buffer.
> - Then again, a buffer is queued and then dequeued.
> - Dequeuing a buffer blocks is the buffer is not ready (unless device 
> opened with O_NONBLOCK).
> - Trying to dequeue a buffer without queuing it first is an error, and 
> the ioctl VIDIOC_DQBUF should return -EINVAL.

Moreover:

- One can only VIDIOC_DQBUF after calling STREAMON. Before it should return -EINVAL? Block?
- After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL

> 
> <- 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.
> 
> 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 is not needed because STREAMOFF flushes the buffer queue. Does it not?

> This code should eventually return -EINVAL, while pwc just blocks 
> waiting for the next buffer (which never arrives because 
> VIDIOC_STREAMOFF has been called).

pwc should return -EINVAL to all ioctl calls after STREAMOFF?

Could someone please tell me where I am right and where I am wrong...

What is the reference implementation? vivi? em28xx?

Andrea

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: A question about VIDIOC_DQBUF

[Andrea]

Is there anybody who could help my with the followin?
I would like to know if my interpretation of VIDIOC_DQBUF is correct.

Thanks


Andrea wrote:
> Andrea wrote:
>> Hi,
>>
>> I would like to understand better the way VIDIOC_DQBUF works.
>>
> ...
>> Is the following correct?
>>
>> - First, an application queues a buffer, then it dequeues the buffer.
>> - Then again, a buffer is queued and then dequeued.
>> - Dequeuing a buffer blocks is the buffer is not ready (unless device 
>> opened with O_NONBLOCK).
>> - Trying to dequeue a buffer without queuing it first is an error, and 
>> the ioctl VIDIOC_DQBUF should return -EINVAL.
> 
> Moreover:
> 
> - One can only VIDIOC_DQBUF after calling STREAMON. Before it should 
> return -EINVAL? Block?
> - After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL
> 
>>
>> <- 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.
>>
>> 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 is not needed because STREAMOFF flushes the buffer queue. Does 
> it not?
> 
>> This code should eventually return -EINVAL, while pwc just blocks 
>> waiting for the next buffer (which never arrives because 
>> VIDIOC_STREAMOFF has been called).
> 
> pwc should return -EINVAL to all ioctl calls after STREAMOFF?
> 
> Could someone please tell me where I am right and where I am wrong...
> 
> What is the reference implementation? vivi? em28xx?
> 
> Andrea

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: A question about VIDIOC_DQBUF

[Jean-Francois Moine]

On Thu, 2008-07-10 at 22:02 +0100, Andrea wrote:
> Is there anybody who could help my with the followin?

Not sure, but I'll try.

> I would like to know if my interpretation of VIDIOC_DQBUF is correct.
	[snip]
> >> - First, an application queues a buffer, then it dequeues the buffer.
> >> - Then again, a buffer is queued and then dequeued.
> >> - Dequeuing a buffer blocks is the buffer is not ready (unless device 
> >> opened with O_NONBLOCK).

DQBUF blocks if _no_ buffer is ready.

> >> - Trying to dequeue a buffer without queuing it first is an error, and 
> >> the ioctl VIDIOC_DQBUF should return -EINVAL.

You do not set a specific buffer at DQBUF call.

> > - One can only VIDIOC_DQBUF after calling STREAMON. Before it should 
> > return -EINVAL? Block?

No, STREAMON may be done later by an other application.

> > - After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL

No, same reason as above.

> >> Now, about pwc: (if the above is correct).
> >>
> >> 1) VIDIOC_DQBUF blocks always until a buffer is ready, regardless of 
> >> O_NONBLOCK.

Oh, bad guy!

> >> 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.

Seems normal.

> >> 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 is not needed because STREAMOFF flushes the buffer queue. Does 
> > it not?

Correct.

> >> This code should eventually return -EINVAL, while pwc just blocks 
> >> waiting for the next buffer (which never arrives because 
> >> VIDIOC_STREAMOFF has been called).
> > 
> > pwc should return -EINVAL to all ioctl calls after STREAMOFF?

No.

> > Could someone please tell me where I am right and where I am wrong...

Done.

It was a good idea to point me on these problems. I will update the
gspca driver accordingly.

Thank you.

-- 
Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: A question about VIDIOC_DQBUF

[Andrea]

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

Re: A question about VIDIOC_DQBUF

[Andrea]

Jean-Francois Moine wrote:
> On Thu, 2008-07-10 at 22:02 +0100, Andrea wrote:
>> Is there anybody who could help my with the followin?
> 
> Not sure, but I'll try.
> 
>> I would like to know if my interpretation of VIDIOC_DQBUF is correct.
> 	[snip]
>>>> - First, an application queues a buffer, then it dequeues the buffer.
>>>> - Then again, a buffer is queued and then dequeued.
>>>> - Dequeuing a buffer blocks is the buffer is not ready (unless device 
>>>> opened with O_NONBLOCK).
> 
> DQBUF blocks if _no_ buffer is ready.

I think there is (should be) a difference between (but it is not 100% clear on documentation):

1) buffers in the queue, but not yet ready
2) no buffer in the queue

In the second case, all drivers I can try (em28xx, uvc, vivi) return -EINVAL. Only pwc blocks.
This is easy tested with mplayer

mplayer -tv driver=v4l2:device=/dev/videoXXX tv://

If it hangs on quit (IMHO wrong), then the driver blocks; if it ends normally (IMHO correct), the 
driver returns -EINVAL.

> 
>>>> - Trying to dequeue a buffer without queuing it first is an error, and 
>>>> the ioctl VIDIOC_DQBUF should return -EINVAL.
> 
> You do not set a specific buffer at DQBUF call.

You are right.

> 
>>> - One can only VIDIOC_DQBUF after calling STREAMON. Before it should 
>>> return -EINVAL? Block?
> 
> No, STREAMON may be done later by an other application.

Again, I agree with you. It is not a matter of "before or after", but if there are buffers in the 
queue (regardless of the fact if they are ready)

> 
>>> - After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL
> 
> No, same reason as above.

Again, I am not yet sure.
IMHO: Immediately after STREAMOFF (which clears the queue) it should be -EINVAL.
In case buffer are requeued, then it blocks.

> 
>>>> Now, about pwc: (if the above is correct).
>>>>
>>>> 1) VIDIOC_DQBUF blocks always until a buffer is ready, regardless of 
>>>> O_NONBLOCK.
> 
> Oh, bad guy!
> 
>>>> 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.
> 
> Seems normal.

IMHO it should check the queue. What happens if it picks a buffer that it still being used by the my 
application (which did not QBUF it)?

> 
>>>> 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 is not needed because STREAMOFF flushes the buffer queue. Does 
>>> it not?
> 
> Correct.

Agree.

> 
>>>> This code should eventually return -EINVAL, while pwc just blocks 
>>>> waiting for the next buffer (which never arrives because 
>>>> VIDIOC_STREAMOFF has been called).
>>> pwc should return -EINVAL to all ioctl calls after STREAMOFF?
> 
> No.

In that case the drivers "em28xx", "vivi", "uvc" (and all the ones that work with mplayer) are all 
wrong.

> 
>>> Could someone please tell me where I am right and where I am wrong...
> 
> Done.
> 
> It was a good idea to point me on these problems. I will update the
> gspca driver accordingly.


It seems to be a very corner-case of the documentation. And usually tests are done to check when it 
should work, not when and how it should fail.

Andrea

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list