Tvheadend

Hi Jaroslav,

Great improvement. Thank you!

However, we found a very slight problem...

Some clients (not very good implemented), expect this behaviour: When the stream is tuned –in this case when "lock" changes to 1– the client would expect to start receiving the RTP stream. This is a real misinterpretation of the standard. As the server only starts to stream when a PLAY command is received. But a lot of clients interpret that a SETUP command with a pid list implies an implicit PLAY. Obviously, this is incorrect. However, for supporting these clients will be necessary to have this behaviour.

So, you agree to add one Config parameter for the SAT>IP Server (for example, "IMPLICIT PLAY AFTER SETUP") and start to stream when the lock goes true if this config value is set?

With our original patch this is the behaviour of the SAT>IP server. But with your (correct) implementation a lot of clients fails. So, making this special behaviour optional all type of clients will be supported.

You agree?
Regards,
D.

Could you show me the RTSP communication between such bad client and server when things works? Is PLAY command issued or this step is completely ignored? Can be clients detected by something in the RTSP communication (User-Agent or so)?

The current (my) implementation sends only RTCP after SETUP and RTP data after PLAY (as it is described in the spec).

Hi Jaroslav,

Jaroslav Kysela wrote:

Could you show me the RTSP communication between such bad client and server when things works? Is PLAY command issued or this step is completely ignored? Can be clients detected by something in the RTSP communication (User-Agent or so)?

We can prepare it. However, I feel it isn't need. The behaviour is quite simple: These clients will send the PLAY command, however only after start to receive the RTP packets. So the command PLAY isn't ignored.

The current (my) implementation sends only RTCP after SETUP and RTP data after PLAY (as it is described in the spec).

An your implementation is correct! The trouble is in such clients.
However, the solution for supporting them is quite simple: with one option (and this point is very relevant, that is only if this option is enabled) the server starts to send the RTP stream just when the lock is true. The internal state-machine will be the same, as after some time the server will receive the PLAY command from the client. The timeout to close the stream if no keep-alives are received (with the OPTIONS command) is the same. Nothing changes, only the moment when starting the RTP stream.

I like to be clear: The problem is the misinterpretation of the standard by several clients. They think that a SETUP command with a pid list implies a PLAY command. So they interpret that his SETUP command triggers a directly change from "Initial State" to "State 2" (see diagram of page 34 in the Specs). This breaks the standard! However, it will be very easy to include a workaround.

Please, can you consider to add the option for fixing these clients?
Regards,
D.

Do you know (or could you test), if it is enough to send 'empty' RTP packets until PLAY is received from the client? Perhaps, it would be good to compare the certified SAT>IP server how it exactly behaves in this case.

Hi Jaroslav,

Here the RTSP communication between such bad clients and the TVH with our old patch:

>>
SETUP rtsp://192.168.11.9:554/stream=17?src=1&ro=0.35&plts=off&fec=56&msys=dvbs&mtype=qpsk&freq=10744&pol=h&sr=22000&pids=0,1,2,16,17,18,19,20 RTSP/1.0
CSeq: 95
Session: 271BE3A1
Transport: RTP/AVP;unicast;client_port=50428-50429
>>
<<
RTSP/1.0 200 OK
CSeq: 95
Session: 271BE3A1;timeout=30
Transport: RTP/AVP;unicast;client_port=50428-50429
com.ses.streamID: 18
<<

>>
DESCRIBE rtsp://192.168.11.9:554/stream=18 RTSP/1.0
CSeq: 96
Accept: application/sdp
>>
<<
RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 890
CSeq: 96
Content-Base: rtsp://192.168.11.108/stream=18

v=0
o=- 8555094662212 8555094662335 IN IP4 192.168.11.108
s=SatIPServer:1 8
t=0 0
a=control:stream=11
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=12
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=13
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=14
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=15
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=16
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=18
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33 ver=1.0;src=0;tuner=0,239,1,15,10744,h,dvbs,qpsk,off,35,22000,56;pids=0,1,2,16,17,18,19,20
a=sendonly
<<

>>
DESCRIBE rtsp://192.168.11.9:554/stream=18 RTSP/1.0
CSeq: 97
Accept: application/sdp
>>
<<
RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 890
CSeq: 97
Content-Base: rtsp://192.168.11.108/stream=18

o=- 8555095062792 8555095062915 IN IP4 192.168.11.108
s=SatIPServer:1 8
t=0 0
a=control:stream=11
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=12
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=13
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=14
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=15
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=16
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=18
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33 ver=1.0;src=0;tuner=0,239,1,15,10744,h,dvbs,qpsk,off,35,22000,56;pids=0,1,2,16,17,18,19,20
a=sendonly
<<

>>
DESCRIBE rtsp://192.168.11.9:554/stream=18 RTSP/1.0
CSeq: 98
Accept: application/sdp
>>
<<
RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 890
CSeq: 98
Content-Base: rtsp://192.168.11.108/stream=18

o=- 8555095533642 8555095533765 IN IP4 192.168.11.108
s=SatIPServer:1 8
t=0 0
a=control:stream=11
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=12
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=13
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=14
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=15
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=16
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33
a=inactive
a=control:stream=18
a=tool:tvheadend
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
a=fmtp:33 ver=1.0;src=0;tuner=0,239,1,15,10744,h,dvbs,qpsk,off,35,22000,56;pids=0,1,2,16,17,18,19,20
a=sendonly
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=100 RTSP/1.0
CSeq: 99
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 99
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=200 RTSP/1.0
CSeq: 100
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 100
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=300 RTSP/1.0
CSeq: 101
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 101
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=400 RTSP/1.0
CSeq: 102
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 102
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=500 RTSP/1.0
CSeq: 103
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 103
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?addpids=600 RTSP/1.0
CSeq: 104
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 104
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=100 RTSP/1.0
CSeq: 105
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 105
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=200 RTSP/1.0
CSeq: 106
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 106
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=300 RTSP/1.0
CSeq: 107
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 107
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=400 RTSP/1.0
CSeq: 108
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 108
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=500 RTSP/1.0
CSeq: 109
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 109
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

