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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
