[FFmpeg-user] Problematic RTSP re-streaming

[George Andguladze]

If anybody stumbles upon the same issue as described in the previous replies of this thread, know that I gave up trying to solve this problem using ffmpeg and instead used GStreamer to re-stream the RTSP stream to HLS. After long, painful hours of reading the documentation I was able to put together a stable pipeline with gst-launch utility that comes with GStreamer:

gst-launch-1.0.exe -v -e -q rtspsrc protocols=udp do-timestamp=1  location=rtsp://admin:password@192.168.1.21/Streaming/Channels/101 name=rtsp !  queue  ! rtpjitterbuffer ! rtph264depay ! h264parse ! mpegtsmux name=mux ! hlssink location="C:\\inetpub\\wwwroot\\HLS\\%06dst1.ts" playlist-location="C:\\inetpub\\wwwroot\\HLS\\stream1C.m3u8" target-duration=5 rtsp. ! queue ! rtpjitterbuffer ! rtppcmudepay ! mulawdec ! audioconvert ! audioresample ! voaacenc ! aacparse ! mux.

What this pipeline does is it takes the RTSP stream transmitted using UDP protocol, de-payloads the RTP packets, parses the H264 within the resultant data, transcodes the MU-LAW audio into AAC , muxes these into TS stream and outputs the corresponding .ts files and the .m3u8 playlist file.

Things to note:  

	* I needed to add 'do-timestamp=1' parameter to instruct the GStreamer to generate timestamps on the go since the original RTSP stream had timestamps completely broken.
	* The 'rtpjitterbuffer' plugin was the actual solution that fixed this weird behavior of my RTSP stream. Without this plugin added to the above command, I received roughly the same results as with ffmpeg.
	* Out of six Hikvision cameras that I have tested this solution (3 different models), I had to expressly specify the UDP protocol for the RTSP stream for one of the cameras ('protocols=udp') because otherwise the session would exit after 20-30 minutes with extremely generic error message. For others tcp worked fine.

After two days of testing, I concluded that each session was able to withstand at least 20 hours of transcoding until encountering a generic error message. But this is far better than ffmpeg was ever able to provide. (20-30 mins tops). Using a small script that monitors the process you can just restart the stream after that. 

Good luck and thank you for help.

George A.