mjpg steamer issues and thoughts about octoprint-docker

[LongLiveCHIEF]

So we had some good conversation about this on octoprint discord yesterday, and I discovered I had the wrong idea entirely about how vanilla OctoPrint does streaming. I thought it was there by default with ffmpeg, and I was wrong.

Now that I've spent some time getting up to speed on how all this works, I am going to make mjpeg-streamer functionality part of the primary "stable" release target for the official octoprint/octoprint image.

Another thing that happened yesterday, is someone pointed out the nunofgs/octoprint octoprint image, and I was really impressed with that image. It has both multi-arch and mjpeg-streamer support.

I'm going to reach out to https://github.com/nunofgs and see if he'd like to collaborate or become a member of this org and become another maintainer of this project.

I think it would be great to combine our efforts and deliver more for the octoprint community together.

I am going to use the same approach he uses for mjpeg-stream and haproxy, but I am first going to look into switching to one of the linuxserver.io base images, due to the work they've done to build supervised multi-process images. (typically docker follows that you should have one container per process). (see https://github.com/just-containers/s6-overlay#the-docker-way)

[badsmoke]

Hello bbreton,

version 1.0.1 was built in x86,arm and arm64, always use the newest) ;-) .
I use even you raspberrys with ubuntu 18.04 and arm64, it worked fine there.

You could change it to a multistage build, but I have no problem with the current size.

I would not like to include ffmpeg, I am more of a proponent of it: one server per image

to the point of your default settings:
This is in the docker-start.sh

#!/bin/sh
set -e

FRAMES=${ENV_FPS:-"15"}
RESOLUTION=${ENV_RESOLUTION:-"640x480"}
PORT=${ENV_PORT:-"8080"}
LOCATION=${ENV_LOCATION:-"/usr/local/www"}
CAMERA=${ENV_CAMERA:-"/dev/video0"}

export LD_LIBRARY_PATH="/mjpg-streamer/mjpg-streamer-experimental"
./mjpg_streamer -i "input_uvc.so -d $CAMERA -f $FRAMES -r $RESOLUTION" -o "output_http.so -p $PORT -w $LOCATION "

so your settings are already being executed?

[LongLiveCHIEF]

In the long run, I think what we're shooting for is that you'd be able to attach other containers to the octoprint network for things like plugins/video/cura/etc.. (anything that isn't native and vanilla octoprint).

The other approach is that we create a build matrix (which the recent build refactor was actually designed to support so we could go that direction if need be), and wind up with a huge bevy of octoprint images with tags based on what features you wanted. That's probably not ideal for the user.

that being said, I believe mjpg is one of the most heavily requested asks, so it wouldn't be unreasonable to add it in, and allow an ENV var to specify which video provider the user prefers.

At the moment, we're working to look at the best approach to making OctoPrint more compatible with docker in general, so some of these types of issues are being held off on so we don't wind up making massive changes to existing user implementations if the container usage changes suddenly down the road.

For now, I'll add this to the official features backlog, and it will be included as a primary test case for the octoprint docker integration designs we're considering.

/cc @foosel