Https video stream not possible - potentially problem with self signed certificate?

I get a blank screen when I try to view an MJPEG video stream from my local camera in a oh-webframe widget via HTTPS. I am connected to openhab server via https, too.
There seems to be an issue with self signed certificates of the IP camera. Does anybody know a solution?

- component: oh-webframe

Can you get it working in the ipcamera binding? The binding canproxy the stream out on either the port 8080 or the https port that openhab serves on by default. The binding does not do https so it will be up to your camera if it will work with the binding.

Hi Matt,
thanks for help.
Unfortunately not.
If my connection to openhab server is http your binding works without problems.
if I connect to openhab server via https I get the same result (blank page).

the trace log is in both requests identical:

2022-02-27 11:21:03.905 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from
2022-02-27 11:21:03.909 [DEBUG] [amera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
2022-02-27 11:21:04.219 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET:
2022-02-27 11:21:05.338 [DEBUG] [era.internal.handler.IpCameraHandler] - Setting Content-Type to:multipart/x-mixed-replace; boundary="MOBOTIX_Fast_Serverpush"
2022-02-27 11:21:10.014 [DEBUG] [amera.internal.servlet.CameraServlet] - Now there are 0 ipcamera.mjpeg streams open.
2022-02-27 11:21:10.018 [DEBUG] [amera.internal.servlet.CameraServlet] - All ipcamera.mjpeg streams have stopped.

this means in both cases the client receives the stream but the browser blocks insecure element embedings within a secure connection.

Then use port 8443 instead of port 8080.
The same urls are available as https on port 8443.

Hi Matt,
:man_facepalming: of course
I can see a picture for a second and then I get this problem

2022-02-27 12:28:37.048 [DEBUG] [camera.internal.servlet.StreamOutput] - FIFO buffer has run out of space:Queue full

I see that you already dealt with this problem.
I am on OH3.3 M1
Client: iOS 15.3.1

How many frames per second is the mjpeg stream? As a temporary measure does dropping the framerate down solve it?

It should be simple enough to increase the FIFO buffer some more as was already done here:
[ipcamera] Fix multiple mjpeg issues and allow stream to stay alive by Skinah · Pull Request #11921 · openhab/openhab-addons (

Framerate is already at 6fps@1280x720 resolution.
Maybe the problem appears because the Mobotix MJPEG API which I use supports “http keep alive”?

Any mjpeg stream is kept alive. I raised the FIFO from 30 to 50 and made a build for you to try here:

Install the Tellstick binding to install the dependencies this needs.
uninstall the binding so it uses the version in the folder
Unzip the jar to the addons folder

Index of /openhab/IpCameraBinding/ (

It is probably caused by the camera sending a single frame as more than 30 individual pieces, probably linked to a high resolution.

thank you very much, matt!

No problem, after you have tested it can you confirm it fixes the problem so I can work towards getting the change merged? Not sure if your thank you means it works or not.

Hi Matt

I have now installed it like suggested. Currently it works but the first dropouts always come after a few days. I will give you an update as soon as I can say something.


hi matt

still the same problem. Difference is, that it happend much faster as it did before.

openhab_log_20220305.txt (435.5 KB)

Camera image froze at 18:24:16


Create your own thread as your problem is not related to what is discussed in this thread. Yours sounds like it works fine until the browser closes the mjpeg stream to the binding. Then when you try to reopen the stream you then get the fifo is full message.

Create thread and give info on what browser, what camera and the json code showing how the camera is setup in the binding. I can use that to replicate your situation and try to reproduce it.

Hi Matt,
I just don’t wanted to be regarded as impolite because today I am going to find some time to test this.
Before starting, I’d like to undestand a little bit more of your fantastic binding and hope to get some tips.
I have Mobotix cameras only which are just capable of delivering MJPEG or MxPEG (which is a proprietary codec). My cameras do not support ONVIF.

Currently I have the following options:

  • MJPEG via http (http://<IP>:80/control/faststream.jpg?stream=full)
  • MJPEG via rtsp (rtsp://<IP>:554/stream0/mobotix.mjpeg)
  • MxPEG via http (http://<IP>:80/control/faststream.jpg?stream=MxPEG)
  • MxPEG via rtsp (rtsp://<IP>:554/stream0/mobotix.mxg)

MxPEG would be my preferred codec but this requires definitely ffmpeg.
In terms of protocol (http or rtsp) what do you think delivers the best result in terms of fluent video at as little CPU usage (on my RPi4) as possible?
Does rtsp always require ffmpeg even if the codec is MJPEG?

Could you please assist for a second how to configure correctly a thing for MxPEG via rtsp? Let’s focus on live stream only.
ffmpeg is installed
Current thing config:

UID: ipcamera:generic:cameingang
label: cam-eingang
thingTypeUID: ipcamera:generic
  ffmpegInputOptions: -f mxg
  mjpegOptions: -q:v 5 -r 2 -vf scale=640:-2 -update 1
  updateImageWhen: "0"
  mjpegUrl: ffmpeg
  gifPreroll: 0
  ffmpegLocation: /usr/bin/ffmpeg
  ipWhitelist: DISABLE
  mp4OutOptions: -c:v copy -c:a copy
  pollTime: 1000
  port: 80
  snapshotOptions: -an -vsync vfr -q:v 2 -update 1
  username: admin
  ffmpegInput: rtsp://
  hlsOutOptions: -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy
    -hls_flags delete_segments -hls_time 2 -hls_list_size 4
  gifOutOptions: -r 2 -filter_complex

from now on I am little bit lost. Do I need the HLS item to get the URL string which is required for oh-image control?
If yes, I get a 404 error message when launching this URL within a browser.
How can I configure the output stream to 1280x960 size and maximum fps?

Many many thanks in advance

EDIT: My Mobotix cameras support RTSP-over-HTTP-Tunnel. Does it make sense to make use of this?

Sorry, my previous post was not a reply so I think you might haven’t noticed my answer.

When using HLS URL I get the following error in OH log:

2022-03-06 14:22:36.769 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from
2022-03-06 14:22:36.771 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-hide_banner -loglevel warning -f mxg -i rtsp://admin:********@ -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4 /var/lib/openhab/ipcamera/cameingang/ipcamera.m3u8
2022-03-06 14:22:37.078 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - rtsp://admin:xxxx@ Protocol not found
2022-03-06 14:22:37.079 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Did you mean file:rtsp://admin:xxxx@

Do you mean mjpeg/mjpg stream or is mxpeg another format and not a typo?

I suspect your not sending h264 or h265 format to ffmpeg in this stream. HLS only supports either one of these two formats and if you were to try to transcode in realtime from another format to one of these it would need a very fast computer to do it. Most cameras can create a stream in one of those 2 supported formats so ensure the camera is setup to use either one in the URL that you provide as the ‘ffmpegInput’

correct. see here:

correct. see here:

for this I am using this input option:

ffmpegInputOptions: -f mxg

mxg stands for MxPEG. MxPEG is supported by ffmpeg.

that answers my question above. then I have to drop the idea of using Mobotix“s native codec and need to use mjpeg as my cameras do not support onvif/h.264.

just want to bring the test to an end. what would be the correct setting to use MxPEG codec and transcode the stream to h.264?

No idea off the top of my head, but the default ffmpeg options which can be changed will just copy the h264 stream directly to HLS. This is why hls is so low on CPU as it is just the stream split into files with no need to transcode.

The only reason I would see u wanting to do this is to cast the stream it needs to be HLS.

hi matt

just for information. I don´t think I fount the root for causing the problem, but since I changed to stream 1, it seems to work (at least since five days - which is much longer than ever before)