On 23.12.2011 22:54, Antti Palosaari wrote:
> On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
>> On 22-12-2011 19:30, Antti Palosaari wrote:
>>> Rename DMB-TH to DTMB.
>>
>> Patrick seems to believe that CTTB is a better name. In any case,
>> whatever name we pick, I think that the DocBook specs (and
>> maybe a comment at the header file) should point all the known
>> ways to call this standard. So, I'm fine with any choice.
>
> I am not going to change it for CTTB unless there is no some document
> given says it is more correct than DTMB. I have looked very many papers
> over there and DTMB is absolutely more common as far as I gave seen.
>
>>> Add few new values for existing parameters.
>>>
>>> Add two new parameters, interleaving and carrier.
>>> DTMB supports interleavers: 240 and 720.
>>> DTMB supports carriers: 1 and 3780.
>>
>> The API change looks sane to my eyes. I have just a couple
>> comments below.
>
> I think I will add carrier modes to enum fe_transmit_mode... I will send
> new propose soon.
>
>>> @@ -169,8 +170,11 @@ typedef enum fe_modulation {
>>> APSK_16,
>>> APSK_32,
>>> DQPSK,
>>> + QAM_4_NR,
>>
>> While the NR is generally associated with the modulation,
>> this is a channel code, and not part of the modulation itself
>> (btw, the DVBv3 API calls it as "constellation").
>>
>> Ok, it is easier to add it here, but maybe it would be safer
>> to add a separate field for channel coding that would be used
>> to enable or disable the Nordstrom-Robinson code.
>>
>> This is currently used only with QAM-4, but nothing prevents this
>> parity code to be added to other types of modulation.
>>
>>> } fe_modulation_t;
>>>
>>> +#define QAM_4 QPSK
>>
>> IMHO, this is overkill, but I'm ok with that.
>
> Anyone else have comment about that?
I don't think we should create such defines unless needed for backwards
compatibility, which is not the case.
Regards,
Andreas
--
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
