Em 11-11-2011 09:36, Antti Palosaari escreveu:
> 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.
>
If you take a look at DVB-C, for example, The reference used by the DVB
subsystem
seems to be the ITU-T J.83, as the delivery systems are named according to
ITU-T J.83 annexes:
Annex A - European DVB-C (also defined on EN 300 429)
Annex B - American DOCSYS
Annex C - Japanese variant of Annex A, optimized for 6 MHz Bw
According with ITU-T J.83/1997 (from where Annex A, B and C are referenced), we
have:
Annex A:
- modulation: QAM 16, 32 and 64
Mentions that QAM 128 and 256 could be used in future
- rolloff: 0.15
Annex B:
- Modulation: QAM 64, 256
Annex C:
- Modulation: QAM 64
- rolloff: 0.13
ITU-T Annex A is also defined at ETSI as EN 300 429/1998. There, we have:
- modulation: QAM 16, 32, 64, 128 and 256
- rolloff: 0.15
As the same delivery system is used for both Annex A and Annex C, the "minimum"
requirement for SYS_DVBC_ANNEX_AC is to support QAM64 (as it can be a device
that
implements only Annex C).
So, just assuming some default from the delivery system is dangerous. Also, as
specs may change with time (as J.83 -> EN 300 429 addition for QAM 128 and 256),
this may lead into troubles in the future.
Btw, DVB-C2, as defined on ITU-T J.122 is even more complex, offering a myriad
of
mandatory and optional formats, as shown at item 6.2.3:
The upstream demodulator MAY support QPSK and 16QAM differential
modulation for TDMA.
The upstream demodulator MUST support QPSK, 16QAM, and 64QAM
modulations for TDMA and S-CDMA channels.
The upstream demodulator MAY support 8QAM and 32QAM modulation for TDMA
and S-CDMA channels.
The upstream demodulator MAY support QPSK, 8QAM, 16QAM, 32QAM, 64QAM,
and 128QAM TCM encoded modulations for S-CDMA channels.
What I think we can do is to provide macros for the capabilities, like:
#define FE_CAN_DVBT FE_CAN_1_2 | FE_CAN_3_4 | ...
With regards to the idea of returning an error, this may not work on all cases.
For example, my 1seg stick is capable of retrieving channel info from 3-seg and
full-seg
streams, even not being able of actually watching those. Ideally, userspace
should
be capable of disabling the 3seg/full-seg channels if they aren't actually
supported
by the plugged device.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
