Hi, On Thursday, November 10, 2011 10:20:46 PM Mauro Carvalho Chehab wrote: > > We should also think on a way to enumerate the supported values for each > DVB properties, the enum fe_caps is not enough anymore to store > everything. It currently has 30 bits filled (of a total of 32 bits), and > we currently have: > 12 code rates (including AUTO/NONE); > 13 modulation types; > 7 transmission modes; > 7 bandwidths; > 8 guard intervals (including AUTO); > 5 hierarchy names; > 4 rolloff's (probably, we'll need to add 2 more, to distinguish between > DVB-C Annex A and Annex C). > > So, if we would need to add one CAN_foo for each of the above, we would > need 56 to 58 bits, plus 5-6 bits to the other capabilities that > currently exists there. So, even 64 bits won't be enough for the current > needs (even having the delivery system caps addressed by something > else). IMHO, we don't need such a fine FE_CAN_-bit distinguishing for most standards. A well defined sub-standard definition is sufficient, which can be handled with a delivery-system-like query as proposed in the original patch. This also will be much simpler for most user-space applications and users. DVB-T means: - 8K or 2K, - 1/4-1/32 Guard, - 1/2, 2/3, 3/4, 5/6 and 7/8 coderate, - QPSK, 64QAM or 16QAM DVB-H (RIP as Remi wrote somewhere) would have meant: - DVB-T + 4K + in-depth-interleaver mode The same applies to ISDB-T and ISDB-T 1seg. And for CMMB, CTTB, DVB-SH. If there are demods which can't do one particular thing, we should forget about them. At least this is what almost all applications I have seen so far are doing implicitly. Though, I see at least one inconvenience is if someone is using linux-dvb for developping dsp-software and wants to deliver things which aren't done. But is this a case we want to "support" within the official API. regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- 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
