Re: [vdr] reel netclient
Hi, Georg Acher schrieb: The thing is not yet available, so the current SVN doesn't contain most of the new code. But in general it uses the same reelvdr-base as the Avantgarde (just with a different output plugin for the SoC). The live TV streaming is not done by the vdr on the Avantgarde, but directly via IPv6-multicast by the NetCeiver-hardware. This is the same way the Avantgarde gets its data, so the NetCeiver traffic is just bridged into the LAN for other clients. 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. 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...) A very interested Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
Hi, Torgeir Veimo schrieb: If the netclient hardware runs GPL software I assume that in theory someone could implement a streamdev client that facilitated the hw mepg2/4 decoder? If you look at the specs and the description Georg provided, a 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 ac...@in.tum.de mailto:ac...@in.tum.de 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 ;-) -- Georg Acher, ac...@in.tum.de mailto:ac...@in.tum.de http://www.lrr.in.tum.de/~acher http://www.lrr.in.tum.de/%7Eacher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org mailto:vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
