Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DQBUF return bad index if queue bigger then 2 for capture #60

Closed
ndufresne opened this issue May 25, 2014 · 10 comments

Comments

Projects
None yet
4 participants
@ndufresne
Copy link

commented May 25, 2014

I've been running some test, with queue of 4, but only keeping 1 or 2 queued buffer at the same time, I endup with wrong buffer id on dqbuf. This used to work in GStreamer because we where queued them all, before dqueueing 1. Hence, any random ID was valid.

@umlaeute

This comment has been minimized.

Copy link
Owner

commented May 26, 2014

could you provide a test-case that exhibits the problem?

@ndufresne

This comment has been minimized.

Copy link
Author

commented May 26, 2014

The quickest test case I have is building GStreamer (git master), and run:

gst-launch-1.0 videotestsrc ! v4l2sink device=....

It fails on a dqueue, looking at the traces should that dqbuf returns a index that was not initially queued. Most likely Hans latest compliance test would detect that.

@ndufresne

This comment has been minimized.

Copy link
Author

commented May 30, 2014

Sorry for the delay. I've written a tight C program to demonstrate the issue. I found a second issue while doing so. Here is the program output, and the device node trace. You can find the program at https://gist.github.com/ndufresne/5daab2e51d79b0d63519

[nicolas@mpb-nicolas Tests]$ ./v4l2-test /dev/video1
BUG #1: Driver should set the QUEUED flag before returning from QBUF
BUG #1: Driver should set the QUEUED flag before returning from QBUF
BUG #2: Driver should not dequeue a buffer that was not initially queued
v4l2-test: v4l2-test.c:102: main: Assertion `bufs[i].flags & 0x0002' failed.
Abandon (core dumped)
[nicolas@mpb-nicolas Tests]$ dmesg 
[80336.177612] video1: open (0)
[80336.178066] video1: VIDIOC_S_FMT: type=vid-out, width=320, height=240, pixelformat=RGB4, field=none, bytesperline=1280, sizeimage=307200, colorspace=8
[80336.178095] video1: VIDIOC_REQBUFS: count=4, type=vid-out, memory=mmap
[80336.178105] video1: VIDIOC_QUERYBUF: 389280:44:54.00932126 index=0, type=vid-out, flags=0x00000000, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x0, length=307200
[80336.178123] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.178158] video1: mmap (0)
[80336.178880] video1: VIDIOC_QUERYBUF: 389280:44:54.00932127 index=1, type=vid-out, flags=0x00000000, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x4b000, length=307200
[80336.178891] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.178916] video1: mmap (0)
[80336.179665] video1: VIDIOC_QUERYBUF: 389280:44:54.00932128 index=2, type=vid-out, flags=0x00000000, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x96000, length=307200
[80336.179676] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.179700] video1: mmap (0)
[80336.180448] video1: VIDIOC_QUERYBUF: 389280:44:54.00932126 index=3, type=vid-out, flags=0x00000001, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x0, length=307200
[80336.180460] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.180482] video1: mmap (0)
[80336.181223] video1: VIDIOC_QBUF: 389280:44:54.00932126 index=0, type=vid-out, flags=0x00000000, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x0, length=307200
[80336.181234] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.181281] video1: VIDIOC_STREAMON: type=vid-out
[80336.181294] video1: VIDIOC_QBUF: 389280:44:54.00932127 index=1, type=vid-out, flags=0x00000000, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x4b000, length=307200
[80336.181304] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.181312] video1: VIDIOC_DQBUF: 389280:44:54.00932128 index=2, type=vid-out, flags=0x00000001, field=none, sequence=0, memory=mmap, bytesused=307200, offset/userptr=0x96000, length=307200
[80336.181322] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
[80336.219096] video1: release

@umlaeute umlaeute added the bug label Jun 2, 2014

@umlaeute

This comment has been minimized.

Copy link
Owner

commented Jun 2, 2014

thanks for the test program.
i'll include it with the v4l2loopback package if that is OK for you (so we can test for regressions later)

@ndufresne

This comment has been minimized.

Copy link
Author

commented Jun 2, 2014

Yes, go ahead, I didn't put any copyright or anything, please consider this work as public domain.

@asmorkalov

This comment has been minimized.

Copy link

commented Aug 19, 2015

Hello guys, do you determine failure reason?
I reproduce the same problem with Ubuntu 12.04 and Linux kernel 3.13. GStreamer reports "Failed to get 0 in input enumeration for /dev/video0. (25 - Inappropriate ioctl for device)" for all pipelines that try to write to this device. I tried several versions of v4l2loopback and detected that it's a regression that appears between 0.80 and 0.90. 0.80 works ok for me.

@spartan263

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2016

Debian Squeeze (EOL) / Linux 2.6.32-5-amd64

In chronological order, inclusive:
(ancient) – 9eb2b3c: ./test_dqbuf fails on 'S_FMT failed: Operation not permitted'
5987d404c664b3: kernel oops on ./test_dqbuf launch
0d3692492f155e: affected by BUG #1 + BUG #2
1f9b485b330dd1: ./test_dqbuf aborts on Assertion 'breq.count == 4' failed.
8cb7ee51581d54: affected by #1 + #2
                ^=> v0.5.0 is released in this range
390c10ea252508: #1 only
('git cherry-pick f69a2fa' is necessary starting at f06117c; appears to be unrelated)
b64337f – (current) : #1 + #2, again
                  ...v0.6.0 released

Debian Jessie, Sid: BUG #1 and #2 as far back as can be seen before ./test_dqbuf sysfails on 'S_FMT' (somewhere around v0.6.2, with a fair amount of cherry-picking to complete builds)

@umlaeute

This comment has been minimized.

Copy link
Owner

commented Apr 3, 2016

@spartan263 what's bug#1 and bug#2? i figure you are not referring to #1 and #2.

@spartan263

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2016

@umlaeute
"BUG#1" refers to "BUG#1: Driver should set the QUEUED flag before returning from QBUF"
"BUG#2" refers to "BUG#2: Driver should not dequeue a buffer that was not initially queued"
Both are generated by 'tests/test_dqbuf.c' are are indeed unrelated to GitHub issues.

@spartan263

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2016

Leaving working notes here for future reference.

Add timing debug statements to tests/test_dqbuf.c:

#include <time.h>
#include <sys/time.h>

  struct timeval now;
  struct tm *tmp;
  char timestr[9];
  int rc;

  for (i = 0; i < COUNT; i++) {
    rc = gettimeofday(&now, 0);
    tmp = localtime(&now.tv_sec);
    rc = strftime(timestr, sizeof(timestr), "%H:%M:%S", tmp);
    printf("post-QBUF     bufs[%d].flags = 0x%08X (%s.%06ld / test_dqbuf)\n", i,
           bufs[i].flags, timestr, now.tv_usec);
    }

...and likewise for v4l2loopback.c (note userspace<->kernel time.h disparity):

   struct timespec tp;

   getnstimeofday(&tp);
   printk("vidioc_qbuf pre set_done buf->buffer.flags = 0x%08X (%ld.%ld / v4l2l)\n",
           b->buffer.flags, tp.tv_sec, tp.tv_nsec);

To the best of my limited ability I haven't found any glaring issues with v4l2loopback code; there seems to be a disconnect between the buffers the application creates and the buffers v4l2loopback sets flags on.

According to v4l2 documentation "After (successful) calling the VIDIOC_QBUF ioctl V4L2_BUF_FLAG_QUEUED is always set and after VIDIOC_DQBUF always cleared." I'm not convinced that's true but would need to start kernel debugging to check.

spartan263 added a commit to spartan263/v4l2loopback that referenced this issue Apr 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.