On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
Alex Betis wrote:In a DVB-S2 demodulator, according to ETSI specifications, and according
> On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger <
> Klaus.Schmidinger@xxxxxxxxxx> 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 <
>>>> Klaus.Schmidinger@xxxxxxxxxx> 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?
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.....
Guys,
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 happy.
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 interface.
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.
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 happy.
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 interface.
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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
