jnohlgard / python-v4l2capture

Python extension to capture video with video4linux2 (fork of https://launchpad.net/python-v4l2-capture)
133 stars 83 forks source link

libv4l2: error dequeuing buf: Broken pipe #16

Open surajshanbhag opened 7 years ago

surajshanbhag commented 7 years ago

Hi,

Thank you for the amazing code . I am using it to stream stereo feeds from 2 webcams (logitech c930e) to my laptop from a raspberry pi. It works most times and when it does it rarely stops. However sometimes i get the following error. libv4l2: error dequeuing buf: Broken pipe

The quick fix is to disconnect the webcams and reconnect them. From debugging i have narrowed it to the following line:

image_data = video.read_and_queue()

Have you encountered this error before ?

Raspberry pi uses Ubuntu Mate 16.0.4 and is connected to my laptop via wifi on a private dedicated network.

zimenglan-sysu-512 commented 6 years ago

hi @surajshanbhag,

do u solve this preblem?

thanks

surajshanbhag commented 6 years ago

Yep. Seems silly. But I was not giving it enough time to initialize at boot. I added a wait for 60s and after that saw it rarely.

zimenglan-sysu-512 commented 6 years ago

hi @surajshanbhag,

how do solve it?

zimenglan-sysu-512 commented 6 years ago

hi @surajshanbhag,

i just sleep 60 seconds, but it dpes not work.

surajshanbhag commented 6 years ago

1) shutdown pi 2) disconnect camera 3) wait 60s 4) switch on pi 5) connect camera 6) wait for 60s

dreamibor commented 6 years ago

@zimenglan-sysu-512 Did you solve the problem?

deganii commented 6 years ago

Getting the same error here. I'll debug further but if anyone has found a solution please update this thread, thanks!

AechPro commented 6 years ago

I am encountering this error as well. After some digging, I've found the point at which the exception is logged on line 271 of this file, and again on line 1,068 of the same file.

In both cases, the error is only logged when SYS_IOCTL(devices[index].fd, VIDIOC_DQBUF, buf) returns a value != 0.

SYS_IOCTL() is a call to some device-specific I/O control driver, probably for the camera. It seems to me that the most likely candidate for the cause of this error is devices[index].fd which seems to be accessing the file descriptor of our camera object.

I wonder if perhaps the camera is not being loaded properly, and as such the device driver can't see it? Further investigation is necessary.

deganii commented 6 years ago

Hey @AechPro I've pretty good success getting the camera out of a bad state using this usb reset code:

Stack OverFlow USB Reset

This simulates a USB unplug/reconnect and is pretty reliable. You can also try calling this from within python while the app is running. Once the pipe is broken, the camera ends up in a bad state and is not accessible using V4L.

Based on the weird nature of the error, it could be possibly related to the temperature. The raspberry pi overheats almost to 80C when the video stream is running (you can check with /opt/vc/bin/vcgencmd measure_temp). In any event, I'd suggest getting a heatsink for the Broadcom IC.

AechPro commented 6 years ago

@deganii I'm currently in the process of trying to use this library instead of v4l2. If I can't get it to work, I'll try that USB reset code. Thanks!

cgpeter96 commented 5 years ago

any fix it ? who can help me :) I also meet this problem:libv4l2: error dequeuing buf: Broken pipe

lyndametref commented 5 years ago

Any update on the reason of this error? I am trying to save images with the code provided in the examples within a loop. The first iteration works fine but on the second one I get libv4l2: error dequeuing buf: Broken pipe and then the device is busy... Thanks for any help.

renan-campos commented 5 years ago

I was able to fix this problem on my system. This isn't an issue with python-v4l2capture, but with the underlying v4l2 library.

Problem: "libv4l2: error dequeuing buf: Broken pipe" occurs because SYS_IOCTL(devices[index].fd, VIDIOC_DQBUF, buf) is returning EPIPE. This occurs because the V4L2_BUF_FLAG_LAST flag was set.

From the v4l documentation:

Last buffer produced by the hardware. mem2mem codec drivers set this flag on the capture queue for the last buffer when the ioctl VIDIOC_QUERYBUF or VIDIOC_DQBUF ioctl is called. Due to hardware limitations, the last buffer may be empty. In this case the driver will set the bytesused field to 0, regardless of the format. Any Any subsequent call to the VIDIOC_DQBUF ioctl will not block anymore, but return an EPIPE error code.

It looks like once the first run is complete, this flag is being set, and doesn't get unset when starting subsequent runs.

Solution: It turns out this issue can be fixed by a patch from December 2017 that zeroes the above flag. The fix for this issue is to apply this patch and build an updated videobuf2-core.ko.

I'm using a raspberry pi 3, so I used rpi-source to pull the needed kernel source code. I saved a copy of videobuf2-core.ko in case something goes wrong. After updating the code in drivers/media/v4l2-core/videobuf2-v4l2.c I then used the procedure in this "your sunny blog post" to build and install an individual kernel module from the source tree. After restarting my system I was able to run capture_picture.py repeatedly without hitting the "Broken pipe" error.

cgpeter96 commented 5 years ago

@renan-campos hello,could you provide some detail tutorial?

YRafalsky commented 5 years ago

faced this issue too My initial state image

after 2 days of googling found this article https://www.raspberrypi.org/forums/viewtopic.php?p=675658#p675658

steps i've made (and it started works)

  1. sudo raspi-config
  2. Choose Interfacing Options image
  3. Choose SPI and enable it
  4. Choose I2C and enable it image
  5. sudo reboot

After this steps USB webcam started working (tested with fswebcam --no-banner -r 640x480 image.jpg) However I did another actions before this steps in desperate attempts to make USB working, so it could be something else before these steps Wanna notice that this issue happens on quite fresh version of Raspbian. 2 years ago this USB webcam started working without any issues on same device (with older version of raspbian). Hell started once I've reinstalled raspbian after MicroSD death