Browser/OS dependent MJPEG video display problem with IPCameraBinding in MainUI


trying to get an MJPEG video to robustly display on mobile devices (aiming for wall mount tablet, so need this running on Android, ideally).

Have ALP600 (Türsprechanlage mit Kamera ohne Cloud | alphago ALP-600) as video source. Using IPCamera Binding to feed MJPEG stream (conversion to anything else with ffmpeg seems to overload the Raspi 4, with CPU load > 100%, unresponsiveness, so not an option, I guess).

What works:

  • MJPEG in image card in MainUI on Firefox on Win 10 and in Chrome on iOS 13
  • MJPEG in this widget Clickable Camera Widget on the same devices

What does not work:

  • MJPEG in image card or abovementioned widget on any Chrome or Firefox on different Android devices (primary target architecture) or Chrome on Win 10 or Firefox on iOS 13 - effect: transparent placeholder, no video
  • getting any MJPEG to display in video card (error: “No compatible source was found for this media.”)

My current best guess is that this may be related to some browsers preventing mixing in the unsecured HTTP connection to the IPCameraBinding stream (e.g. http://xx.xx.xx.xx:12000/ipcamera.mjpeg) into the MainUI page accessed via HTTPS. The fact that those browser unable to display the MainUI with the MJPEG video correctly can show the MJPEG stream without issues when opening this in a separate tab.

So I guess getting the IPCameraBinding to support an HTTPS connection would be worth a try. Haven’t found any suggestions for this, though.

Any help would be appreciated.

Many thanks in advance!



Update: hypothesis seems to be proven.
When using chrome://flags/ in affected browsers to set

" Insecure origins treated as secure" and entering the IPCameraBinding URL incl. port, i.e.


and relauching Chrome, the MainUI displays fine incl. MJPEG in the widget (verified on Chrome for Android an Win 10). Still doesn’t fix video card, seems to be an unrelated issue, but the widget is nicer anyways…

So, I have a workaround. A clean fix would involve getting the IPCameraBinding to expose an HTTPS connection, I guess.


Have you tried the latest version that uses the built in server as it may work via https? This was one reason for the change as Alexa needed the streams to be https so you can follow the guides on how to do what works for Alexa.

IpCamera binding - Breaking changes and new features in 3.2 Milestone 3 and newer - Add-ons / Bindings - openHAB Community

I’m not clear what it is your trying to do, is the camera already mjpeg and your trying to turn it into h264? that would overload the pi4 in realtime. To turn h264 into mjpeg that can be done in realtime on a pi4, just not the other direction.

I am not sure what your really asking in this post, can you explain the problem and what your wanting to do and what the problem is?

Tx for the quick reply! Sounds like good news. Do you happen to know when the HTTPS capability is expected to become part of the stable release branch? Another idea might be to have either the MainUI app server or an nginx proxy the stream from the IPCameraBinding. Will stick with the workaround for now, I guess.

Sorry for the confusion. The camera has MJPEG. Just wanted the video to get displayed robustly on the various devices & was experimenting with ffmpeg format conversions before I figured out that the issue was related to some browsers blocking HTTPS/HTTP mixes, not the the video stream format.

The changes were in the milestone 3 and newer so it will be in the next stable, which should be a week away with some luck as the first RC build is due in 3/4 days time. I’m not sure how the Alexa method is done, so it may need nginx setup from memory. Just wanted to point that there are posts that guide you on how to do it now and all cameras are on the same port which makes it easier.

Then check out the autofps.mjpeg and snapshots.mjpeg streams as these in the latest version are by far the most robust as they keep working even if the camera reboots or drops out of wifi. The other robust method is to use a jpg source and use the image card with a refresh on it, this by design will be the most robust as it can handle the camera going offline. Some tablets may make the website sleep to save battery life as mine does give a notice that it has done this.

Excellent. Will keep an eye on this.

Thanks for the recommendations! The issues I’m facing appear to all be located on the client/browser side, however. Maybe a sentence hinting at this issue (which seems to affect a significant part of the current browser generation) in the docs could help others. Btw., just switching to HTTP (no HTTPS) for MainUI eliminates the problem without further steps, but is of course suboptimal for other reasons.

The camera (part of a door bell setup) is wired with PoE and hasn’t dropped out yet. The current setup seems to work well now. Maybe I’ll get the tablets in place over the holidays.

I wonder if this could also explain your problems.

Display streams and snapshots from ipcamera binding in oh-image - Add-ons / UIs - openHAB Community

For now I’m fine with the IP-specific Chrome config adjustment as mentioned above & wait for the HTTPS capability, but tx anyways!

Update: with the latest stable release, HTTPS/TLS connections seem to be supported by the IPCamera binding. The URL pattern has changed, but the MJPEG stream is now available via the OpenHab TLS port (8443 in my case), at the URL exposed by the MJPEG URL channel of the camera thing. Now, everything works smoothly as designed.
Thanks for the support & excellent dev work!