[VDPAU] VP8 support in the VDPAU interface

[Emeric Grange]

2012/4/25 Stephen Warren <swarren at nvidia.com>

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


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

Yes it make sense, I'm ok with it.


Thanks,
Emeric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/vdpau/attachments/20120426/2d80a406/attachment.htm>