[vdr] reel netclient

[Torgeir Veimo]

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.

2009/4/14 Matthias Müller <keef at networkhell.de>

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



-- 
-Tor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20090414/38cde74f/attachment-0001.htm