Em Wed, 19 Dec 2018 13:16:49 +0100 Josef Wolf <jw@xxxxxxxxxxxxx> escreveu: > Thanks for your response, Mauro! > > On Wed, Dec 19, 2018 at 09:22:11AM -0200, Mauro Carvalho Chehab wrote: > > Em Wed, 19 Dec 2018 11:28:46 +0100 > > Josef Wolf <jw@xxxxxxxxxxxxx> escreveu: > > > > I would like to know how to know whether for a specific program SYS_DVBS or > > > SYS_DVBS2 should be specified to the FE_SET_PROPERTY ioctl() call. > > > > This is not specific to a program. It affects the hole transponder. Either > > the transponder is DVB-S or DVB-S2. > > Yes, I'm aware of it. In my question I meant: when I want to tune to some > program, I need to set the SYS_DVBx property in addition to the other tuning > parameters (like frequency, polarization, FEC etc/pp) > > > > Is this somehow broadcasted in some PAT/PMT tables? > > > > It is at the NAT tables. They contain all needed information to properly > > tune into the transponders. There are different tables, depending if the > > transponder is -S or -S2. > > OK. > > > > Or is it possible to simple always specify SYS_DVBS2 and the kernel will > > > manage the backwards compatibilities when a DVB-S transponder is specified in > > > the tuning parameters? > > > > The Kernel can't and shouldn't guess the tuning parameters. It depends > > on userspace to parse the NAT tables and get it right. > > It is pretty much obvois to me that the kernel can't guess tuning parameters > like diseqc-sequence, polarity, frequency and symrate. This is because the > kernel needs those parameters to get a signal at all. > > But, on the other side, there are lots of parameters that the kernel (or > hardware?) _can_ guess: INVERSION_AUTO, FEC_AUTO, QAM_AUTO just to name some. The Kernel implements only INVERSION_AUTO. The rest is implemented by the device itself, if it has support for it. > So what' so special about SYS_DVBS/SYS_DVBS2 that it has to be handled > differently from those other parameters? DVB-S2 adds a lot more parameters, including the possibility of using different modulations (QPSK, 8PSK, 16APSK, 32APSK). DVB-S was just QPSK. The rolloff parameter also can be changed. DVB-S was just 0.35. On DVB-S2 it can also be 0.20 and 0.25. That affects frequency filtering. It even allows to have multiple MPEG-TS streams inside a physical transponder, each with a separate ID. If, for example, there are multiple streams, neither the device nor the Kernel could know what ID would contain the MPEG stream that the user wants. It may also use a scrambling code, with requires userspace to pass the gold code, in order to de-scramble it. So, if the transponder is using those extra features provided by DVB-S2, the device has to know how to properly tune transponder and how filter/de-scramble the transport stream that contains the program the user wants. It is worth to say that DVB-S2 is a superset of DVB-S. If your tuner can do DVB-S2 and you want to tune to a DVB-S transponder, provided that you properly fill all DVB-S2 properties to match a DVB-S channel (rollback, modulation, ...), in thesis[1] you could use SYS_DVBS2 as delivery system. [1] In practice, I'm not so sure, as this is something that developers don't usually test. Both userspace apps and Kernelspace don't assume that. So, it is not warranted to work. I guess that, if one uses SYS_DVBS2 to tune, the results will vary from driver to driver. Things like gold code and PLS ID, if set wrong, could prevent the channel to tune. Thanks, Mauro
