I recently saw the popcornhour and the HD demo on the popcorn wasn't what I expected. It felt like the early adopters of the first DVD players that came out. It was more jittery than a Blu-Ray disk on a PS3. So now I am wondering, what is the best silent/cheap client out there? That actually does 100% smooth playback like a normal DVD except at HD resolution/video bandwidth? Are there popcorn alternatives? Or is the best now to get a nvidia 9400/9500 to do video decode acceleration with a Core 2 Duo type processor of about 3GHz?
What are you opinion?
Theunis
-----Ursprungligt meddelande----- Från: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] För Theunis Potgieter Skickat: den 18 augusti 2009 15:00 Till: VDR Mailing List Ämne: [vdr] HD clients for vdr
I recently saw the popcornhour and the HD demo on the popcorn wasn't what I expected. It felt like the early adopters of the first DVD players that came out. It was more jittery than a Blu-Ray disk on a PS3. So now I am wondering, what is the best silent/cheap client out there? That actually does 100% smooth playback like a normal DVD except at HD resolution/video bandwidth? Are there popcorn alternatives? Or is the best now to get a nvidia 9400/9500 to do video decode acceleration with a Core 2 Duo type processor of about 3GHz?
What are you opinion?
Theunis
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.59/2310 - Release Date: 08/17/09 18:04:00
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats. It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu. /Magnus H
Magnus Hörlin wrote:
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer.
It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
Anssi Hannula wrote:
Magnus Hörlin wrote:
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer.
It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
Just got my ION A up and running as a NAS. Quite a bit of overkill there as all I need are the SATA and LAN connectors, plus VGA+KBD to get everything set up.
Both fans running at 7v (Case and CPU) and it is pretty quiet. Not sure about running the ION A fanless though.
So I will turn that board into my HD client for VDR as soon as I get a board more suited to be a NAS.
On 18/08/2009, Anssi Hannula anssi.hannula@gmail.com wrote:
Magnus Hörlin wrote:
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer.
It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
--
Anssi Hannula
What GPU does the nvidia ION A type board have? Wikipedia lists it as NVIDIA PureVideo HD. And if you look that up on wikipedia then it could be any of the GPUs http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GP...
Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1.
From what I could read about Flash HD, is that the limitation seems to
be from the Adobe plugin (on windows) that does not do hardware acceleration for h264 (http://www.nvnews.net/vbulletin/showthread.php?t=135840). But if we use mplayer or Xine to, then it should in theory it should be able to do Flash HD?
What is your setup like? Do you use VDR as the main application or do you use something like XBMC with VDR or do you load a plugin on VDR to play flash type movies? Which output plugin do you guys use? I currently use xineliboutput 1.0.4. It does have its short comings but very good for Live TV.
2009/8/19 Theunis Potgieter theunis.potgieter@gmail.com:
On 18/08/2009, Anssi Hannula anssi.hannula@gmail.com wrote:
Magnus Hörlin wrote: > > Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer.
> It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
--
Anssi Hannula
What GPU does the nvidia ION A type board have? Wikipedia lists it as NVIDIA PureVideo HD. And if you look that up on wikipedia then it could be any of the GPUs http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GP...
Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1.
Initially you might think you do, since you'd like to playback bluray material in the future. But in fact, most of the time you'd be displaying h.264 from HDTV transmissions, and deinterlacing it, if it's 1080i. Not all the different GPUs can do the advanced (temporal) deinterlacing for 1080i material.
In most cases, a 9500gt is the better choice, since it can do just that, even though it doesn't support VC-1 decoding in hardware, while a 8400gs can do that, but not deinterlace it.
For a more thorough answer, have a look at the mythtv mailing lists.
On Wed, Aug 19, 2009 at 1:18 AM, Torgeir Veimotorgeir@pobox.com wrote:
Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1.
Initially you might think you do, since you'd like to playback bluray material in the future. But in fact, most of the time you'd be displaying h.264 from HDTV transmissions, and deinterlacing it, if it's 1080i. Not all the different GPUs can do the advanced (temporal) deinterlacing for 1080i material.
In most cases, a 9500gt is the better choice, since it can do just that, even though it doesn't support VC-1 decoding in hardware, while a 8400gs can do that, but not deinterlace it.
For a more thorough answer, have a look at the mythtv mailing lists.
That's all and well but you should be slapped for that last sentence.
2009/8/20 VDR User user.vdr@gmail.com:
On Wed, Aug 19, 2009 at 1:18 AM, Torgeir Veimotorgeir@pobox.com wrote:
For a more thorough answer, have a look at the mythtv mailing lists.
That's all and well but you should be slapped for that last sentence.
Ah, yes :), here's a couple of non mythtv references;
http://www.avsforum.com/avs-vb/showthread.php?t=1117067 http://www.avsforum.com/avs-vb/showthread.php?p=15671995
In my experience, you just have to do deinterlacing in vdpau with interlaced content, even when displaying on an interlaced display. If you try to output interlaced material directly, you get ghosting since the weaved frames are copied to the progressive surface, and the output resolution might be different than the weave pattern.
It's a shame they didn't get it right when they implemented interlaced support in this framework.
Spatial termporal deinterlacing is the best one, so get a 9500gt at a minimum, and forget about vc-1 decoding until there is actually a working open source bluray player.
On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote:
In my experience, you just have to do deinterlacing in vdpau with interlaced content, even when displaying on an interlaced display. If you try to output interlaced material directly, you get ghosting since the weaved frames are copied to the progressive surface, and the output resolution might be different than the weave pattern.
the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently.
The main reason is: even with VDPAU there still exists no synchronization between stream and video timing.
That means there will be an arbitrary amount of lost/doubled fields with current VDPAU implementation.
Nvidias workaround now is to deinterlace all content in any case. As a result these field losses are (mostly) not directly visible to the human eye.
Ceasing from deinterlacing here would reveal field sequence problems (caused by missing stream-synchronization) immediately.
Cheers Thomas
the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently.
The main reason is: even with VDPAU there still exists no synchronization between stream and video timing.
is it possible to solve radically this problem with vdpau ? did you discuss with nvidia developpers about this issue ?
Goga
Is it AMD (ATI) have the same problem?
Vladimir
On Sat, 2009-08-22 at 13:12 +0400, Goga777 wrote:
the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently.
The main reason is: even with VDPAU there still exists no synchronization between stream and video timing.
is it possible to solve radically this problem with vdpau ? did you discuss with nvidia developpers about this issue ?
Goga
Приветствую, Vladimir
Is it AMD (ATI) have the same problem?
yes. but for ati and intel there's solution from Thomas - see
http://www.forum.free-x.de/wbb/index.php?page=Thread&postID=2576#post257... http://lowbyte.de/vga-sync-fields/vga-sync-fields/
Goga
On Sat, Aug 22, 2009 at 01:12:43PM +0400, Goga777 wrote:
is it possible to solve radically this problem with vdpau ? did you discuss with nvidia developpers about this issue ?
I don't know if nvidia hardware is capable of such things at all. This issue (among others) once has been discussed somewhere here [1].
- Thomas
2009/8/22 Thomas Hilber vdr@toh.cx:
On Thu, Aug 20, 2009 at 08:31:43AM +1000, Torgeir Veimo wrote:
In my experience, you just have to do deinterlacing in vdpau with interlaced content, even when displaying on an interlaced display. If you try to output interlaced material directly, you get ghosting since the weaved frames are copied to the progressive surface, and the output resolution might be different than the weave pattern.
the main reason why nvidia chooses to deinterlace always even if you use an interlaced video timing is not the scaling problem you mention. This could be eventually solved (albeit not perfectly) by scaling both fields independently.
The main reason is: even with VDPAU there still exists no synchronization between stream and video timing.
I accept that they prefer "always" deinterlacing because they didn't implement proper field parity in their architecture / api / implementation. But I still think they screwed up. The matrox mga 450/550 cards do field parity pretty well, with a simple api, and in 98% of cases with predictable results and with manageable clock drift workarounds. Too bad they offer no mpeg2 or h.264 acceleration.
Torgeir Veimo wrote:
2009/8/19 Theunis Potgieter theunis.potgieter@gmail.com:
On 18/08/2009, Anssi Hannula anssi.hannula@gmail.com wrote:
Magnus Hörlin wrote:
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer.
It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
--
Anssi Hannula
What GPU does the nvidia ION A type board have? Wikipedia lists it as NVIDIA PureVideo HD. And if you look that up on wikipedia then it could be any of the GPUs http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GP...
Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1.
Initially you might think you do, since you'd like to playback bluray material in the future. But in fact, most of the time you'd be displaying h.264 from HDTV transmissions, and deinterlacing it, if it's 1080i. Not all the different GPUs can do the advanced (temporal) deinterlacing for 1080i material.
In most cases, a 9500gt is the better choice, since it can do just that, even though it doesn't support VC-1 decoding in hardware, while a 8400gs can do that, but not deinterlace it.
For a more thorough answer, have a look at the mythtv mailing lists.
Well, my ION board with 9400m does temporal deinterlacing of 1080i HDTV just fine in xbmc. The question was about the best silent solution and a computer with just an Atom and a 9400 requires a lot less cooling than something with a discrete graphics card. /Magnus H
Goga777 wrote:
Well, my ION board with 9400m does temporal deinterlacing of 1080i HDTV just fine in xbmc.
did you try the temporal_spatial with 1080i ?
Goga
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi Goga. No, it's not available in xbmc. For some reason xineliboutput has never worked as well for HD as xbmc does. /Magnus
Well, my ION board with 9400m does temporal deinterlacing of 1080i HDTV just fine in xbmc.
did you try the temporal_spatial with 1080i ?
Hi Goga. No, it's not available in xbmc.
do you know - why so limited ?
For some reason xineliboutput has never worked as well for HD as xbmc does.
sorry, what do you mean ?
Goga
On 19/08/2009, Magnus Hörlin magnus@alefors.se wrote:
Hi Goga. No, it's not available in xbmc. For some reason xineliboutput has never worked as well for HD as xbmc does. /Magnus
So how do you set timers or lookup EPG etc in XBMC is there a plugin on XBMC to make it appear like VDR frontend?
-----Ursprungligt meddelande----- Från: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] För Theunis Potgieter Skickat: den 20 augusti 2009 09:28 Till: VDR Mailing List Ämne: Re: [vdr] HD clients for vdr
On 19/08/2009, Magnus Hörlin magnus@alefors.se wrote:
Hi Goga. No, it's not available in xbmc. For some reason xineliboutput
has
never worked as well for HD as xbmc does. /Magnus
So how do you set timers or lookup EPG etc in XBMC is there a plugin on XBMC to make it appear like VDR frontend?
I do all that in vdr-sxfe but there's a lot of work being done to use xbmc as a vdr frontend here: http://xbmc.org/forum/showthread.php?t=45314 /Magnus
So how do you set timers or lookup EPG etc in XBMC is there a plugin
on XBMC to make it appear like VDR frontend?
I do all that in vdr-sxfe but there's a lot of work being done to use xbmc as a vdr frontend here: http://xbmc.org/forum/showthread.php?t=45314 /Magnus
but xbmc-pvr has a lot of limitation as vdr-frontend - it can't control of vdr plugins and vdr settings, go to osd vdr menu, to use vdr plugins (femon, channellist,...)
have a look please http://xbmc.org/forum/showpost.php?p=376056&postcount=344
Goga
Goga777 wrote:
So how do you set timers or lookup EPG etc in XBMC is there a plugin
on XBMC to make it appear like VDR frontend?
I do all that in vdr-sxfe but there's a lot of work being done to use xbmc as a vdr frontend here: http://xbmc.org/forum/showthread.php?t=45314 /Magnus
but xbmc-pvr has a lot of limitation as vdr-frontend - it can't control of vdr plugins and vdr settings, go to osd vdr menu, to use vdr plugins (femon, channellist,...)
have a look please http://xbmc.org/forum/showpost.php?p=376056&postcount=344
Goga
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Of course it has limitations, it's a very young project. But it's progressing very fast and I think, given some time, that I will eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds. /Magnus
Magnus Hörlin wrote:
Of course it has limitations, it's a very young project. But it's progressing very fast and I think, given some time, that I will eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds.
Can a single vdr server have multiple independent xbmc clients?
BR, Seppo
Seppo Ingalsuo wrote:
Magnus Hörlin wrote:
Of course it has limitations, it's a very young project. But it's progressing very fast and I think, given some time, that I will eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds.
Can a single vdr server have multiple independent xbmc clients?
BR, Seppo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Yes, that's the nice part since it uses streamdev. For me that's the main reason I'm interested in it. /Magnus
eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds.
would you like to describe more details your installation - xbmc and vdr please
Goga
I too have tried mythtv and found it to be a big bloated slow piece of crap. It seems to be a bunch of odds & ends slapped together rather then a solid dvb app built from the ground up. Not impressed with it at all.
I should note that even though I did give it a try, I never intended to replace VDR with it regardless of the test results. I am a VDR loyalist. :)
Cheers, Derek
On Thu, Aug 20, 2009 at 7:55 PM, VDR Useruser.vdr@gmail.com wrote:
I should note that even though I did give it a try, I never intended to replace VDR with it regardless of the test results. I am a VDR loyalist. :)
I too have tried Myth on a number of occasions and have found it unwieldy and slow, not sure why its so popular, perhaps because of the flashier interface.
I currently have an ehd but have also just invested in a nvidia 9400, to begin fiddling with VDR + XBMC but as usual I never get really great results from using X11 based output, even with VDPAU and temporal-spatial de-interlacing. It never seems to be up to the same quality as a dedicated output card like the eHD, or FF TT card before it.
That said, I haven't done the XBMC + VDR bit yet, just tried using vdr-xine and xinelibout which just don't cut it. :-(
Right now I have ehd on one HDMI input for the TV with LIRC remote control and X11 desktop with XBMC on the other output with mouse control. Would be nice to eventually have all of it on one output with just LIRC control for it all, but right now it serves me well with good quality output and stability.
On Thu, Aug 20, 2009 at 12:37 PM, Morfstamorfsta@gmail.com wrote:
On Thu, Aug 20, 2009 at 7:55 PM, VDR Useruser.vdr@gmail.com wrote:
I should note that even though I did give it a try, I never intended to replace VDR with it regardless of the test results. I am a VDR loyalist. :)
I too have tried Myth on a number of occasions and have found it unwieldy and slow, not sure why its so popular, perhaps because of the flashier interface.
That's definitely is a part of it. I know former VDR users who switched to myth for that very reason. Now that VDR has support for hdtv, it's finally getting an osd overhaul as well (maybe coming in 1.7.9?), which will be 24bit iirc. We'll finally be able to have a high color/high resolution osd as well, which I'm hoping will spawn peoples interest in making some really great skins and so on. Most tv stations it seems offer their logos in high color/high res as well. I know Klaus prefers to focus more on stability then things like candy enhancements but I think he realized this is something users really wanted to see implemented now that hdtv support is present. And with so many users investing in things like inexpensive vdpau-supported video cards over overly expensive 'full featured' dedicated cards, it's a logical enhancement to make to bring VDR up-to-speed visually.
One thing I would like to see in the future is a solid server/client solution for VDR. That is the other and probably biggest reason users have abandoned VDR in favor of myth. Yes there are things like streamdev or xbmc+vdr, etc.. But those options are either too limited or too much hassle. It would be great if we could just set one software (VDR) up and keep things lean. I don't think this is something we'll see any time soon, if at all. But then a lot of people said the same thing about support for hdtv and an awesome osd. :)
Cheers, Derek
On Thu, Aug 20, 2009 at 6:15 PM, Goga777goga777@bk.ru wrote:
eventually abandon xinelib. At the moment I just press a button on my remote to switch between xbmc and vdr-sxfe so I can have the best of both worlds.
would you like to describe more details your installation - xbmc and vdr please
Goga
Hi.
I'm trying to do just that. A separate install for vdr and xbmc. No integration for me now, since the plugins functionality is lost.
A few methods are described here - http://www.xbmc.org/forum/showthread.php?t=47560.
Perhaps Magnus can say for sure what method he uses.
Cheers Cris
Does the unified xbmc pvr work with VDR 1.7.8? The howto instructions on the xbmc forum only mention 1.7.4.
Does 1.7.8 and latest xbmc-pvr svn only require a new streamdev (to support TS?), or are other patches required?
Would be good if someone could outline what's needed to get it working.
Thanks,
Morfsta
I have it working with 1.7.7.if that helps. Some patches are required to streamdev and VDR, I believe these are included in the source of the pvr-testing branch. If you search the thread on xbmc for mirak you will see a prebuilt 1.7.7 and streamdev available via launchpad.
For me it's not stable enough yet. The one big show stopper I've got is the following issue - changing channel by pushing up or down when watching TV crashes xbmc on two of my channels. This may jus tbe something to do with my setup - I've tried debugging xbmc to get to the bottom of this with no luck.
Saying that development is cracking on: you can see the commits on Trac if you're interested, http://www.xbmc.org/trac/browser/branches/pvr-testing/
On Fri, Aug 21, 2009 at 9:24 PM, Morfstamorfsta@gmail.com wrote:
Does the unified xbmc pvr work with VDR 1.7.8? The howto instructions on the xbmc forum only mention 1.7.4.
Does 1.7.8 and latest xbmc-pvr svn only require a new streamdev (to support TS?), or are other patches required?
Would be good if someone could outline what's needed to get it working.
Thanks,
Morfsta
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I'm trying to do just that. A separate install for vdr and xbmc. No integration for me now, since the plugins functionality is lost.
A few methods are described here - http://www.xbmc.org/forum/showthread.php?t=47560.
with that scrip you can run vdr or xbmc independently
!/bin/bash export LANG=ru_RU.UTF-8 export LC_ALL=ru_RU.UTF-8 /usr/src/VDR/vdr --lirc --localedir=/usr/src/VDR/locale -s /etc/vdr/vdrpoweroff.sh -v /video -c /etc/vdr -u root -L /usr/src/VDR/PLUGINS/lib -P"xine -r" &
while [ 1 -eq 1 ]; do
svdrpsend.pl remo on &&
xine -f --post vdr_video --post vdr_audio --post upmix_mono --verbose=2 -V vdpau -A alsa "vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"
svdrpsend.pl remo off && xbmc -fs -l
done
Hi,
Are there cleaner or later patches somewhere for vdr (1.7.8) for xmbc? The patch vdr-1.7.4-ext68-streamdev.patch from ticket http://xbmc.org/trac/ticket/5595
could be applied but there could be some extra that I don't need from some VDR extensions patch.
I'm also wondering if streamdev cvs is good as such. The HISTORY file mentions "added XBMC support by extending VTP capabilities (thanks to Alwin Esch)".
Anyway this is what I got when compiling
g++ -march=pentium4 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DUSE_STREAMDEVEXTENSION -DREMOTE_KBD -DVDR_USER="vdr" -DLIRC_DEVICE= "/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR="/video" -DCONFDIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="/usr/local/share/locale" -I/usr/include/freetype2 -I/usr/src/v4l-dvb/linux/include channels.c In file included from skins.h:17, from osdbase.h:15, from player.h:14, from status.h:15, from channels.c:17: recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’ cannot be overloaded recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent() const’ make: *** [channels.o] Error 1
BR, Seppo
On Sat, 2009-08-22 at 14:31 +0300, Seppo Ingalsuo wrote:
recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’ cannot be overloaded recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent() const’ make: *** [channels.o] Error 1
The duplicate due to patching had to be removed from recording.h. Also there was need to include status.h to videodir.c.
Now xbmc connects to vdr server and gets first radio channels, then tv channels and then nothing happens. I wonder how long it needs to be waited. Perhaps wrong/non working patches?
Xmbc without vdr seems to be fine.
BR, Seppo
On Sat, 2009-08-22 at 22:43 +0300, Seppo Ingalsuo wrote:
Now xbmc connects to vdr server and gets first radio channels, then tv channels and then nothing happens.
Now after PC and xbmc restart live tv works. Even DVB subtitles are shown!
How should I access vdr recordings from xbmc? Should I somehow import vdr directory (NFS share) to xbmc video library?
I'm also wondering when vdr channnels and particularly EPG are updated. Is it only when xbmc is restarted? Now I don't see EPG for satellite channels that provide only now & next or very short some hours EPG.
Othervise xbmc-vdr looks very promising with totally new high definition UI.
BR, Seppo
On Sun, Aug 23, 2009 at 1:46 AM, Seppo Ingalsuoseppo.ingalsuo@iki.fi wrote:
Othervise xbmc-vdr looks very promising with totally new high definition UI.
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
On Sun, 2009-08-23 at 09:05 -0700, VDR User wrote:
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me.
There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client.
Xbmc plus vdr as video streaming source & recorder seems to be a step into that direction. It could become a great option for vdr in the future.
BR, Seppo
2009/8/24 Seppo Ingalsuo seppo.ingalsuo@iki.fi:
On Sun, 2009-08-23 at 09:05 -0700, VDR User wrote:
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me.
There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client.
Maybe a streamosd plugin could provide what you need.
On Mon, 2009-08-24 at 09:12 +1000, Torgeir Veimo wrote:
Maybe a streamosd plugin could provide what you need.
I can't find further information about that with Google. Is that an existing project?
So, I'm not really having problem with VDR's OSD. I just want three independent user interfaces to each HTPC/television.
Xbmc test drive status: I found the VDR recordings as well from xbmc but unfortunately the recordings database seems to be corrupted. Selecting something from the list brings up a random recording :^) I was just lost with UI philopsophy that is totally different from native VDR. I suppose XBMC's was developed by Microsoft so it can't be bad, it just takes some time to learn ;^)
BR, Seppo
Hi, just thought I'd post the ttxtsubs patch I modified to apply cleanly to vdr-1.7.9 if someone is interested. /Magnus H
Have you tested it to make sure it works? I only ask cuz making a patch apply clean, and having it still work can be two totally different things sometimes.
VDR User wrote:
Have you tested it to make sure it works? I only ask cuz making a patch apply clean, and having it still work can be two totally different things sometimes.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I just checked it worked in my own environment, no thorough testing, no guarantees...... /Magnus H
2009/8/24 Seppo Ingalsuo seppo.ingalsuo@iki.fi:
On Mon, 2009-08-24 at 09:12 +1000, Torgeir Veimo wrote:
Maybe a streamosd plugin could provide what you need.
I can't find further information about that with Google. Is that an existing project?
So, I'm not really having problem with VDR's OSD. I just want three independent user interfaces to each HTPC/television.
I was merely suggesting a new type of plugin that allows a remote client to access and control the osd instance of the vdr server. The reason this is a problem is that vdr only have the notion of one osd instance, and streamdev doesn't really provide a way of controlling this osd.
On Mon, 2009-08-24 at 21:31 +1000, Torgeir Veimo wrote:
2009/8/24 Seppo Ingalsuo seppo.ingalsuo@iki.fi:
On Mon, 2009-08-24 at 09:12 +1000, Torgeir Veimo wrote:
Maybe a streamosd plugin could provide what you need.
I can't find further information about that with Google. Is that an existing project?
So, I'm not really having problem with VDR's OSD. I just want three independent user interfaces to each HTPC/television.
I was merely suggesting a new type of plugin that allows a remote client to access and control the osd instance of the vdr server. The reason this is a problem is that vdr only have the notion of one osd instance, and streamdev doesn't really provide a way of controlling this osd.
Yeh, for separate UIs - independent clients, you'd need a single backend which has the DVB cards, and a series of 'frontend' VDRs (even on the same PC) which each export a UI .. and then use streamdev to shuffle video data. I never trusted streamdev as a reliable plugin for a long time, but it now appears to be quite robust and still under active improvement.
Of course sharing recordings / timers adds the usual levels of complexity, but I don't forsee VDR becoming a full client/server architecture any time soon so it's likely the best solution for some time..
Cheers, Gavin.
On 24/08/2009, Gavin Hamill gdh@acentral.co.uk wrote:
Yeh, for separate UIs - independent clients, you'd need a single backend which has the DVB cards, and a series of 'frontend' VDRs (even on the same PC) which each export a UI .. and then use streamdev to shuffle video data. I never trusted streamdev as a reliable plugin for a long time, but it now appears to be quite robust and still under active improvement.
Of course sharing recordings / timers adds the usual levels of complexity, but I don't forsee VDR becoming a full client/server architecture any time soon so it's likely the best solution for some time..
Cheers,
Gavin.
So what happens when the main/server machine gets stuck on channel zapping, when there and you see only a "no channel" display on the client? Should the recording happen on the server? or on the client side? how do you restart vdr if you can't see the server's menu?
On Mon, 2009-08-24 at 14:26 +0200, Theunis Potgieter wrote:
So what happens when the main/server machine gets stuck on channel zapping, when there and you see only a "no channel" display on the client? Should the recording happen on the server? or on the client side? how do you restart vdr if you can't see the server's menu?
I didn't say it was either flawless or an ideal approach, but there are always methods by which to deal with such failure. (e.g. the 'remote' plugin can listen on a TCP port and give you text OSD via telnet)
IMO, the recordings should always happen on the server. The xbmc-modified streamdev is now able to playback recordings over its own VTP:
http://www.xbmc.org/trac/ticket/5595#comment:29
The 'clever stuff' is handling clashes of recordings / timers - some kind of priority system e.g. parents timers override the kids ones.
gdh
On Mon, Aug 24, 2009 at 4:59 AM, Gavin Hamillgdh@acentral.co.uk wrote:
Yeh, for separate UIs - independent clients, you'd need a single backend which has the DVB cards, and a series of 'frontend' VDRs (even on the same PC) which each export a UI .. and then use streamdev to shuffle video data. I never trusted streamdev as a reliable plugin for a long time, but it now appears to be quite robust and still under active improvement.
When I tried streamdev it was very unstable. Granted, that was some time ago and I certainly hope the plugin has matured dramatically since then. However, I don't think that plugin is the best route to take for server/client.
Of course sharing recordings / timers adds the usual levels of complexity, but I don't forsee VDR becoming a full client/server architecture any time soon so it's likely the best solution for some time..
The more we have things like the Nvidia Ion platform appearing, the more important I think it is to add a well-thought out server/client design into the core of VDR. For example, right now you can buy mini-itx Ion systems that offer a great solution as an HTPC that supports HD all in a very small footprint. This is just what the doctor ordered.. A small low power but fully capable media pc you can easily hide or attach to the back of your tv. Or your 19" LCD if you prefer. But what do you do with all the pci dvb cards? Or even usb dvb devices? That little pc can handle most (if not all) of your needs with the exception of one major drawback... The small size comes by sacrificing things like pci slots & case space.
If there wasn't a need for server/client, mythtv wouldn't be so popular. It's one of the top features it offers, and reason enough for users who have abandoned VDR in favor of it. Unfortunately I agree that we won't see this type of change to VDR any time soon. I know Klaus isn't exactly thrilled about the idea and afaik doesn't intended to address this need any time soon, or possibly ever. A lot of people thought VDR would never see support for HDTV either and look how quickly that was implemented once the decision was made to do it. Maybe there's hope! ;)
Seppo Ingalsuo wrote:
On Sun, 2009-08-23 at 09:05 -0700, VDR User wrote:
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me.
There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client.
I really do not understand the rage about HD OSD and/or skins. VDR is meant for watching TV-programs, like sports, movies, documents, and porno, not OSD.
On Sun, Aug 23, 2009 at 11:24 PM, Lauri Tischlerlwgt@iki.fi wrote:
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me.
There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client.
I really do not understand the rage about HD OSD and/or skins. VDR is meant for watching TV-programs, like sports, movies, documents, and porno, not OSD.
Many of us are using real tv's and not computer monitors for viewing. And of course many are now doing hdtv. It's likely you're not a user of either or both of those. Certainly an HD OSD isn't required to watch tv but if you knew how ass ugly it was to see the crappy low-res 8bit OSD on a big high definition tv, you'd understand. Consider the HD OSD like having real nice woodgrain trim in your car. It's not required to drive but damn sure makes your car look better.
Something else you might not have considered is that it really is necessary to have a flexible OSD these days when you have tons of users both with SD & HD...Their display device capable of say 1920x1080 but the current OSD implementation not allowing you the full resolution when you're tuned to an SD channel. If you're going to update it to accommodate current/future needs, why not improve the OSD as a whole?
There's no law that says VDR has to be stuck in the stone age.. It really can be slim & trim, stable, and provide users with luxury as well.
VDR User wrote:
On Sun, Aug 23, 2009 at 11:24 PM, Lauri Tischlerlwgt@iki.fi wrote:
Did you know that Klaus is giving VDR a new 24bit OSD? High resolution/high color will soon be in vanilla VDR, no expensive eHD card or otherwise required. ;)
That's nice but my main problem with vdr is having two televisions + one computer that can be used for TV watching too. HD UI is not the main driver for me.
There really should be a proper server/client(s) architecture with vdr. Possible HD UI development for vdr to be useful should be developed to operate as IP streaming client.
I really do not understand the rage about HD OSD and/or skins. VDR is meant for watching TV-programs, like sports, movies, documents, and porno, not OSD.
Many of us are using real tv's and not computer monitors for viewing. And of course many are now doing hdtv. It's likely you're not a user of either or both of those. Certainly an HD OSD isn't required to watch tv but if you knew how ass ugly it was to see the crappy low-res 8bit OSD on a big high definition tv, you'd understand. Consider the HD OSD like having real nice woodgrain trim in your car.
I really wouldnt care less, if the OSD on my Toshiba 42" FullHD looks ass ugly, so be it, just about anything, while developing VDR, is more important then HD OSD. "Real nice woodgrain trim in cars" was used in some 1950's stationwagons. :)
I really wouldnt care less, if the OSD on my Toshiba 42" FullHD looks ass ugly, so be it, just about anything, while developing VDR, is more important then HD OSD.
You are absolutely right, totally unimportant, but it can look so unbelievable good.
"Real nice woodgrain trim in cars" was used in some 1950's stationwagons. :)
I get still tears in my eyes, when I remember my 1978's Alfa Romeo Giulia Nuova 1600 with steering wheel made from wood and leather all around.
Gerald
On Mon, Aug 24, 2009 at 3:57 AM, Lauri Tischlerlwgt@iki.fi wrote:
I really wouldnt care less, if the OSD on my Toshiba 42" FullHD looks ass ugly, so be it, just about anything, while developing VDR, is more important then HD OSD. "Real nice woodgrain trim in cars" was used in some 1950's stationwagons. :)
While I would place other things higher on the TODO list (well-designed server/client capability for example), a nice HD OSD wouldn't be at the bottom. I'm glad Klaus took notice of how many users wanted this. Keep in mind, that's why VDR even has HD support now, and probably TS as well because from previous postings he didn't show much interest since those wern't things he needed. But it's made the user base happy!
Overall I'm for anything that improves/enhances VDR, and attracts more users in. If that's a fancy OSD or something else, it's all fine by me. I stand by my earlier statement that VDR "can be slim & trim, stable, and provide users with luxury as well" because I think it's foolish not to believe that.
Some people like peas & carrots, some don't. ;)
Seppo Ingalsuo wrote:
Hi,
Are there cleaner or later patches somewhere for vdr (1.7.8) for xmbc? The patch vdr-1.7.4-ext68-streamdev.patch from ticket http://xbmc.org/trac/ticket/5595
could be applied but there could be some extra that I don't need from some VDR extensions patch.
I'm also wondering if streamdev cvs is good as such. The HISTORY file mentions "added XBMC support by extending VTP capabilities (thanks to Alwin Esch)".
Anyway this is what I got when compiling
g++ -march=pentium4 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DUSE_STREAMDEVEXTENSION -DREMOTE_KBD -DVDR_USER="vdr" -DLIRC_DEVICE= "/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR="/video" -DCONFDIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="/usr/local/share/locale" -I/usr/include/freetype2 -I/usr/src/v4l-dvb/linux/include channels.c In file included from skins.h:17, from osdbase.h:15, from player.h:14, from status.h:15, from channels.c:17: recording.h:66: error: ‘const cEvent* cRecordingInfo::GetEvent() const’ cannot be overloaded recording.h:63: error: with ‘const cEvent* cRecordingInfo::GetEvent() const’ make: *** [channels.o] Error 1
BR, Seppo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi, I've stripped the ext72 patch to contain just the two necessary extensions streamdevext and parentalrating and adapted it to vdr-1.7.9 but it should work for 1.7.8 also. Seems to work here so far and it's compatible with the iptv and ttxtsubs patches. Now all you need to get vdr-xbmc running is: vdr (duh!) my attatched patch for vdr streamdevoutput plugin from cvs XBMC pvr-testing from svn (with the streamdev patch in the XBMC tree, the osdteletext plugin also works)
No guarantees that it's gonna work for you though. /Magnus H
On Mon, 2009-08-24 at 18:00 +0200, Magnus Hörlin wrote:
Hi, I've stripped the ext72 patch to contain just the two necessary extensions streamdevext and parentalrating and adapted it to vdr-1.7.9 but it should work for 1.7.8 also. Seems to work here so far and it's compatible with the iptv and ttxtsubs patches. Now all you need to get vdr-xbmc running is: vdr (duh!) my attatched patch for vdr streamdevoutput plugin from cvs XBMC pvr-testing from svn (with the streamdev patch in the XBMC tree, the osdteletext plugin also works)
No guarantees that it's gonna work for you though.
Thanks! I'll give it a try!
Meanwhile I ran xbmc without patched vdr 1.7.9, just cvs streamdev. The functionality was quite okay with working channel selections, epg, list of recordings. Recording playback didn't work. According to vdr logs streamdev tried to start some wrong recording.
I wonder if parental rating is really mandatory. On the other hand I suppose it doesn't harm.
BR, Seppo
Seppo Ingalsuo wrote:
Meanwhile I ran xbmc without patched vdr 1.7.9, just cvs streamdev. The functionality was quite okay with working channel selections, epg, list of recordings. Recording playback didn't work. According to vdr logs streamdev tried to start some wrong recording.
I have the same problem with my vdr+xbmc setup. It might be a sorting order problem: if I select nth recording from the list in XBMC (which is in alphabetical order), vdr seems to do a depth first search in the video directory tree without any sorting at all and plays the recording that is in nth position in this order.
Also subtitles do not work for me when watching recordings (in live TV they are OK)
BR, H
On Wed, 2009-08-26 at 22:02 +0300, Harri Kaimio wrote:
I have the same problem with my vdr+xbmc setup. It might be a sorting order problem: if I select nth recording from the list in XBMC (which is in alphabetical order), vdr seems to do a depth first search in the video directory tree without any sorting at all and plays the recording that is in nth position in this order.
Do you have idea where the error is, is it in streamdev/server/recplayer.c in function scan()? Or at upper level in connectionVTP.c? While looking the code I don't get where the bug could be.
I really wonder how xbmc can be usable for some, is the separate patch for an old streamdev better?
Also subtitles do not work for me when watching recordings (in live TV they are OK)
I haven't yet been able to randomly hit a suitable YLE recording to check that :^)
BR, Seppo
Hi,
adding line
Recordings.Sort();
after
Recordings.Update( true );
in cConnectionVTP::CmdPLAY (in server/connectionVTP.c) fixes this particular problem. So the problem seems to be that streamdev reloads the recording list every now and then and does not sort it always.
By looking at code there seems to be a similar problem when deleting recordings which is of course even more worrying as it can lead to data loss... I haven't verified this yet though (and cannot test it before my kidslet me use the system again :-)
I still don't have any idea why the subtitles are not shown correctly in recordings. Also with some recordings from Yle's TV channels XBMC plays the wrong soundtrack (plain VDR works OK with them)
BR, H
Seppo Ingalsuo kirjoitti:
On Wed, 2009-08-26 at 22:02 +0300, Harri Kaimio wrote:
I have the same problem with my vdr+xbmc setup. It might be a sorting order problem: if I select nth recording from the list in XBMC (which is in alphabetical order), vdr seems to do a depth first search in the video directory tree without any sorting at all and plays the recording that is in nth position in this order.
Do you have idea where the error is, is it in streamdev/server/recplayer.c in function scan()? Or at upper level in connectionVTP.c? While looking the code I don't get where the bug could be.
I really wonder how xbmc can be usable for some, is the separate patch for an old streamdev better?
Also subtitles do not work for me when watching recordings (in live TV they are OK)
I haven't yet been able to randomly hit a suitable YLE recording to check that :^)
BR, Seppo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, 2009-08-30 at 08:49 +0300, Harri Kaimio wrote:
Hi,
adding line
Recordings.Sort();
after
Recordings.Update( true );
in cConnectionVTP::CmdPLAY (in server/connectionVTP.c) fixes this particular problem. So the problem seems to be that streamdev reloads the recording list every now and then and does not sort it always.
Thanks. That makes it work for me so that correct recording is opened.
But vdr-xbmc looks rather broken othervise related to recordings. Most of the time with new videos I get only sound chirps without video. Old vdr format videos seem to work better.
By looking at code there seems to be a similar problem when deleting recordings which is of course even more worrying as it can lead to data loss... I haven't verified this yet though (and cannot test it before my kidslet me use the system again :-)
Sounds scary!
I still don't have any idea why the subtitles are not shown correctly in recordings. Also with some recordings from Yle's TV channels XBMC plays the wrong soundtrack (plain VDR works OK with them)
I was able to open one recording from YLE Teema where subtitles were shown. It was an edited recording that seems to work better (audio chirps & no video problem).
BR, Seppo
I got xbmc-vdr working the other day - but can't seem to see any active deinterlacing when using VDPAU Temporal. Other methods such as bob and weave work okay, but not VDPAU. Does anyone else see this problem? Pretty useless without any reasonable deint going on.. :-(
Thanks,
Morfsta
do you know why xbmc support only vdpau-temporal ? what about bob-vdpau ? temporal_spatial-vdpau ?
I got xbmc-vdr working the other day - but can't seem to see any active deinterlacing when using VDPAU Temporal. Other methods such as bob and weave work okay, but not VDPAU. Does anyone else see this problem? Pretty useless without any reasonable deint going on.. :-(
Seppo Ingalsuo wrote:
On Mon, 2009-08-24 at 18:00 +0200, Magnus Hörlin wrote:
Hi, I've stripped the ext72 patch to contain just the two necessary extensions streamdevext and parentalrating and adapted it to vdr-1.7.9 but it should work for 1.7.8 also. Seems to work here so far and it's compatible with the iptv and ttxtsubs patches. Now all you need to get vdr-xbmc running is: vdr (duh!) my attatched patch for vdr streamdevoutput plugin from cvs XBMC pvr-testing from svn (with the streamdev patch in the XBMC tree, the osdteletext plugin also works)
No guarantees that it's gonna work for you though.
Thanks! I'll give it a try!
Meanwhile I ran xbmc without patched vdr 1.7.9, just cvs streamdev. The functionality was quite okay with working channel selections, epg, list of recordings. Recording playback didn't work. According to vdr logs streamdev tried to start some wrong recording.
I wonder if parental rating is really mandatory. On the other hand I suppose it doesn't harm.
BR, Seppo
Well, it seems you're right. I've read a post somewhere that parentalrating was needed but it seems to work just fine without it. And the streamdev extensions only seem to add some messages when new recordings start and that kind of things. /Magnus
On Wed, 2009-08-26 at 21:10 +0200, Magnus Hörlin wrote:
Well, it seems you're right. I've read a post somewhere that parentalrating was needed but it seems to work just fine without it.
It seems to give at least nice color coding to EPG. It's not correctly used in Finnish DVB broadcast (Mythbusters listed as sports :^) but useful any way.
And the streamdev extensions only seem to add some messages when new recordings start and that kind of things.
Oh, that sounds important. Och tack så mycket för patch, it applied cleanly.
BR, Seppo
Seppo Ingalsuo wrote:
On Wed, 2009-08-26 at 21:10 +0200, Magnus Hörlin wrote:
Well, it seems you're right. I've read a post somewhere that parentalrating was needed but it seems to work just fine without it.
It seems to give at least nice color coding to EPG. It's not correctly used in Finnish DVB broadcast (Mythbusters listed as sports :^) but useful any way.
Ok, didn't see that. For a while there I thought I made the patch for no reason... /Magnus
And the streamdev extensions only seem to add some messages when new recordings start and that kind of things.
Oh, that sounds important. Och tack så mycket för patch, it applied cleanly.
BR, Seppo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Goga777 wrote:
Of course it has limitations, it's a very young project. But it's progressing very fast
sure
and I think, given some time, that I will eventually abandon xinelib.
and vdr too ? :-)
Goga
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Oh no, I will NEVER abandon VDR. I have tried myth twice and I wasn't impressed. /Magnus
On Thu, 2009-08-20 at 18:44 +0200, Magnus Hörlin wrote:
Goga777 wrote:
Oh no, I will NEVER abandon VDR. I have tried myth twice and I wasn't impressed.
Ah, I have to butt in here with my Myth rant. I too tried Myth, but for me it has a critical flaw -> channel zapping... it takes several seconds to change channel.
The myth 'community', aware that it takes many seconds, told me that I am doing it wrong -> the user is supposed to choose something from the programme guide and then switch to it.
That alone kills Myth as a TV interface :/ Myth might be pretty to look at, but VDR is super-functional :)
gdh
On 19/08/2009, Magnus Hörlin magnus@alefors.se wrote:
Well, my ION board with 9400m does temporal deinterlacing of 1080i HDTV just fine in xbmc. The question was about the best silent solution and a computer with just an Atom and a 9400 requires a lot less cooling than something with a discrete graphics card. /Magnus H
On http://www.mythtv.org/wiki/VDPAU it indicates that the 9400M has limitations: Advanced (2x, Hw) used for <= 720, Temporal 2x HW or Advanced 1X HW for > 720
Where as Nvidia ion - GeForce 9400. Zotac IONITX-C reports: Works great even w/ single core atom. No fans. 20W power draw.
Can you confirm that you don't experience the same problems as with the GeForce 9400GT/M ?
Thanks, Theunis
-----Ursprungligt meddelande----- Från: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] För Theunis Potgieter Skickat: den 20 augusti 2009 10:00 Till: VDR Mailing List Ämne: Re: [vdr] HD clients for vdr
On 19/08/2009, Magnus Hörlin magnus@alefors.se wrote:
Well, my ION board with 9400m does temporal deinterlacing of 1080i HDTV just fine in xbmc. The question was about the best silent solution and a computer with just an Atom and a 9400 requires a lot less cooling than something with a discrete graphics card. /Magnus H
On http://www.mythtv.org/wiki/VDPAU it indicates that the 9400M has limitations: Advanced (2x, Hw) used for <= 720, Temporal 2x HW or Advanced 1X HW for > 720
Where as Nvidia ion - GeForce 9400. Zotac IONITX-C reports: Works great even w/ single core atom. No fans. 20W power draw.
Can you confirm that you don't experience the same problems as with the GeForce 9400GT/M ?
Thanks, Theunis
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.61/2312 - Release Date: 08/19/09 18:06:00
Yes, it has limitations but given the low power consumption it's still impressive. The ION runs fine with advanced deinterlacer for 576i and temporal for 1080i. A 9500GT can do advanced on 1080i but for me it's not worth the extra heat and space. I have the computer on the back of my TV. http://www.minhembio.com/magho /Magnus
2009/8/20 Magnus Hörlin magnus@alefors.se:
Yes, it has limitations but given the low power consumption it's still impressive. The ION runs fine with advanced deinterlacer for 576i and temporal for 1080i. A 9500GT can do advanced on 1080i but for me it's not worth the extra heat and space. I have the computer on the back of my TV. http://www.minhembio.com/magho
You have the setup I'm looking to get soon. I want to be able to transmit video + 7.1 sound over HDMI, do you know if your ION can do this? From the screenshots I've seen, the difference between temporal and spatial-temporal deinterlacing isn't enough to warrant using a regular size pc (which I have now sitting behind my tv) over the much much smaller & power not-hungry ION. Temporal should suit my wants just fine.
-Derek
-----Ursprungligt meddelande----- Från: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] För Theunis Potgieter Skickat: den 19 augusti 2009 09:52 Till: VDR Mailing List Ämne: Re: [vdr] HD clients for vdr
On 18/08/2009, Anssi Hannula anssi.hannula@gmail.com wrote:
Magnus Hörlin wrote:
Hi. My opinion is that nvidia's ION platform with vdpau and XBMC
gives the best result. The atom's cpu load is <10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats.
Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in
mplayer.
It's not very cheap yet but you can build a fanless one for €200. For
example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu.
--
Anssi Hannula
What GPU does the nvidia ION A type board have? Wikipedia lists it as NVIDIA PureVideo HD. And if you look that up on wikipedia then it could be any of the GPUs http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_ GPUs
It's a 9400.
Ideally you would like to have the 9400/9500 type GPU that can do both h264 and VC1.
From what I could read about Flash HD, is that the limitation seems to be from the Adobe plugin (on windows) that does not do hardware acceleration for h264 (http://www.nvnews.net/vbulletin/showthread.php?t=135840). But if we use mplayer or Xine to, then it should in theory it should be able to do Flash HD?
Sorry, my mistake. I didn't know flash movies were h264. It's just a problem for the poor souls that are stuck with windows then.
What is your setup like? Do you use VDR as the main application or do you use something like XBMC with VDR or do you load a plugin on VDR to play flash type movies? Which output plugin do you guys use? I currently use xineliboutput 1.0.4. It does have its short comings but very good for Live TV.
I have a vdr server that runs xineliboutput and streamdev, both from cvs. Then I use vdr-sxfe or xbmc on my diskless clients. Mostly vdr-sxfe for SD tv and xbmc for everything else. /Magnus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.59/2310 - Release Date: 08/18/09 18:05:00
-
Alex Fazzari -
Anssi Hannula -
Brian -
Chris Silva -
Gavin Hamill -
Gerald Dachs -
Goga777 -
Harri Kaimio -
Lauri Tischler -
Magnus Hörlin -
Morfsta -
Seppo Ingalsuo -
Theunis Potgieter -
Thomas Hilber -
Torgeir Veimo -
VDR User -
Vladimir Kangin