Jump to content
nzsjb

Recording service streaming problems

Recommended Posts

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.

 

Share this post


Link to post
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.

Share this post


Link to post
nzsjb

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

Share this post


Link to post
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...

Share this post


Link to post
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.

Share this post


Link to post
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...