Project

General

Profile

Actions

Feature #4449

closed

SAT>IP: Fix tuner status in state 1 when client waits for RTCP messages

Added by DSA APF almost 8 years ago. Updated almost 8 years ago.

Status:
Fixed
Priority:
Normal
Category:
SAT>IP
Target version:
-
Start date:
2017-06-20
Due date:
% Done:

100%

Estimated time:

Description

Hi,

We like to publish another useful patch for SAT>IP that fixes some specific case.

First the description of the problem:

When a SAT>IP client likes to tune one frequency, at minimum two commands are required: SETUP and PLAY. The trouble is related about the server actions in between the two commands. As described in the SAT>IP documentation (diagram “Server Stream Output State Machine” at section 3.5.3 page 34 of version 1.2.2), the sever doesn’t need to stream anything in the State 1 (the middle state after SETUP (unicast) and previous to PLAY).

However, several SAT>IP clients are requesting in the SETUP command a list of pids. Then, they expect to start receiving some RTCP packets with the tuner status... just after receive the response to the SETUP command over the RTSP protocol. The idea behind this is to receive some confirmation of the tuner status to asserting that the frequency is locked. And only after receiving a good signal status the client will sends the PLAY command.

We have confirmed this behaviour with several clients (hardware and software). And if the client doesn’t receive any RTCP packet then it fails and doesn’t send the PLAY command.

The specification is ambiguous about this behaviour. It is not described in the document. However, a lot of implementations assume this behaviour. In fact, it has sense, as the SETUP command implies a “tuning action”. And when a tuner is active the RTCP messages must be received indicating the status. However, if the server is in state 1 (no streaming), it’s common then that it doesn’t send any RTCP command.

So, we have prepared one patch that implements this behaviour in TVHeadend. It fixes a lot of scanning failures with a large list of SAT>IP clients. For sure, it only has sense with clients that require receiving RTCP packets before sending the PLAY command. With other clients this patch is completely transparent. So don’t care about breaking functionality with other clients.

We hope you agree to commit this patch.
Regards,
D.

Here the path (Fix_tuner_status.diff):

--- tvheadend/src/satip/rtsp.c    2016-04-04 14:00:41.187765643 +0200
+++ tvheadend/src/satip/rtsp.c    2016-04-04 14:39:47.289866499 +0200
@@ -577,6 +578,11 @@ rtsp_start
     if (oldstate) {
       setup = 0;
       rs->state = STATE_SETUP;
+      tvhtrace("satips", "Change State to SETUP (1)");
+    }
+    if (setup && (rs->state == STATE_DESCRIBE)) {
+      rs->state = STATE_SETUP;
+      tvhtrace("satips", "Change State to SETUP (2)");
     }
   } else {
 pids:
@@ -590,7 +596,7 @@ pids:
     if (rs->used_weight != weight && weight > 0)
       subscription_set_weight(rs->subs, rs->used_weight = weight);
   }
-  if (!setup && rs->state != STATE_PLAY) {
+  if ((!setup && rs->state != STATE_PLAY) || (setup && (rs->state == STATE_SETUP))) {
     if (rs->mux == NULL)
       goto endclean;
     satip_rtp_queue((void *)(intptr_t)rs->stream,
@@ -1223,7 +1229,7 @@ rtsp_describe_header(session_t *rs, htsb
 static void
 rtsp_describe_session(session_t *rs, htsbuf_queue_t *q)
 {
-  char buf[4096];
+  char buf[8192];

   htsbuf_qprintf(q, "a=control:stream=%d\r\n", rs->stream);
   htsbuf_append_str(q, "a=tool:tvheadend\r\n");
@@ -1232,10 +1238,15 @@ rtsp_describe_session(session_t *rs, hts
     htsbuf_append_str(q, "c=IN IP6 ::0\r\n");
   else
     htsbuf_append_str(q, "c=IN IP4 0.0.0.0\r\n");
+  tvhtrace("satips", "Rtsp_describe_session: rs->state=%i,rs->stream=%i",rs->state,rs->stream);
   if (rs->state == STATE_PLAY) {
     satip_rtp_status((void *)(intptr_t)rs->stream, buf, sizeof(buf));
     htsbuf_qprintf(q, "a=fmtp:33 %s\r\n", buf);
     htsbuf_append_str(q, "a=sendonly\r\n");
+  } else if (rs->state == STATE_SETUP) {
+    //fixme: send real tuner status (at this point the status is empty!)
+    htsbuf_append_str(q, "a=fmtp:33 ver=1.0;src=0;tuner=0,240,1,15,,,,,,,,;pids=all\r\n");
+    htsbuf_append_str(q, "a=sendonly\r\n");
   } else {
     htsbuf_append_str(q, "a=fmtp:33\r\n");
     htsbuf_append_str(q, "a=inactive\r\n");

Actions

Also available in: Atom PDF