[linux-dvb] Multiproto API/Driver Update

Rudy Zijlstra rudy at grumpydevil.homelinux.org
Tue Sep 9 14:12:25 CEST 2008

barry bouwsma wrote:
> --- On Tue, 9/9/08, hermann pitton <hermann-pitton at arcor.de> wrote:
>> following your thoughts, you are likely right. DVB-T2 likely indicates
>> that you need new hardware, like it is for sure on DVB-S2.
> Servus,
> Disclaimer:  I'm only an outsider, not a programmer, and not
> familiar with the digital broadcast specs or the DVB API, so
> I will both not know what I'm talking about, and be asking
> stupid questions.
> I decided to look again at DVB-T2, as it's likely to be the
> next change that will be in need of Linux support in a year
> or so, at least in the UK, when hardware becomes available.
Likely true, DVB-T2 is well on the way in development.
> My stupid question is, will DVB-T2, in Transport Stream mode,
> be similar enough to existing DVB-T, apart from the extended
> modulation parameters, that it can be fit into the existing
> API, or am I overlooking something in my ignorance of the API?
TS is unchanged from DVB-T, simply higher capacity. The changes are in 
the modulation (and additional table entries)
> This seems to me somewhat like the case of existing DVB-C,
> where some hardware is incapable of 256QAM and so cannot tune
> all the carriers, but I really haven't tried to understand
> the API or how it can be extended without breaking things...
That is old... QAM256 is pretty standard now. Only rather old HW should 
be incapable of handling QAM-256.

> In looking at the Wikipedia article on DVB-T, it appears that
> at least the following diffs to include/dvb/frontend.h might
> be needed to support the additional possibilities that a DVB-T2
> tuner would be likely to support -- diff against the S2API, as
> this file is unchanged in multiproto, while S2API already has
> the additional FEC values present...

 From my understanding, S2API is a generic approach, and should not have 
troubles supporting these standards.
> goto Disclaimer;

DVB-C2, i do not expect to get beyond definition stage, as - unless 
someone is really willing to pay for it - it seems unlikely there will 
be a market for it.
Too many significantly cheaper solutions to solve the problem on cable.



More information about the linux-dvb mailing list