On 11/11/2011 11:55 AM, Patrick Boettcher wrote:
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.
I agree that. Those are totally useless in general. Let driver return error to userspace if it cannot handle.
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.
I know only one case where device cannot support all standard parameters. It is one TDA10023 device and looks like stream goes too wide when QAM256 is used.
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 Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
