Please consider adding native support for multiple camera streams/streamers.
The streamer itself could remain external to Octoprint as it is now. Consider adding a more integrated approach to the stream handling with the option for more than one camera.
I find that the classic webcam handling is dealing with the termination of streams very well, while Multicam and other plugins, etc. keep the streams open and running to the point of causing high network load and occasional USB communication problems.
Might be a good idea to at least report what your experiencing on the Multicam plugin's repository on GitHub. I'm sure that @crysxd would be able to help figure out why this might be happening as well.
Technically it shouldn't be horribly hard to add support for more than one webcam in the classic plugin. The data structure is already there, I'm just not sure if you can expose the same template multiple times. Do you know @jneilliii?
I see the same problem using TCP/IP with Multicam and the non webrtc streams.
BTW: If I kill the stream service for one of my cameras, then I can force the streaming to stop by selecting the killed stream in Octoprint / multicam. That immediately stops the high network utilization.
Thanks to the advanced settings for killing streams in the classic webcam interface this does not happen even if I am using the new stack.
I think this is generally not clear, looking at @opjose response.
What @opjose linked can't be solved by adding multiple cameras to the classic plugin, this is a bug in the WebRTC server. Generally there are two sides to the webcam: The server and the user interface. The user interface is what the classic plugin is, the server can be any compatible server. The interface is responsible for stopping the webcam if it's e.g out of view because the user changed the browser tab or the tab in OctoPrint's interface. Every plugin can easily make use of the classic's logic here by simply hooking into the webcam visibility callback: https://github.com/OctoPrint/OctoPrint/blob/a93b4d397248dc406a75e634c1326fb1b8ddcb63/src/octoprint/plugins/classicwebcam/static/js/classicwebcam.js#L58
The browser itself is responsible for stopping the webcam when the browser tab/window is closed. The webcam server is responsible for recognizing a broken connection (because connection was closed by interface of browser) and then stopping to send data. This is what doesn't work here seemingly for this webcam server.
Adding multiple webcams to the classic plugin is possible, but this doesn't solve the issue here. Firstly, it does not support WebRTC, which is a deliberate decision because every WebRTC server needs a different handshake. And secondly the only part that makes the classic plugin "special" according to @opjose is the good cancelling of the stream, but every plugin can easily make use of this (in fact it's far easier than writing this logic yourself)
That's only assuming the classic webcam plugin isn't disabled if I'm not mistaken? With the multicam plugin you don't use the classic webcam so with it disabled those hooks/callbacks aren't available.
This is part of OctoPrint, so any plugin can use it, regardless of the classic plugin.
Looking at the comment from multicam, the problem seems to be that the plugin exposes multiple webcams but there is only one VM? So the VM gets the callback for all webcam displays? That's at least my interpretation.
The suggestions both seem to be a reasonable improvement. Alternatively the plugin would need to use one VM per webcam, but that loops back to the question for @Charlie_Powell how a plugin can expose the same template multiple times and if this is possible with multiple webcams
To respond to a couple of specific points & where I've been specifically asked first:
I cannot think of any technical limitations with the templates that would mean you could not show the same template multiple times. It should be possible. If it is not, then something that OctoPrint does in manipulating the template configuration when it collects all the plugins templates is the problem - you can render the same template in Jinja no problem.
Actually calling the hooks is done from the 'Control' viewmodel, the link is an example of how the Classic Webcam plugin responds. OctoPrint's control tab has the webcam visibility logic baked in to it, tells Classic Webcam to either stop/start streaming and then classic webcam loads/unloads.
My position on the overall issue is that I would rather fix/enable the multicam plugin to work properly. The request basically boils down to the plugin having a bug, so please can OctoPrint do it itself so it works properly. OctoPrint is not immune from bugs, and while it's very stable these days adding more and more complexity to the hands of the same people (and generally, just Gina) is not going to mean it necessarily remains this way. I don't think there would be any shortcuts, all the logic would have to be migrated. And it might not even "just work" for the same reason.
The comments in the MultiCam plugin @jneilliii highlighted seem valid from my intuition. The same viewmodel is being bound to each template, so when the visibility is changed the viewmodel does not know what is going on because all the webcams end up calling the same visibility option. So when OctoPrint tells MultiCam to stop streaming, multicam has no indication of which webcam is currently selected.
I don't currently have time to solve this issue, but I can see there may be two potential solutions - either OctoPrint is updated to pass through the ID of the webcam to disable, or the MultiCam plugin binds a different viewmodel to each webcam. It may even be possible to do this programmatically, without writing complicated code. I'd love to sort it out, but I can't currently.
I was trying to think of a plugin that actually does this but was coming up blank. There aren't too many that do complicated ko bindings, but in this scenario it might require a programmatic internal ko.applyBindings (with second parameter identifying the id) in onAfterBinding with a foreach loop generating the containers specifying a ko bound attr for id for each camera.
Then just now after thinking through that logic did a search and seems telegram is doing something like this.