[enen92]

I am wondering if simply configuring a backend that can talk the sat>IP protocol and expose the streams to Kodi would not be easier and enough for what you want to do. Example:

http://oapeon.blogspot.com/2016/04/using...r.html?m=1

Or using minisatip: https://github.com/catalinii/minisatip

[phunkyfish]

What I’m looking for is an example of the URL you call locally. The url format used by various devices tends to differ and it also usually specifies things like the multicast port.

As an example users instead of call the rtsp link sometimes use something like this for satip devices.

Code:


rtp://[email protected]:10000


Which is roughly the equivalent of

Code:


rtp://232.0.10.35:10000/sources=87.141.215.251


But unless I know the format of URL you end up with it’s hard to know a working solution.

[phunkyfish]

Also, have you tried to open the rtsp url with ffplay? That is usually a good test to see what ffmpeg supports natively. It does have full rtsp support.

[stko]

I am wondering if simply configuring a backend that can talk the sat>IP protocol and expose the streams to Kodi would not be easier and enough for what you want to do. Example:

http://oapeon.blogspot.com/2016/04/using...r.html?m=1

Or using minisatip: https://github.com/catalinii/minisatip

I understand, but I really would like to avoid another piece of software between my SAT server as source and Kodi as player. Expecially as if I would not like to have any UI to operate on the tvheadend or Kodi side - just because I'm made another software for the user interface and use Kodi just to play streams on request

The minisatip does (roughly) the same as what my Sat>IP black box is doing: Providing sat streams. But for minisatip you'll need a computer with DVB-S cards. That is what I have already today as a LinVDR system, but this PC solution is big and expensive, you always hear the active cooling, and it always  needs to be booted before use to save power when not used.

To get rid of these disadvantages, I found these Sat>IP "black box" server solutions quite nice (https://www.amazon.de/MegaSat-0600208-Sa...B0718X8DRM)

[stko]

What I’m looking for is an example of the URL you call locally. The url format used by various devices tends to differ and it also usually specifies things like the multicast port.

As an example users instead of call the rtsp link sometimes use something like this for satip devices.

Code:


rtp://[email protected]:10000


Which is roughly the equivalent of

Code:


rtp://232.0.10.35:10000/sources=87.141.215.251


But unless I know the format of URL you end up with it’s hard to know a working solution.

A working link looks like this: rtsp://<my_box_IP>/?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

This works when starting vlc with it

Code:


vlc  rtsp://<my_box_IP>/?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


it also works when starting vlc with 

Code:


vlc  satip://<my_box_IP>/?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


because vlc knows that satip protocol


When listen to the traffic with WireShark and try to start the stream with ffmpeg, vlc , curl and another rtsp-download tool, it becomes obvious that ffmpeg, the tool, etc. are initiating a sequence (accourding the  rtsp protocol?) with a DESCRIBE command, but DESCRIPE is not part of the satip- protocol, so the box replies with error code 404, and the tools stops by throwing an error message. Only vlc ignores that error code 404 and continues with the protocol initialisation, so that finally the sat box send the rtp data as UDP packets to the IP adress from where the request was initiated (= my client)

When simulating the satip protocol with python on the kodi machine and then let Kodi play the url rtp://0.0.0.0:60480, it works: The simulation makes the sat box to send UDP packets, and Kodi receives and plays 'em

[stko]

 

"so the box replies with error code 404, and the tools stops by throwing an error message. Only vlc ignores that error code 404 and continues .."

That could mean that if ffmepg (=kodi) would just ignore the error 404 and continue, that might work already, depending on which other commands ffmpeg would send as next and if this would match to what the SAT box would expect to come.. 

[tmm1]

Hi, I'm looking at patching ffmpeg to ignore the DESCRIBE 404 as you suggested. But doesn't the DESCRIBE return the SDP required to setup the connection? If you can share your python script or wireshark, that would be helpful in figuring out what needs to happen inside ffmpeg.

[stko]

Hi, I'm looking at patching ffmpeg to ignore the DESCRIBE 404 as you suggested. But doesn't the DESCRIBE return the SDP required to setup the connection? If you can share your python script or wireshark, that would be helpful in figuring out what needs to happen inside ffmpeg.

Good morning

You are welcome :-)

I would like to show the wireshark traces for ffmpeg and VLC, because it nicely shows the differences when VLC is handling either the rstp.// or the satip:// prococol

First we do the ffmpeg request:

ffmpeg -i 'rtsp://192.168.1.99:554/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,167,136,47,71' -acodec copy -vcodec copy test.mp4

Code:


OPTIONS rtsp://192.168.1.99:554/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,167,136,47,71 RTSP/1.0
CSeq: 1
User-Agent: Lavf57.83.100

RTSP/1.0 200 OK
CSeq: 1
Date: Thu, 01 Jan 1970 00:19:02 GMT
Public: OPTIONS,DESCRIBE,SETUP,PLAY,TEARDOWN

DESCRIBE rtsp://192.168.1.99:554/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,167,136,47,71 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf57.83.100

RTSP/1.0 404 Not Found
CSeq: 2



So as you can see, ffmpeg (and other tried tools) fail on the DESCRIPE command

Now we try to start ffmeg with a satip:// request

ffmpeg -i 'satip://192.168.1.99:554/?src=1&freq=12188&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34&pids=0,17,18,167,136,47,71' -acodec copy -vcodec copy test.mp4

and we get the error message

satip://192.168....: Protocol not found

So ffmpeg obviously don't know a satip( 


Now we trying VLC. We can start VLC with both rtsp:// or satip://, both is accepted

vlc 'rtsp://192.168.1.99:554/?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'
or
vlc 'satip://192.168.1.99:554/?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'