>>
PLAY rtsp://192.168.11.9:554/stream=18?delpids=600 RTSP/1.0
CSeq: 110
Session: 271BE3A1
>>
<<
RTSP/1.0 200 OK
CSeq: 110
RTP-Info: url=rtsp://192.168.11.108/stream=18
Session: 271BE3A1
<<

As you can see, the client sends a SETUP, and after some DESCRIBES... waiting for receiving the RTP stream. And when it receives the stream, then it adds more pids using the PLAY command. The conclusion is easy: the client assumes an implicit PLAY with the first SETUP.

Please, if that seems reasonable to you, it would be good to include that option for supporting such type of clients.
Do you agree?
D.

Jaroslav Kysela wrote:

Do you know (or could you test), if it is enough to send 'empty' RTP packets until PLAY is received from the client? Perhaps, it would be good to compare the certified SAT>IP server how it exactly behaves in this case.

Hi,

Of course, we can test it!

However, I prefer the simple assumption (as an option) of an implicit PLAY with a SETUP with a pid list (a SETUP command without a pid list, doesn't need this, as the client in this case assumes the correct behaviour). I'm sure that this option will fixes the troubles with a lot of wrong SAT>IP clients.

So, the "hack" is this: When the lock goes true and the pid list isn't empty, then automatically change the state to play (State 2) and start the RTP streaming.

Regards.

Looking again to spec, diagram in 3.5.9 paragraph (RTSP Method Summary / RTSP State machine). It appears that if PLAY is issued, then the client can send SETUP for the current session which modifies the transport parameters, but the server should stay in the playing state. Could you check, if there's PLAY before the new SETUP and if client sends PLAY after the first SETUP regarless RTP data are sent in this case?

Jaroslav Kysela wrote:

Looking again to spec, diagram in 3.5.9 paragraph (RTSP Method Summary / RTSP State machine). It appears that if PLAY is issued, then the client can send SETUP for the current session which modifies the transport parameters, but the server should stay in the playing state. Could you check, if there's PLAY before the new SETUP and if client sends PLAY after the first SETUP regarless RTP data are sent in this case?

OK, a next patch which should keep the playing state when a new SETUP is received after PLAY for the new session. Also, I fixed the stream filtering for DESCRIBE.

Hi Jaroslav,

The current version only works partially. During the scanning process several clients continue having troubles.
However, we finally find where the problem is:

- First of all, you're right. The diagram in 3.5.9 shows a different behaviour of SETUP with the "stream=" parameter and without it. And this is the key question.

- Now, when a new SETUP is received without "stream=" you create a new stream. And this is right.

- But when you receive a SETUP with the "stream=" the behaviour is incorrect. First, you create a new stream (as the response with the OK increases the number of the stream in 1 unit). The client can (or can not) interpret this response right (some do it correctly). However, then you wait for a PLAY command, but clients wait for the RTP stream... Why? Because for you is another stream (and the PLAY it's required). But for the client is the same stream, and you're in the play state. So, here is the bug!

But the solution is in fact very simple:

- In the standard (and in my opinion it's a very bad idea to support synonyms), in the playing state the PLAY and SETUP commands are identical if: 1) both have the "stream" parameter, AND 2) both change the frequency (or other tunning parameters).

- Several clients use the SETUP command when changing the frequency, and the PLAY command when chaging the pids list. So when requesting a change of the stream with a SETUP/stream=...&src=..., in this specific case this is identical to PLAY/stream=...&src=... And this is the case we call IMPLICIT PLAY WHEN SETUP.

As a consequence, a simple solution can be: When you receive a SETUP command with a "stream" parameter, and if the stream is valid (and owned by the client), then you can replace 'SETUP' with 'PLAY ' in the request and process it. This will solve the problem.

You agree?
D.

Jaroslav Kysela wrote:

Could you check, if there's PLAY before the new SETUP and if client sends PLAY after the first SETUP regarless RTP data are sent in this case?

Regarding this specific question:

1) All tested clients send the PLAY command after the initial SETUP (= a new setup without the stream parameter).

2) Only a very few list of clients send a PLAY command after one SETUP with the stream parameter. And this is independent whether or not they receive the RTP stream.

I guess you can see where the problem is, right?

Hi Jaroslav,

We have created a patch that provides the correct behaviour:

--- a/src/satip/rtsp.c
+++ b/src/satip/rtsp.c
@@ -956,8 +956,10 @@ rtsp_parse_cmd
         *valid = 1;
         goto ok;
       }
-      *oldstate = rs->state;
-      rtsp_close_session(rs);
+      // *oldstate = rs->state;
+      cmd = RTSP_CMD_PLAY;
+      goto setup_with_session;
+      // rtsp_close_session(rs);
     }
     if (cmd == RTSP_CMD_SETUP) {
       r = parse_transport(hc);
@@ -979,6 +981,7 @@ rtsp_parse_cmd
         errcode = HTTP_STATUS_NOT_FOUND;
       goto end;
     }
+setup_with_session:
     *oldstate = rs->state;
     dmc = &rs->dmc;
     if (rs->mux == NULL)

The solution is very simple!
Regards,
D.

Hi Jaroslav,

Please, forget about the previous patch. It doesn't work! See the patches presented in #4499.
If you like to continue on the other thread, then close this one.

Regards,
D.