Limiting the FPS of an RTSP stream using H264 passthrough

Forum for questions and support relating to the 1.32.x releases only.
Post Reply
MarkH
Posts: 7
Joined: Thu May 09, 2019 8:37 am

Limiting the FPS of an RTSP stream using H264 passthrough

Post by MarkH » Thu May 09, 2019 8:47 am

Hey all,

We've gradually moved over to using H264 passthrough for storage on all our cameras but are struggling with the FPS that is being sent from the cameras. On 5 of our existing cameras we could limit the FPS at the camera side - but we're now adding 8 cameras that have no such option and each wants to send 15 FPS. Naturally, the disk space required for this is a lot higher than I'd like.

So.... is there an elegant way to limit the FPS whilst using H264 passthrough? FPS limiting from ZM side seems to be frowned upon for H264 streams. Plus, with passthrough, would this even work? Skip frames doesn't seem to work (again, passthrough I presume?) - so I'm currently left with pulling 120 FPS for a load of cameras that I'd happily be pulling less than 30!

Thanks for any thoughts!

User avatar
iconnor
Posts: 760
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by iconnor » Fri May 10, 2019 1:36 am

No. You set it in the camera. If the camera offers no option then you are out of luck.

MarkH
Posts: 7
Joined: Thu May 09, 2019 8:37 am

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by MarkH » Fri May 10, 2019 8:45 am

Damn - I thought that may be the case!

Assuming I can't find any way to limit it at the camera end (I've contacted the manufacturers, too) - can you think of any way that this can be achieved without significant CPU processing? I presume H264 re-encoding would work (haven't tested, though) but at a significant CPU hit?

Cheers anyway!

MarkH
Posts: 7
Joined: Thu May 09, 2019 8:37 am

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by MarkH » Fri May 10, 2019 11:34 am

To follow up with my own query; even with X264 encoding (rather than passthrough) it does not respect Frame Skip / Motion Frame Skip.

So... SOL at the moment. Reduces the total capacity for storage by amount 4 times.

Any thoughts - even those a little 'out there'?! Like running an FFMpeg (or similar) 'proxy' that receives the RTSP stream, reduces the framerate and then forwards it back on to Zoneminder... But that would happily run 10 of those streams without too much CPU usage and setup?!...

kitkat
Posts: 65
Joined: Sun Jan 27, 2019 5:17 pm

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by kitkat » Sat May 11, 2019 7:04 pm

The FFMpeg proxy idea was my first thought, but you make a good point about re-encoding several streams being quite CPU-heavy.

Perhaps, though, you could do a similar thing but instead of re-encoding to H264, get FFMpeg to dump JPEGs into a folder instead and then use the File source type in ZM?

User avatar
snake
Posts: 181
Joined: Sat May 21, 2016 2:20 am

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by snake » Sun May 12, 2019 4:17 pm

MarkH wrote:
Thu May 09, 2019 8:47 am
FPS limiting from ZM side seems to be frowned upon for H264 streams.
FPS limiting should never be done from ZM side (with one exception - local cameras)*. It doesn't matter if it's an H264 stream. This seems to be a consistent mistake from people on these forums. I don't understand why.

Back to the topic at hand, you should be able to limit the FPS with an ffserver (ffmpeg) reencode. You could use a separate computer for this. The other option would've been to use JPEGs and not H264 passthrough. Did you try this? Some cameras will encode slower in JPEG mode, others will not. So, disable Passthrough, disable encoding, store JPEG frames only.

It's probably easier just to get good cameras, but if you want to use ffserver, you would have it read the videos, and then serve them on the network. Finally, ZM would pull from the RTSP ffserver stream. It's possible, but I don't know how robust it would be.


*Ok, maybe two exceptions, if you want to lower the blue screen / disconnected FPS limit, from say 900 to 100, but that isn't required, and if the cameras work, is superfluous.

MarkH
Posts: 7
Joined: Thu May 09, 2019 8:37 am

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by MarkH » Sun May 12, 2019 5:33 pm

I am actually aware that limiting it at ZM side is bad - and quite understand why, too... But, in this case, I haven't got much choice (or rather, I have to limit it between the camera and ZM - but not the cameras themselves. They're decent cameras hardware-wise but the software is designed to be cloud, etc etc. The RTSP stream is the saving grace).

The ffserver could be a distinct possibility. I have considered going back to JPEG storage - although I had some major issues with the periodic mass deletion of files. It was a BTRFS issue (major server lockup when deleting millions of files) which could be avoided (storage has changed). Also, for a couple of the cameras I need audio recording. To be honest, either way is looking like so kind of re-encoding is going to have to happen.

So it looks like some kind of ffmpeg / ffserver proxy is the only viable solution. I'll see if I can't put something together and see what the results are like. If it were just one or two cameras I'd definitely just replace them - as it's 8 it's just not justifiable - it would be better to take the hit in storage space and/or just buy another 8TB drive or two for the money.

Thanks for the suggestions! Will update if this works out or not ...

rockedge
Posts: 1097
Joined: Fri Apr 04, 2014 1:46 pm
Location: Connecticut,USA
Contact:

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by rockedge » Mon May 13, 2019 2:36 am

have you considered using opencv? I think it would be possible to use a threaded video mode written with python using opencv that receives the camera streams, reduces the FPS and then passes those to a proxy server which ZM can use. Something like darknet-YOLO does when compiled with opencv where it is possible to stream via built in http server on some port like 8080.

might be a long shot but it might be a solution that would work with multiple cameras, and if this was done on a separate machine, the ZM server would have very manageable CPU loads as would the machine running the python (or C++) program and opencv libraries.

I have been experimenting with running darknet-yolo, compiled with opencv and running the command ./darknet detector demo ./cfg/coco.data ./cfg/yolov3-tiny.cfg ./yolov3-tiny.weights -c 0 -mjpeg_port 8090 which makes it possible with multiple simultaneous connections to connect to a mjpeg stream on port 8090. And then using that stream like http://192.168.0.7:8090 in a ZM monitor setup on a separate machine running the ZM server .
I think using this idea it is possible to duplicate this functionality without the object detection, with a program that can do this with your camera setup

MarkH
Posts: 7
Joined: Thu May 09, 2019 8:37 am

Re: Limiting the FPS of an RTSP stream using H264 passthrough

Post by MarkH » Wed May 22, 2019 9:09 am

Thanks, rockedge, for your suggestion - and thanks all for your thoughts on this!

So, a few things 'solved' this problem...
- The company that manufacturers the cameras have a separate DVR application. Turns out that can manipulate settings on the camera that are completely locked out from all their other software - the documentation on these things is terrible, but the settings exposed mean we can limit FPS at the camera side!!

- Turns out.... H264 may be more efficient at encoding than I initially thought. Reducing it from 15 FPS to around 5 FPS had only about a 10% reduction in filesize and the cost of significantly reduced 'experience' when viewing the videos. Unless I'm missing something, and the reduction should have been much higher, it makes sense to retain 15 FPS at a very small filesize penalty. (Also... despite using VBR and a reduction in FPS, the quality was visually worse with 5 FPS than 15 FPS. I'm guessing the visual tricks that H264 use to smooth motion/etc make up for the 'jumpy' visuals seen at a lower FPS. Anyway...).

I've been interested in doing other processing - and opencv as always looked interesting - so I may still revisit that at some point. But from an FPS-limiting perspective the problem is solved/side-stepped! I'm seeing just under 400 MB per hour per camera (15 FPS / 1080p recording).

Thanks for all your input!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests