Re: [vdr] reel netclient
Maybe some of the Sigmatel Chips used in Popcorn co? 2009/4/14 Georg Acher ac...@in.tum.de On Mon, Apr 13, 2009 at 08:48:44PM +0100, Andrew Herron wrote: What is the hardware platform then? What CPU GPU is used? Are you running closed or open graphics drivers etc? It's a typical System-on-Chip for STBs. Details will be announced later. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acherhttp://www.lrr.in.tum.de/%7Eacher Oh no, not again ! The bowl of petunias ___ 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
Re: [vdr] reel netclient
Georg Acher wrote: 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 ;-) Hi Georg. Since there currently isn't v4l looback driver in mainline kernel, I suggest you take part on this ongoing discussion at linux-media mailing list: http://www.mail-archive.com/linux-me...@vger.kernel.org/msg04362.html As you can see, Mauro was going to add that loopback driver on v4l as out-of-tree driver. For end-user it would be a lot easier if your loopback implementation would be integrated on that driver and added to upstream kernel tree :) Regards, Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] reel netclient
http://www.reel-multimedia.com/en/shop_netclient.php describes a new product by reel that allows streaming of HD content over the network. It includes a hw decoder that supports mpeg2/4 and is to be used with the reelbox avantgarde as server. I'd assume reel has implemented something a bit more sophisticated than streamdev for this, but given the open source nature of their products, I'm wondering if someone has tried looking into using this client with pure VDR? -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote: http://www.reel-multimedia.com/en/shop_netclient.php describes a new product by reel that allows streaming of HD content over the network. It includes a hw decoder that supports mpeg2/4 and is to be used with the reelbox avantgarde as server. I'd assume reel has implemented something a bit more sophisticated than streamdev for this, but given the open source nature of their products, I'm wondering if someone has tried looking into using this client with pure VDR? 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. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
So it does not allow viewing of channels received as DVB-C/S/T on the avantgarde, or such recordings, only IPTV transmissions? 2009/4/13 Georg Acher ac...@in.tum.de On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote: http://www.reel-multimedia.com/en/shop_netclient.php describes a new product by reel that allows streaming of HD content over the network. It includes a hw decoder that supports mpeg2/4 and is to be used with the reelbox avantgarde as server. I'd assume reel has implemented something a bit more sophisticated than streamdev for this, but given the open source nature of their products, I'm wondering if someone has tried looking into using this client with pure VDR? 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. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list 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
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
On Mon, Apr 13, 2009 at 11:54:14PM +1000, Torgeir Veimo wrote: So it does not allow viewing of channels received as DVB-C/S/T on the avantgarde, or such recordings, only IPTV transmissions? The NetCeiver IS a DVB-S/C/T headend to IPTV. So the tuners the Avantgarde-vdr uses are already sourced by that way, a new client makes no difference. The PC mainboard and the NetCeiver in the AVG just happen to be in the same casing and share the same power supply. Beyond that they are totally seperated devices. The tuner data is delivered by a loop back ethernet cable on the backside. It's similar to a USB tuner, but with all advantages of ethernet, especially more than one client ;-) Of course the NetClient can also access recordings over NFS etc. There's also a multiroom-setup that transfers timers to the AVG. So there is a full vdr running on the client, just the tuners are external. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
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 http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ 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
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? 2009/4/14 Georg Acher 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 http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list 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
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
Re: [vdr] reel netclient
That might be, but one of the reasons that I run VDR is the ability to tweak the capabilities and the user experience. So changing the client is just as interesting as implementing a suitable backend. 2009/4/14 Matthias Müller k...@networkhell.de 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 -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 05:46:14PM +0100, Andrew Herron wrote: But does the Reel Smart-Client box run vdr? Yes, but like on the Avantgarde it's the Reel-variant (based on 1.4.x with our own HDTV extensions). -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
What is the hardware platform then? What CPU GPU is used? Are you running closed or open graphics drivers etc? On Mon, Apr 13, 2009 at 6:27 PM, Georg Acher ac...@in.tum.de wrote: On Mon, Apr 13, 2009 at 05:46:14PM +0100, Andrew Herron wrote: But does the Reel Smart-Client box run vdr? Yes, but like on the Avantgarde it's the Reel-variant (based on 1.4.x with our own HDTV extensions). -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acherhttp://www.lrr.in.tum.de/%7Eacher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Convergent Home Technologies Ltd www.dianemo.co.uk Tel: +44 (0)1245 330101 Fax: +44 (0)1245 263916 Unit 205 Waterhouse Business Centre Cromar Way Chelmsford Essex CM1 2QE UK Watch Dianemo Videos here; http://www.dianemo.co.uk/index.php/your-home/overview-videos/8-your-home/31-dianemo-overview-videos ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
On Mon, Apr 13, 2009 at 08:48:44PM +0100, Andrew Herron wrote: What is the hardware platform then? What CPU GPU is used? Are you running closed or open graphics drivers etc? It's a typical System-on-Chip for STBs. Details will be announced later. -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
