I’m trying to add an RTSP camera using the IPCamera Binding.
The stream works fine in VLC:
rtsp://:554/cam/realmonitor?channel=1&subtype=0
The Thing comes online and snapshots update correctly, but I can’t get the live stream to display in Main UI.
Has anyone run into something similar?
Not sure if this is an ffmpeg issue or something in the binding configuration.
Thanks!
VLC supports RTSP, web browsers do not, so there’s nothing mysterious here. To view it in a web browser, you must convert it to a supported format. I don’t know the binding and how/if the conversion is supposed to work, but using VLC as a “test case” proves nothing else than that the camera itself produces a valid RTSP stream.
Put the binding into TRACE logging level, then try and use a feature that needs the RTSP stream. What does the log show? Also pause and un-pause the camera with the TRACE in case it fails ealier on. The logs should give something useful, and dont forget to search the forum with the error text to see if someone has already solved it. It’s possible that FFMPEG is placing some helpful text into the log which can only be seen in TRACE level.
give this a read if you convert to something like HLS you can then just use the video card widget.
The ipcamera binding can turn an rtsp stream into HLS. I have been doing this for years to display cameras on a Google home hub screen. It uses ffmpeg to do the lifting for this.
I assume that it’s writing to disk if it’s generating HLS. If you could pipe it directly from FFmpeg to the browser, I would have thought that MPEG2-TS would be more suitable - depending on what codecs are in use of course. But, if it’s generating HLS to disk, it means that it’s doing that constantly, not only when somebody is viewing the feed, right? That sounds like a SD card killer to me.
Read the ipcamera binding documentation, it covers how to use a ram disk and the binding will auto start and stop the generation automatically on a as needed basis.
There are multiple ways to use cameras and the documentations should cover what people need to know.
If this was a response to me, what I said was more of a general observation than it was about the binding. I don’t use the binding, and haven’t looked at the details, but generally you use things like HLS or MPEG-DASH to enable time-based seeking and/or dynamic quality (where you have multiple sources of different quality to choose from, and will assign whatever the client can receive without the buffer filling up).
None of this is relevant for a live stream, which is why I was thinking that HLS was a “strange choice”. But, if you write it to disk before streaming it to the client, it makes some sense, because HLS produces a lot of small fragments, which can then be deleted as they get “old”, while a “normal” stream would just grow larger and larger on disk. The use of a RAM disk confirms my suspicion that writing to disk is a part of the routine here. If it was possible to find a solution where you could skip writing to disk altogether, HLS shouldn’t be needed and the same goes for the RAM disk. But, this might not be easy to actually achieve, I don’t know without looking into the details.
I was aware the ip camera binding could do the conversion still it is using ffmeg to accomplish this as well.
My reply to the OP was more around information on what it would take to be able to display a video stream in a browser or a simple video card in OpenHab. as well as giving a link to the OP to help understand why rtsp was only working with a media player such as VLC.
Thanks, that makes sense. I know browsers can’t play RTSP directly, so VLC only confirms that the camera itself is serving a valid stream.
My expectation was that the IPCamera Binding would use ffmpeg to convert the RTSP stream into something the Main UI can display. Since snapshots are working and the Thing is ONLINE, I’m trying to figure out where that conversion step is failing.
Do you know if there are any common reasons why the binding would successfully grab snapshots but fail to generate the browser-friendly stream?
That’s a good suggestion, thanks. I haven’t enabled TRACE logging yet, so I’ll do that next and see what ffmpeg reports when I try to open the live stream.
If I find any ffmpeg errors, I’ll post the relevant log output here. Have you seen any recurring TRACE messages that usually point to codec incompatibility or an ffmpeg configuration issue?
Thanks for the clarification. I understand your point now—you were explaining why RTSP itself isn’t suitable for direct playback in a browser, regardless of whether VLC can open it.
From what I’ve read, the IPCamera Binding should handle the ffmpeg conversion internally, which is why I expected the Main UI stream to work. I’m now trying to determine whether this is a binding configuration issue or something specific to my camera’s RTSP stream.
Out of curiosity, have you seen this binding work successfully with other RTSP cameras, or is it fairly sensitive to different camera implementations?
I played with the ip camera binding a few years back using nonnamed off brand camera and it worked ok for me after I configured it based on the good documentation in the bindings readme it seemed to work fine. I later moved to a separate standalone solution and added ffmeg to a separate server and feed it through a nginx install since I wanted 1. the feed to be available to more than just my openhab install and 2. did not want to overload my openhab server with constant video conversion workloads. I run HLS and set my segments low and only have about 3 to 4 seconds of delay.
Most likely yours should work fine if you follow the instructions in the bindings docs and assuming your ffmeg is installed properly that is a prereq the binding does not install that as part of the add on if I recall and you have passed the startup command either manually or using a rule to start encoding and passed a valid RTSP url it should work correctly. I seem to recall some early versions had challenges with passing the username and password but I am pretty sure that was solutioned in a later version