IpCamera: New IP Camera Binding

No I have not uploaded the new readme as I am in the middle of a big change in the code. Everything is the same between brands so you only need to know the “thing” is called DOORBIRD in caps if doing textual config. Looking at the cameras config/channels in PaperUI should also guide you, any questions just ask and I will update the readme.

If the alarms do not work, just let me know what the binding is reporting in TRACE logging mode when motion is occurring and not happening and I can update it next build. How to enable trace logging is explained in the readme.

If I am correct at what the API stated, the doorbird cameras only support a single stream, so using this binding should allow many more streams of the video if you open more than 1 habpanel or app on your phone/s.

Hi Miha.
No, the binding doesn´t support the motion detection feature, unfortunatly…

Ok, thanks. Everything’s OK, got the stream and motion detection is working.

1 Like

Is anyone interested in doing some Alpha testing of the next build? You will need to be skilled enough to setup ffmpeg and tmpfs if you are running on SD cards as the HLS video streams are written to disk.

The next lot of features are huge and since they can be used in so many different ways, they will need a lot of testing to look for bugs:

  • ffmpeg abilities
  • rtsp
  • Casting to chromecasts with audio and video working.

HLS means staying in h264 format hence no re-encoding, you can trial it to see what works with this URL. It works in browsers like Edge, some versions of chrome and probably has excellent support on all Apple platforms.

http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/sl.m3u8
1 Like

Where the h… do I find the JAR file(s) under https://github.com/Skinah/IpCamera for newest build?

I can alpha test new binding.
I have experimented with ffmpeg to stream hikvision to chromecast.

/Mike

Normann:
See How to install section in the beginning:
Download the binding already built in JAR format from here:
http://www.pcmus.com/openhab/

1 Like

Hey,
im using ffmpeg stream from Xiaomi Dafang Hacked Firmware.
There is H264 RTSP:
Path to feed: rtsp://192.168.31.67:8554/unicast
HLS: http://192.168.31.67:8554/unicast.m3u8
hls.js web player: http://192.168.31.67:8554
MPEG-DASH: http://192.168.31.67:8554/unicast.mpd
For now streaming by ffmpeg is low resolution and low bitrate and low fps.

Maybe I can check Alpha version?:slight_smile: will it be better quality footage?

That depends on what you are trying to do? If you want to stream the cameras feed to a chromecast then yes it will be high FPS and high quality as it does not need much CPU to turn a h264 stream into a HLS feed. If you are wanting a mjpeg format stream then this takes CPU grunt and it will always mean you either need a camera that does this for you or another CPU will need to do the conversion.

Have you tried using the cameras HLS feed? Also to check the cameras firmware is not the cause try this feed to test with…

http://qthttp.apple.com.edgesuite.net/1010qwoeiuryfg/sl.m3u8

It would be great if someone could test and report back if the HLS format works in a webview item. It may be possible to get it working depending on which browser you are using and if you have an addon installed that gives the browser HLS support which is the case with Chrome.

HLS works on iOS app in webview item, but it opens in fullscreen. And I think that is not what we want.

That’s great news (and expected as Apple invented the HLS format) as it should work around an issue with mjpeg locking up the app on ios. If you can have a play at what does work and what features do not with HLS that would be great as I am flat out debugging code I cant spare time to try myself as my main goal is being able to cast to my TV.

Try this format…

Text label="Webview Stream" icon="camera"{Webview url="http://192.168.31.67:8554/unicast.m3u8" height=1}

Text label="Video Stream" icon="camera"{Video url="http://192.168.31.67:8554/unicast.m3u8" encoding="HLS"}

The height can be increased to make the size bigger. This works well as I like the full screen and the android app has a great way of displaying the controls from the previous page to the side which the IOS app does not have.

WebView opens in fullscreen.
Video is not working at all…

An update on how well the next build (Alpha currently) is working on an ARM processor (odroid C2)…

I have 1 camera doing the following jobs whilst the CPU load is 3.8 to 7.5% all of these are running at the same time…

  • Updating the snapshot every second.
  • Streaming to my TV with h264 720p at 6fps with audio working at same time.
  • Streaming low res Mjpeg to a browser.

ffmpeg starts and stops automatically so it wont run when it is not needed, the only downside is you need to call the HLS stream to start ffmpeg and then wait before calling it again after the files are created.

To get working audio in the HLS stream your camera needs to send it and in a format that is compatible. Working with Dahua when set to use AAC audio stream.

1 Like

Thanks for all the hard work on this

So I’ve tested the video section yesterday/this morning.
Was getting very frustrated and couldn’t get it on last night. So left it. Came down this morn, 1 of cameras showing in habpanel. Probably the Hikvision lockout Bugginess.
Added the rest of the cameras as per the one showing.
For not I had to override the url as

/ISAPI/Streaming/Channels/102/httppreview

Doesn’t work on ds-2cd-2032 camera, so instead just

/Streaming/Channels/102/httppreview

