I've got this nearly working using two different methods, both of which currently have some advantages and drawbacks, but both of them aren't working the way I'd hope they would just yet.
Here's a WIP guide I'm building for running multiple octoprint instances on a single server which has the ffmpeg restreaming method I started out with.
This method has two drawbacks:
- The cpu power required is pretty high unless you get HEVC encoding working, which I haven't managed yet
- The octoprint instance will load the first frame of the mjpeg stream only. Manually refreshing is required to get any further frames
The other method I'm testing now is using VLC
I'm still working on the systemd service units for this, but after installing vlc and vlc-bin packages you can run this command in a screen session to test it out:
cvlc -R rtsp://<camera_username>:<camera_pass>@<camera_hostname>/live --sout-x264-preset fast --sout="#transcode{acodec=none,vcodec=MJPG,vb=10000,fps=5}:standard{mux=mpjpeg,access=http{mime=multipart/x-mixed-replace; boundary=--7b3cc56e5f51db803f790dad720ed50a},dst=:8990/videostream.mjpeg}" --sout-keep
and then putting into the octoprint config:
http://<octoprint_hostname>:8990/videostream.mjpeg
Good news is that this stream does work as expected.
The issue I'm having with this method is that I cannot for the life of me get nginx's reverse proxy to work. Here's the config I set up for it:
location /webcam_printer0/ {
proxy_pass http://127.0.0.1:8990/videostream.mjpeg;
}
when I try to access the new url, nginx reports a 404.
Once I can get either of these methods working properly, I plan to build a plugin for Octoprint to make it easy and accessible to everyone.
I'm also hoping to incorporate Intel's QuickSync (HEVC) and have been poking around with the concepts in this gist
