Need help finding an IP camera

[velociti]

Hello all,

I'm looking for an IP camera and have a general idea of what I need:
1) 1080p resolution, ideally a good low-light sensor like the IMX322/323
2) Indoor daytime use, so with an IR-cut filter for natural-looking colors
3) h264 encoding
4) 30fps is acceptable, but 60fps would be a very nice bonus
5) Interchangeable s-mount lens
6) PoE
7) Most importantly... I want the ability to continuously transmit the video stream to a multicast address over RTP.
8) Low latency video, like under 200ms.

Until now, I have been using a USB webcam hooked up to a Raspberry Pi, and was using ffmpeg to stream the video over RTP to a multicast address. It was an AR0330-based camera (with UVC driver and h264 codec support) that I bought from aliexpress, and after a few months it stopped working... I literally can't find any other USB cameras that support UVC and H264, so I figured this time maybe I'll try an IP camera. It's too bad, because the USB camera was working great when it actually worked (I managed to get around 100ms latency, which I thought was pretty amazing - I measured by using a stop watch and taking a photo of it next to my monitor showing the video stream, and subtracting the time difference).

The biggest question marks for me are #7 and #8. I've seen some Hi3516-based cameras on aliexpress that seem to satisfy the remaining points. But I don't know what kind of latency to expect, and I've seen no indication from the web interface screenshots that I would be able to stream continuously to a multicast address.

Any feedback and suggestions would be much appreciated!

 

[bp2008]

Ok, it isn't an exact match, but have a look at this dahua starlight model: http://www.aliexpress.com/item/DAHUA-2Megapixel-Starlight-Ultra-Smart-IP-Box-Camera-with-POE-Without-DAHUA-logo-IPC-HF8281E/32352880533.html

It should be very good low light capability.

This takes C/CS mount lenses... but maybe you can find one that does normal S mount. There are also bullet and dome models of this, but they have zoom lenses built in and are probably hard to swap out for anything else.

This camera has the rather rare ability to do higher than 30 FPS. It will probably max out at 50 FPS though ... it is absolutely idiotic in this era but in many IP cameras have an NTSC/PAL mode which changes the frame rate limit between 25 and 30 FPS (or 50 and 60 FPS) and all my Dahuas end up being locked in PAL mode only. Even though they do not have analog video outputs in the first place, so it is utterly pointless to have a limited frame rate caused by PAL mode.

I don't know if it applies to this camera, but my Dahua PTZs are capable of fairly low latency. Under half a second with the right player. Possibly under 200ms, but it is really hard to measure with these cams mounted outdoors.

I don't know if this uses RTP, but Dahua cameras do support multicast:

 

[velociti]

Thanks for the suggestion! That looks really interesting, especially with the 1/1.9" sensor and 60fps. And yes the latency does depend a lot on the video player used. VLC is really bad with latency. From the tools I've tried, ffplay (comes with ffmpeg) is very good (at least on Linux... but I haven't tried on Windows), but the best (in my experience) has been omxplayer on the Raspberry Pi, with the --live command-line option. And of course the h264 baseline profile is critical for minimizing encoding/decoding delay.

If it's not too much trouble, would you mind testing the latency on your camera over a UDP stream? Of course I totally understand if it would be too much of a hassle. The trouble with aliexpress is the shipping cost if I have to send it back (if the latency isn't good enough). So it's going to be a bit of a gamble.

 

[nayr]

omxplayer is just a ffmpeg wraper, you can achieve lower latency by tweaking the ffmpeg settings so it starts the feed as soon as possible using same arguments omxplayer does.. like not looking for audio or waiting for avindex.. also a lower iframe rate on the camera will help it fire up faster.

udp with h264 requires tuning linux's udp buffers to get performance reliable enough its not dropping iframes randomly.. Ive tested multicast and it offers no performance increase, its for environments where you have more displays/monitoring stations than your NVR can feed directly.

 

[velociti]

