• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 28
VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder
#46
It seems like nVidia saw ATI's XvBA coming soon and jumped to be the first to release their accelerated video API for Linux.

For clarification, ATI's UVD is the unified video decoder that came out around the 2xxx series of ATI cards to compete with the new nVidia PureVideo on GeForce 7 series that both had some serious design flaws (but still blow XvMC out of the water). PureVideo HD (3rd generation) and UVD2 are on about the same level now, with the ability to do entropy decompression, frequency transform, prediction and in-loop deblocking in hardware. They have hooks for doing deinterlacing, frame rate changing, OSD compositing, scaling, and even dual stream decoding for PIP.

The good news/bad news for XBMC is that you can't get it to output to a GL context but you may not need to. The VDPAU design kinda like XVideo where you allocate a context, set the parameters for size/location/format and then give it the right data per frame. In this case, the right data is a ton of frame information and the raw compressed frame data. Once this gets into and stabilized in ffmpeg, XBMC can select the proper codec that doesn't decompress the frames and then a renderer would have to be written that doesn't really render anything but sets up the VDAPU in the proper place on the screen. The really good news is that looking over their patch, the basic concept is similar to ATI's version of the same thing which means at least for getting a video on the screen, the codepaths will look very similar. Post-proc and OSD callback interfaces could be very different though.

It is a step in the right direction, but this is still a ways off because you can't do OSD compositing and seeking in mplayer can pretty much lock your display to the point you have to alt-sysreq reboot. OSD being the big thing that's going to need major work on both ends.

This is completely different than the SOC method. SOC is for writing an MPEG decoder in shaders, this is sending the bitstream into a black box. (that's why I'm elaborating in this thread rather than the other)
#47
That is the single most helpful comment I think I've ever seen in this forum. Way to do your research!

So I've got a question. The docs say you could composite on top of the video. I imagined that meant OSD, and I assumed it would be OpenGL. Any idea what they meant by that if it wasn't OSD?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
#48
freddyflinty Wrote:Just FYI -- I dual-boot my XBMC box (Nvidia 8400) to Vista (very rarely) and have the GPU decoding working fine for x264 mkv files. While 720p has worked just fine, it doesn't support any "scene" 1080p releases due to some of the encoding options used. So --- if during any testing of GPU decoding under linux some stuff doesn't play, it may be a limitation of the GPU and not the linux implementation.

Okay this confuses me... You have the GPU working in... Vista? I don't understand the importance of the dual boot here.

As for working or not working with specific encoding it's got nothing to do with the GPU ability and more to do with them not having encoded the acceleration for more than a small number of encoding profiles from what I gather. Are you trying to say that the GPU is incapable of doing more than these few and that it's not a coding limitation? I do not think that is accurate...
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
#49
BLKMGK Wrote:Okay this confuses me... You have the GPU working in... Vista? I don't understand the importance of the dual boot here.

As for working or not working with specific encoding it's got nothing to do with the GPU ability and more to do with them not having encoded the acceleration for more than a small number of encoding profiles from what I gather. Are you trying to say that the GPU is incapable of doing more than these few and that it's not a coding limitation? I do not think that is accurate...

OK let me clarify -- for reasons I can't explain, the hardware acceleration that Nvidia provides (under Windows) doesn't work with certain encoder/profile options often used by the "scene" for 1080p x264 releases. I am surmising that some of the testing mentioned already in this thread may not be working because of driver/hardware limitations rather than being a fixable bug that one of the ffmpg/xbmc geniuses can fix.

I looked back to see where I first discovered this limitation and it seems there's a great follow-up post over at avsforum right here that walks through the encoder options necessary to make an x264 video playback with Nvidia (and ATI/PS3) h/w acceleration.
#50
Thanks, I try to keep on top of these things! Yes it can composite using a mixing renderer will only composite other vdp surfaces as far as I can tell. You can also pixel blit to an output surface, but it is all "native blits" meaning RGB 444 data.

Both ATI and nVidia's solutions are very close to the VMR9 chains with DXVA on windows. I heard one of the ATI techs actually say the silicon is optimized for that workflow so that's probably why they both look so similar.

Actually it looks like if you want to be hacky you can pull native bits back from an output surface, which you could then convert to a texture and push back to the GL surface.
Image
#51
Okay this makes more sense I think. However I'm not sure that it's a limitation of the hardware that prevents movies from being accelerated if they aren't matching specific settings. It would make sense that they would concentrate on specific profiles I guess although naturally I'm using something custom I cobbled together and probably am over the top. I guess with my next BD encode I'll have to try the profile they specified.

I'm not sure that they cannot accelerate other profiles and it's not clear to me that it's not a CODEC issue from that thread either but that's pretty interesting indeed. I guess we'll see if this is something that requires specific settings or not soon enough. Appreciate the clarification for sure!
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
#52
Here is some info:

http://www.avsforum.com/avs-vb/showthread.php?t=972503
#53
sweet, they recommend a windows only app. way to post that in the linux users support forum!
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
#54
What, meGUI? That's what I use! If it's too hard to get that running on a Windows box then why not just take the commandline it creates and use that with x264 which I think is crossplatform? All meGUI does is allow you to build the commandlines easily for x264, there should be no reason why that advice couldn't also be used on Linux. <shrug> I use the Linux XBMC but encode on a Windows desktop - it's easier and there are more tools handy for me to use.

