This isn't about patents, it's about one simple thing: GPUs aren't actually suitable for video decoding. A lot of effort required for not much gain.
Yeah, I've been preaching this for YEARS, but most people apparently still like to believe in fairies. Shader-based video decoding is simply useless for the vast majority of configurations. You can't offload some of the most demanding parts of the pipeline, it's WAY more power-guzzling than CPU decoding, and you need a somewhat beefy GPU to start with.
But it's still good to have VDPAU, as it provides a very capable presentation layer, much better than the old Xvideo.
Can you expand on that - what am I missing by still using XV?
Well, here's a quick list. Xv doesn't provide
- frame queueing and accurate display timing. This is especially problematic if video FPS are higher or equal to the display refresh rate
- any notable control over colorspace conversion and only limited control over image color settings
- any notable control over scaling quality
- subpicture composition for OSD/subtitles
- RGB formats (only few implementations of Xv can do that)
- 10bpp formats
- interoperability with OpenGL
and these are, IMHO, very important features. Xvideo is still common because it is usually the least common denominator, but this is really holding Linux back with respect to video output quality and capability, compared to OS X or Windows.
Your E-350 decodes Full HD using a dedicated hardware decoder (UVD) that the fglrx driver has access to. But I wasn't talking about a dedicated decoder, I was talking about the GPU. The GPU is bad at decoding.
I know one can use fglrx but ufortunetly it is not without issues either which quick search shows. Therefore I much rather follow development of the open source driver version - r600 in my case.
Originally Posted by Gusar
Adding vaapi to Gallium wouldn't change anything when it comes to AMD. It's not about the API, it's getting access to UVD. We don't have documentation to do that, so Gallium can only use the GPU (shaders) for decoding. And writing a shader-based h264 decoder would be a lot of effort for little gain, it's not worth it.
Well for me regular John Doe shaders or not I would love to see improvements in video decoding department for AMD chips so I would not have think twice before purchasing their hardware in the future, but I do admit it went long way already for both fglrx and r600 with the resources comitted to the development
EDIT: More bugs out of fglrx here, but seems there is progres on that part which I was not aware of. Anyone can confirm this trick works which I found on the very end of this thread?
Yes, with Xvideo subtitles and OSD have to be rendered into the video, with all associated problems. I.e. blurry text with low-res video, video aspect ratio affects subtitle/OSD rendering, and subtitle/OSD rendering is restricted to the same colorspace and video mixer settings as the video.
If you have a capable driver, MPlayer's OpenGL output is similarly efficient as Xv or VDPAU. That is, the overhead is negligible.