Can the new cam stack handle RTSP? Is backup-reinstall-restore _really_ the only way to get the cam stack?

Get Help Webcams
1

Camera model

VIP TZC3MV167W00251 for example (ONVIF RTSP security camera type - fairly generic, various others may be utilised, all of which were intended to be accessed by rtsp until discovered a lack of support)

What is the problem?

Lack of support

What did you already try to solve it?

Investigate RTSP support, been astonished at the archaic mjpeg foundation for webcams, explored plugins for options, researched rtsp solutions, all of which refer to mjpeg transcoding (astonished again) discover there is a different cam stack, (woohoo), I'll probably be able to leverage that with an update, discovered just updating is apparently not an option.

Have you tried running in safe mode?

Not Applicable

Did running in safe mode solve the problem?

Not Applicable

Systeminfo Bundle

You
octoprint-systeminfo-20240818125152.zip (1.3 MB)
can download this in OctoPrint's System Information dialog ... no bundle, no support!)

WRITE HERE

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

x86-64 deployment of octoprint on ubuntu 24.04 in proxmox virtual machine HA environment leveraging usbipd (USB over TCP/IP) connectivity to printer with pi4B exporting printer USB over ethernet/wlan failover bond, with the same pi also handling a touch screen running octodash, and the intention of exporting cams (USB or Pi cams) over network via h264/h265 RTSP * this last aspect just hit a brick wall.

It's basically an ethernet connected printer with a thin client touchscreen and rtsp cams managed by octoprint running in a private proxmox cloud.

Super happy with the deployment (used octodeploy) and solution development right up until I looked into enabling web cams and was astonished by apparent mjpeg dependency.

Intending to write up a high-availability octoprint howto when solution is complete. Version 1.10.2, don't recall any dialogue re: new camera stack from deployment tool; if I was presented with one and it's labelled as experimental I probably declined.

Not keen on reinstalling, have a philosophical objection to the popularity of rebuilding as an easy (lazy) solution (often just hides a problem and destroys evidence of it instead of understanding it), particularly so as I'm making good progress on a bespoke installation type and would prefer not to go backwards by actioning some kind of uninstall and re-deploy (I have more to configure here than just octoprint)

Any suggestions? Wait until modern camera support is available? Should I just do without camera integration for the time being if I don't want to redeploy, or is there another option I'm missing?

Yes I'm a noob octoprint user. Yes I'm aware the config I've just described will trigger some people to berate me for doing something they consider wrong. Hoping we can focus on the solution and present an option that isn't some kind of redeployment. I'm not here to justify deployment decisions to naysayers, I'm looking into more advanced cam support. Sorry, please don't take offence I'm just keenly aware that if I'd asked in forums how to do this deployment I'd have received a torrent of "don't do it that way!" by people with little imagination and often less experience. That would be true of the vast majority of support forums in my experience.

If we can't do something other than redeploy I might handle cameras independently of octoprint until camera support is modernised in stable.

I do understand that for the vast majority of octopi users a redeployment makes sense. I do understand what I'm asking is probably outside the support norms.

I am surprised at the camera stack support state, mostly I'm just looking for options that don't involve one step forward two steps back.

WRITE HERE

2

I suppose I could still export the streams as RTSP from the printer's pi4 or IP cam and temporarily use an mjpeg transcoder on/next to octoprint in proxmox and cringe at the bandwidth/cpu inefficiency/perceived crudity of the solution until stable cam stack comes around.

Am I assuming too much that RTSP h264/265 would be an option with the new cam stack?

Am open to suggestions as to what will work with the new stack if RTSP IP cams remain unsupported, bearing in mind that RTSP standard security cameras are readily available on-hand hardware that I want to be able to use.

there seems to be rtsp support in libcamera from reading I've just done, which I've not yet explored yet, so I'm hopeful new cam stack will support some bespoke configs that differ from the common usb.

Would very much prefer to be able to patch my installation than backup and redeploy.

