I assume it was due to the timestamps being saved incorrectly. It was needed to fix problems with video files not being seekable. This resets the timestamps at the start of each segment file to zero. These next few parameters tell FFmpeg to save the video stream to smaller segment files, instead of writing to one never-ending file. The quality and size of the “copied” video stream files will depend on the specific camera and its settings. The trade-off is that the video will probably be larger than if re-encoded into a more efficient format. This will minimise the CPU usage which is good for recording multiple streams on something like a Raspberry PI. These parameters tell FFmpeg not to reencode the video or audio streams, and instead just to copy them. If the camera needs a username and password it is prefixed to the IP address. Each camera will have a different URL that you can find with an online search.
i is the address of the RTSP video stream we want to use as the input. I think this resolves issues with varying framesrates from some network cameras, and streams from some brands not including correct timestamps. In my experiments with various network cameras this was needed to make the saved videos correctly seek-able. This rebuilds the timestamps in the video feed. It does provide a good lower-latency, lighter-bandwidth live streaming option though. I have tried tweaking various FFmpeg settings such as the buffer size, but could not get files saving reliability on UDP. I assume this is due to the non-guaranteed packet delivery or order. In my experiments with recording UDP streams, the video files were regularly corrupted. We can fix most of these warnings with the other command line options, and I didn’t want these warnings filling up my logs during normal use. I received a lot of warning messages from most RTSP camera streams. This supresses the copyright notice, build options, and library versions from printing to the console. Photo by Breaking Down The Script -hide_banner -y
0 kommentar(er)
