We got internal data stream error when using gst_loopback even a dummy /dev/video* is created and is assigned by v4l2loopback.
By following this nice tutorial, both ptpcam and gst_viewer works well.
But we stuck on gst_loopback, it outputs below error:
start, hit any key to stop Error: Internal data stream error. stop
Seems like we are very close, one step to get it working, were wondering if any one got the same issue.
Our desktop testing environment is Ubuntu 18.04 LTS, with Linux 4.15.0-118-generic, x86-64
Camera is Theta V with the firmware 3.50.1
If you moved the camera around to different systems. Reboot the camera. Hold the power down for about 15 seconds and then reboot it while it is plugged it. I sometimes have problems if I have the camera plugged into one system and then move it.
Please confirm and report back with additional errors. It should work on your system.
Craig, thanks for your reply. We have double checked lsmod, /dev/video1 (we have one existing webcam), added qos=false and reboot, and tried exclusive_caps=1 or 0. But internal data stream error is still there. We have two linux systems getting the same error.
As far as we know, the error message is from v4l2loopback, a most related discussion and a potential solution was discussed below:
Before digging into above, we are getting one more theta V to double check it’s not caused by the specific camera.
Note that the reason is says, “Off” next to the GeForce GTX 950 is because the “Off” refers to Persistence-M (row above). It does not indicate if the GPU is enabled or not. In this case, the driver is the proprietary Nvidia driver 450.66.
The v4l2loopback does not work on all systems.
There is a small note on the README.md for libuvc-theta-sample with potentially big meaning.
If you have an nvidia graphics card, you may need the nvidia plug-in for gstreamer, which I think is in the “plug-ins bad” group, but appears to work. I got this information from someone that is more knowledgeable about gstreamer than I am.
In my case, I don’t really understand gstreamer, so I installed everything.
Note that I normally use the nvidia driver. I switched over to nouveau after I saw your post to try and test it. I did basic testing with the nouveau driver and the THETA. It appears to run about the same.
i get a slightly different result on my nvidia NX and generic ubuntu 18.04:
nvidia@nx:~/build/libuvc-theta/build$ ./example
UVC initialized
uvc_find_device: No such device (-4)
UVC exited
also note that i do not see any /dev/video* devices but lsusb shows:
nvidia@nx:~/build/libuvc-theta/build$ lsusb
Bus 002 Device 002: ID 0bda:0489 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 13d3:3549 IMC Networks
Bus 001 Device 005: ID 0c45:7403 Microdia Foot Switch
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 006: ID 05ca:0368 Ricoh Co., Ltd
Bus 001 Device 002: ID 0bda:5489 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
i tried that as well. it calls the you modified libusb and returns “THETA NOT FOUND”. lsusb recognizes that the camera is connected, however there is no /dev/video* device whatsoever.
The ID you posted from the camera is 05ca:0368. Note that my ID is 05ca:2712 Either the computer is not detecting the camera in live streaming mode or the camera is not functioning properly in live streaming mode. If the ID is not 2712, the application will not find the camera.
An ID of 0368 may indicate that either the camera is "off’ or the computer is not detecting the camera accurately. If the camera is on and in Live streaming mode, meaning the ID is 2712, you should next consider changing the USB cable or switching the USB port. As long as the ID is detected as 0368, the sample gstreamer app will not work.
In the header file, you can see that the app needs to find 0x2712 (THETA V) or 0x2715 (Z1)
Please feel free to post again. This is new stuff for everyone. You don’t need to hold back.
Unlike a web cam, you need to manually turn the THETA on and physically press the “mode” button on the side of the camera until you see a word, “LIVE”. For the word, “LIVE” to appear, the camera needs to be plugged into the computer with a USB cable. It will not appear if it is not plugged in. The cable itself may also not be functioning. If you have a USB adapter on the computer, it may be incompatible. It’s also possible that security software on your computer may be interfering with detection.
Although you can turn the camera on and switch it to LIVE mode with the USB cable, it does not do this by default.
If you are building something like a robot where you need to power on the camera from the robot, please post again. We did a test here to show that it is possible.
thanks. i did not know that i had to put the camera into “live” mode first. after doing that, i get a little bit further with ./gst_viewer, but all i get is a pure red display. also there are still no /dev/video* devices.
also, is there a way to control the camera via the USB interface as opposed to putting it into live first?
If it works with gst_viewer, you will also need to the change line 188 to match. It is possible that gstreamer is not auto-detecting your video system and you need to specify the video sink and decoder.
The gstreamer pipeline line above is specific to NVIDIA Jetson. If you do the same test on x86, you will need to change the line back to autodetect or specify a pipeline specific to your setup.
Getting /dev/video0 to work
If you are using a Jetson, you may have only one video device on your system. If this is the case, change line 190 to device=/dev/video0. This is a case where you do not have another webcam on your system and the THETA is /dev/video0
There is a detailed video on this process at the linux streaming site.
summary:
$ git clone https://github.com/umlaeute/v4l2loopback.git
$ cd v4l2loopback
$ make
$ sudo make install
$ sudo depmod -a
$ sudo modprobe v4l2loopback
verify that you have v4l2loopback installed
Post a screenshot of the output of lsmod.
Now run gst_loopback to pipe the video from the sample app to the loopback device. You should now able to use things like OpenCV on /dev/video0
Feel free to ask additional questions. We are happy to help you.
USB API
There is detailed information on using the USB API on the Linux streaming site. The process is involved. The basic steps:
install libptp2 from source. You will like need to install libusb-dev with apt.
run ldconfig with sudo ldconfig. Note. hopefully, /usr/local/lib is in your library load path, which it should be by default on JetPack 4.4 and likely earlier versions too.
set to live streaming with the command below.
$ ptpcam --set-property=0x5013 --val=0x8005
If you want to switch the camera back to still image to take a detailed shot, it is
$ ptpcam --set-property=0x5013 --val=0x0001
You can also do the following:
put camera to sleep
wake camera from sleep
turn camera power off
turn camera power on
Let me know if you want to schedule a 15 minute or 30 minute Google Meet video conference or Zoom call. I am in Palo Alto, California. I can answer basic questions. I am not an experienced developer, but I have some knowledge of the camera due to using it and getting information from people on this forum. Be aware that I don’t work for RICOH. It’s likely that you want to get past this stage quickly and focus on AI or object detection stuff and that you’ve just received the THETA. There may be basic RICOH THETA-specific information that could help. Happy to continue to answer questions on this forum as well.
Have my Theta V and Jetson all up and running due to the great work of the contributors. gst_viewer works perfectly, lsmod shows v4l2loopback and I have a /dev/video0
However the following ($OUTPUT is a YouTube URL and secret key)
Another member posted information using gst-rtsp-server.
I see on stackoverflow that someone is using rtmpsink with gstreamer to get it to YouTube. This was back in 2015. There may be a better solution now. If you get it working with gstreamer, please post your pipeline.
I have gst-rtsp-server working on a Jetson Nano and can help with that if you have problems. I think I compiled it from source using the specific version of gstreamer that came with JetPack 4.4. I don’t think it was the newest version. I think I took notes. I hope I did…
Note that I moved the topic to this topic as there is at least one other person working on the same ffmpeg problem. The search on this forum is not that great and things are difficult to find.
In community tests, gstreamer was not able to automatically detect the decoder and needed the specific decoder and sink. The line below should also be usable on the Nano, so you should be able to use the same test for both Nano and Xavier.
"nvv4l2decoder ! nv3dsink sync=false"
The Xavier is better for testing the THETA. If you are going to use the Nano, you may want to change the line below to THETAUVC_MODE_FHD_2997. I am using a Nano in my tests. However, this is mainly because I don’t have budget for a Xavier as RICOH isn’t providing funds for this type of test equipment. If you apply AI processing to the stream, you may have a better experience with Xavier, especially if you need the high resolution frames for detection.
For me, the output freezes.
gst_viewer works fine.
for the first couple of seconds, that gst_loopback runs the output is normal
VLC, OpenCV and FFmpeg all can receive the stream from video2 normally for a couple of seconds.
Then it freezes and only updates every couple of seconds.
I also coupled it to ROS before using Gscam and to VLC using the rtsp-server example someone above showed. This gave the same result. From the ROS messages, I can see it first receives consistent messages and then only every couple of seconds.
I use Ubuntu 18.04 on a ThinkPad P1 Gen 2.ifconfig
Processor: Intel® Core™ i7-9750H CPU @ 2.60GHz × 12,
Graphics: Nvidia Quadro T1000/PCIe/SSE2.
As far as I can tell am running the exact code from the examples.
I am new to Gstreamer, V4l2 and MTP though, so maybe I just oversaw something obvious.
What do you think the issue might be? I suspect something along the lines of memory or buffer handling and that maybe the pipeline gets overloaded somewhere, but I do know how to check for this.