Alex Betis wrote:
> On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <[EMAIL PROTECTED]>wrote:
>> Alex Betis wrote:
>>> On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger <
>>> [EMAIL PROTECTED]> wrote:
>>>> On 22.11.2008 17:25, Georg Acher wrote:
>>>>> On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote:
>>>>>> On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger <
>>>>>> [EMAIL PROTECTED]> wrote:
>>>>>>> Maybe I'm totally missing something here, but I can't figure out how
>>>>>>> an application using the S2API driver can tell whether a DVB device
>>>>>>> DVB-S or DVB-S2. Can somebody please point me in the right direction
>>>>>> I run into the same question when made changes in scan-s2 application.
>>>>>> The question I want to ask is why do you really need it?
>> In a DVB-S2 demodulator, according to ETSI specifications, and according
>> to the manufacturers, there are 2 demodulators, A DVB-S demodulator and
>> a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths.
>> With these 2 distinct paths, you need a flag, aka a delivery system
>> notation, to select the path as well as a "holder" to hold common
>> delivery system specifics. This is the whole difference between
>> multiproto and S2API.
>> S2API depends on a flat concept where it assumes a single demodulator,
>> ie the concept of a delivery system doesn't exist there.
>> Expect more fun when there are newer delivery systems which are going to
>> define backward compatibility stuff, ie when vendors do start to
>> implement backward compatible stuff in hardware, similar to DVB-S2
>> It is just a matter of time, till the more advanced features are
>> implemented practically by more broadcasters, rather than the few
>> experimental ones.
>> I guess, there is more to come.....
> Lets not start that fire again, from my experience mostly innocent people
> gets hurt from it.
It is not about any fire, but about what really is at large.
> As someone new to DVB implementation who joined the ride when both S2API and
> multiproto are already available I see some benefits and drawbacks in both
> of them. From my perspective I see S2API best benefit is the 'API' itself
> and its flexibility, while multiproto has its respectful 'flight hours' and
> more implemented features. That's probably a matter of time and efforts
> while more features will be implemented in S2API that will make everybody
> It was decided already to move to S2API and as I see from the lists and
> patches flying around many people are very interested in it.
> We probably all agree that S2API is not mature enough for all the cases.
The problem is that, once an untested API makes it upstream, it is
really hard after that. Don't know how many people realize that ...
vdr mailing list