Request for Multi-Cam Support

[jalanjarosz]

Was wondering the possibility to add multiple-camera support.

Provide input for second camera and possibly a layout of side-by-side or over/under. Defaulting to a side-by-side would probably be best.

Multi-Cam support can be found in two different OctoPrint plug-in's: MultiCam and OctoSlack. I currently use OctoSlack and it combines snapshots into a single image and provides options for over/under and side-by-side.

[FormerLurker]

Hi @jalanjarosz!

You'll be pleased to know that the latest pre-release versions of Octolapse already support multiple cameras (including many DSLR cameras). Each camera used will generate its own separate timelapse. However, there are currently no options to combine these into a single video at the moment. You'll need to post-process your videos to accomplish this at the moment.

Check out this video where I used a DSLR + a webcam to create a multi-camera timelapse: https://www.youtube.com/watch?v=CQ6n3HF3hdY

Here is a link you can use to install the latest pre-release version (currently 0.3.4rc1) via the plugin manager (Octoprint Settings[wrench icon]->Plugin Manager->Get More->... From Url): https://github.com/FormerLurker/Octolapse/archive/v0.3.4rc1.zip

Here is a video explaining how to configure the new version (things have changed significantly since 0.3.1): https://www.youtube.com/watch?v=sDyg9lMqMG8

Finally, here is a video showing how to configure a DSLR, if you want to use one: https://www.youtube.com/watch?v=J5SskYwP5JQ

If you want to use multiple webcams, you will have to configure the streams (mjpegstreamer probably) separately. I have not created a guide for this yet, and in fact I'm not sure the best way to do this with OctoPi yet. The MultiCam plugin suggests that you dedicate a PI ONLY for your webcams, though I have been able to manually start a second stream on the same pi (rpi 3b+) and it seemed to work just fine. your mileage may vary.

After your new camera profiles are created in Octolapse for either a second webcam or a dslr, make sure you enable all of the cameras you want to use (Octolapse Tab->Expand Current Settings->Click the check box next to the camera profiles you want to use).

Let me know if that helps or if you have any questions!

[szafran81]

Setting up the cam streams is the problem. I run into this: libv4l2: error turning on stream: No space left on device Unable to start capture: No space left on device while trying to use mjpg streamer for a c930e and c920 at the same time. This is a problem for me since in the end I was planning to get a setup for 3x c930e and 1x c920 streaming setup. It would be a bummer if I was forced to do it by using a separate RPi (or similar device) for each stream. And don't even get me started on trying to use the hardware h264 codec on those cameras, which would be a great thing if it would work (10x less bw needed).

[FormerLurker]

@szafran81, this seems to be related to usb bandwidth. As a test you may want to try turning down the resolution/framerate on all 3 streams to see what the limit is.

FYI, the multicam plugin recommends using a dedicated RPI for your camera server, but I've been able to run 2x1080p streams + a DSLR without issue on my Pi3B+. One of my cameras was a c920, the other was a cheapo endoscope of unknown brand.

I'll toy with this to see what the limitations are, but please keep me updated with anything you find. Testing multiple camera streams on the host pi is something I need to do more of.

[szafran81]

My OP setup is on a nice Odroid XU4 with 2x USB3.0 ports - so the total USB bw is more than enough - from what I've read it's a software issue - something overreserves the USB bandwith. Just dug up one of my backup RPi 3's and I'll do some tests with a single c920 for now (my c930e is working with the OP setup). I should have 2 more c930e's in 2-3 days (just ordered some good condition used ones for a good price). When they arrive I'll have the HW on hand to test this. Even if it would be possible to run 2 1080p streams on one RPi 3 that would be ok, but I'm pretty dissapointed they don't work on the Odroid (and they should without problems).

[szafran81]

A bit of an update. After some reading, and reading, and reading... and so on. I've found something that's called Restreamer https://datarhei.github.io/restreamer/ and it works on Odroid, RPi's etc. Basically everywhere where you can install Docker. From what I've read untill now it is for restreaming h264 streams for web usage. Haven't tested it yet, so this is only my understanding of some text on the web. Going to put some test image on the Pi and try it out.

[szafran81]

Ok. So restreamer is out. It only gets the cam stream and reencodes it using ffmpeg. On c920 with 1920x1080x30 input I've got only about 5fps output. Maybe someone that's more into ffmpeg can do somethings with the command lines that restreamer used:

ffmpeg -thread_queue_size 512 -f v4l2 -framerate 30 -video_size 1920x1080 -i /dev/video -f lavfi -i anullsrc=r=44100:cl=mono -b:a 0k -vcodec libx264 -preset ultrafast -r 30 -g 60 -b:v 4882k -bufsize 9764k -acodec aac -map 0:v -map 1:a -shortest -f flv rtmp://127.0.0.1:1935/live/usbcam.stream
ffmpeg -stats -loglevel quiet -err_detect ignore_err -i rtmp://127.0.0.1/live/usbcam.stream -codec copy -map 0:v -map 0:a -bsf:a aac_adtstoasc -map_metadata -1 -metadata application=datarhei/Restreamer -metadata server=NGINX-RTMP -f flv rtmp://127.0.0.1:1935/hls/live.stream

