Recording service streaming problems

[nzsjb]

A use of my software (EPG Collector) has been using the Recording Service 1.33.1.0 as a Sat>IP server and may have uncovered a couple of problems with the messages/responses generated by the Recording Service.

 

Firstly the response from a Describe request seems incorrect.

 

12:07:50:493 RTSP DESCRIBE response:

12:07:50:498 RTSP DESCRIBE response: v=0

12:07:50:500 RTSP DESCRIBE response: o=- 6716311 1 IN IP4 192.168.1.201

12:07:50:502 RTSP DESCRIBE response: s=SatIPServer:1 4

12:07:50:503 RTSP DESCRIBE response: t=0 0

12:07:50:505 RTSP DESCRIBE response: a=tool:DVBVRS

12:07:50:507 RTSP DESCRIBE response: a=control:rtsp://192.168.1.201:554/stream=13

12:07:50:508 RTSP DESCRIBE response: m=video 6200 RTP/AVP 33

12:07:50:509 RTSP DESCRIBE response: c=IN IP4 0.0.0.0

12:07:50:510 RTSP DESCRIBE response: b=AS:5000

12:07:50:510 RTSP DESCRIBE response: a=fmtp:33 ver=1.0;src=1;tuner=1,64,1,0,667000,h,dvbs,qpsk,off,0.35,6952,;pids=3

12:07:50:511 RTSP DESCRIBE response: a=sendonlya=control:rtsp://192.168.1.201:554/stream=15

12:07:50:512 RTSP DESCRIBE response: m=video 6204 RTP/AVP 33

12:07:50:512 RTSP DESCRIBE response: c=IN IP4 0.0.0.0

12:07:50:513 RTSP DESCRIBE response: b=AS:5000

12:07:50:513 RTSP DESCRIBE response: a=fmtp:33 ver=1.0;src=1;tuner=1,64,1,0,667000,h,dvbs,qpsk,off,0.35,6952,;pids=3

12:07:50:514 RTSP DESCRIBE response: a=sendonlya=control:rtsp://192.168.1.201:554/stream=14

12:07:50:514 RTSP DESCRIBE response: m=video 6202 RTP/AVP 33

12:07:50:514 RTSP DESCRIBE response: c=IN IP4 0.0.0.0

12:07:50:515 RTSP DESCRIBE response: b=AS:5000

12:07:50:515 RTSP DESCRIBE response: a=fmtp:33 ver=1.0;src=1;tuner=1,64,1,0,667000,h,dvbs,qpsk,off,0.35,6952,;pids=3

12:07:50:515 RTSP DESCRIBE response: a=sendonly

As you can see the a=sendonly line has no carriage return/line feed at the end of it for the 2 video streams.

Secondly the announcement packets sent by the Recording Service are wrong when the tuner used is DVB-C. The packet seems to be formatted as if it were DVB-S.

Announcement Packet: name=SES1 src=1 fe=1 level=64 lock=True quality=0 freq=667000 pol=h sys=dvbs type=qpsk pilot=off ro=0.35 sr=6952 fec= pids=3

The above is a logging message from EPG Collector.

The setup request was as follows

12:07:39:318 RTSP SETUP request: SETUP rtsp://192.168.1.201:554/?freq=667&pids=3&msys=dvbc&sr=6952 RTSP/1.0

12:07:39:319 RTSP SETUP request: Cseq:1

12:07:39:319 RTSP SETUP request: Transport:RTP/AVP;unicast;client_port=19005-19006

12:07:39:320 RTSP SETUP request: Connection:close

12:07:39:321 RTSP SETUP request:

In addition there seems to be a CI attribute at the end of the announcement line (not logged by EPG Collector but flagged as an error). That's not part of the Sat>IP specification is it?

These are only minor problems but they might cause other media software to fail when using the Recording Service as a Sat>IP server so I thought it helpful to post them.

 

[Griga]

Very helpful. Thanks for feedback.

 

As you can see the a=sendonly line has no carriage return/line feed at the end of it for the 2 video streams.

 

Confirmed and fixed.

Secondly the announcement packets sent by the Recording Service are wrong when the tuner used is DVB-C. The packet seems to be formatted as if it were DVB-S.

 

Confirmed and fixed. DVB-T is also affected. The version number must be adjusted as well (ver=1.0 for DVB-S, 1.1 for DVB-T, 1.2 for DVB-C).

 

In addition there seems to be a CI attribute at the end of the announcement line. That's not part of the Sat>IP specification is it?

 

You are right. There may be even more proprietary stuff attached to the RTCP announcement, particularly an x_tnr attribute signalling a forced switch-over to a different channel / transponder due to a recording with higher priority than client demands. It enables DVBViewer as Sat>IP client to follow automatically by switching to the same channel.

[nzsjb]

If I notice anything else I'll let you know.

[Griga]

I think there are some more flaws in the DESCRIBE response and RTCP anouncements, but in some cases it's hard to tell right from wrong. I've inherited the code from the original Recording Service developer who died in 2013, and sometimes the only thing left is to guess the original intention behind it

 

Here are some points that I've noticed:

 

(1) s=SatIPServer:1 4

 

The response always reports 4 frontends (hard-coded). According to the 1.2 SDP syntax it should be

 

s=SatIPServer:1 <sat frontends>,<terr frontends>,<cable frontends>

 

which means, the number of available DVB tuners of the corresponding type. However, clients that still adhere to the 1.0 syntax may expect a single <sat frontends> number. So what to do?

 

(2) a=control:rtsp://192.168.1.201:554/stream=13

 

This is the complete absolute URL, but all examples in the Sat>IP specifications reduce it to

 

a=control:stream=13

 

which can be regarded as relative URL (relative to the base URL in the Content-Base response header). According to this a relative URL should be used in the media level information if the base URL is given in the session level part. However, there is none in the Sat>IP examples. So what to do?

 

(3) b=AS:5000

 

The application specific bandwidth modifier is not part of the Sat>IP specifications and does not show up in the examples. So what to do?

 

(4) tuner=1,64,1,0,667000,...

 

The first number is supposed to specify the frontend ID <feID> , but is always "1" (hard-coded). Since the Recording Service responds to the fe=<feID> query parameter, enabling Sat>IP clients to select a specific DVB tuner with <feID> interpreted as one based device list index (see Recording Service Options -> Hardware), the DESCRIBE response should use it accordingly.

 

(5) rtsp://<ip_address>/stream=<streamID>

 

The Recording Service does not support this kind of DESCRIBE request for a specific stream, but responds with 404 not found.

 

(6) CI=1

 

I think I will rather restrict the proprietary attributes in the RTCP announcements to DVBViewer & Co. clients that can be recognized because they use proprietary query parameters (particularly tnr=...) if (and only if) the server is a Recording Service instance.

 

That's all for now...

[Griga]

P.S.

 

One thing that must be considered is the support for Non-Sat>IP RTSP clients like VLC or WMP that are able to play RTSP URLs like the ones exported by the Recording Service as RTSP channel list. It may require RTSP attributes that are not mentioned in the Sat>IP specs.