2018-08-27 23:16 GMT+02:00, George Andguladze <[email protected]>: > 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:[email protected]/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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
