[vdr] reel netclient

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