On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote: > I have no netceiver to play with and didn't look at the sources. But > it's nice to see a real world use for IPv6 in consumer hardware (if you > can call the reel boxes consumer hardware, it's probably only for a > limited, but sophisticated market.
The client and the also available standalone NetCeiver should bring it more to the "masses" as the price will be comparable to typical HDTV receivers. > Does it just use a fixed multicast-address to receive the stream and if > yes, how is the communication to the tuner realized? Is this something > reel-specific or could this be used to start a unified streaming-concept > for vdr based on standards (and using IPv6 to avoid all that ugly IPv4 > stuff...) It is a proprietory protocol in the sense as it is no standard. When there are so many IPTV standards to choose from, why make not a new one? ;-) At the time we started, DVB-IPTV was not even named and still I think it is so bloated that it cannot be efficiently used to use cheap hardware as a server. However, our protocol uses standard protocols like MLDv2 just with a different interpretation to make it light-weight and use hardware supported streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders (~40MByte/s), only the zapping time increases a bit... Do that with a PC :p The protocol translates (almost) all DVB specifics to ethernet, so it was no problem to wrap it back to DVB-API. The multicast address is not static but contains all relevant reception parameters. The basic communication only exchanges a few MLDv2-messages (no XML), so it can be processed very fast and also gains from MLDv2-aware switches. Only tuner capabilities and tuning states (SNR, lock, ...) are transmitted regularly in a side band via XML on a specific multicast address. That also allows zero configuration for the client. We will write a "white paper" about the protocol, currently we just don't have enough time... For the client side, the sources will be published as GPL. Currently we use a closed source daemon with a dvb loopback driver in the kernel, but that makes it hard to fully use the tuner virtualization and costs some overhead for small CPUs. Since we already have a native vdr plugin for that, the network code will be then forced to be GPL anyway ;-) -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias _______________________________________________ vdr mailing list email@example.com http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr