Re: [FFmpeg-user] RTSP to HLS
Hello again,
maybe someone could help a ffmpeg-newbie to get the correct hls-settings
(hope there is something possible without re-encoding). The GOP is
IPP 31 CLOSED (got it from this script
https://gist.github.com/ragnraok/638023456771dc596e6f953b47061f0e).
Thanks,
Thomas
Am 14.11.2020 um 01:35 schrieb Thomas Schmiedl:
Hello,
I try to local restream https://herberts.meinekameras.de:10169
(rtsp-over-websocket) with this workflow: Go-script (proxy websocket to
rtsp) -> ffmpeg (rtsp to hls) -> xupnpd2 mediaserver -> vlc or TV.
It works good in vlc, but on the TV it plays too fast and there are
pauses. I tested all 4 hls-handlers (hls, hls2, hls3, hls4) in xupnpd2
with the same result.
ffmpeg command:
ffmpeg -re -rtsp_transport tcp -i
"rtsp://localhost:8554/axis-media/media.amp?overview=0=1=1280x720=empty=true=15"
-c copy -f hls /home/user/lighttpd-install/htdocs/stream.m3u8
Hope that someone could test the workflow and maybe optimize the
ffmpeg-command.
Thanks,
Thomas
PS: I never had this issue in xupnpd2 when receiving hls-streams
directly from the internet.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
package main
import (
"net"
"fmt"
"crypto/tls"
"net/http"
"github.com/gorilla/websocket"
)
func handleConn(tcpConn net.Conn) {
d := websocket.Dialer{TLSClientConfig: {InsecureSkipVerify:
true}}
wsConn, _, err :=
d.Dial("wss://herberts.meinekameras.de:10169/rtsp-over-websocket", http.Header{
"Sec-WebSocket-Protocol": []string{"binary"},
})
if err != nil {
panic(err)
}
go func() {
defer tcpConn.Close()
buf := make([]byte, 10 * 1024)
for {
n, err := tcpConn.Read(buf)
if err != nil {
return
}
wsConn.WriteMessage(websocket.BinaryMessage, buf[:n])
}
}()
go func() {
defer wsConn.Close()
for {
_, buf, err := wsConn.ReadMessage()
if err != nil {
return
}
tcpConn.Write(buf)
}
}()
}
func main() {
l, err := net.Listen("tcp", ":8554")
if err != nil {
panic(err)
}
fmt.Println("ready")
for {
tcpConn, err := l.Accept()
if err != nil {
panic(err)
}
go handleConn(tcpConn)
}
}
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] RTSP to HLS re-stream stops with “No more output streams to write to, finishing.”
On 19/10/17 13:19, Alex Molon wrote: > Did you try with something like this? > > ffmpeg -i url://whatever/link.ext?fifo_size=100_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".
Re: [FFmpeg-user] RTSP to HLS re-stream stops with “No more output streams to write to, finishing.”
Did you try with something like this? ffmpeg -i url://whatever/link.ext?fifo_size=100_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-boun...@ffmpeg.org] On Behalf Of Tim Williams Sent: 18 October 2017 14:11 To: ffmpeg-user@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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ 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".
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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] RTSP to HLS re-stream stops with “No more output streams to write to, finishing.”
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 : +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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
