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
> is
> >>>>> DVB-S or DVB-S2. Can somebody please point me in the right direction
> >> here?
> >>>> 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.
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.

I didn't look in the VDR code yet, but I think it might be a good idea to
have a layer that will handle the interface to the device and hide all those
changes to the rest of the application. Since VDR is written in C++, that
shouldn't be too complicate to achieve. And will allow easy switch to S2API
(or any other in the future), while still maintainging the multiproto

Regarding the resource decisions:
I see a strong point to move the decision to configuration file and not rely
only on device reported capabilities.
Here is an example:
Several cards are in one PC, all DVB-S2 from different vendors, while one of
them is not that good handling S2 streams (lets say a driver problems that
suppose to be resolved), so the user might want to force that card to be
used for DVB-S channels only, regardless the reported DVB-S2 support.
To get even further with the example, stb0899 cards are known not to lock on
all DVB-S2 channels and not work well with different symbol rates, so I
might want to have per-channel decision configuration so those problematic
channels will be handled by another card, while all other DVB-S and DVB-S2
channels would be handled by all cards.

> Regards,
> Manu
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list

Reply via email to