[vdr] reel netclient

[Matthias Müller]

Hi,

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 
>> 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.
>
>   
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.

Bye,
Matthias