[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:***@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 : [phone]

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


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

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with

[Tim Williams]

An additional point, I did try re-encoding the video rather than just
coping the stream, the "No more outputs" error went away but the
behaviour was the same, ffmpeg will exit when the connection to the
camera is re-established. I would prefer to avoid re-encoding if
possible since this will mean a hosting cost increase, the VPS this is
running on is only just fast enough to do the re-encode so will need an
upgrade to actually serve the streams.

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 : [phone]

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

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

To unsubscribe, visit link above, or email
ffmpeg-user-***@ff

[Tim Williams]

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 : [phone]

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


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

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with subject "u

[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-***@ffmpeg.org] On Behalf Of Tim Williams
Sent: 18 October 2017 14:11
To: ffmpeg-***@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 : [phone]

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


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

To unsubscribe, visit link above, or email ffmpeg-user-***@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
ffmpeg-***@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-***@ffmpeg.org with

[Tim Williams]

Post by 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...

I'm not certain I know how to make that work with an RTSP webcam, the
ports used for the UDP/RTP aren't fixed so how do I work out what port
to use in the URL? Will a camera designed to work with RTSP send data
requested in this way?

That said, I have however finally found a way to get around this problem
so the above questions are (I hope) purely for academic interest. I've
got a Raspberry Pi 0 sitting on the same network as the webcam, the RPi
maintains a VPN link to the server. Incoming RTSP requests (from the
VPN) are forwarded on to the camera by firewall rules on the RPi, while
further rules are set to forward everything on ports 6970-6999 that
comes from the camera to the RPi back to the server. On the server I'm
using the live555 openRTSP client to initiate a unicast RTP/UDP session
using a specific port number via the -p option. This seems to have
finally cured the problem, I had a stream run for 9 hours today without
interruption. I found it necessary to use the -K option of openRTSP
which sends "keepalive" requests, without this the RTP/UDP stream stops
after 2 minutes. openRTSP then pipes into ffmpeg to do the encoding.

One thing that using openRTSP has shown is that part of the problem
might have been down to a bug in the camera firmware. When accessing a
video using TCP via the RTSP port, if the stream dropped, openRTSP would
attempt to re-connect using the same session information, however the
camera would respond to this with a 500 internal error, causing openRTSP
to bail out. If ffmpeg does the same then that would explain the
behaviour I experienced. So it may not after all be a bug in ffmpeg
causing this problem. However it would be nice if there was a workaround
option (in either client!) which allow this to be avoided by attempting
a full restart with a new session number before giving up.

Tim W