[FFmpeg-user] RTSP to HLS re-stream stops with “No more output streams to write to, finishing.”

[Alex Molon]

Did you try with something like this?

ffmpeg -i url://whatever/link.ext?fifo_size=1000000&overrun_nonfatal=1

I don't use RTSP in my environment but I use a lot of UDP streams (coming from outside my network and with recurrent drops even for few seconds) and ffmpeg is able to compensate without dying. Of course the encoding stops...

Alex

-----Original Message-----
From: ffmpeg-user [mailto:ffmpeg-user-bounces at ffmpeg.org] On Behalf Of Tim Williams
Sent: 18 October 2017 14:11
To: ffmpeg-user at ffmpeg.org
Subject: Re: [FFmpeg-user] RTSP to HLS re-stream stops with “No more output streams to write to, finishing.”

Hi All,

Can I assume that nobody knows the answer to this? If that's the case can I ask for some advice on how to move forward and find a solution, it seems to me there is a clear bug in ffmpeg since short interruptions (a few seconds) when using a remote stream causes ffmpeg to stop, effectively preventing it from being used reliably in such cases. I can't see how you are ever going to get that degree of reliability across anything other than a local LAN. I have seen a few other instances of this problem being reported elsewhere, but there is never a solution. So my questions are:

- Should I be reporting this to the bug tracker either as bug or a feature request for an option enabling outputs to cope with a discontinuity in the input when it comes from a source which might have gap in the data due to network issues.

- Is ffmpeg fundamentally unsuited to the task of re-streaming a remote RTSP feed?

- Would running two instances of ffmpeg with the raw video being piped between them allow the interruptions to be tolerated?

- Should I be using some other tool to read the RTSP stream and then pipe that into ffmpeg to do the HLS encapsulation?

- Would I be better off running the RTSP>HLS encoding on a machine located on the local LAN with the segment data then being automatically synced to the remote server? This seems to defeat the object of having a streaming protocol like RTSP, but it would isolate ffmpeg from short network interruptions, which a file sync process will cope with far better.

I'm not expecting ffmpeg to tolerate big interruptions, we're talking about a few seconds here and I'm not worried about frame drops during the interruptions, I just want to avoid having to repeatedly restart ffmpeg, I had about 15 restarts today during ~4 hours of streaming, many of which caused client playback to stall. If ffmpeg could be made to tolerate the interruption, then playback wouldn't stall and all the viewer would see is a glitch in the picture.

Any help would be much appreciated, I've spent many hours trying and failing to solve this!

Tim W

--
Tim Williams BSc MSc MBCS
AutoTrain
58 Jacoby Place
Priory Road
Edgbaston
Birmingham
B5 7UW
United Kingdom

Web : http://www.autotrain.org, http://www.utrain.info Tel : +44 (0)844 487 4117

AutoTrain is a trading name of EuroMotor-AutoTrain LLP Registered in the United Kingdom, number: OC317070.


_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".