VDPAU API for Linux released by NVIDIA today - GPU hardware accelerated video decoder

No, it doesn't talk about the 9x series but it may give some indication as to what the 8x series does. I realize that it's Windows geared but if the hardware doesn't exist for Windows then it certainly isn't going to be there for Linux either. It does suck that it doesn't cover the 9x series however so I will keep reading. So far that mplayer discussion seems to have some decent information - I'm surprised the ffmpeg list is as quiet about this as it is. <sigh>

Oh and the NVIDIA guys seem to be active on the mplayer discussion too which is nice!

You people's search skills are sad

http://www.nvnews.net/vbulletin/showthread.php?t=123091

theuni Wrote:Supported list is here:
http://www.nvnews.net/vbulletin/showthread.php?t=123091

What does that say about your reading abilities?

You expect me to remember 6hrs ago?

BLKMGK Wrote:The reasoning for this is that apparently only one H.264 "profile" has been accelerated to date. I believe I picked that tidbit up from the Pharonix testing or from one of the posts in their forums that naturally I cannot find at the moment. From the sounds of it they accelerated one profile as an example and are maybe hoping others will work out patches for others? I believe the max profile was 4.1? I'm not "up" on the nomenclature but am pretty sure that was what I'd read and that hopefully more will be coming as people tune up on this? The ffmpeg guys sound a bit critical of the patches <shrug>

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.

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)

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?

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...

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.

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.