I have made some experiments with xineliboutput and vdpau, it looked promising, but at least I had to give up for now. I have used vdr 1.6.0, xineliboutput 1.0.3, nvidia driver 180.22, xine-lib-vdpau from 20090113 and xinelib 1.1.90hg from 20090114 with vdpau-patch r160. I use it with sdtv, because I have only DVB-T and a PVR350. The cpu usage for vdr-sxfe goes down from 25% to 7%, but the picture is not in sync with the sound. The biggest problem is that if I switch channels it happens that the video starts to flicker. You can see that between the pictures of the current channel the pictures of the previous channel appear. Restarting vdr-sxfe fixes it till the next channel switch. In the beginning of my test this happened seldom, but now it happens with every channel switch, the problem is that I have no idea what configuration change I have done that is to blame.
Does anyone have an idea what I can try next, or should I simply wait for a better version of the xine-lib for vdpau.
Gerald
The biggest problem is that if I switch channels it happens that the video starts to flicker. You can see that between the pictures of the current channel the pictures of the previous channel appear.
I noticed now that it get worst if I use "software scaling" in the xineliboutput settings for video.
Gerald
On Mon, 19 Jan 2009 00:47:17 +0100 Gerald Dachs vdr@dachsweb.de wrote:
I have made some experiments with xineliboutput and vdpau, it looked promising, but at least I had to give up for now. I have used vdr 1.6.0, xineliboutput 1.0.3, nvidia driver 180.22, xine-lib-vdpau from 20090113 and xinelib 1.1.90hg from 20090114 with vdpau-patch r160. I use it with sdtv, because I have only DVB-T and a PVR350. The cpu usage for vdr-sxfe goes down from 25% to 7%, but the picture is not in sync with the sound. The biggest problem is that if I switch channels it happens that the video starts to flicker. You can see that between the pictures of the current channel the pictures of the previous channel appear. Restarting vdr-sxfe fixes it till the next channel switch. In the beginning of my test this happened seldom, but now it happens with every channel switch, the problem is that I have no idea what configuration change I have done that is to blame.
I had the same problems. I didn't notice that the picture flickering (do you get big patches of mostly green garbage?) was triggered by channel changes, but that could well be the case.
I noticed the bad sync too. It seemed to start off slightly out of sync and get worse the longer I left it running, but I haven't confirmed that. I'm using HDMI audio, you'd think the video and sound clocks would therefore be derived from the same clock on the NVidia chip and it should be easier to avoid loss of sync :-(.
I had the same problems. I didn't notice that the picture flickering (do you get big patches of mostly green garbage?)
No, not at all, always still pictures that was seen before.
was triggered by channel changes, but that could well be the case.
Only with channel changes here, and only with the option "software scaling" set to true in xineliboutput.
I noticed the bad sync too. It seemed to start off slightly out of sync and get worse the longer I left it running, but I haven't confirmed that.
I didn't have the feeling that it get worse, it seems to be stable.
I'm using HDMI audio, you'd think the video and sound clocks would therefore be derived from the same clock on the NVidia chip and it should be easier to avoid loss of sync :-(.
Okay, I don't use HDMI audio, because my receiver is too old for this and I am even not sure currently whether my Plasma supports HDMI Audio, will test next chance.
Yesterday I have switched back to the use of vdpau, because I got now periodically hick ups with xv and xxmc, the last time I had this working correct I had another CPU, mainboard and nvdida driver :(. The loss of sync is less disturbing than this periodically stops of motion.
Will soon try the r167 release of the vdpau patch.
Gerald
On Mon, 19 Jan 2009 17:40:17 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Yesterday I have switched back to the use of vdpau, because I got now periodically hick ups with xv and xxmc, the last time I had this working correct I had another CPU, mainboard and nvdida driver :(. The loss of sync is less disturbing than this periodically stops of motion.
What graphics card/chip have you got? AFAIK xvmc/xxmc only works on NVidias up to 7x00 and VDPAU is for 8x00 and newer. If your CPU usage dropped significantly with VDPAU it sounds like you didn't actually have xxmc working, just plain xv.
Am Mon, 19 Jan 2009 17:03:34 +0000 schrieb Tony Houghton h@realh.co.uk:
On Mon, 19 Jan 2009 17:40:17 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Yesterday I have switched back to the use of vdpau, because I got now periodically hick ups with xv and xxmc, the last time I had this working correct I had another CPU, mainboard and nvdida driver :(. The loss of sync is less disturbing than this periodically stops of motion.
What graphics card/chip have you got? AFAIK xvmc/xxmc only works on NVidias up to 7x00 and VDPAU is for 8x00 and newer. If your CPU usage dropped significantly with VDPAU it sounds like you didn't actually have xxmc working, just plain xv.
I have an onboard Geforce 8200. CPU usage with xv was 27%, with xxmc 22% and with vdpau 7% max. You could be right that xxmc is in reality xv, because the usage is not very constant, so it could be the same CPU usage. Anyway, before I could use xv without this hick ups.
Gerald
On Mon, 19 Jan 2009 18:26:22 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Am Mon, 19 Jan 2009 17:03:34 +0000 schrieb Tony Houghton h@realh.co.uk:
What graphics card/chip have you got? AFAIK xvmc/xxmc only works on NVidias up to 7x00 and VDPAU is for 8x00 and newer. If your CPU usage dropped significantly with VDPAU it sounds like you didn't actually have xxmc working, just plain xv.
I have an onboard Geforce 8200. CPU usage with xv was 27%, with xxmc 22% and with vdpau 7% max. You could be right that xxmc is in reality xv, because the usage is not very constant, so it could be the same CPU usage. Anyway, before I could use xv without this hick ups.
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
Am Mon, 19 Jan 2009 17:40:44 +0000 schrieb Tony Houghton h@realh.co.uk:
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
Of course is the cpu usage no problem, but the lost frames estimated every 10 seconds are, currently xv is not usable for me. Nothing in the logs to see when it happens.
Gerald
On Mon, 19 Jan 2009 18:57:51 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Am Mon, 19 Jan 2009 17:40:44 +0000 schrieb Tony Houghton h@realh.co.uk:
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
Of course is the cpu usage no problem, but the lost frames estimated every 10 seconds are, currently xv is not usable for me. Nothing in the logs to see when it happens.
Have you tried opengl output?
Am Mon, 19 Jan 2009 21:39:29 +0000 schrieb Tony Houghton h@realh.co.uk:
On Mon, 19 Jan 2009 18:57:51 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Am Mon, 19 Jan 2009 17:40:44 +0000 schrieb Tony Houghton h@realh.co.uk:
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
Of course is the cpu usage no problem, but the lost frames estimated every 10 seconds are, currently xv is not usable for me. Nothing in the logs to see when it happens.
Have you tried opengl output?
No, haven't even thought about, will try next chance. Could only happen that I will try the vdpau patch r167 before ;), I think I can't resist.
Gerald
On 20 Jan 2009, at 08:28, Gerald Dachs wrote:
Am Mon, 19 Jan 2009 17:40:44 +0000 schrieb Tony Houghton h@realh.co.uk:
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
If I recall correctly, the only difference between xvmc and xxmc, is that the latter falls back to xv when xvmc is not available. So you are probably using it in xv mode.
Am Mon, 19 Jan 2009 23:28:23 +0100 schrieb Gerald Dachs vdr@dachsweb.de:
Am Mon, 19 Jan 2009 21:39:29 +0000 schrieb Tony Houghton h@realh.co.uk:
On Mon, 19 Jan 2009 18:57:51 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Am Mon, 19 Jan 2009 17:40:44 +0000 schrieb Tony Houghton h@realh.co.uk:
I'm fairly sure xvmc (which xxmc is based on) isn't supported on Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and xine etc until VDPAU is known to be stable.
Of course is the cpu usage no problem, but the lost frames estimated every 10 seconds are, currently xv is not usable for me. Nothing in the logs to see when it happens.
Have you tried opengl output?
No, haven't even thought about, will try next chance. Could only happen that I will try the vdpau patch r167 before ;), I think I can't resist.
Gerald
with r167 the problem with "software scaling" and the hick ups still exist.
Gerald
Am Mon, 19 Jan 2009 16:10:48 +0000 schrieb Tony Houghton h@realh.co.uk:
I noticed the bad sync too. It seemed to start off slightly out of sync and get worse the longer I left it running, but I haven't confirmed that. I'm using HDMI audio, you'd think the video and sound clocks would therefore be derived from the same clock on the NVidia chip and it should be easier to avoid loss of sync :-(.
With the vdpau patch r181 the sound is in sync now.
Gerald
Hi Gerald,
Gerald Dachs schrieb:
[...] The biggest problem is that if I switch channels it happens that the video starts to flicker. You can see that between the pictures of the current channel the pictures of the previous channel appear. Restarting vdr-sxfe fixes it till the next channel switch. In the beginning of my test this happened seldom, but now it happens with every channel switch, the problem is that I have no idea what configuration change I have done that is to blame.
Does anyone have an idea what I can try next, or should I simply wait for a better version of the xine-lib for vdpau.
I read something similar on the MythTV mailinglist.
From http://www.gossamer-threads.com/lists/mythtv/users/366684: In the end I believe it was accidental code bugs when he was porting the automatic letterboxing patch over to work with VDPAU that caused him to end up with his OSD ghosted over every image displayed via VDPAU.
HTH, Greetings -Sascha-
I read something similar on the MythTV mailinglist.
From http://www.gossamer-threads.com/lists/mythtv/users/366684: In the end I believe it was accidental code bugs when he was porting the automatic letterboxing patch over to work with VDPAU that caused him to end up with his OSD ghosted over every image displayed via VDPAU.
Are you sure that this is the right thread? Someone thinks vdpau has destroyed his video card.
Gerald
Hi,
Gerald Dachs schrieb:
I read something similar on the MythTV mailinglist.
From http://www.gossamer-threads.com/lists/mythtv/users/366684: In the end I believe it was accidental code bugs when he was porting the automatic letterboxing patch over to work with VDPAU that caused him to end up with his OSD ghosted over every image displayed via VDPAU.
Are you sure that this is the right thread? Someone thinks vdpau has destroyed his video card.
Yeah I thought because of the overlapping pictures this might be related to your problem. It is just a wild guess, so feel free to ignore it.
Greetings -Sascha-
-
Gerald Dachs -
Sascha Vogt -
Tony Houghton -
Torgeir Veimo