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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
