Capture RTSP stream from IP Camera and store

Question

I've got a few IP Cameras which output an RTSP (h264 mpeg4) stream.

Hitting the URL locally via VLC: rtsp://192.168.0.21:554/mpeg4

I can stream the camera and dump to disk (on my desktop). I'd like to however store these files on my NAS (FreeNAS). I was looking at ways to capture the RTSP stream and dump them to disk but I'm unable to find anything.

Is it possible to capture the stream on FreeBSD or Linux (RaspberryPi) and dump the streamed content to a disk local to Linux or FreeBSD - preferably every 30minutes?

EDIT: The NAS is headless (HP N55L or something) and the RaspberryPi's are headless too.

I've already looked into ZoneMinder but need something small. I was hoping maybe using Motion to detect motion on the stream but that will come later.

Solution 1

IP cameras are of varying quality, some behaving erratically in my experience. Dealing with their RTSP streams requires a dose of fault-tolerance.

The Live555 project provides a relatively fault-tolerant RTSP client implementation, openRTSP, for pulling RTSP audio/video streams via CLI: http://www.live555.com/openRTSP/

For example, to save a camera's RTSP audio/video to files in QuickTime format (AVI and MP4 also available), one file every 15 minutes:

$ openRTSP -D 1 -c -B 10000000 -b 10000000 -q -Q -F cam_eight -d 28800 -P 900 -t -u admin 123456 rtsp://192.168.1.108:554/11

These options mean:

-D 1 # Quit if no packets for 1 second or more
-c   # Continuously record, after completion of -d timeframe
-B 10000000 # Input buffer of 10 MB
-b 10000000 # Output buffer 10MB (to file)
-q   # Produce files in QuickTime format
-Q   # Display QOS statistics 
-F cam_eight  # Prefix output filenames with this text
-d 28800      # Run openRTSP this many seconds
-P 900        # Start a new output file every -P seconds
-t            # Request camera end stream over TCP, not UDP
-u admin 123456  # Username and password expected by camera
rtsp://192.168.1.108:554/11  # Camera's RTSP URL

Removing the -t option causes openRTSP to default to UDP instead, which can reduce network traffic a bit. You will need to play with the options in order to find the combination which suits you.

Frankly, the cameras themselves are sometimes unreliable, or just implemented differently -like closing the socket unexpectedly is not all that unusual.

Sometimes the openRTSP client does not catch these glitches. So I've opted to code a controller in Python using the 'subprocesses' module to invoke and monitor the stdout of each openRTSP client instance, and also check that the files are continuing to grow in size.

This appears to be a byproduct of the low-end of the CCTV industry playing fast and loose with standards, RTSP and ONVIF being the two most frequently abused.

Fortunately, you can usually work around these problems. Unless your IP cameras and controller are all designed to play nicely together, only use ONVIF for once-only discovery and settings management.

I use openRTSP on a few Raspberry Pi B+ running Raspbian. Each 1280x1024 stream occupies around 8-10% of the CPU's time, and I've successfully run up to eight cameras per RPi, writing the files to NAS storage. Another RPi processes completed files with ffmpeg, searching for motion and produce index PNGs of those frames, to assist with spotting break-ins.

There is an open-source effort called ZoneMinder which does this latter part, but I was unable to get it working with my cameras. ONVIF support is new and nascent in ZM, and it doesn't seem to contend well with the spotty RTSP streams produced by my menagerie of under-$100 IP cameras.

Solution 2

If I follow your question correctly, why don't you try the following command on a Linux system (RPi):

ffmpeg -i rtsp://192.168.0.21:554/mpeg4 -vcodec copy -acodec copy -map 0 -f segment -segment_time 300 -segment_format mp4 "ffmpeg_capture-%03d.mp4"

This should save the video in chunks of 300 seconds. (Note that the clip length will depend on your input and output frame rates)

Solution 3

I just thought I'd add my two cents and complement BjornR's answer.

Instead of running a cron job to periodically kill the VLC process, one could tell VLC to run for a specified amount of time and close afterwards.

This is the command that I run on my box:

/usr/bin/vlc -vvv rtsp://192.168.1.128:1554/11 --sout=file/ts:/media/path/to/save/location/recording-$(date +"%Y%m%d%H%M%S").ts -I dummy --stop-time=480 vlc://quit

