2008-11-18, 05:22
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)
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)
