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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
