[vdr] reel netclient

Matthias Müller keef at networkhell.de
Mon Apr 13 17:44:40 CEST 2009


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 at in.tum.de <mailto:acher at in.tum.de>>
>     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 at in.tum.de <mailto:acher at in.tum.de>
>             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 at linuxtv.org <mailto:vdr at linuxtv.org>
>     http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> -- 
> -Tor
> ------------------------------------------------------------------------
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

More information about the vdr mailing list