XBMC for Linux VDPAU - NVIDIA GPU video decoding support (now in the mainline SVN)

tidan Wrote:Has anyone else had a problem with XBMC crashing when using VDPAU render mode on ubuntu Jaunty?

I have had this issue for the last few svn updates I have built (stretching back approx 2 weeks). When running "sudo apt-get build-dep xbmc" i get an error along the lines of "xbmc dependencies could not be met" but compiling and running xbmc stills works without problems.

Except of course that when i switch to VDPAU as the video rendering mode, xbmc crashes as soon as I play a video. No issues set to auto...

A system update of my Jaunty installation recently updated nvidia-180-libvdpau to nvidia-190-libvdpau and I suspect this may be related. I'll post a debug log soon but I just wanted to confirm that I'm seeing this problem too tidan.

Hello,

I am using the XBMC expertimental PPA from Henning Pingel , on an HP thinclient AMD sempron 2100+, 1Ghz, 512 mb + nvdia 8400gs. VDR is running on an other computer, and I am reading the streams with the thinclient. The thinclient is connected (dvi/hdmi) to a panasonic full hd 40" television.
SD is running flawless, but when I try ZDF HD I get 100% cpu and stuttering sound and image.
Is that normal with that kind of Hardware, or do I need to look to the soft configuration ?

thanks,

sp

splinux Wrote:Hello,

I am using the XBMC expertimental PPA from Henning Pingel , on an HP thinclient AMD sempron 2100+, 1Ghz, 512 mb + nvdia 8400gs. VDR is running on an other computer, and I am reading the streams with the thinclient. The thinclient is connected (dvi/hdmi) to a panasonic full hd 40" television.
SD is running flawless, but when I try ZDF HD I get 100% cpu and stuttering sound and image.
Is that normal with that kind of Hardware, or do I need to look to the soft configuration ?

thanks,

sp

You need to set the decoder to be vdpau first of all. It's in one of the options, I forget where. This is the 8400gs that I got that is able to decode 1080p h.264, so check to make sure yours is the same:

http://www.newegg.ca/Product/Product.asp...GS-TD512EH

Second is make sure the HD video is in h.264. Xvid will not work here.

Third is make sure your network can handle the bandwidth required for it. I suggest gigE for that. Don't even think about trying it with wireless. Wired is much more reliable.

I still cannot get VDPAU to work with 1080P videos. XBMC just shutsdown.
I found that using "Software" as the rendering mode helps reduce jitter dramatically, but would like to see the GPU doing the work instead of my CPU.
Any ideas

tidan Wrote:I still cannot get VDPAU to work with 1080P videos. XBMC just shutsdown.
I found that using "Software" as the rendering mode helps reduce jitter dramatically, but would like to see the GPU doing the work instead of my CPU.
Any ideas

same problem here :-(

Quote:xbmc@xbmc:~$ export XBMC_HOME=/usr/local/share/xbmc && xbmc-standalone
[....... and after try to play 1080p video using vdpau I get a random crash ....]
xbmc.bin: ../../src/xcb_io.c:176: process_responses: Assertion `!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))' failed.
Aborted

Run it manually from the command line and post the log at the end of it when it crashes.

As of revision 24203 XBMC is capable of selecting VDPAU automatically when setting render method to "Auto detect" from player settings. This is a really nice addition but would it also be possible for XBMC to fall back to using software renderer when it detects a file that is not VDPAU compatible?

Quote:All feature set B hardware cannot decode H.264 for the following widths: 769-784, 849-864, 929-944, 1009-1024, 1793-1808, 1873-1888, 1953-1968, 2033-2048 pixels.

XBMC can extract videostream details from files and stores this info to database/nfo like this (Nightmare Before Christmas):


If XBMC detects video width that is not compatible with VDPAU it would automatically fall back to using software renderer. The needed information is already available but is it possible to implement this function? This way "Auto detect" would work just like it sounds it would. Or is this already on the "to-do"-list? Reading between the lines here would suggest that?

Putting it in the file or metadata is a bad solution. It ends up creating more work for the user, unless they're a programmer, they'd like this kind of detailed functionality.

But shouldn't the driver itself should be able to tell what resolutions it can and can't handle via the hardware it's on? Then you wouldn't need to have to set it for every single file you got. I know I'd prefer the driver method.

pyrates Wrote:But shouldn't the driver itself should be able to tell what resolutions it can and can't handle via the hardware it's on? Then you wouldn't need to have to set it for every single file you got. I know I'd prefer the driver method.

This is exactly what I mean. No need for another entry in the database or manually setting the renderer file per file. I was just referring to database and nfo-files to highlight that the needed stream information is already extracted by XBMC. Auto detect already works for the non H.264 files (like xvid avi file) but not for the H.264 files with incompatible widths.

ubiq Wrote:This is exactly what I mean. No need for another entry in the database or manually setting the renderer file per file. I was just referring to database and nfo-files to highlight that the needed stream information is already extracted by XBMC. Auto detect already works for the non H.264 files (like xvid avi file) but not for the H.264 files with incompatible widths.

Ah ok. Misunderstood your point there. But it's not just incompatible widths, but also incompatible heights and encoded levels such as only going up to 4.1, not all the way to 5.2.