-
-
Notifications
You must be signed in to change notification settings - Fork 248
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
Feature Suggestion: MJPG-Source Support #2
Comments
I have not needed to add support for the MJPG, but I will try to do it for you :) |
Not for me per se, for all of us out there who'd want a little more choice than just mjpg-streamer...
|
Done 1541921
|
Thanks Maxim, great work, latest master working here:
It seems ustreamer consumes a little more CPU than mjpg-streamer does with similar settings, is there maybe any kind of re-encoding happening or any other idea why? I'll wrap a small ebuild around it to make it easy for gentoo users to use as well. |
Try option |
I'll try to pin the workers and see what that does, gentoo ebuild is ready, shall I just paste it here or do you rather want a PR?
|
It doesn't matter to me |
ustreamer-9999.ebuild
|
By default ustreamer spawn one worker per core for parallel compressing. In some cases, this may provide an additional overhead but you can adjust this parameter to reduce cpu consuming. |
ye, thats what I thought. My question is only, why does it need to compress? the data coming from the cam is already compressed MJPG, is it not? |
True, but no compression occurs. I think that the cpu load is associated with a large number of workers. Regardless of the compression method at least one thread is spawned to process data from the camera. It seems that 17 streams were simply trying to read the data from your camera in sequence. |
Try to add |
No real change that I can see. I was testing idle (about 10% cpu) and with a client (about 25%). |
One of the differences with mjpg-streamer is that ustreamer always reads the data from the camera, regardless of whether there are any clients who are looking at the stream. The main reason is that the usteramer was designed to use with a separate broadcast control daemon (https://github.com/pi-kvm/kvmd, https://github.com/pi-kvm/kvmd/blob/master/kvmd/apps/kvmd/streamer.py). I assumed that if there were clients, this would launch the ustreamer; after disconnecting the last one, it would kill the process. Therefore, in an inactive state, my program consumes more cpu time. However, if there are clients, the result should not differ significantly from mjpg-streamer. |
Show me |
@chron0 Is the problem with CPU still relevant? |
sorry... busy week - well, it depends, it clearly consumes more CPU than mjpg-streamer. For me, in this setup it's no problem at all, I've got plenty of resources on this machine. It would be great to be lean on all arch's but I guess it's fine if it performs well on small-scale/embedded devices.
I think it's always worthwhile to investigate room for optimization :) |
I need more statistics. Let the ltrace work for about 30 seconds without clients Optimization is a necessary and good thing, although the ustreamer was primarily designed to fully utilize the available resources for maximum image quality and fps. I use it on raspberry pi to encoding and streaming fullhd video with 24 fps. |
I din't stop it, it stopped automatically once it started the worker. I was surprised to see it finish so quickly but I haven't used ltrace thus far. Maybe we need additional parameters to keep running and tracing the worker? Update: I've played around with ltrace a little more, using -f or attaching to a running instance via -p. In all cases it seems like ustreamer gets killed in the process. At this point I suspect my kernel missing some debugging facility but I've got no prior experience with ltrace to refer to :/ |
What kernel version you use? |
|
That's strange. Could you use perf and attach perf.data?
|
The situation has not become clearer, but I have one hypothesis. Do you have another camera? Not so cool :) Will the problem be reproduced with another camera? |
hmm, I don't think my other webcams do mjpg, only YUV - I do have one of those HDMI/USB UVC adapters I haven't tried yet - I could rig my big cam to it and try to capture from there, maybe it will do mjpg, let me see if I can rig another test setup up. |
Usually video capture devices don't know MJPG but I would be interested to see if I am right. In contrast, almost all even the oldest cameras supports MJPG. Also I started to do an option that reduces the CPU usage if there are no clients looking to stream. |
Try to use fresh version from git with option |
@chron0 could you try the latest version? |
BUILD
RUN
LOAD It's even less load when idle (highest thread tops at 2.2%). I think I'll redo the setup and use a little gl.inet with an openwrt and attach it directly to the cam to get rid of the USB connection between the cam and my client. That'll give me an opportunity to test it on small non-x86. This is a great improvement. Thank you for your time and effort you put into making and improving it. |
Thanks for testing! I think this issue can be considered solved. If you have more suggestions or requests for improving the program - I will be glad to hear them :) |
See #4 :) |
Also use option |
Nice) |
very! :) |
* Setup guide for H.264 * Phrasing, structure * Remove MJPEG primer and rewrite intro * Link to library files directly * Adjust page title * Remove todo * Resolve todo (Janus setup) * Comment all JavaScript * Rephrase to use active voice, clarify details * Phrasing and clarifications * Write backend instructions * Grammar * Use generic URL with port number * Use consistent terminology * Use term “V4L2 device” to refer to the video device * Link “building” section of uStreamer README * Use active voice * Change page title to “demo” * Add comment about the `janus.js` library file * Use window location to construct server URL * Move `videoElement` variable closer to it’s usage * Elaborate why we clone the media stream * Drop obsolete `WITH_OMX` option * Correct path of shared object file * Fix shadowing variable of same name * Send `start` request to avoid (harmless) `400` response * Add `refcount.h` fix Co-authored-by: Jan Heuermann <[email protected]>
I was looking for mjpg-streamer alternatives and found ustreamer. I've played a little with it now and like it so far but without being able to use the MJPG source stream of the cam, my max fps is capped by the cam itself to 5 fps. Only the MJPG stream delivers FHD@30fps. I'd really love to try it again if you get around to teach it to also just forward the MJPG stream coming from the device. Building itself went without issues and it runs smoothly here. Thanks for sharing.
The text was updated successfully, but these errors were encountered: