Closed stauraum closed 3 years ago
which level of debug would be sufficent?
with -t01 and additional "tcpdebug" , not sure if this is sufficent https://pastebin.com/MxQPU02S
Oh, I see. Your problem is the re-connection timeout and not the keep-alive. Somehow, the video data streaming doesn't start with a PLAY command, but requires one-time or constant RTSP communication, that you've been dealing with OPTIONS commands.
btw you can also use minisatip as a "proxy" with option " -s dvbs:192.168.178.1 -s dvbs:192.168.178.1 " if you have only a satip server available for testing.
I'll try to setup a proper minisatip environment, but it won't happen this week.
there's no rush thank's
should this be the final fix 8130a4b4e5dbe829ad6cf8782f4793635 , if so then there is still an issue with the keep-alive as I have connection timeout issues with the latest git
the timeout is now every 5 seconds before it was every 2 seconds
Oct 21 15:53:10 acer533 vdr: [2077] starting plugin: satip
Oct 21 15:53:10 acer533 vdr: [2077] SATIP: Using CURL 7.58.0 rtsp
Oct 21 15:53:10 acer533 vdr: [2081] SATIP: Adding server '192.168.178.113|DVBS2-4,DVBC-2,DVBT2-2,DVBC2-2|minisatip' Bind: default Filters: none CI: yes Quirks: RtpOverTcp,CiXpmt
Oct 21 15:53:10 acer533 vdr: [2081] SATIP: Adding server '192.168.178.1|DVBC-4|FRITZ!Box 6490 Cable' Bind: default Filters: none CI: no Quirks: PlayPids,ForceLock
Oct 21 15:53:17 acer533 vdr: [2082] SATIP-ERROR: Connection timeout - retuning [device 0]
Oct 21 15:53:17 acer533 vdr: [2082] SATIP: Detected 1 RTP packet error [device 0]
Oct 21 15:53:22 acer533 vdr: [2082] SATIP-ERROR: Connection timeout - retuning [device 0]
Oct 21 15:53:28 acer533 vdr: [2082] SATIP-ERROR: Connection timeout - retuning [device 0]
Oct 21 15:53:33 acer533 vdr: [2082] SATIP-ERROR: Connection timeout - retuning [device 0]
That commit fixed only the existing RTCP issue.
ok makes sense
I've added an ugly fix for this one. It would be great, if someone could point out how the CURL_RTSPREQ_RECEIVE should be used.
98ecd22a2717a03d16433958e81be079c4fac7d8 did work now thank's for fixing it! there is a reference in lib571.c from curl tests
the only issue I can see now is in a mixed setup where one server supports rtsp-over-tcp and the other not like here:
Oct 21 20:01:40 acer533 vdr: [5775] SATIP: Adding server '192.168.178.113|DVBS2-4,DVBC-2,DVBT2-2,DVBC2-2|minisatip' Bind: default Filters: none CI: yes Quirks: RtpOverTcp,CiXpmt
Oct 21 20:01:40 acer533 vdr: [5775] SATIP: Adding server '192.168.178.1|DVBC-4|FRITZ!Box 6490 Cable' Bind: default Filters: none CI: no Quirks: PlayPids,ForceLock
btw the Quirks for "FRITZ!Box 6490 Cable" and "FRITZ!Box 6590 Cable" are obsolete if they have "Fritz OS 7"
I've already removed the quirks earlier and added a note in README as well. What's the issue with your mixed setup?
in case of a mixed setup and rtsp-over-tcp in the plugin menu is set, the minisatip server is working fine now but the Fritzbox will not work as there is no rtsp-over-tcp support implemented in the box. Unicast is working fine for both devices.
maybe a check if the interleave works at the server after SETUP helps to do a fallback to unicast not sure what will be the best option to handle this
SETUP rtsp://192.168.178.129/?src=1&freq=11493&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=23 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: vdr-satip/2.3.1-GIT-8dc4844 (device 0)
RTSP/1.0 200 OK
Date: Tue, Feb 6 22:44:52 2018 GMT
Cseq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
Session: 1804289383;timeout=30
com.ses.streamID: 1
Server: minisatip/0.7.15
@stauraum can you test and close?
A proper fix is still missing, so let's keep this open until it's done.
I've recently been trying to get rtsp-over-tcp working with this plugin on the minisatip server. While searching for info on this, I came across this ticket.
What is the current status here?
With my setup it already fails at the setup of the client to the server. Already here no TCP is requested under transport. I have tried it with 2.3.1 and also with 2.4.1 on several VDRs. Unfortunately everywhere the same. As a cross-check, to be able to exclude the minisatip server as an error, I tried it with VLC. There RTSP over TCP works perfectly together with minisatip.
Thanks
VDR and minisatip with rtp-over-tcp did work
Jan 20 17:46:24 localhost minisatip[10565]: [20/01 17:46:24.955 main]: MSG client >> process :
Jan 20 17:46:24 localhost minisatip[10565]: SETUP rtsp://192.168.178.129/?freq=330&msys=dvbc&mtype=256qam&sr=6900 RTSP/1.0
Jan 20 17:46:24 localhost minisatip[10565]: CSeq: 2
Jan 20 17:46:24 localhost minisatip[10565]: Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Jan 20 17:46:24 localhost minisatip[10565]: User-Agent: vdr-satip/2.4.1-GIT-df81905 (device 0)
Jan 20 17:46:24 localhost minisatip[10565]: #015
Jan 20 17:46:24 localhost minisatip[10565]: [20/01 17:46:24.955 main]: detect_dvb_parameters (S)-> freq=330&msys=dvbc&mtype=256qam&sr=6900
Jan 20 17:46:24 localhost minisatip[10565]: [20/01 17:46:24.955 main]: detect_dvb_parameters (E) -> src=0, fe=0, freq=330000, fec=9, sr=6900000, pol=0, ro=3, msys=1, mtype=5, plts=2, bw=8000000, inv=2, pids=NULL - apids=NULL - dpids=NULL x_pmt=NULL
Jan 20 17:46:24 localhost minisatip[10565]: [20/01 17:46:24.955 main]: Setup stream sid -1 parameters, sock_id 7, handle 7
This is interesting. I have even compiled the same tags that worked for you, but they didn't work for me. There must be differences somewhere. It can't be the minisatip server, because it streams TCP with VLC flawlessly.
Which Linux / VDR /... Version do you use? With which start parameters do you start VDR or the satip plugin? Is the VDR vanilla, or patched?
I'll attach a trace excerpt later that shows it cleanly
vdr 2.4.1 with some patches but I do not think there is a issue, but it could be the curl version(mine is curl 7.68.0)
but if there is no good reason you should use unicast, the rtsp-over-tcp is not well tested and @rofafor likes a proper implementation as you can read some posts obove
Wich Linux distro do you use?
it's Ubuntu 20.04.2 focal
With curl 7.68 out of your Ubuntu?
With RTSP over TCP, WAN streams work much more stable. This is actually the only reason for TCP in my environment.
yes but 7.58 should do also apt-cache policy curl
curl: Installed: 7.68.0-1ubuntu2.4 Candidate: 7.68.0-1ubuntu2.4 Version table: *** 7.68.0-1ubuntu2.4 500 500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 7.68.0-1ubuntu2 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
apt-cache policy libcurl4 libcurl4: Installed: 7.68.0-1ubuntu2.4 Candidate: 7.68.0-1ubuntu2.4 Version table: *** 7.68.0-1ubuntu2.4 500 500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 7.68.0-1ubuntu2 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
please try first rtsp-over-tcp in you local LAN, and if it's not working show us the logs from vdr and minisatip, maybe a packet capture also helps to debug
Thanks for the info. I was going to install a new computer anyway. Then I will connect that right away and test RTSC/TCP again...
Thanks for the info. I was going to install a new computer anyway. Then I can test the RTSP/TCP with the newer versions. Currently my latest curl version is the 7.52 from the MLD-5.4, but it doesn't work with that yet.
All tests so far have been exclusively on the LAN.
I have attached two dumps here. Good case vlc-01-1.pcapng Bad case satip-01-1.pcapng
The minisatip server is on 192.168.100.70
No peculiarity was visible in the VDR logging
setup.conf:
satip.CICAM = 0 0 satip.DisabledFilters = satip.DisabledSources = satip.EnableCIExtension = 0 satip.EnableEITScan = 0 satip.EnableFrontendReuse = 1 satip.OperatingMode = 3 satip.TransportMode = 2
Excerpt from the startup command:
-Psatip -d 2 -s 192.168.100.70|DVBS2-2|Server2
hmm, it may looks like it's as simple as replacing Server2 with minisatip
https://github.com/rofafor/vdr-plugin-satip/blob/a7625c028c460b8350a023db495e2b6b0bc93607/server.c#L126 or you need to enable the needed quirks manually
Wow, so simple, ...Server1...3 is assigned by the MLD via the WebIF. Just took this value for my manual tests and never gave a thought that this value is crosschecked by the satip plugin....
Anyway, it runs with it.
Many thanks for your support and clarification
This issue is still open due to this issue: https://github.com/rofafor/vdr-plugin-satip/blob/master/rtsp.c#L221 I couldn't figure out, why it didn't work as specified.
This issue is still open due to this issue: https://github.com/rofafor/vdr-plugin-satip/blob/master/rtsp.c#L221 I couldn't figure out, why it didn't work as specified.
Unfortunately, I am not a programmer, so I have only a rudimentary idea of what this line is about.
But I can, if there is a need, offer my help for tests. I have enough equipment at my disposal.
This issue is still open due to this issue: https://github.com/rofafor/vdr-plugin-satip/blob/master/rtsp.c#L221 I couldn't figure out, why it didn't work as specified.
@rofafor Do You now the (short) mail thread from the curl mailinglist under How to get a frame of image data from rtsp stream? Maybe the reply gives some help into the proper direction?
There is also some code snippet given (does not seem to work) handled in this RTSP Ip camera frame callback issue #4377
That linked issue looks pretty similar. One can't get the frames via RECEIVE command as it should according to the documentation and I've circumvent it by using OPTIONS command instead. However, I haven't tested the latest libcurl libraries, so might work nowadays.
@rofafor Mhhh...I was searching for code examples but without any positive hits ... maybe this gives a hint to the proper direction multi interface and RTSP interleved referencing to RTSP Interleaved Multi Interface
I am neither an expert for SAT>IP nor RTSP but what would like like to achieve changing the current setup? In principle it is working as supposed to or am I wrong?
Closing this due to inactivity. There's a FIXME
comment in the code reminding about this.
I don't know whats wrong.