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