The biggest things to be gotten out of that thread IMO is that there are specific coding requirements for getting acceleration working on Windows and as we've seen Linux too - the two may not be the same profiles but obviously this isn't a magic wand that just speeds up everything. IMO that kind of sucks but at least they seem to be doing a standard profile so we've not got some silly profile like the game consoles seem to want that's different than others. It's also important to get out of that thread that while meGUI may work "best" to encode these you can do it with something on other OS so long as you have an H.264 encoder it seems - like x264. Use the right switches and levers and it works and that's not something Windows specific even if the tool they use as an example is... Near as I can tell the Windows port of x264 is unofficial anyway, Linux seems to be it's primary platform... -> http://www.videolan.org/developers/x264.html
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
#55
The bottom line of this thread is that GPU acceleration sucks. If it won't accelerate all H.264/VC-1 profiles then I'm glad I choose the all-software solution with high end CPU - at least I know I can really play it all.

I'm beginning to think that developers choice to prefer GLSL over hardware codecs is the best thing to do. At least it can off-load portions of every codec, be it MPEG2, H.264 or something as common as DivX HD! I only hope that IGP's have enough power to still advantage from the GLSL accelerations, because that is what I have Smile
#56
malloc Wrote:sweet, they recommend a windows only app. way to post that in the linux users support forum!

i'm sure you could translate the settings to a handbrake profile. that's what i'm using on linux and it works fine for me. both of them are using the x264 slave backend to do the actual encoding.
#57
gbyte Wrote:The bottom line of this thread is that GPU acceleration sucks. If it won't accelerate all H.264/VC-1 profiles then I'm glad I choose the all-software solution with high end CPU - at least I know I can really play it all.

I'm beginning to think that developers choice to prefer GLSL over hardware codecs is the best thing to do. At least it can off-load portions of every codec, be it MPEG2, H.264 or something as common as DivX HD! I only hope that IGP's have enough power to still advantage from the GLSL accelerations, because that is what I have Smile

I'm not sure I'd say it sucks. I mean taking CPU usage down to a tenth or less of what it was when run on the CPU is not something to sneeze at and would bring down costs of building a machine by at least $100 if not more. The question I have so far as the profile limitations is where is the limitation - the driver? The hardware? Something in the CODEC? I believe that it's probably not the hardware but if it's the driver that sux too since it's closed source. The hardware wouldn't make sense to me either since even if they have pretty specific stuff in there I'd think that some gains could be gotten on more generic things anyway.

I guess we'll see. Hopefully the NVIDIA guys will keep working at this and we'll see soem good results. Maybe ATI will get in the game tooShocked

Edit: New beta has added GL3.0 support as well! http://www.phoronix.com/forums/showthread.php?t=13928
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
#58
BLKMGK Wrote:I'm not sure I'd say it sucks. I mean taking CPU usage down to a tenth or less of what it was when run on the CPU is not something to sneeze at and would bring down costs of building a machine by at least $100 if not more. The question I have so far as the profile limitations is where is the limitation - the driver? The hardware? Something in the CODEC? I believe that it's probably not the hardware but if it's the driver that sux too since it's closed source. The hardware wouldn't make sense to me either since even if they have pretty specific stuff in there I'd think that some gains could be gotten on more generic things anyway.

I guess we'll see. Hopefully the NVIDIA guys will keep working at this and we'll see soem good results. Maybe ATI will get in the game tooShocked

Edit: New beta has added GL3.0 support as well! http://www.phoronix.com/forums/showthread.php?t=13928

I agree, if it can be coded to support every profile, it will be great feature I would consider for my next HTPC. But if it adds acceleration for just a few codec profiles, it's disappointing and using slow CPU will again make it impossible to play any video file.

If I was fine with just partial codecs support for my movie playing device, I would have buy DivX Connected DSM-330 set-to-box or SageTV HD extender or PS3 even, instead to bother building full featured play-it-all box. I guess many pick XBMC because its complete video support and some partial acceleration would still suck and not eliminate the need for fast CPU to play the rest of your HD content. What will you do now? Re-encode all your old BluRay rips that don't comply with specifications?!

I truly hope it's software limitation and ffmpeg or XBMC folks can get a better codec than windows to accelerate any type of h.264 profiles. And if not, then let's hope ATI or Intel will do it better Smile

All this looks to me like a conspiracy to make illegal BluRay rips unplayable. Nod
#59
The grand majority of new BD rips are compliant with 4.1 profile, hence fully supported by hardware decoding. At least, that's the way it is under Windows. The problem is how picky the hardware codec is when it comes to subtitles rendering, I wonder if the Linux solution will be more flexible.

On the other hand. I agree with gbyte: if one can't be sure of hw acceleration working for all material... you end up in a situation where a fast CPU and onboard video is the best way to go, just to be sure.
#60
Well, my particular BD rips which I do myself aren't likely compliant although my next one probably will beWink My current ones will not be redone, it's too much time invested to recompress them all. If what you are saying about BD rips being compliant is that what comes right off the media is compliant than that also doesn't work for me - the file sizes are huge. I dunno' what "the scene" does as I don't download movies but if that is what you are referring too then yeah being able to play those would make many happy.

I guess we'll see. My feeling is that there are hardware paths onboard that can accelerate specific functions and that now a driver to access them exists. So long as those paths aren't for complete specific profiles and can be used more generally than we just need to wait for coded support. If instead they can only be used for specifically coded video then yeah - that sux and we'll need a fast CPU. I sort of get the impression that even on Windows there's a need to use specific encodings to gain the acceleration, if that's ibndicitive of what we'll be saddled with on top of the fact that this is a speedup for NVIDIA only then yeah this might not be such great news afterall.

I guess maybe we'll know more when the driver is more stable and when the changes are rolled into ffmpeg and accepted by the devs here. IMO this isn't going to be a short time period fix to anything...Sad hopefully I'll be proven wrong, my fingers are crossed!
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 28

Logout Mark Read Team Forum Stats Members Help
VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder3