Kodi Community Forum
XBMC for Linux VDPAU - NVIDIA GPU video decoding support (now in the mainline SVN) - Printable Version

+- Kodi Community Forum (http://forum.kodi.tv)
+-- Forum: Help and Support (/forumdisplay.php?fid=33)
+--- Forum: Kodi General Help and Support (/forumdisplay.php?fid=111)
+---- Forum: Linux and Live support (/forumdisplay.php?fid=52)
+---- Thread: XBMC for Linux VDPAU - NVIDIA GPU video decoding support (now in the mainline SVN) (/showthread.php?tid=45525)



- Rand Al Thor - 2009-04-01 03:48

Hey guys,

VDPAU was working quite well for me a few weeks back. Unfortunately, now it fails completely. Auto Refresh is off. I have tried setting renderer to Auto Detect and VDPAU ( in the hopes of forcing VDPAU).

Info:
Gentoo 2.6.23.8
Intel Celeron 3.2ghz
4gb Ram
Nvidia GeForce 8400 (180.44 Drivers)

Log

Cheers.


- Antioch - 2009-04-01 05:20

I just built my first nvidia based xbmc htpc and compiled today's main SVN (19113) and VDPAU doesn't work for me either. I have auto refresh off and have tried setting the rendering mode to both VDPAU and Auto Detect, in both cases CPU usage with a 720p x264 video is around ~40%.

I have an Intel e5200, and an nVidia 9300 IGP with the graphics memory aperture set to 512MB in BIOS with the 185.13 drivers installed. Oh, I'm also running on the Xbuntu 9.04 32-bit Beta but I doubt that will be an issue. Also, I ran .config with no options.

There we go. They changed the location!
http://pastebin.com/m7c5c832c

Thanks!


- gotoman00 - 2009-04-01 05:24

Antioch Wrote:I just built my first nvidia based xbmc htpc and compiled today's main SVN (19113) and VDPAU doesn't work for me either. I have auto refresh off and have tried setting the rendering mode to both VDPAU and Auto Detect, in both cases CPU usage with a 720p x264 video is around ~40%.

really? i can select vdpau or auto detect and my cpu usage will be ~4-5% (and that's at 1920x1080 60hz), however the video is stuttering and skipping alot...


- Antioch - 2009-04-01 05:47

Yes, really...

I'd like to know what you did to get it to work. Tongue


- gotoman00 - 2009-04-01 05:51

start reading about a page back and it details pretty much my whole story... originally vdpau was running but it was choppy as all hell way worse than any of the other render settings... after installing the new nvidia drivers that came out yesterday (not the beta drivers the new official ones) vdpau was working perfectly for a bit (although it couldn't seem to handle my dark knight 1080p rip or the killa sample that well)... however after freezing up starting a video and having to restart xbmc vdpau went back to being choppy again even after a few reboots... so unfortunately friend it's not really working at the moment... i posted my logs and hopefully someone can help Nerd


- motd2k - 2009-04-01 07:46

Antioch Wrote:I just built my first nvidia based xbmc htpc and compiled today's main SVN (19113) and VDPAU doesn't work for me either. I have auto refresh off and have tried setting the rendering mode to both VDPAU and Auto Detect, in both cases CPU usage with a 720p x264 video is around ~40%.

I have an Intel e5200, and an nVidia 9300 IGP with the graphics memory aperture set to 512MB in BIOS with the 185.13 drivers installed. Oh, I'm also running on the Xbuntu 9.04 32-bit Beta but I doubt that will be an issue. Also, I ran .config with no options.

There we go. They changed the location!
http://pastebin.com/m7c5c832c

Thanks!

Thats a pretty weird log, it's not even attempting to use VDPAU. Can you try checking your config.h file (in the XBMC source folder)...

PHP Code:
cat config.|grep HAVE_LIBVDPAU 

Something is very wrong there, and first instinct would be to suggest that the problem is missing libraries.


- Antioch - 2009-04-01 08:18

Code:
#define HAVE_LIBVDPAU 1

I have the vdpau dev package installed and when I ran .config it said that there was vdpau support. I will try it all again on fresh code.

Edit: .configure returns the following

Code:
------------------------
  XBMC Configuration:
------------------------
  Debugging:    Yes
  Profiling:    No
  Optimization:    Yes
  OpenGL:    Yes
  VDPAU:    Yes
  Joystick:    Yes
  XRandR:    Yes
  PCRE Support:    Yes
  MID Support:    No
  ccache:    No
  PulseAudio:    No
  FAAC:        Yes
  DVDCSS:    Yes
  Avahi:    No
  prefix:    /usr/local
------------------------

Hopefully a refresh was all it needed.


- motd2k - 2009-04-01 08:44

Strange. It might be worth a 'make reallyclean' and recompile. If that fails, next i'd try renaming the ~/.xbmc folder.


- Antioch - 2009-04-01 08:53

I made reallyclean and recompiled. With my x264 file both cores were sitting at ~10%! I'm happy now Smile (Unfortunately my xvid files don't offload to the GPU.... yet Rolleyes )

Thanks for the trouble shooting, and good luck on your bug-squashing hunt!


- Haggy - 2009-04-01 09:55

OT: motd2k, do you ever sleep? If i follow your posts i guess: nope

edit: must be that healbot thingy you mentioned some pages back Smile


- gotoman00 - 2009-04-01 16:42

good work... anything for me yet? Big Grin


- Antioch - 2009-04-01 23:25

Possible bug I thought I should bring up:

Using main's SNV 19113 on a GeForce 9300 IGP with 512MB RAM enabled (from a pool of 2GB DDR2 800) with an Intel e5200 CPU and both refresh and decoder set to auto I have noticed artifacting at the bottom of the screen on a 1080p VC-1 video.

Specifically, while watching the first episode of Planet Earth directly ripped from BluRay (that is to say, the original VC-1 video stream) during the first few minutes I notice what looks like artifacting at the bottom of the screen. It is clearly noticeable during the famous "bird scene" at the beginning of the episode -- and perhaps a bit more noticeable in the wispy snow at the bottom of the screen during the beginning of the penguin sequence immediately following the bird scene.

I used the debug overlay's CPU usage to ensure the video was in fact being decided using VDPAU. I then switched the decoder to software and attempted to see if the artifacts were still being produced. Naturally, frames were dropped during the decode so even though I didn't see any artifacting, it may be impossible to clearly say that it was due to VDPAU.

So I then decided to try the software decoder on my desktop PC which has a Core2Duo e6700 and XBMC svn deb installed (r18760, compiled Mar 21). This machine too dropped frames, but not nearly as many and again I didn't notice any artifacting.

Interestingly enough this artifacting only occurred in the bottom of the screen (at least what I noticed).

If this is a known issue, I apologize for bringing it up, but this thread is far too large to remember everything.

Thanks! Smile


- pike - 2009-04-01 23:45

Yes, this is a known bug, but the bug lies in Nvidia's DRIVER, so not much we can do about it other than letting them know about it. You should reproduce it using mplayer or ffmpeg and report it to them here:
http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

Antioch Wrote:Possible bug I thought I should bring up:

Specifically, while watching the first episode of Planet Earth directly ripped from BluRay (that is to say, the original VC-1 video stream) during the first few minutes I notice what looks like artifacting at the bottom of the screen. It is clearly noticeable during the famous "bird scene" at the beginning of the episode -- and perhaps a bit more noticeable in the wispy snow at the bottom of the screen during the beginning of the penguin sequence immediately following the bird scene.



- Antioch - 2009-04-02 00:39

pike Wrote:Yes, this is a known bug, but the bug lies in Nvidia's DRIVER, so not much we can do about it other than letting them know about it. You should reproduce it using mplayer or ffmpeg and report it to them here:
http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

I'll try to - supposing I can figure out how to get an mplayer-vdpau build easily up and running.

Either way, I'm glad it's a known bug. Seems like nVidia released another beta driver in the 180.xx series a week ago with more "vdpau fixes" and will hopefully keep doing so -- too bad we're stuck using 185.13 for now Sad


- fasteddy - 2009-04-02 03:14

I was using 19098, but I rolled back to 19031 as that was the last rev that didn't give me stutter (igp 8200).