Hi, Ben!
h264 encoding is computationally intensive task, but you can experiment with resolution, FPS and other settings to encode dual cameras at once.
There is a Systemd unit file called ‘ffmpeg-hls.service’. You can copy it for the second camera. Streaming source and parameters are defined in it. Good news are that you don’t need two HTTP servers for this, just one NGINX. Simply use two different directories.
Hi, I got this working on my RPI-4 running OctoPi v0.18 and I can see the stream within the OctoPrint control tab. For some reason no matter what I do I cannot get the Dashboard plug-in to see and I just get a broken link icon, but that's not why I am here.
Can I set a different resolution and frame rate, e.g. my camera in config.txt is set for 720p 10fps?
Yes, you can, but for now HLS settings are not controlled by ‘config.txt’.
- Edit ‘/etc/systemd/system/ffmpeg-hls.service’.
- ‘sudo systemctl daemon-reload’.
- ‘sudo systemctl restart ffmpeg-hls’.
- ‘sudo systemctl status ffmpeg-hls’.
I think you can figure out the details yourself. 
1 Like
Hi All,
Very happy with all what all are doing. This is amazing. Just to tell before raising an potential issue here.
I'm a beginner on 3D printing, octopi, octoprint. That's a lot, so forgive me if I am writting something totally off:
while moving towards more securtiy on my octopi (0.18), I am facing NGINX service failure at start apparently caused by the absence of /etc/octopi_streamer/hls folder or file. This can be fixed if camera_streamer option is set to hls in octopi.txt.
The things is that due to current stage of development of HLS, I would like to still be able to use mpjpeg.
I can confirm that I could (dirty) fix this by:
a-manually creating this folder, then nginx can start flawlessly. but this is gone for next reboot
or
b-permanently overriding nginx below service variable (which is inheritated from ffmpeg_hls.service, I guess?):
[Unit]
Description=FFMPEG HLS webcam streaming service
ConditionPathExists=/etc/octopi_streamer/hls
Is above diagnosis correct? Is there a cleaner way to do overcome this?
Beside my NGINX challenge (fixed in an ugly way), I saw that anyway ffmpeg_hls.service is reported as failing due to missing path, no idea what is the logic using octopi.txt options but I guess this is not your preference.
if it helps:
admin@octopi:~ $ sudo systemctl status nginx
● nginx.service - NGINX server for serving HLS and JPEG frames
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
Active: inactive (dead)
Condition: start condition failed at Thu 2021-03-18 18:58:58 GMT; 8min ago
└─ ConditionPathExists=/etc/octopi_streamer/hls was not met
Docs: man:nginx(8)
Finally had a chance to revisit this and happy to report I got it working - unfortunately my RPI4 gets a little on the warm side when I switch to 720p which is what I have the MJPEG stream set to although it's at 10fps whereas HLS is 30fps - but it's nice and smooth. I did try to knock down the HLS fps to 10 as well but that worked for about 2 secs before the whole image becomes corrupted. Perhaps I need to tweak some of the other parameters, and the obvious ones that were still 30 made no difference when set to 10 as well.
So for now I have switched back so save my poor Pi from getting cooked just at idle - and yes it has a fan..
Thank you, Toamyn.
Yes, h264 encoding is a computationally intensive task, and the board will inevitably become hot, and power draw will be increased.
However, the issues with 10 fps HLS look unexpected. Have you set 10 fps for both resolutions we have in the stream?
Sorry, the service design is experimental., but thanks a lot for testing
ffmpeg_hls service is supposed to be started only if /etc/octopi_streamer/hls path exists. The path is created at boot by a oneshot Systemd unit (“service”, I dont remember its name), which checks a configuration file.
1 Like
After first only changing the fps on the line with the resolution which I set to 1280x720, the next attempt I replaced all the values of "30" with "10" and still no different.
Perfectly understood and thanks for spending your personal time and energy on developing gorgeous features ;)... it was more to raise this for cleaner integration when it will be more mature, and help those who may face same challenge with NGINX or any other service that looks into HLS service conditions, as it is quite manageable even by a rooky on raspbian/octopi like me.
1 Like
Let me try to reproduce when I will have time. It can come later than sooner 
Sorry for my ignorance...but how are you guys testing this?
I changed the following line in octopi.txt:
camera_streamer=mjpeg
to
camera_streamer=hls
What else am I missing?
I think you need to change your stream url in OctoPrint's webcam settings to /hls/stream.m3u8 and the snapshot url to /jpeg/snaphot.jpg (not 100% sure on this one).
/jpeg/frame.jpg
For the snapshot. Found it up the thread
Hi - Awesome work nad thank you for your effots on this plugin and I have managed to get my Creality USB camera working with this. Any ideas on how to reduce the lag?
Im running it at 1920x1080 at 30frames. RPI3B+ - CPU ~ 44%.
Current lag is ~ 3 secs
Thanks
That's the nature of this implementation, as it has to store the images in order to serve them, and to be fair 3 secs is way less lag then what I was seeing of ~30 secs.
Ah I did wonder. I assume ffmpeg should be able to serve directly as well if I try this manually right?
pretty sure the nginx proxy is necessary to middleman the stream and handle timings, which is built into the octopi 0.18 image.
Thanks. Have been researching several alternatives but there isnt any that I can see which are easily implemented that wont produce a lag of less than 3secs. This implementation does work really well but always keen to see if I can get it lower than 3secs.
You can’t make it 10x less, but ypu can experiment with ffmpeg settings, specifically with ‘hls_time’ setting. Please not that it has to do with frame rate and frequency of key frames, it means that in each segment there has to be at least one key frame.
Here is the file:
To apply changes, you have to reload a systemd service, learn here: Systemd Essentials: Working with Services, Units, and the Journal | DigitalOcean
Yes, ffmpeg can stream directly, but I don’t know a way to stream it to the web page.