3

I'd also be very happy to test and document RTSP source camera configs in due course.
Skimming through the camera-streamer documentation so far, it would seem if I'm not redeploying I need to get the camera-streamer.service installed.

I'm finding the /boot configuration file location an odd choice. I'm sure there's a good reason, it just seems strange, would appreciate some enlightenment on the reasoning for that.

Looking into the camera-streamer installation. Compile from source might be necessary as my libcamera version appears to be 0.2 and github says camera-streamer precompiled against 0.1 and I imagine there may be dependency issues with ubuntu 24.04

At this stage I imagine I'm not going to need to do any transcoding just relay the rtsp source through camera-streamer if that's doable, so I'll see if I can get the dependencies installed/compiled and configured to be happy in my current octoprint deployment. It doesn't seem like it should be particularly difficult but that might be famous last words. :joy:

4

Well having dug through more documentation, I'f I'm understandings things correctly, camera-streamer won't help me either for IP cams but I can run it on the "thin client" octo-dash and usbipd hosting pi to export USB and/or CSI cameras.

RTSP source cameras are not supported in new stack either, but what IS supported in the new stack is WebRTC and h264 (265?) encoding which will be extremely welcome once it's in stable. Yes mjpeg was easy back in 2013 but personally I stopped using it years ago because it is horribly inefficient.

To use IP cam with old stack, it seems I need to transcode to mjpeg stream on any host on the network, pi or otherwise (and cringe).

To use IP cam with the new stack then it seems the same is necessary, although I probably don't need to transcode as such - it's already h264 or h265, it just needs to be encapsulated in WebRTC. That does get described as transcoding around the traps, but I suspect it wouldn't really be doing much with the media stream except demux/remux into WebRTC.

It's such a useful feature (webcam) to be integrated in octoprint I'm inclined to suggest that in addition to the USB/CSI support, some kind of RTSP/IPcam WebRTC relay be included as the new stack matures and web interface configuration integration be expanded a little.

One other observation is the deployed codebase is in no way tied to any particular type of hardware. The codebase is processor and architecture agnostic.

So why on earth is the support environment and update procedures and documentation all pi-centric?
I get that the majority of users are pi users. Hell even I am I'm just not using it the way you might expect... you could be supporting the userbase without onboarding the architecture specific social environment.

It's a great piece of software, I'd suggest it'll be a lot better when you start packaging it properly with apt support etc, which would immediately solve the (slightly ridiculous) situation I have of needing to find a completely undocumented procedure to convert my x86 old-cam-stack deployment to new-cam-stack.