[szafran81]

MotionEyeOS is also out for me. Should work fine for most with very little config. But with c920 at 1920x1080x30 setup I was getting only ~2fps output stream. After investigation I've found out that the only way for it to use any hardware help is when one is using raspicam. But then there is only 1 cam per device. Otherwise everything is pure software/CPU based, and reencoded (no direct streming h264).

[szafran81]

I'm a bit annoyed by this situation. It appears there is no simple way to redirect x264 stream from camera to html img. One can start streming the strem with something as simple as this: cvlc v4l2:///dev/video0:chroma=h264:width=1920:height=1080 --sout '#standard{access=http,mux=ts,dst=localhost:8080,name=stream,mime=video/ts}' -vvv But one needs a software (like vlc or mplayer) to play that stream. My knowledge about stream mangling in linux is to small to do anything about it. Would be great if some linux video guru could chime in.

[szafran81]

@FormerLurker I've managed 3 streams with mjpg_streamer on a RPI3 with 3x 1920x1080x10 - anything above 10fps and it wont do it. So a total of 30fps is max with mjpeg.

On the other hand using a Dell minipc (3020m) with an i5 on board I've managed 3x 1920x1080x30 streams no problem (but each cam had to be in it's own USB port on the machine - when I've connected them to a USB 3.0 hub only one worked - and yes I've tried options uvcvideo quirks=128), but this little thing is a "bit" pricier than a RPi.

[FormerLurker]

I've been doing a bit of issue maintenance (as I'm sure you are aware since you've been in a few of these threads already :), and I think this has been solved from an Octolapse perspective. Please let me know if you want me to reopen this issue, and you're ALWAYS welcome to create a new one. Thanks for your posts (all of them)!!!

[szafran81]

@FormerLurker Once again great plugin. Just a small req (nothing urgent). It would be nice if I could append to the file names of the videos the names of the cameras (instead of automatically appended numbers).

Eg. now I get those:

20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m
20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m_1
20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m_2

(I'm only generating videos from 3 of my 4 cams - soon to be 4 of 5 cams ;) - i'll be adding a cheap chinese 720p endoscope on the extruder assembly)

Would be great to get those:

20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m_Front
20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m_Back
20190814213428__PegBoard_-_Plyta_-_no_supports_x08___F1___Prusa_ABS__MMU2_0.20_20-___08h50m_Extruder

where "Front", "Back" and "Extruder" are the names I gave the cameras in the settings.

Or maybe this is allready available and I've missed it in the options ?

Best regards Szafran

[FormerLurker]

How does this look:

I have to say this was more difficult than I thought. It's very hard to ensure that the camera name can be used to create a valid file. Also, FFMPEG doesn't seem capable of working with unicode file names (they were silently reencoded and the resulting file name did not match was was expected, causing an error). As a temporary workaround I just replaced all unicode characters with an underscore, but that's not a particularly savory workaround, but I'll keep playing with it.

[szafran81]

Oh Man, that was a fast response. Thank you for that. Is that code allready available for testing ? My current long print will end around 8PM CET so I could test that with the next print that I have in my queue. I also rembered about something else that would be great to see implemented, but I think that should be in a separate topic.

[FormerLurker]

You can install the new version via the plugin manager with the following link: https://github.com/FormerLurker/Octolapse/archive/devel.zip

See this guide for info on how to install.

If you have any issues, please create a new issue. Let me know how it goes!

[szafran81]

Installed and running an overnight print. Thank you. We'll see what happens. Unfortunatelly I haven't had the time to regenerate my g-codes with verbose option i PS turned on. So It may be a bumpy ride ;) Will try to regenerate them tomorrow evening.

Coming back to reqs - it would be nice to have an option to set snapshot positions per camera. But I think it'll be a lot of work, so if you'll be willing to take a look at it some time in the future I'll create a new req topic so it doesn't get lost.

[FormerLurker]

@szafran81, I like the idea but there are several problems. First, it would really complicate the settings, but I think that would be solvable. Generating the gocde and acquiring the snapshots wouldn't be all that difficult. The part that prevents me from wanting to actually do it is that it would add to the snapshot acquisition time. That would reduce print quality (for some printers a TON), and I get so many complaints about print quality that I don't think I want any more of those :)

[szafran81]

I get that.

One could set the points to be the same for each camera an then it would make no difference for him.

I do think that if someone has quality issues then that person should first get thier hardware setup fixed to work perfect and only then add another software layer of g-code manipulation.

Just my 2 cents ;)