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?
Hi,
with the latest cvs version of xineliboutput the OSD scaling is broken using HD content. The OSD seems way to large on HD content.
My setup is :
Soft :
vdr-1.7.5 xineliboutput from today xine-lib-vdpau
Hard : For video out i use vdpau on an IGP8300 motherboard.
Anyone else noticed that behavior ?
cu
Edgar (gimli) Hucek
On Mon, 13 Apr 2009 12:35:24 +0200 (CEST) "gimli" gimli@dark-green.com wrote:
Hi,
with the latest cvs version of xineliboutput the OSD scaling is broken using HD content. The OSD seems way to large on HD content.
My setup is :
Soft :
vdr-1.7.5 xineliboutput from today xine-lib-vdpau
Hard : For video out i use vdpau on an IGP8300 motherboard.
Anyone else noticed that behavior ?
Yes, but the other way around: The OSD is too small when viewing sub-PAL resolutions. Didn't try HD-stuff yet.
I made a screenshot, viewable here: http://www.vdrportal.de/board/thread.php?threadid=85767
BTW. the problem does not occur when using HUD-Mode, but that doesn't play nice with VDPAU yet ...
cu
Edgar (gimli) Hucek
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Mon, 13 Apr 2009 13:02:39 +0200 Malte Schröder maltesch@gmx.de wrote:
On Mon, 13 Apr 2009 12:35:24 +0200 (CEST) "gimli" gimli@dark-green.com wrote:
Hi,
with the latest cvs version of xineliboutput the OSD scaling is broken using HD content. The OSD seems way to large on HD content.
My setup is :
Soft :
vdr-1.7.5 xineliboutput from today xine-lib-vdpau
Hard : For video out i use vdpau on an IGP8300 motherboard.
Anyone else noticed that behavior ?
Yes, but the other way around: The OSD is too small when viewing sub-PAL resolutions. Didn't try HD-stuff yet.
I made a screenshot, viewable here: http://www.vdrportal.de/board/thread.php?threadid=85767
BTW. the problem does not occur when using HUD-Mode, but that doesn't play nice with VDPAU yet ...
I just checked, it works when using --video=vo, it only happens with vdpau.
Malte Schröder wrote:
BTW. the problem does not occur when using HUD-Mode, but that doesn't play nice with VDPAU yet ...
I can't get any OSD with --hud and 185.19 driver. Can't even change channels.
Log: [3463] [vdr-fe] Keypress: LIRC Menu [3460] [vdr-sxfe] HUD osd Close [3460] [vdr-sxfe] hud_osd_command: unknown osd command
http://www.nvnews.net/vbulletin/showthread.php?t=131178 "The VDPAU presentation queue now syncs to VBLANK in the blit path."
Wanted to test if tearing is gone with Composite enabled.
On Tue, 14 Apr 2009 14:09:26 +0300 Pertti Kosunen pertti.kosunen@pp.nic.fi wrote:
Malte Schröder wrote:
BTW. the problem does not occur when using HUD-Mode, but that doesn't play nice with VDPAU yet ...
I can't get any OSD with --hud and 185.19 driver. Can't even change channels.
you need a compositing manager like xcompmgr or compiz.
Log: [3463] [vdr-fe] Keypress: LIRC Menu [3460] [vdr-sxfe] HUD osd Close [3460] [vdr-sxfe] hud_osd_command: unknown osd command
http://www.nvnews.net/vbulletin/showthread.php?t=131178 "The VDPAU presentation queue now syncs to VBLANK in the blit path."
Wanted to test if tearing is gone with Composite enabled.
For me it is gone, but video is not as smooth as without compositing.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am Tue, 14 Apr 2009 19:03:26 +0200 schrieb Malte Schröder maltesch@gmx.de:
On Tue, 14 Apr 2009 14:09:26 +0300 Pertti Kosunen pertti.kosunen@pp.nic.fi wrote:
Malte Schröder wrote:
BTW. the problem does not occur when using HUD-Mode, but that doesn't play nice with VDPAU yet ...
I can't get any OSD with --hud and 185.19 driver. Can't even change channels.
you need a compositing manager like xcompmgr or compiz.
The lack of a compositing manager doesn't explain why he can't change channels.
Gerald
gimli wrote:
Hi,
with the latest cvs version of xineliboutput the OSD scaling is broken using HD content. The OSD seems way to large on HD content.
My setup is :
Soft :
vdr-1.7.5 xineliboutput from today xine-lib-vdpau
Hard : For video out i use vdpau on an IGP8300 motherboard.
Anyone else noticed that behavior ?
cu
Edgar (gimli) Hucek
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Yes, I've had the very same problem for weeks. It looks as though I only see the upper left 720x576 pixels no matter what content I play. So for 1080i I hardly see any OSD at all. Dose xineliboutput CVS work with 1.7.5 already? /Magnus H
It's half working with 1.7.5. Audio on HD channel is also broken. Only tested on ORF 1 HD.
gimli wrote:
Hi,
with the latest cvs version of xineliboutput the OSD scaling is broken using HD content. The OSD seems way to large on HD content.
My setup is :
Soft :
vdr-1.7.5 xineliboutput from today xine-lib-vdpau
Hard : For video out i use vdpau on an IGP8300 motherboard.
Anyone else noticed that behavior ?
cu
Edgar (gimli) Hucek
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Yes, I've had the very same problem for weeks. It looks as though I only see the upper left 720x576 pixels no matter what content I play. So for 1080i I hardly see any OSD at all. Dose xineliboutput CVS work with 1.7.5 already? /Magnus H
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 "reel"vdr-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.
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 acher@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 "reel"vdr-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, acher@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
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.
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 "reel"vdr-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
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 ;-)
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
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 acher@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, acher@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
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 <acher@in.tum.de mailto:acher@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, acher@in.tum.de <mailto:acher@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
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 keef@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 <acher@in.tum.de mailto:acher@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, acher@in.tum.de <mailto:acher@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
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-media@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
But does the Reel Smart-Client box run vdr?
On Mon, Apr 13, 2009 at 2:50 PM, Georg Acher acher@in.tum.de wrote:
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 "reel"vdr-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, acher@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
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).
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 acher@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, acher@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
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.
Maybe some of the Sigmatel Chips used in Popcorn & co?
2009/4/14 Georg Acher acher@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, acher@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
-
Andrew Herron -
Georg Acher -
Gerald Dachs -
gimli -
Karl Glatz -
Magnus Hörlin -
Malte Schröder -
Matthias Müller -
Matti Horila -
Pertti Kosunen -
Torgeir Veimo