Generally the only time I would reinstall these days is when a product is end of life (it's permanently shut down), it's been security-compromised, or it's suffered an irreparable filesystem failure. Everything else is in-place maintenance.

Reinstalling an entire OS as a solution for an application upgrade is absurd, and the pi-centric support focus which seems to be born of the social environment and NOT the codebase seems to mean that a perfectly functional x86 deployment doesn't have a clear path forward.

I'll soldier forward when I have the time to focus on it, I'll definitely try to find a new cam solution that isn't a bare-metal rebuild; It's not the end of the world if that's the way forward but it's inflexible and not user-friendly and just a little ridiculous.

5

I know you are not just looking to get your RTSP camera stream in Octoprint, but also if you have a camera that is RTSP and you want its stream to be shown in Octoprint. This could be accomplished by using a converting service like RTSP.me

This service converts the RTSP stream to something that can be placed in a browser iframe. Honestly I have no idea what format it is converting it to but I am gonna bet it's pretty efficient or it would cost a lot in bandwidth to the service. Once you have that setup, you can use a plugin like WebCam Iframe to replace the built in camera feed.

This short video goes over this a bit but not specifically for OctoPrint.

These are some challenging points for this group. I’ve shared similar thoughts before, and the experienced members often provide their very pro RPi perspectives. While also helping others with RPi-related issues that seem to come up over and over. Personally, I prefer not to use RPi for projects that need to run smoothly for extended periods. The cost can be a bit high in time as well as materials. There are a lot of hidden incremental costs to run a RPi. I find it more practical to invest in something stable and reliable from the start. However, one must understand that the community enjoys tinkering and RPi gives them plenty of fuel for that.

I believe the RPi is here to stay and will continue to be a central focus for the future of OctoPrint. It aligns well with the community’s interests and generally performs reliably most of the time.

There really is no room or reason to complain about the software itself. Its solid and at this price point, complaining about the software stack without a real contribution is just ill mannered entitlement.

On a more hardware agnostic note, there is a good install script for those that are not installing the Octopi OS. I am sure this is a contributing factor to the absence of an Apt install package.

Once it is installed the update process is (at least in my experience) pretty solid. I also only update as needed but I have not had to install a new OS to update OctoPrint. I think you see this as a path for users because many are just "users" and they don't really understand the linux nature of what they are doing. It's more of a device to them not software.

6

I offer that part of the reason for not supporting an upgrade path is the concern for creating more problems than it solves. There are plug-ins available that do all manner of things. Configurations that can be as varied as the printers supported by the OS. Hardware options well beyond the RPi. The potential for repeated upgrades that could be leaving trash behind that you can't predict as part of an upgrade. All of those things come together to make a potentially very complex upgrade. An upgrade to a system very often used by folks that do not understand it, but use it as a "fire and forget" type of management tool. They lack the experience to perform the troubleshooting and diagnostics you seem to be able to do. As jcassel said, given the cost of the software and incredible support making the choice to force a clean install seems like an easy one to me.

2 Likes
7

Cheers, thanks for the responses.

I hope I don't seem to be full of ill mannered entitlement, certainly some frustration probably comes across. I don't disagree with any of responses, I agree the software itself seems quite solid.

Octoprint_deploy is indeed a good script - it's what I used as a 100% noob first time install. The only problem and one I was taken aback by is the mjpeg stream dependency, and the IMO very clumsy handling of change management.

I've been doing IT for along time, and don't often ask questions on support forums anymore - In recent years the quality of community responses (not specifically octoprint) has taken a massive dive, and as I'm usually asking about something that might be considered unorthodox by the average user, I've noted that responses often fall towards "don't do it that way, do it this way" instead of actually answering the question - people don't get their questions answered, they don't get insight into how things work, they just get told "don't do that". Just look at almost any microsoft support thread since Win10.

It is really nice to come back and read something that doesn't head down that well worn path.

re: criticisms, because honestly I am criticising, and please forgive me if I came across as brusque, my only real problem with the octoprint ecosystem is the absence of packaging and a platform/arch centric support model where there is no technical reason to be platform/architecture centric.

On the other hand that does highlight a positive - the community environment has clearly been pretty tight in the formative years, and that's a big positive. It has only one negative really - groupthink.

re: upgrade path - that is solved the moment you package everything properly. Plugins become packages dependent on octoprint package versions. The chain of dependencies are defined and if I asl apt to replace octoprint-x.x.1 with octoprint-newcam-x.x.2 these dependencies are determined, the package changes necessary are put to the user to approve. If some plugins need to be removed, and others updated with a -newcams version, that's highlighted and config file changes are prompted to.

Everything Slacker suggests as justification for forcing a clean install are in fact far better reasons to embrace software packaging; it's a better technical solution that is not platform or architecture dependent that addresses everything Slacker raises. Sometimes the easy choice isn't the right one. There's more than a hint of groupthink in the suggested logic that promotes reinstall.

Having said that I understand implementing packaging might be a workload dev team are reluctant to take on. I'm just putting my voice out there to suggest it would be worthwhile in the longer run...you'd see a broader userbase from other architectures, easier updating and upgrading, and so on.

In hindsight it's not so much the mjpeg dependency that frustrated me as the scorched earth approach to swapping it out for webrtc. Packaging makes life easier for everyone, especially end users.