This runs VLC for the specified amount of time and later exits. The vlc://quit parameter is required since VLC would stop recording and stay open. This command needs to be placed inside a loop.

The only problem I've found so far is that it might miss a few seconds every time a new recording starts.

Solution 4

VLC looks like an ideal candidate to process your stream. Basic methods to capture a stream are described on the Videolan website. I sucessfully recorded the output of my D-Link DCS-5222 network camera using the following command:

vlc rtsp://user:password@ip/play1.sdp --sout=file/ogg:mystream.ogv

In your case, this might work to save the output locally:

vlc rtsp://192.168.0.21:554/mpeg4 --sout=file/ts:mystream.mpg

I'd suggest to run a script that ends this vlc process and launch a new instance every 30 minutes as i'm not sure VLC is able to do this.

As for storing on a NAS, just mount it to your local file system.

View more solutions

Comments

[LatinSuD]

Why not use VLC for linux?

[Admin]

oops, I forgot to mention that both the FreeNAS server and RaspberryPi's are headless!

[LatinSuD]

You can use VLC from command line. Not trivial, but possible.

[Admin]

As RTSP is just a protocol, will it just dump the h264 content or do I have to get VLC to transcode it?

[LatinSuD]

Well that's part of the VLC command line voodoo, and sorry that's why i'm not giving you a full answer here. I think a fully transcoding is not necessary but maybe change the container. I hope that some VLC expert pops up here.

[Admin]

ahhh okay, that's perfectly fine @LatinSuD, I will look into VLC Commandline until our VLC Ninja flies past :-)

[Kinnectus]

You could also use FFMPEG to do exactly the same job. You will still need to mount your NAS as per the answer suggests.

[Igor]

Great solution Kevin, could you please share more with motion search/png indexing solution - at least where to dig on further?

[CP3O]

@Kevin-Prichard I wanted to understand, 1. If I could convert say Analog SD CVSB to IP stream would your solution work? ( I want to capture mp4 videos in 1 hour chunks from each source) And would I be able to record 300 such streams over a single network 24/7 or would this overload the network? 2. Is it possible to conver Analog SD/ CVSB to IP stream?

[Eddified]

@Kevin-Prichard, I am interested in your python scripts. It sounds like we have similar use cases: save the video streams from multiple security cameras to disk 24/7.

[Kevin-Prichard]

@Eddified - It's been a few years, not sure if they're in usable state, because I switched to Yi Home wifi cameras. For short-term use I had them write continuous a/v to SD card, swapped weekly and copied to server -a bad practice. I plan to switch to open enhancements to Yi camera firmwares found on github, some of which expose the RTSP endpoint to the localnet. Then, I'll need a script to download those streams, and then I'll clean up and release my scripts. How's that for a plan?

[Eddified]

@Kevin-Prichard Sounds like a plan. The part I’m most interested in is this, it sounds quite useful!! : “ Sometimes the openRTSP client does not catch these glitches. So I've opted to code a controller in Python using the 'subprocesses' module to invoke and monitor the stdout of each openRTSP client instance, and also check that the files are continuing to grow in size.”

[Kevin-Prichard]

@Eddified Honestly, a lot has happened since 2015, both w/ Python and potential RTSP clients. Looks like live555's openRTSP has been getting updates (mirrored from their repo I guess).

[Kevin-Prichard]

On another project that async processes on-disk video via concurrent.futures, I'm using a ffmpeg wrapper that manages pipes pretty well. Inserting a process btw allowed to inspect when ffmpeg borked on a file, or just died. I want to carry that to whatever RTSP recorder comes in the next iteration. openRTSP may be fault-tolerant, but not perfect.

[bruin]

It seems that openRTSP does not support h265 video format yet, as I tested today (Jan 17, 2021).

[iambr]

@bruin I don't know when but now it does support h265

[iambr]

@bruin yet It cannot include the correct h265 headers on created filés. Yeah you are right.

[iambr]

@Kevin-Prichard your answer is an aewsome knowledge-sharing! Thanks to you I managed to setup my cheap ip camera. I made ffmpeg 'more forgiving' on its RTSP setup/requests

[MitchellK]

This should be marked as the correct answer as VLC is just full of horrible bugs