Maximum resolution and frame rate it could handle was 320x240 @ 4fps for 4 cameras, any higher and the images were flakey at best, little bit disappointing.

For those that wish to use authentication with Hikvision (which you could probably integrate into the binding) you can use a base64 encoded username and password as follows:

http://CAMERAIP:80/Streaming/Channels/102/httppreview?auth=BASE64ENCODEDUSERPASS

To get this string you can use:

https://www.base64encode.net

And input in the format

username:password

Hit encode and you have your string (don’t put it out there anywhere as it’s easily decoded.

So working better than the image refresh, albeit lower quality, just gotta investigate the bandwidth as seems abnormally high and the rpi can’t take it (cpu and ram are normal)

No Problems, glad people are using it.

Thanks for suggesting as that is something I can change as the older non ISAPI url works on the newer cameras as well. It is possible your issue was caused by a bug which I found and fixed a few days ago, I believe it would not accept changes to the override url until the binding was restarted. If you find any settings dont ‘stick’ until a reboot please report them thanks.

I just tried 640x360 and 20fps with mjpeg with 1 camera and it worked fine. I suspect you have hit a bottleneck in your setup somewhere. Without knowing more about your setup I can not comment, but be careful with using a rapberry pi with a USB drive and using a lot of network traffic, at some point it will flood the USB bus as the network shares the same bus. It may be your wifi router you will have to diagnose it.

If your camera works with that then I suggest you use the camera directly and not through the binding for mjpeg as the data will go direct from the camera to the tablet and not through your Openhab server. The binding supports proper BASIC authentication (which uses base64 in headers) or DIGEST. You do not need to use that url format with this binding if the camera supports one of those which I am sure it will.

I think you have just made me realise an issue, in all builds the override will need to be this.

/Streaming/Channels/102/httppreview

The binding handles the rest, but the snapshot override will accept a full url and throw away the first half. Not consistent so I will look at fixing this for the next build.

Yes MJPEG is less compressed and needs more bandwidth then h264, but it is more compatible. The new HLS streaming features in the Alpha build allow much higher resolution but that may mean if you have a bottleneck somewhere you will hit it sooner.

Yeah ill investigate over the next few weeks, not sure where the bottleneck is, everything cat6, enterprise grade mikrotik router, no usb on the pi and native app/browser work fine, I’ll let you know if I find anything. The cameras are on a different subnet/vlan tho so maybe something not quite right in my config.
Up until this point I was using the cameras directly, just thought I’d give the binding another bash and see the progress for motion detection etc also.

I would always use the cameras video feed directly to keep traffic off the Openhab server, there are times when you have no choice as some cameras won’t work another way. There is no reason why you can not use the HLS feature to cast the feeds and also use the motion detection features of the binding and use mjpeg directly as the binding only generates traffic on demand and not constantly.

If you have a constantly open overview style page with all cameras, then use the mjpeg or snapshots directly from the camera and when you want the higher Resolution the HLS can provide, switch to using it for a full screen display mode. You could even automate casting the video to a google home hub when motion or a doorbell is pressed.

Did the motion detection work for you? I may be using the newer ISAPI methods for that as well.

New build 2019-05-01-Beta has these changes:

Build will stay Beta until feedback from users indicate that the default ffmpeg options are working on a range of systems. I have been running this for over a week now and the build is stable and working well.

  • ffmpeg abilities. (See note below)
  • Animated gif generation so you can use to send via telegram, pushover and email. Also possible to use in sitemaps/habpanel to display a looping video of the start of any motion alarms or if the doorbell is pushed.
  • Last motion alarm now displays as a string channel to work out which alarm was last triggered.
  • HLS stream creation and serving. Can be used to watch high res video or can be cast to a Chromecast. Works in the iOS app.
  • Heaps more changes and fixes.

If you have not used textual config you will need to delete and readd any cameras for the new features and channels to show up. Also clear tmp and cache folder contents regardless of how you setup the camera. Readme has been updated with minimal info and will get updated as I get time.

*** NOTE ***
You will need to install ffmpeg manually on your server for the new features to work. Please use google for how to do this. Under Linux this command should work if you login with Putty.

sudo apt update && sudo apt install ffmpeg

The output of ffmpeg can be seen in your logs if you enable DEBUG output which is covered in the readme, this will help uncover any issues and the cause.

Also the HLS feature will write a lot of temporary data to your storage device, for SBC running with SD cards like a raspberry Pix, I would highly recommend setting up a 5-10mb tmpfs folder for the camera to use. It does not need much as the files are rotated so very small tmpfs will work great. If you are streaming a lot and the power fails in the middle of a write, you will have raised your changes of corruption greatly and it is not the fault of the binding. If using SSD or normal platter HDD there is no need to do this if the drive can keep up with the required speed and the drive is designed to safely handle power loss in the middle of a write.

1 Like

Hi Matt…
Where to find the latest readme ?

The source code and the readme can be found here. All open source.