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

[Tim Williams]

On 19/10/17 13:19, Alex Molon wrote:
> 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


-- 


Web : http://www.autotrain.org