2009/4/14 Matthias Müller <keef@xxxxxxxxxxxxxx>
Hi,
Torgeir Veimo schrieb:
> If the netclient hardware runs GPL software I assume that in theoryIf you look at the specs and the description Georg provided, a
> someone could implement a streamdev client that facilitated the hw
> mepg2/4 decoder?
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>>
> 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 ;-)
>
> --
> <http://www.lrr.in.tum.de/%7Eacher>
> "Oh no, not again !" The bowl of petunias> vdr@xxxxxxxxxxx <mailto:vdr@xxxxxxxxxxx>
>
> _______________________________________________
> vdr mailing list
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
--
-Tor
_______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
