Open Komak57 opened 5 years ago
Thanks for the thorough report, I'm assuming this is a compatibility issue between mjpg-streamer and Ubuntu's version of v4l2. It looks like its a problem with the YUV capture mode only, since I guess when the C920 works it's working in JPEG mode.
Are you able to get a valid capture (e.g you can watch it) from the Sonix 2.0 Camera in another app, e.g. ffmpeg?
Actually, scratch that.
The input_init message is because it doesn't recognize one of the options you've passed (error could be clearer there).
I expect you've built mjpg-streamer without libjpeg causing it to not support YUV mode (again, error could be better, we probably shouldn't try YUV mode automatically if we can't support it).
Can you make sure you have the
libjpeg dependencies installed (see readme.md) and do a make distclean
before building again.
Can confirm that FFMPEG can pull data from 0c45:62c0 Microdia Sonix USB 2.0 Camera. Can confirm that libjpeg8-dev is the latest version (8c-2ubuntu8) before recompile. Wouldn't originally compile without it.
Note* Running the c920 AND the USB 2.0 Camera simultaneously appears to be impossible at the moment?
I'd also like to note that, in the compilation, only input_file.so
, input_http.so
, and input_uvc.so
appear to be built, while plugins/input_opencv
DOES exist.
After a recompile with make distclean
everything appears to be working. Including quality options for both the USB 2.0 and c920.
I can confirm having the same issue, with the same symptoms, and also the same result of a 'make distclean' plus a rebuild producing a working executable.
This was on a LMDE 3 Cindy system (Linux Mint Debian Edition).
In my case, the error was quite confusing, as all of my cameras supported both MJPG and YUV modes. So they would operate just fine in the "normal" case, it was only when I added the '-y' parameter to switch them to YUV mode that I received the cryptic input_init() failure response. So it really did appear to be a command line option/parameter issue, but I double-checked it about a hundred times of course before my web searches led me here.
Is the lack of YUV support something that could be detected, and a different error message provided to the user when this condition occurs?
Yep error message should be better.
I believe this happens because you build for the first time without the libjpg dependency installed. CMake caches that you don't have it so any further builds would be without it untill you do a distclean
.
I want to make this obvious but not sure how, without running make
forcing a distclean each time, which would be non standard. Perhaps I can cause make to output some useful info when building without libjpeg...
I'd like to report I had this same issue on a RPi4 with Buster (2019-07-10).
During my first build it was reported libjpeg.h could not be found, I install libjpeg-dev
and carried on with the build, resulting in the same errors as above. To get it working, after installing libjpeg-dev
, I deleted my build directory, reran cmake
, rebuilt and it worked as expected.
Thanks for the tool, I looks really great with a (even low end) camcorder and HDMI>USB3 capture card.
First, "make clean && make uninstall", then, "make && make install", and finally, remember to add the "-y" command to the start.sh
This error appears to happen a lot with mjpg-streamer, and with different cameras (Tested with c920 and Sonix 2.0 Camera).
For now, we'll discuss the specs and issues, and some of the remedies I've tried for the 0c45:62c0 Sonix 2.0 Camera, which refuses to work.
OS: Ubuntu 16.04.6 [4.4.0-142-generic] CPU: AMD FX-4100 Quad Core GPU: Radeon HD5670 CAM: 0c45:62c0 Microdia Sonix USB 2.0 Camera MJPG Streamer Version: git rev: 501f6362c5afddcfb41055f97ae484252c85c912
mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x1024 -f 9" -o "output_http.so -p 8080 -w /var/www/mjpg-www"
This is where we start doing some debugging. Adding -n to the list fixes most of the errors, but we still Segment Fault.
So it looks like it doesn't support MJPG, so let's take the advice and use -y (--yuv)
First instance of the input_init bug. Let's try some other settings that also seem weird.
Let's also try to use a different input codec...
It was here that I went through a few different guides between Raspi, Octoprint, and mjpg-streamer and added LD_LIBRARY_PATH=. (while in the make directory) before AND after compiling. No change. Added direct path, still no change. I found a compatibility list that says it should work with
-r 320x240 -f 5 -y
but we run into the same input_init() issue.I've also copied the output_http.so and input_uvs.so to /urs/local/lib and set this directory to the LD_LIBRARY_PATH to no avail.
So let's check FFMPEG and see what I can see from there?
At this point, I'm left with the conclusion that something is horribly wrong with my mjpg-streamer compilation.
Some additional information, using the Logitech c920, I can get video without a segment fault, but then I run into problems trying to get good quality from the camera at 1080p, and using -y or -q repeats the input_init() bug.
I have a similar setup using a slightly newer USB 2.0 camera on a raspberry pi (motioneye), and I have a bigger problem with USB bus speeds than compatibility issues, but it uses a different branch of mjpg-streamer for ARM devices.