If the netclient hardware runs GPL software I assume that in theory someone could implement a streamdev client that facilitated the hw mepg2/4 decoder?<br><br><div class="gmail_quote">2009/4/14 Georg Acher <span dir="ltr">&lt;<a href="mailto:acher@in.tum.de">acher@in.tum.de</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote:<br>
<br>
&gt; I have no netceiver to play with and didn&#39;t look at the sources. But<br>
&gt; it&#39;s nice to see a real world use for IPv6 in consumer hardware (if you<br>
&gt; can call the reel boxes consumer hardware, it&#39;s probably only for a<br>
&gt; limited, but sophisticated market.<br>
<br>
</div>The client and the also available standalone NetCeiver should bring it more<br>
to the &quot;masses&quot; as the price will be comparable to typical HDTV receivers.<br>
<div class="im"><br>
&gt; Does it just use a fixed multicast-address to receive the stream and if<br>
&gt; yes, how is the communication to the tuner realized? Is this something<br>
&gt; reel-specific or could this be used to start a unified streaming-concept<br>
&gt; for vdr based on standards (and using IPv6 to avoid all that ugly IPv4<br>
&gt; stuff...)<br>
<br>
</div>It is a proprietory protocol in the sense as it is no standard. When there<br>
are so many IPTV standards to choose from, why make not a new one? ;-) At<br>
the time we started, DVB-IPTV was not even named and still I think it is so<br>
bloated that it cannot be efficiently used to use cheap hardware as a<br>
server.<br>
<br>
However, our protocol uses standard protocols like MLDv2 just with a<br>
different interpretation to make it light-weight and use hardware supported<br>
streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders<br>
(~40MByte/s), only the zapping time increases a bit... Do that with a PC :p<br>
<br>
The protocol translates (almost) all DVB specifics to ethernet, so it was no<br>
problem to wrap it back to DVB-API. The multicast address is not static but<br>
contains all relevant reception parameters. The basic communication only<br>
exchanges a few MLDv2-messages (no XML), so it can be processed very fast<br>
and also gains from MLDv2-aware switches. Only tuner capabilities and tuning<br>
states (SNR, lock, ...) are transmitted regularly in a side band via XML on<br>
a specific multicast address. That also allows zero configuration for the<br>
client. We will write a &quot;white paper&quot; about the protocol, currently we just<br>
don&#39;t have enough time...<br>
<br>
For the client side, the sources will be published as GPL. Currently we use<br>
a closed source daemon with a dvb loopback driver in the kernel, but that<br>
makes it hard to fully use the tuner virtualization and costs some overhead<br>
for small CPUs. Since we already have a native vdr plugin for that, the<br>
network code will be then forced to be GPL anyway ;-)<br>
<div class="im"><br>
--<br>
         Georg Acher, <a href="mailto:acher@in.tum.de">acher@in.tum.de</a><br>
         <a href="http://www.lrr.in.tum.de/~acher" target="_blank">http://www.lrr.in.tum.de/~acher</a><br>
         &quot;Oh no, not again !&quot; The bowl of petunias<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">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><br clear="all"><br>-- <br>-Tor<br>