omxplayer is just a ffmpeg wraper, you can achieve lower latency by tweaking the ffmpeg settings so it starts the feed as soon as possible using same arguments omxplayer does.. like not looking for audio or waiting for avindex..

Yep, but omxplayer gets you hardware accelerated playback on the raspberry pi, using the on-chip h264 decoder. To achieve the same delay on a regular PC, I could probably look through the omxplayer source and find out what ffmpeg flags it uses for the "--live" option.

Edit: It looks like it sets AVFMT_FLAG_NOBUFFER, which is described in the ffmpeg documentation as "Do not buffer frames when possible":

https://github.com/popcornmix/omxplayer/blob/master/OMXReader.cpp#L289
http://ffmpeg.org/doxygen/trunk/avformat_8h.html#aee579ebc55f7067a964fbfd09c14e8c2

also a lower iframe rate on the camera will help it fire up faster.

Yeah I figured that out in the many hours that I spent tweaking. Although, I don't mind the few seconds of "startup" time so much. I'm more concerned about the delay after the stream gets going. So basically I just want to minimize the delay between an object moving in front of the camera and seeing the movement on the screen.

udp with h264 requires tuning linux's udp buffers to get performance reliable enough its not dropping iframes randomly..

Yep, that gave me a lot of headache before I figured it out! This thread on github was very useful: https://github.com/ZoneMinder/ZoneMinder/issues/811

Ive tested multicast and it offers no performance increase, its for environments where you have more displays/monitoring stations than your NVR can feed directly.

This is exactly the reason why I need multicast - I need to be able to stream the video to at least 5-10 Raspberry Pis simultaneously. Multicast will minimize the load on the camera, and hopefully also help to keep the Pis more closely in sync.

 

[nayr]

try these options for omxplayer to reduce latency, the time it takes to load is your latency.. if it takes 3s to load the stream it remains 3s behind, if its less than a second to load then its less than a second behind.

--lavfdopts probesize:25000 --no-keys -p --live --aidx -1

also note that the bitrate/resolution seems to impact it.. a bunch of substreams loaded up on my pi are all very low latency and as close as they can get... but if I make one of them a mainstream then its obviously behind the other substreams and its the last one displayed while all the substreams blink onscreen in unison.

my NVR could easily provide direct stream to 10 devices at once.. I dont think the camera directly would, but I pull all my feeds from my NVR and through my testing Ive had that many feeds coming off it with less observed latency than direct off the camera.. especially once you crank up the load.. I had more problems w/multicast than w/out it so I abandoned my efforts..

 

[velociti]

Interesting I'll give that a shot when I get things up and running again, thanks!

if it takes 3s to load the stream it remains 3s behind, if its less than a second to load then its less than a second behind.

My understanding is that the initial delay occurs because it has to wait to receive its first i-frame before it can begin displaying the image (the i-frame is a complete frame, whereas the p-frames in between just contain the difference between the current and previous frame). So the video player discards all the p-frames that it receives, up until the first i-frame. With the USB webcam I was streaming, the i-frame interval was something like 8 seconds, so it took about that long for the video to start playing, but after that the latency was just under 200ms (so the video wasn't 8 seconds behind).

 

[nayr]

not really, it loads up the stream and figures out its resolution/framerate.. the time it takes to load the stream ends up being the delay.. if its waiting for the iframe then the stream is already loaded and its processing it.. it might not be displayed correctly until that iframe comes in.

turn it into debug/verbose logging and watch omxplayer process the stream, the time from starting to the time you see it churning through frames is your delay.. that string I gave you above tells it there is no audio, no keyboard, and changes the libav options to reduce that initial probe buffer to figure out the resolution/framerate to a fraction of the default.. it makes it load much faster.. the end result is a latency thats comparable to monitor plugged directly into my NVR.. its not actual realtime, but its as close as your likely to get.

If latency is really a problem for your situation, then your best off using analouge cameras and displays.. no latency at all.. also no detail either.. encoding/decoding and transferring data takes time, you cannot eliminate it.