+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder (/showthread.php?tid=40362)
- oldnemesis - 2008-12-18
mythmaster Wrote:[2] Only 3 GB of ram are currently being used because of the 32-bit os.
Did you install kernel compiled with PAE? You do not need 64-bit OS to use 4GB.
- topfs2 - 2008-12-18
malloc Wrote:Have you tried a mailinator email address?
It does appear that they support alpha, but it would still be a pain to implement without writing to a gl texture. They may not support that for security (drm) reasons.
Ive only scanned trough it fast but according to this: http://http.download.nvidia.com/XFree86/vdpau/doxygen/html/index.html
It looks like it should be possible to decode the frame and blend it with the underlying GUI, and then refeed that VdpOutputSurface to render the rest of the gui ontop of it. and this could be done by rendering to texture twice, which should include pixelshaders I think?, not that we use pixelshaders in the gui now but we should in the future to support blur and such.
The VdpOutputrendering supports alpha blending in a GL type of way so if we can just handle which should be feed first then it would be possible.
Though splitting the GUI in two and the big trouble is when there isnt a clear line, as with jmarshalls example when you blend stuff skinwise ontop of the video, as the scanlines in PM3 home.
Also from what I can deschiffer in the api it looks like one could do lots of surfaces and post process them in vdpau first and skip OpenGLs rendering, and let vdpau do that. This could be a way aswell. Only doing this on video ofc, and it relies on that the gl renderer is abstracted enough for us to switch between them easily after creating the context, IMO its probably the worse way of doing it though, duplicated code and such.
Anyways it might be possible and that is interesting.
- Gamester17 - 2008-12-18
Deanjo Wrote:BTW Xine Picks Up Support For NVIDIA's VDPAU.Cool that the Xine developers (like the MythTV developers) figured out how to support overlays and de-interlacing to support OSD, etc. with VDPAU
http://www.phoronix.com/scan.php?page=news_item&px=Njk0MA
Mailing list for xine-vdpau:
http://lists.kafic.ba/pipermail/xine-vdpau/2008-December/thread.html
The subversion repository:
svn://jusst.de/xine-vdpau
IRC:
Freenode
xine-vdpau
http://www.phoronix.com/scan.php?page=news_item&px=Njk0MA
Quote:This Xine VDPAU implementation doesn't depend upon ffmpeg and currently supports H.264 and MPEG streams with OSD (On-Screen Displays) and de-interlacing also working.
http://www.phoronix.com/scan.php?page=news_item&px=Njg4Ng
Quote:VDPAU in MythTV has full OSD (On-Screen Display), de-interlacers, color controls, and codecs support through the Video Decode and Presentation API for Unix. MythTV will automatically use VDPAU when it's compatible with the video format otherwise it falls back to using X-Video.
- quake101 - 2008-12-18
Very good news!
- eddietop - 2008-12-18
It would be amazing if this functionality came to XBMC one day!
- mythmaster - 2008-12-18
oldnemesis Wrote:Did you install kernel compiled with PAE? You do not need 64-bit OS to use 4GB.
It's the stock kernel in Kubuntu 8.10, so I guess not. Thanks!
- mythmaster - 2008-12-18
Using the same setup as my previous post --> http://forum.xbmc.org/showpost.php?p=255989&postcount=91
In mythtv, watching live HD channels uses ~10-12% cpu and looks great!
- BLKMGK - 2008-12-19
Stupid question on VDAPU - as I read it this was very profile specific yes? I saw that they had managed to get MKV files working but is this still profile specific and do you anticipate that it will always be so? If they can remove the profile limitations I'd be very veyr interested in this to say the least and the little ION board that NVIDIA demontrated would be QUITE attractive!
- CapnBry - 2008-12-19
BLKMGK Wrote:Stupid question on VDAPU - as I read it this was very profile specific yes?I'm not sure what you mean by profile specific. It supports some H264 profiles. Does it support Main Profile Level 1.1? Sure. Does it support High 4:4:4 Predictive Profile with 14-bit sample depth? Probably not.
It does have limitations, but as of 180.16 it seems to support High Profile up to Level 4.1 which cover almost any sanely coded video you send it. Driver 180.11 supported most of it too, but was hard-coded to allow a maximum of 4 reference frames to save memory. Unfortunately videos easily exceeded this limit which would abort playback at the moment a 5th DPB was needed.
- BLKMGK - 2008-12-19
I guess what I am trying to understand is if I have encoded my videos at something other than a specific canned profile are they likely to play? My vids are encoded in a manner I deemed "good" and would certainly not fit a specific "profile". If these could still see a reduction in CPU usage then I'm all for it! I suppose what I need to do is simply install the driver and patched player(s) and find out for myself.
What I'd read early on was that trying such videos was likely to lead to a player crash or poor video, I am hoping that this isn't the case any longer or that it's to a lesser degree. I do clearly recall reading about the 4 reference frame issues, NVIDIA was pretty quick to fix this it seemed - good for them!For day to day use would you say that the current beta NVIDIA driver is stable enough? I know that XBMC has not got any of these accelerations coded into it (ffmpeg not adopted them yet right?) so this would be for experimentation and I wouldn't want to lose anything in the course of "normal" XBMC usage is all.
- mythmaster - 2008-12-19
BLKMGK Wrote:For day to day use would you say that the current beta NVIDIA driver is stable enough? I know that XBMC has not got any of these accelerations coded into it (ffmpeg not adopted them yet right?) so this would be for experimentation and I wouldn't want to lose anything in the course of "normal" XBMC usage is all.
Works fine for me with gl vsync enabled in both the driver and XBMC. The UI is kind of choppy with "Desktop Effects" enabled, though.
- CapnBry - 2008-12-19
BLKMGK Wrote:I guess what I am trying to understand is if I have encoded my videos at something other than a specific canned profile are they likely to play? My vids are encoded in a manner I deemed "good" and would certainly not fit a specific "profile".Ah I see. Well the profile restricts things like the feature set, macroblock rate, reference frame count, dct size, etc. So anything under that limit means it fits the profile. NVidia hasn't published exact specs so nothing is set in stone, but here's here's what features I've found they support:
Reference frames: "Up to the proper number supported by the resolution divided the profile's macroblock limit" is what they say. This means 4 for 1080p content, 9 for 720p in High L4.1, and 13 for 720x480p High L3.1. I've never tried anything higher than 8 personally.
Mixed refs: Supported
B-Frames: Should support up to reference frame count, but I've never tried more than 5.
Weighted B-Frames: Supported
Pyramidal B-Frames: Supported
8x8 vs 4x4 DCT Adaptability: Supported
In-loop deblocking: Supported
Trellis Quantization[b]: Supported
[b]Entropy Encoding: CABAC and CALVC supported
So based on these specs, I'd say they're either High or Main profile up to Level 4.1, but as long as your video fits under the frame size and reference count, you should be good to go. I haven't seen anything you can generate with a sane x264 command line (a.k.a not a killasampla) that it will not play. I have also not tried anything except MPEG2 and H.264 either.
Hope that helps!
- CapnBry - 2008-12-19
Oh forgot to say the beta driver works for my media center box, a GeForce 9400, but sometimes when I am task switching via compiz's Static Application Switcher, I sometimes get spastic flashing between the desktop background, the switcher, and the foreground application which can only be remedied by Alt-Tabbling and clicking randomly until it settles down.
- BLKMGK - 2008-12-19
Good to hear it's fairly stable - I may jump in on my box and test it soon then - after I back it up
I may move to Ubuntu 8.1 too as it seems to work well on the box I just built. Appreciate the feedback on the new driver, breaking my box would make me sad but it wouldn't be end of world bad. <shrug>Here's the commandline meGUI feeds me that it uses for x.264. It's likely a bit insane but hopefully not using anything that this patch cannot handle. Produces decent sized flawless video for me so far and my CPu can decode it - not quite Killa' levels of nutz though.
Code:
program --pass 2 --bitrate 11000 --stats ".stats" --keyint 14 --min-keyint 2 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --trellis 2 --partitions all --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 14475 --vbv-maxrate 24000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd- mythmaster - 2008-12-20
BLKMGK Wrote:breaking my box would make me sad but it wouldn't be end of world bad.
You can always roll back the driver if it doesn't work well for you.