SAT>IP Stream Support: [rtsp] method DESCRIBE failed: 404 Not Found #196

Cybolord · 2018-08-09T11:10:28Z

Dear Dev Team,

spent a lot of time in trying to use IPTV Simple Addon for Kodi 17.6 to connect to a Panasonic SAT>IP TV Server via M3U playlist in this format:

#EXTM3U
#EXTINF:0,1. Das Erste HD
rtsp://sat.ip:554?src=1&freq=11491.77&pol=h&msys=dvbs2&mtype=8psk&ro=0.35&plts=off&sr=22000&fec=23

Kodi Logfile offers:

16:46:53.006 T:1906307840 ERROR: ffmpeg[719FF300]: [rtsp] method DESCRIBE failed: 404 Not Found
16:46:53.007 T:1906307840 DEBUG: Error, could not open file rtsp://192.168.100.146/?src=1&freq=11494&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5100,5101,5102,5104
16:46:53.007 T:1906307840 ERROR: OpenDemuxStream - Error creating demuxer

...meanwhile I found out via Wireshark that the used method could be the culprit in here:

IPTV Simple Client Request:

OPTIONS rtsp://sat.ip:554/?src=1&fe=1&freq=11494&pol=h&msys=dvbs2&mtype=8psk&ro=0.35&plts=on&sr=22000&fec=23&pids=0,17,18,5100,5101,5102,5104 RTSP/1.0\r\n
DESCRIBE rtsp://sat.ip:554/?src=1&fe=1&freq=11494&pol=h&msys=dvbs2&mtype=8psk&ro=0.35&plts=on&sr=22000&fec=23&pids=0,17,18,5100,5101,5102,5104 RTSP/1.0\r\n
...404 not found

e.g. VLC or DVB Viewer Request:

SETUP rtsp://sat.ip:554/?src=1&fe=1&freq=11494&pol=h&msys=dvbs2&mtype=8psk&ro=0.35&plts=on&sr=22000&fec=23&pids=0,17,18,5100,5101,5102,5104 RTSP/1.0\r\n
PLAY rtsp://sat.ip:554/stream=14 RTSP/1.0\r\n
...Stream started

Thank you very much for your assistance.

Kind Regards,
Paule

The text was updated successfully, but these errors were encountered:

palinek · 2018-08-10T06:09:49Z

The IPTV Simple doesn't handle the stream URLs anyhow. It just forwards the URL to Kodi, see:

for Krypton (17.*): https://github.com/kodi-pvr/pvr.iptvsimple/blob/2.4.14-Krypton/src/PVRIptvData.cpp#L474 and https://github.com/kodi-pvr/pvr.iptvsimple/blob/2.4.14-Krypton/src/PVRIptvData.cpp#L592
for Leia (18.*): https://github.com/kodi-pvr/pvr.iptvsimple/blob/master/src/client.cpp#L347

... so for finding a solution to your problem, you need to report/contact Kodi core devs.

phunkyfish · 2019-08-27T16:10:40Z

Closing as from v17

tmm1 · 2020-12-14T22:49:55Z

@Cybolord did you find any solution?

…AT>IP behavior Some SAT>IP servers will respond to DESCRIBE sent before SETUP with a 404 In fact, the examples in the SAT>IP spec do not even show DESCRIBE as it is not required. It is assumed that the device will send back MP2T data only. https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax kodi-pvr/pvr.iptvsimple#196

SAT>IP servers do not use DESCRIBE thr same way regular RTSP servers do, since SAT>IP assumes MP2T only. The spec says DESCRIBE will return 404 if no streams are active, and information about the active streams when tuners are a tibe. In the former case ffmpeg would previously fail, and in the latter ffmpeg would previously join an existing stream for a different channel instead of the one requested. https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf (section 3.5.7) https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax kodi-pvr/pvr.iptvsimple#196

SAT>IP servers do not use DESCRIBE the same way regular RTSP servers do, since SAT>IP assumes MP2T only. The spec says DESCRIBE will return 404 if no streams are active, and information about the active streams when tuners are in use. In the former case, ffmpeg would previously fail. In the latter, ffmpeg would join an existing stream for a different channel instead of the one requested. - https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf (section 3.5.7) - https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax - kodi-pvr/pvr.iptvsimple#196

