[VDPAU] VP8 support in the VDPAU interface

[Stephen Warren]

Aaron Plattner wrote at Tuesday, April 24, 2012 2:01 PM:
> Sorry for the slow reply.
> 
> On 02/29/2012 01:46 PM, Emeric Grange wrote:
> > I have been using this implementation to develop and test the mesa decoder.
> > The flaws of this simple method are that some fields like "color_space" or
> > "clamping_type" could be used by the decoder.
> > As Aaron said the calling application still needs to parse out the
> > refresh_golden_frame, refresh_alternate_frame and refresh_last_frame. This is
> > bad news because these fields are binary arithmetic encoded, there positions
> > cannot be guessed, and so every fields preceding them must be decoded too. That
> > also mean that the calling application must implement a VP8 "boolean decoder".
> 
> Yeah, that's pretty lame. If I'm reading it right, the caller just needs to keep
> track of the arithmetic decoder state for the first partition, and can pass the
> other partitions as-is into the library.
> 
> The question is whether it's better to pass the entire compressed first
> partition in too, or have the caller decompress the whole thing first, or some
> hybrid approach.
> 
> > - The first patch (https://github.com/emericg/libvdpau-
> vp8/commit/f7e3e25cadace8b5dff2f4ee9870f7e86faf30d8)
> 
> This is the "pass in all the partitions" approach, right?  When it says "Include
> all frames," do you mean all compressed partitions in the frame?
> 
> Stephen, does this new interface look like it makes sense?  It's just the parsed
> uncompressed header plus reference frame handles, and then leaves parsing
> everything else up to the decoder.

I think this looks basically fine. A couple thoughts though:

* We should validate this with internal VP8 experts, just in case there's
some problem more obvious to them. I'm not at all familiar with VP8.

* I would be tempted to require inclusion of all frame header in the
bitstream buffer - starting right at the first byte of the "uncompressed
data chunk". If a driver doesn't need it, it's fixed-size so easy to skip.
If a driver does need it, having it already in the bitstream buffer avoids
the need to reconstruct it from VdpPictureInfoVP8 before sending it to
hardware.

-- 
nvpublic