Closed mjsobrep closed 4 years ago
Hello, I'm the original author of the package. When I wrote this package I was guided by the OpenCV API docs to believe that OpenCV supported opening a video provider by two (necessarily different) calls:
When reading the actual source code of that method: https://github.com/opencv/opencv/blob/1acadd363b0d0ffcdabac8af3196cb65bef426b1/modules/videoio/src/cap.cpp
It 'seems' like the string method should be able to deal with a path being a video device... when I tried, it didn't work for me. So I ended up having that way of differentiating if it's a video device just getting the number of the device. I see that it works for you! Maybe it's based on the backend that OpenCV is using? At the time I wrote it for OpenCV 2.X.Y... I don't really know.
In your case, the only thing I can recommend, is to find which index device makes the program find your camera. If you have no other cameras, it will be 0 most probably. The launchfile just needs the number, e.g. 0, as in the example launchfile.
Good luck! I hope it's useful for you.
Gotcha, that makes sense. The path as a video device seems to work well for me. Getting the number does work, but those numbers are not stable, correct? By using a path using either video for linux or udev you can guarantee that you always get the device you want.
@mjsobrep Hey, just wanted to give a heads up here. I haven't been very active as I'm pretty busy finishing writing my PhD dissertation, I hope @furushchev has a moment to also review your PR. Otherwise, I'll probably test and merge your PR when I have a bit of time off... worst case in a month probably. I think your PR will fix the issue you report here in a very nice way.
Thanks again for bringing this up and providing a simple and beautiful fix.
@awesomebytes Thanks for the heads up. Good luck on the dissertation!
@mjsobrep Thank you very much for contribution. The issue is now solved on #60 being merged.
Sure thing. Glad to help
When the connection is opened, the cod determines the video stream provider type using a try catch statement. The way this works, leads the code to think that path based descriptions of a camera, like:
/dev/v4l/by-id/usb-HD_Camera_Manufacturer_USB_2.0_Camera-video-index0
are for videofiles:Then the node will ask for the frame count and try to set the frame pos. Somewhere this leads to an error:
That prints for every frame (I think)