Feature #2859

Feature #2993: Bouquets - add support for m3u / xspf playlist (file:// and http[s]://)

Custom url extension for SAT>IP services

Added by B C over 7 years ago. Updated about 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


While going through the SAT>IP specifications and trying to find the proper way to tune to a server side descrambled service, I realized that decryption is only supported on the client side, and not intended to be done on the server. As there is some software which does support this with the help of propriety extensions to the url, it would be nice if this custom information could be added manually on a per service level.

So, as an example, the unmodified setup message would look like this:

and with a custom extension like this &tnr=1,11804,27500,10600,1,1,5,3,1220,1260,5002,2,1,0,25,0,1,9,-1 it should be at the end this:

Although this information would in some case also be available via a m3u channel list from a SAT>IP server, this should be much easier to implement and possible be suitable for other propriety solutions as well



Updated by Jaroslav Kysela over 7 years ago

Just my 2 cents: I don't like this extension at all. It seems like a dup of tuning parameters and PIDs already sent - something like an internal configuration string. Some other extensions (Digital Devices) supports pmt=PID parameter for the integrated CI modules support to specify which service should be descrambled which is simplier, but also the server can identity the requested service using the audio/video PIDs already passed in the RTSP request.


Updated by B C over 7 years ago

the DD pmt=PID parameter is also a propriety extension and not in the standard. And DDs implementation is to use the CI over the network on the client side AFAIK, so actually not even over SAT>IP. Anyway, this extension would work for DD as well.
You can not use A/V pids to determin the service in general as multiple services can be defined with the same A/V pids for different providers with even different encryption systems.


Updated by Jaroslav Kysela over 7 years ago

Digital Devices has a SAT>IP server with the integrated CI slot, so I believe that descrambling is on the server side.

For the PIDs list - if the SAT>IP server knowns which CAIDs/PrividerIDs can descramble (and it should know this information) then only services which can be decoded should be decrypted. Yes, there might be shared audio/video PIDs with multiple services, but usually the services from different broadcaster use another CAIDs and the user should be able to manage the decoded services (enable/disable) on the server.

In other words - the standard SAT>IP requests ALLOW to descramble services on the server side without extra client requirements.


Updated by B C over 7 years ago

from english wiki:
The SAT>IP protocol doesn't provides any specific support for encrypted services. The specification only targets the tuner, and how to access to DVB streams over the network. So if the client likes to access to encrypted feeds it can do it, but needs to have the correct support for them. This is easy when the client is a device with CAS/CAM hardware support (like a television or set-top-box), but it's unclear how to do it in a PC, mobile or tablet.

From the manual of octupus net (Google translated :-)):
The CI in your Octopus Net can be used with any program (client), which can call on M3U lists RTSP links. In the RTSP links is determined whether or not a station is to be decrypted using an existing CI. Programs that can handle M3U lists, for example, are on your PC or MAC the VLC® Player. On your mobile device (smartphone or tablet) as the GoodPlayer®. Of course, the use of the browser screen TVs in the web interface of Octopus Net is possible. After SAT> IP standard is currently the DVBViewer GE suitable for the use of CIs.

So no, SAT>IP does not officially support scrambling in any way and does only work with the help of propriety extensions (actually the &tnr stuff was DVB-Viewers original way to call DDs Octopus Net). The &tnr is redundant for sure, but compared to scan PAT, CAT and each PMT of the whole TS just to find out the SID is IMHO overkill and also not done by DD


Updated by Jaroslav Kysela over 7 years ago

OK, I think that we are on the similar road. I just don't see any possibility to integrate this to the standard SAT>IP client in tvh, but there's a possibility to manage automatically m3u playlist in an IPTV network which will have URLs with all these credentials to obtain descrambled streams from those devices/software servers.

TVH can also detect the pids= argument automatically and filter out the services for which the PIDs are not available.


Updated by B C over 7 years ago

was just writing this while you replied, so think of it b4 your post, but it is quite the same :-)

but if you don't like it at all than an IPTV-m3u source with an URL to the rtspchannels.xml file would for sure be another option and maybe the clean way but more work for the coding guy. So adding the mux with the URL it gets parsed and populates the services with the URLs from the XML. Sounds cool as it would make the user happy with a fully automated setup and would make it also possible for the guys with an octopus net device to use the CIs.

just in case this might be considered, i have seen #EXTINF tags in two flavours by now
#EXTINF:-1,KabelKiosk - iTVN (DVBViewer)
#EXTINF:0,1. TF1 (Sat>IP spec)
i don't know where DVB-Viewer got the format from but it might be valid as there own creation would not make much sense (but who knows :-)). I have not yet seen an octopus net list and their implementation


Updated by Jaroslav Kysela over 7 years ago

  • Parent task set to #2993

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from New to Fixed

We support the M3U playlist now. Open a specific issue, if you need something more.

Also available in: Atom PDF