[FFmpeg-user] Problematic RTSP re-streaming

[Carl Eugen Hoyos]

2018-08-27 23:16 GMT+02:00, George Andguladze <gandguladze at hotmail.com>:
> 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.

Thank you for the summary!

You should be able to produce the same effects as "do_timestamps" with
asetpts, I suspect there is no equivalent for rtpjitterbuffer.

Carl Eugen