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