SAT>IP servers do not use DESCRIBE the same way regular RTSP servers do, since SAT>IP assumes MP2T only. The spec says DESCRIBE will return 404 if no streams are active, and information about the active streams when tuners are in use. In the former case, ffmpeg would previously fail. In the latter, ffmpeg would join an existing stream for a different channel instead of the one requested. https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf (section 3.5.7) https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices and fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3]. This commit adds proper spec-compliant support for SAT>IP, including: - support for satip:// urls - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional /UDP suffix confuses some servers [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf (section 3.5.7) [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices and fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional /UDP suffix confuses some servers [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf (section 3.5.7) [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices and fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional /UDP suffix confuses some servers [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices and fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional "/UDP" suffix confuses some servers [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices, but fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional "/UDP" suffix confuses some servers [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices, but fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3][4]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol[5] - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional "/UDP" suffix confuses some servers This patch has been validated against multiple SAT>IP vendor devices: - Kathrein EXIP 418 (https://www.kathrein-ds.com/en/produkte/sat-zf-verteiltechnik/sat-ip/227/exip-418) - Kathrein EXIP 4124 (https://www.kathrein-ds.com/en/products/sat-if-signal-distribution/sat-ip/226/exip-4124) - Megasat MEG-8000 (https://www.megasat.tv/produkt/sat-ip-server-3/) - Megasat Twin (https://www.megasat.tv/en/produkt/sat-ip-server-twin/) - Triax TSS 400 (https://www.conrad.com/p/triax-tss-400-mkii-sat-ip-server-595256) [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196 [4] https://forum.kodi.tv/showthread.php?tid=359072&pid=2995884#pid2995884 [5] https://www.satip.info/resources/channel-lists/

The SAT>IP protocol[1] is similar to RTSP. However SAT>IP servers are assumed to speak only MP2T, so DESCRIBE is not used in the same way. When no streams are active, DESCRIBE will return 404 according to the spec (see section 3.5.7). When streams are active, DESCRIBE will return a list of all current streams along with information about their signal strengths. Previously, attemping to use ffmpeg with a rtsp:// url that points to a SAT>IP server would work with some devices, but fail due to 404 response on others. Further, if the SAT>IP server was already streaming, ffmpeg would incorrectly consume the DESCRIBE SDP response and join an existing tuner instead of requesting a new session with the URL provided by the user. These issues have been noted by many users across the internet[2][3][4]. This commit adds proper spec-compliant support for SAT>IP, including: - support for the satip:// psuedo-protocol[5] - avoiding the use of DESCRIBE - parsing and consuming the com.ses.streamID response header - using "Transport: RTP/AVP;unicast" because the optional "/UDP" suffix confuses some servers This patch has been validated against multiple SAT>IP vendor devices: - Telestar Digibit R2 (https://telestar.de/en/produkt/digibit-r1-2/) - Kathrein EXIP 418 (https://www.kathrein-ds.com/en/produkte/sat-zf-verteiltechnik/sat-ip/227/exip-418) - Kathrein EXIP 4124 (https://www.kathrein-ds.com/en/products/sat-if-signal-distribution/sat-ip/226/exip-4124) - Megasat MEG-8000 (https://www.megasat.tv/produkt/sat-ip-server-3/) - Megasat Twin (https://www.megasat.tv/en/produkt/sat-ip-server-twin/) - Triax TSS 400 (https://www.conrad.com/p/triax-tss-400-mkii-sat-ip-server-595256) [1] https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf [2] https://stackoverflow.com/questions/61194344/does-ffmpeg-violate-the-satip-specification-describe-syntax [3] kodi-pvr/pvr.iptvsimple#196 [4] https://forum.kodi.tv/showthread.php?tid=359072&pid=2995884#pid2995884 [5] https://www.satip.info/resources/channel-lists/

phunkyfish closed this as completed Aug 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SAT>IP Stream Support: [rtsp] method DESCRIBE failed: 404 Not Found #196

SAT>IP Stream Support: [rtsp] method DESCRIBE failed: 404 Not Found #196

Cybolord commented Aug 9, 2018

palinek commented Aug 10, 2018

phunkyfish commented Aug 27, 2019

tmm1 commented Dec 14, 2020

SAT>IP Stream Support: [rtsp] method DESCRIBE failed: 404 Not Found #196

SAT>IP Stream Support: [rtsp] method DESCRIBE failed: 404 Not Found #196

Comments

Cybolord commented Aug 9, 2018

IPTV Simple Client Request:

e.g. VLC or DVB Viewer Request:

palinek commented Aug 10, 2018

phunkyfish commented Aug 27, 2019

tmm1 commented Dec 14, 2020