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

[Tim Williams]

Hi All,

I've been trying to cure this problem for several weeks (this was
previously posted on Stackoverflow and the ffmpeg forum, but I got no
replies).

To summarise, I'm using FFMPEG to restream a live video webcam. The
camera bitrate is set to 1Mbps and it's on an ADSL line which has a
fairly consistent upload speed of 6Mbps, so there's plenty of bandwidth.
The FFMPEG (version 3.3.4) command I'm currently using looks like this:

ffmpeg -loglevel debug -err_detect ignore_err -bug trunc -rtsp_transport
tcp -i rtsp://user:password@mycamera.com/live/ch0 -reset_timestamps 1
-movflags empty_moov+omit_tfhd_offset+frag_keyframe+default_base_moof
-bufsize 7168k -stimeout 60000 -segment_list_flags +live
-hls_allow_cache 0  -hls_flags temp_file+omit_endlist+discont_start
-hls_time 10 -hls_wrap 90 -muxpreload 15 -muxdelay 15 -start_number 410
-acodec none -vcodec copy streaming.m3u8

I've tried quite a few variations of the options, with no impact on the
problem, you'll note that I've added a lot of parameters to try and
buffer the input and tolerate errors. Sometimes the stream will run for
several hours without any trouble, on other occasions the stream will
fail every few minutes with the error:

"No more output streams to write to, finishing."

I've done a lot of testing and this error seems to be misleading. It
actually occurs as a result of an interruption to the RTSP input, but
the error is delayed until the connection is re-established. If I test
this by deliberately cutting the network connection between the camera
and FFMPEG, FFMPEG will wait for the connection to be re-established for
quite a long time. If the interruption was long (>10 seconds) the stream
will then immediately drop with the "No More Outputs" error the instant
that the network connection is re-established. If the interruption is
short, then RTSP will actually start pulling data from the camera again,
but the stream will then drop with the same error a few seconds later.
So it seems that the gap in the input stream causes the HLS encoder to
give up with the error. Is there any option I can use that will enable
HLS to tolerate missing data in the input?

I've got code which monitors the ffmpeg process and automatically
restarts it when the stream drops, from the correct HLS segment number,
but this causes problems with client playback which will frequently
stall permanently if this happens too many times quickly in succession,
which is usually the case when there is a problem.

I suspect that I have a quality of service problem on the router which
might be the underlying cause of the interruptions, I hope to solve this
in the next few weeks but it requires a site visit to a location that's
2-3 hours drive from home. However, even if the QOS issue is solved,
it's likely that there will still be occasional interruptions to the
input when the network connection is busy and I would rather that the
HLS encoder was able to tolerate gaps in the input? I've successfully
built ffmpeg binaries from source, so if this needs a custom code patch,
that's not a problem and I don't particularly care if the patch breaks
ffmpeg HLS in other circumstances, I just need a binary that works for
this specific use case, it won't be used for anything else.

Thanks in anticipation!

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.