Hi, Torgeir Veimo schrieb: > 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? If you look at the specs and the description Georg provided, a streamdev-client isn't needed, only a proper streamdev-server, that relays the transport stream from the transponder to the network and implements a feedback-channel to provide infos like supported demuxes and so on. > > 2009/4/14 Georg Acher <acher@xxxxxxxxx <mailto:acher@xxxxxxxxx>> > > 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, acher@xxxxxxxxx <mailto:acher@xxxxxxxxx> > http://www.lrr.in.tum.de/~acher > <http://www.lrr.in.tum.de/%7Eacher> > "Oh no, not again !" The bowl of petunias > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx <mailto:vdr@xxxxxxxxxxx> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > > -- > -Tor > ------------------------------------------------------------------------ > > _______________________________________________ > 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
