<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <span dir="ltr">&lt;<a href="mailto:abraham.manu@gmail.com">abraham.manu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Alex Betis wrote:<br>
&gt; On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger &lt;<br>
&gt; <a href="mailto:Klaus.Schmidinger@cadsoft.de">Klaus.Schmidinger@cadsoft.de</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On 22.11.2008 17:25, Georg Acher wrote:<br>
&gt;&gt;&gt; On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote:<br>
&gt;&gt;&gt;&gt; On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger &lt;<br>
&gt;&gt;&gt;&gt; <a href="mailto:Klaus.Schmidinger@cadsoft.de">Klaus.Schmidinger@cadsoft.de</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Maybe I&#39;m totally missing something here, but I can&#39;t figure out how<br>
&gt;&gt;&gt;&gt;&gt; an application using the S2API driver can tell whether a DVB device is<br>
&gt;&gt;&gt;&gt;&gt; DVB-S or DVB-S2. Can somebody please point me in the right direction<br>
&gt;&gt; here?<br>
&gt;&gt;&gt;&gt; I run into the same question when made changes in scan-s2 application.<br>
&gt;&gt;&gt;&gt; The question I want to ask is why do you really need it?<br>
<br>
<br>
</div>In a DVB-S2 demodulator, according to ETSI specifications, and according<br>
to the manufacturers, there are 2 demodulators, A DVB-S demodulator and<br>
a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths.<br>
<br>
With these 2 distinct paths, you need a flag, aka a delivery system<br>
notation, to select the path as well as a &quot;holder&quot; to hold common<br>
delivery system specifics. This is the whole difference between<br>
multiproto and S2API.<br>
<br>
S2API depends on a flat concept where it assumes a single demodulator,<br>
ie the concept of a delivery system doesn&#39;t exist there.<br>
<br>
Expect more fun when there are newer delivery systems which are going to<br>
define backward compatibility stuff, ie when vendors do start to<br>
implement backward compatible stuff in hardware, similar to DVB-S2<br>
<br>
It is just a matter of time, till the more advanced features are<br>
implemented practically by more broadcasters, rather than the few<br>
experimental ones.<br>
<br>
I guess, there is more to come.....<br>
</blockquote><div>Guys,<br><br>Lets not start that fire again, from my experience mostly innocent people gets hurt from it.<br>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 &#39;API&#39; itself and its flexibility, while multiproto has its respectful &#39;flight hours&#39; and more implemented features. That&#39;s probably a matter of time and efforts while more features will be implemented in S2API that will make everybody happy.<br>
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.<br>We probably all agree that S2API is not mature enough for all the cases.<br><br>I didn&#39;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&#39;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.<br>
<br>Regarding the resource decisions:<br>I see a strong point to move the decision to configuration file and not rely only on device reported capabilities. <br>Here is an example:<br>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.<br>
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.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Regards,<br>
<font color="#888888">Manu<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
vdr mailing list<br>
<a href="mailto:vdr@linuxtv.org">vdr@linuxtv.org</a><br>
<a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr" target="_blank">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a><br>
</div></div></blockquote></div><br></div>