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

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



- motd2k - 2009-03-16

External subtitles are currently disabled over xbmc-VDPAU.


- Jaco2k - 2009-03-16

motd2k Wrote:External subtitles are currently disabled over xbmc-VDPAU.

Define "external subtitles" and... any plans when they will be enabled?

and...

I am going to switch my video card to take advantage of VDPAU. After I do this, do I need to install from scratch to use xbmx -vdapu or do I just need to add the repository and fetch the binaries?


- motd2k - 2009-03-16

Urrm, subtitles that arn't composited on the encode.

Yes, there are plans... there is no ETA.


- Jaco2k - 2009-03-16

motd2k Wrote:Urrm, subtitles that arn't composited on the encode.

Yes, there are plans... there is no ETA.

And for my second question?

I guess I was not clear - I am Linux noob... Wink
I have the regular xbmc branch installed now and this is my first install of the VDPAU branch. Is there anything special about the install or just a matter of following the instructions in the Wiki?

----
and I forgot to say: Thank you for the very great work you are doing - because of this I am building my first ever Linux dedicated PC... Smile


- zoxzox - 2009-03-16

danillll Wrote:@zoxzox

I am not sure if the subtitles are of type ASS (that's a wrong name for a format Smile ) , I will check when I first get home, but I can assure you that these subtitles were working fine with VDPAU 2 weeks ago before I updated to the latest rev.

I will try to debug it later on this evening and update you with my findings.

Here's a quick way to do it...

Find subtitle ID in mkv file foo.mkv:

mkvmerge -i foo.mkv
File 'foo.mkv': container: Matroska
Track ID 1: video (V_MPEG4/ISO/AVC)
Track ID 2: audio (A_DTS)
Track ID 3: audio (A_AC3)
Track ID 4: subtitles (S_TEXT/ASS)
Track ID 5: subtitles (S_TEXT/ASS)
Track ID 6: subtitles (S_TEXT/ASS)

Extract wanted subtitle:

mkvextract tracks foo.mkv 4:extracted.sub

Then look at the sub, and if it looks like described in here, than it's SSA/ASS subtitle...


- motd2k - 2009-03-16

Instructions are on Pg.1


- motd2k - 2009-03-16

As of latest SVN, 185.13 drivers are now required.

motd


- stuartmarsden - 2009-03-16

motd2k Wrote:As of latest SVN, 185.13 drivers are now required.

Why? I thought no one knew what had changed in 185.13. Do we get new functionality?

Thanks for your great work motd2k


- motd2k - 2009-03-17

There is a fix relating to spec compliance of glXBindTexImageEXT.


- szwagros - 2009-03-17

Hi,

I don't know if it's related only to vdpau branch but since I'm not using "normal" one I post it here.

From some time (I don't know exact svn revision or maybe it's because of 185.13 drivers which I installed recently) XBMC crashes at startup.

After some checking I found that the problem is in function printing GL_EXTENSIONS:

here is backtrace:

http://pastebin.com/m307c280b

Disabling call to LogGraphicsInfo() in Surface.cpp or commenting out
printing GL_EXTENSIONS in this function solves the problem.

Here is the output from glxinfo:

http://pastebin.com/m28ab6013

I hope this helps.

Szwagros


- stuartmarsden - 2009-03-17

motd2k Wrote:There is a fix relating to spec compliance of glXBindTexImageEXT.

I do not understand what that will bring but I will take your word for it being a good thing.

But will relying on a beta driver not preclude this from making it into the next stable release. If jaunty is the target then I guess it will either ship with 180.29 or 180.37.

By forcing the use of a beta driver it will preclude a lot of new users from getting access to this technology which I think is a bad thing. It has been working great for me with 180.29, 180.35 and 180.37 so while I am sure the fix you mention might be desirable is it really needed?

I would love to see this in the 9.04 release of XBMC as it will really boost Linux's position as the best platform for XBMC.

Cheers for the amazing work.


- Haggy - 2009-03-17

motd2k Wrote:Is there anything relevant in the log files? Anything in dmesg or Xorg.0.log?

I now have a debug log showing the issue i still get on the very latest r18605 and nVidia 185.13. Dumped it here: http://sprunge.us/bUGi?en

As you can see, i tried playing the Artbeats sample twice and everytime i get judder, then audio dropouts and then 'CDVDMessageQueue(audio)::Get - retrieved last data packet of queue' in the log.

For the last try i switched to GLSL rendering and all went fine - no suspicious lines in the log.

Hope you can find anything.
Thanks again for all your efforts!


- Haggy - 2009-03-17

stuartmarsden Wrote:I would love to see this in the 9.04 release of XBMC as it will really boost Linux's position as the best platform for XBMC.

As general acceptance for VDPAU and its proprietary counterpart at nvidia is not that good among the xbmc developers (at least i read about that), i'm nearly sure that this VDPAU improvements will not make it to the next release. If you're a frequent reader of nvnews you will see, that even nvidia sees its vdpau implementation as beta quality and in constant motion. i don't think it makes sense freezing it into a stable version just to see that the api changes the day after.

just my 2 cents.


- motd2k - 2009-03-17

I don't believe so. This change was implemented purely to make it *more* likely that this code get accepted into linuxport, as it was - i was having to deviate from the 'OpenGL' specification to get around a nuance in the NVIDIA implementation of glXBindTexImageEXT. As such it would have made running the code on anything other than NVIDIA hardware unreliable.

I realise that right now only NVIDIA implement VDPAU, but there was (i believe) talk of Intel adding it, and as such it's right that the function should be implemented according to specification.

Regarding the general acceptance of VDPAU within the xbmc developer community, I couldn't disagree more - as soon as there was a working 'proof of concept' of xbmc-VDPAU i've seen nothing but support and assistance from the rest of the team.

If it doesn't make 9.04 then its not because of road-blocks put in by the team, it's because it's not ready. Either way, once it's in linuxport, it's official and its very likely that xbmc-live would be updated to include it for example. To hell with Ubuntu and the driver version they may or may not choose to include. I'd rather people installed the driver the correct way anyway!


- motd2k - 2009-03-17

Haggy Wrote:As general acceptance for VDPAU and its proprietary counterpart at nvidia is not that good among the xbmc developers (at least i read about that), i'm nearly sure that this VDPAU improvements will not make it to the next release. If you're a frequent reader of nvnews you will see, that even nvidia sees its vdpau implementation as beta quality and in constant motion. i don't think it makes sense freezing it into a stable version just to see that the api changes the day after.

just my 2 cents.

The core API hasn't changed in as long as i've seen it. They've added features but not changed the way the old ones were accessed, so it's been pretty transparent development-wise. I've nothing short of total respect for the linux team at NVIDIA - they really are working hard on this stuff, which i'm sure you can all appreciate the results of.