Re: [vdr] reel netclient

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

--

-Tor

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr