A question about VIDIOC_DQBUF

DISCUSSION Andrea 2 participants 6 messages Jul 8, 2008 – Jul 11, 2008 1 message not in the archive Media (V4L/DVB)

lore

Share & tools

lore

Andrea

author

2008-07-08 20:20 UTC #0 lore raw

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Andrea

author

2008-07-08 22:16 UTC #1 lore raw

Quoted 4 lines · Andrea

Hi,
I would like to understand better the way VIDIOC_DQBUF works.

...

Quoted 8 lines

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

Quoted 12 lines

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

Quoted 1 line

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Andrea

author

2008-07-10 21:04 UTC #2 lore raw

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

Thanks

Quoted 38 lines · Andrea

Quoted 4 lines · Andrea
Hi,
I would like to understand better the way VIDIOC_DQBUF works.
...
Quoted 8 lines
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
Quoted 12 lines
<- 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?
Quoted 1 line
This code should eventually return -EINVAL, while pwc just blocks waiting for the next buffer (which never arrives because VIDIOC_STREAMOFF has been called).

Quoted 7 lines

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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Jean-Francois Moine

2008-07-11 07:45 UTC #3 lore raw

Quoted 1 line · Andrea

Is there anybody who could help my with the followin?

Not sure, but I'll try.

Quoted 1 line

I would like to know if my interpretation of VIDIOC_DQBUF is correct.

	[snip]

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
- 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.

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
- 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.

Quoted 2 lines

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

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

Quoted 1 line

Quoted 1 line
- After calling STREAMOFF, VIDIOC_DQBUF should return -EINVAL

No, same reason as above.

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
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!

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 8 lines
Quoted 5 lines
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.

Quoted 5 lines

Quoted 5 lines
Quoted 3 lines
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.

Quoted 1 line

Quoted 1 line
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.

Signature · 8 lines

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


--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Andrea

author

2008-07-11 20:05 UTC #4 lore raw

Quoted 5 lines · Jean-Francois Moine

Quoted 1 line · Andrea
Is there anybody who could help my with the followin?
Not sure, but I'll try.

Quoted 8 lines

Quoted 1 line
I would like to know if my interpretation of VIDIOC_DQBUF is correct.
	[snip]
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
- 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.

Quoted 5 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
- 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.

Quoted 5 lines

Quoted 3 lines
Quoted 3 lines
- 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)

Quoted 4 lines

Quoted 2 lines
Quoted 2 lines
- 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.

Quoted 10 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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!
Quoted 1 line
Quoted 1 line
Quoted 1 line
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)?

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.

Quoted 5 lines

Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
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.

Quoted 7 lines

Quoted 2 lines
Quoted 2 lines
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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andrea

author

2008-07-11 19:19 UTC #6 lore raw

Quoted 11 lines · Aidan Thornton

Hi,
Quoted 3 lines · Andrea
- 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.

Quoted 4 lines

Quoted 4 lines
<- end of question ->
Now, about pwc: (if the above is correct).

Quoted 10 lines

Quoted 6 lines
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.

Quoted 12 lines

Quoted 8 lines
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:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list