[vdr] reel netclient
keef at networkhell.de
Mon Apr 13 17:21:27 CEST 2009
Georg Acher schrieb:
>> 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.
Indeed, 299€ announced on the website sounds good for an out of the box
client with the functionality of the reelbox (or a vdr-server).
>> 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
> 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
I can understand these arguments, I was thinking about a protocol more
like upnp/av extended for real dynamic streaming. But something
lightweight is really needed. Especially for the future of vdr and vdr
based systems. Extending and fixing streamdev isn't a way for the
future, but implementing a server-plugin for vdr, that could 'emulate' a
netceiver could unify the reel-way and the stalled streamdev-way.
> 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
I just had a short look von the RfC for MLDv2 and on the first look it
doesn't look so bloated (in a way that an implementation could limit
throughput on typicall pc hardware, especially as this shouldn't affect
the streaming-part at all). But I'd like to be corrected ;-) For a
typicall vdr scenario streaming 6 full transponders is probably nothing
that is really needed, but it's nice to know that your hardware (and
software) scales to that throughput.
> 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...
That sounds very good and would allow an easy way to map a dvb-stream to
a network stream and feed it back on the client via standard kernel
interfaces. That could be even interesting for my boss. Do you have a
recommendation for a small hardware-setup with a netceiver that would
work in a dvb-c environment (I only have dvb-c at the moment, enough pc
hardware and if necessary even a sat-dish to play with)? After my
vacation I'll check with my boss, perhaps he'll pay for it ;-)
> 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 ;-
Sounds even better, so there's working code to verify the functionality.
I'm only a networking guy with a little bit experience with dvb, but
that seems to be a project worth while to invest some time.
More information about the vdr