The communication is the same (!) in both cases. As you can see, VLC is using different commands even for the rtsp:// request. These commands follow the SATIP specification, but probably not the RTSP spec..

Code:

SETUP rtsp://192.168.1.99:554/?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 RTSP/1.0
CSeq: 0
Transport: RTP/AVP;unicast;client_port=9088-9089

RTSP/1.0 200 OK
CSeq: 0
Date: Thu, 01 Jan 1970 00:02:45 GMT
Session: AB18C70;timeout=60
Transport: RTP/AVP;unicast;destination=192.168.1.85;source=192.168.1.99;client_port=9088-9089
com.ses.streamID: 1

PLAY rtsp://192.168.1.99:554/stream=1 RTSP/1.0
CSeq: 1
Session: AB18C70

RTSP/1.0 200 OK
CSeq: 1
Date: Thu, 01 Jan 1970 00:02:45 GMT
Session: AB18C70
RTP-info: url=rtsp://192.168.1.99/stream=1

TEARDOWN rtsp://192.168.1.99:554/stream=1 RTSP/1.0
CSeq: 2
Session: AB18C70

RTSP/1.0 200 OK
CSeq: 2
Date: Thu, 01 Jan 1970 00:02:51 GMT
Session: AB18C70


After the PLAY command, the server is sending UPD RTP packets to the destination ip and port, which can be received there even with Kodi as rtp://0.0.0.0:client_port[0]

The TEARDOWN command is sent at the end when stopping the player to release the server stream resources.


My work-in-progress source you can find here in https://paste.kodi.tv/lazubodogu


I hope this infomation might help. Of course it would be marvelous if you could extend ffmeg to the satip:// protocol. That would not only help me, it also would enable that other Kodi plugins like the Simple IPTV could use SAT>IP hardware natively without the need of having a "translator" like tvheadend or dvbviewer in between.

If there's anything I could help you with, please let me know

regards
Steffen

[tmm1]

Thanks!

satip:// is just an alias for rtsp://, so it doesn't matter which one you use. ffmpeg only understands rtsp:// but the behavior will be the same.

I think ffmpeg can be taught to interpret 404 from DESCRIBE as a trigger to fallback to simpler satip behavior.

However a patch is going to be hard to develop if I cannot test during development. Is there any way you could provide temporary access to your satip box? (vpn, ssh, etc)

What platform are you using (mac, windows)?

[stko]

Thanks!

satip:// is just an alias for rtsp://, so it doesn't matter which one you use. ffmpeg only understands rtsp:// but the behavior will be the same.

I think ffmpeg can be taught to interpret 404 from DESCRIBE as a trigger to fallback to simpler satip behavior.

However a patch is going to be hard to develop if I cannot test during development. Is there any way you could provide temporary access to your satip box? (vpn, ssh, etc)

What platform are you using (mac, windows)?

Hi
yes, I think an access should be possible. I can probably open a port on my router for the communication port - but I think I can not forward the sat movie rtp udp packets, at least I've never tried that.. As soon I've set it up, I'll send you the link via PM

I also need to mention, that I've forgotten one important thing in the wireshark traces:

The initiating client need to send a regular keep_alive message to the server, which frequence must be less then the timeout parameter received from the server as answer for the SETUP command. You can find this keepalive message as OPTIONS command in my sample source code.

I'm working here neither on windows nor on a Mac, I'm using Linux Ubuntu instead. My Kodi instance, on which my script is tested is an Raspi 3 with Kodi 18.x (the actual one)


In case the port forwarding would not work well, I could maybe setup a little python  script which would simulate the server handshake. Let us try what would work best.

So I'll try to setup the port forwarding now and let you know the results asap via PM

Thanks in advance
Steffen

[tmm1]

I'm using Linux Ubuntu instead

Great.

I have one simple patch which makes it so `ffmpeg -loglevel debug` will show the RTSP request/responses. Easier to debug without needing wireshark.

Code:


diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..a33924babc 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1195,7 +1195,7 @@ start:
         }
         *q = '\0';

-        av_log(s, AV_LOG_TRACE, "line='%s'\n", buf);
+        av_log(s, AV_LOG_DEBUG, "line='%s'\n", buf);

         /* test if last line */
         if (buf[0] == '\0')
@@ -1350,7 +1350,7 @@ static int rtsp_send_cmd_with_content_async(AVFormatContext *s,
         out_buf = base64buf;
     }

-    av_log(s, AV_LOG_TRACE, "Sending:\n%s--\n", buf);
+    av_log(s, AV_LOG_DEBUG, "Sending:\n%s--\n", buf);

     ffurl_write(rt->rtsp_hd_out, out_buf, strlen(out_buf));
     if (send_content_length > 0 && send_content) {


I also started on a patch to handle DESCRIBE 404, and to parse com.ses.streamID as required by SATIP spec. Hopefully if I can connect to your satip server I can test it out.

[tmm1]

BTW which model satip server is this that you're using?

[stko]

BTW which model satip server is this that you're using?

I'm using a https://www.amazon.de/MegaSat-0600208-Sa...B0718X8DRM.

I've also found during my investigations that as bigger the server model is, as more features (=protocols) it seems to support. But my model is one of the cheapest and smallest one and support just this satip protocol. Unfortunally all these small models seems to disappear from the market. As I started to program my own video recorder a half a year ago, there where several small models available. But if I search for them now, they are mostly shown as out of stock  - I don't know what's going on there 

[tmm1]

I have published my patches here: https://github.com/FFmpeg/FFmpeg/compare...provements

[phunkyfish]

I will add these patches to ffmpegdirect over the next few days. What platform are you testing on?