[Mesa-dev] GSoC : Video decoding state tracker for Gallium3d

[★ Emeric]

2011/3/25 Matt Turner <mattst88 at gmail.com>:
> On Wed, Mar 23, 2011 at 4:28 PM, ★ Emeric <emeric.grange at gmail.com> wrote:
>> Hi everyone,
>> My name is Emeric, I am a 22 years old french student, and I am
>> currently looking to apply to the google summer of code 2011.
>> I saw the "Gallium H.264 decoding" idea on the X.Org GSoC page, and I
>> am particularly interested by this project.
>
> A couple days ago, a few developer talked in passing about this idea
> on IRC. One point made was that shader-based video is kind of, well,
> not ideal, for cards that have dedicated hardware since it's going to
> utilize most of the cards resources and also use quite a bit of power
> in the process. Now, shaders may be the best we can do in practice,
> given the difficulties in releasing documentation for AMD's UVD, for
> instance, but still.

Is there any chance to see the documentation of these dedicated
decoder chips published ?
In the mean time doing some work using shaders could be a start ?

> Since Google (and most of the free software community) is pushing WebM
> over H264, it might be a good idea to focus instead of WebM. Clearly
> there are no cards today that support WebM video decoding, so this
> would be neat. I don't know, but I'd guess a lot of the code needed
> for WebM decoding is also useful for H264 decoding.

VP8 is similar in H264 in so many ways, with less functionalities and
less complexity, I have no objection on focusing on it.
But as said by Stéphane Marchesin, I'm not sure we can use vaapi or
vdpau with it. And that kill the "out of the box usability" of the
state tracker.

On a related note, a US student, Aaron Watry have been developing an
Open CL accelerated libvpx for his thesis, the code is here :
https://github.com/awatry/libvpx.opencl
So far the implementation is slower than pure cpu decoding but it
should be fixable according to the author.