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.
We can use openRTSP (A command line program ) program to store/record the RTSP streaming packet into the local folder.
Eg: Suppose, If we need to stream the IP camera through this application, then use the following command
./openRTSP rtsp://admin:admin@192.168.0.1:554/sample/media
note: "admin" is the username and passwords for some IP cameras.
syntax: rtsp://< ipaddress : port >/sample/media
Best Answer
Just had exactly the same problem - I was trying to access DVR RTSP stream via VLC player and had no video but no error as well. It turns out that in VLC preferences you must switch Live555 stream transport from default HTTP to RTP over RTSP (TCP).
VLC > Tools > Preferences > Input & codecs > Network > toggle to RTP over RTSP