On 18.04.2010 16:51, Manu Abraham wrote: > On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger > <Klaus.Schmidinger@xxxxxxx> wrote: >> On 15.04.2010 22:21, Manu Abraham wrote: >>> Hi Klaus, >>> >>> On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger >>> <Klaus.Schmidinger@xxxxxxx> wrote: >>>> The enum fe_caps provides flags that allow an application to detect >>>> whether a device is capable of handling various modulation types etc. >>>> A flag for detecting PSK_8, however, is missing. >>>> This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements >>>> it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones >>>> with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. >>> >>> The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is >>> FE_CAN_TURBO_FEC >> Well, when processing the NIT data in VDR, for instance, the possible >> modulation types that can be used according to the driver's frontend.h >> are >> QPSK, >> QAM_16, >> QAM_32, >> QAM_64, >> QAM_128, >> QAM_256, >> QAM_AUTO, >> VSB_8, >> VSB_16, >> PSK_8, >> APSK_16, >> APSK_32, >> DQPSK, >> >> There is nothing in frontend.h that would be in any way related to >> "turbo fec" (whatever that may be). >> >> Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't >> something like >> >> if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_TURBO_FEC)) >> return false; >> >> be even more irritating than a straight forward >> >> if (Modulation == PSK_8 && !(frontendInfo.caps & FE_CAN_PSK_8)) >> return false; >> >> After all it's >> >> if (Modulation == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256)) >> return false; >> >> Please advise. Whatever you prefer is fine with me. >> All I need in VDR is a flag that allows me to detect whether a device >> can handle a given transponder's modulation. I don't really care how >> that flag is named ;-). > > > Maybe I wasn't clear enough, why I stated that ... > > consider any DVB-S2 frontend: stb0899, cx24116, stv090x, ds3000 or any > other any frontend .. > All these devices are capable of demodulating 8PSK. Now, if people > start adding capabilities that which the devices are capable, then it > will cause a lot of problems for the applications themselves, since > you don't get the differentiation between the frontends that you were > originally looking for. > > Now looking at another angle .. > > consider the Genpix frontend, can it tune to 8PSK ? Yes, it can.. > > Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but > not all 8PSK capable devices are DVB-S2 capable. Since there are already FE_CAN_* flags for all but PSK_8, I guess it would make sense that all devices that support PSK_8 set the related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the suboptimal naming scheme), independent of the "Turbo FEC" thing. > Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make > any sense, when it is applied to the whole group of 8PSK frontends ? I > guess not. You would require a flag that is capable of distinguishing > between the S2 8PSK category and the other category. There already is such a flag: FE_CAN_2G_MODULATION. > Looking back at history, originally France Telecom introduced the > superior Error Correction scheme called Turbo Mode or so called > Concatenated FEC mode on a 8PSK modulated carrier. This was a great > approach, but they wanted to people to pay them a royalty and hence > the general acceptance for it went down. In the initial phase, it was > implemented in the Americas and for small clients alone. Eventually, > the rest of the world wanted a royalty free approach and thus came > LDPC which is just as good. > > So eventually while the difference between these 2 carriers is that > while both are 8PSK modulated stream, the Error correction used with > France Telecom's proprietary stream is Concatenated Codes, while for > S2 and DVB.org it became LDPC. > > As you can see, the discriminating factor is the FEC, in this > condition and nothing else. You will need a flag to discriminate > between the FEC types, rather than the modulation, if things were to > look more logical. I guess the problem, as I can see now, is that there is now way of telling from the SI data that a transponder uses "8psk turbo fec", or is there? Would it make sense to differentiate this in the following way: - an 8psk transponder on DVB-S is "turbo fec" - an 8psk transponder on DVB-S2 is *not* "turbo fec" ? So an "8psk/DVB-S" transpoder will require a device that has FE_CAN_TURBO_FEC set, while an "8psk/DVB-S2" transpoder simply requires a DVB-S2 device (since there is no FE_CAN_PSK_8). Klaus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
