[VDPAU] VP8 support in the VDPAU interface

Younes Manton younes.m at gmail.com
Wed Feb 29 14:38:07 PST 2012


On Mon, Feb 27, 2012 at 7:49 PM, Aaron Plattner <aplattner at nvidia.com> wrote:
> A while ago, Emeric Grange did a GSoC project to add support for VP8:
> http://cgit.freedesktop.org/~emericg/libvdpau-vp8/commit/?id=d861763cce90b4e4f3e46ef624307e512dc63a28
>
> I'd like to thank Emeric for getting the ball rolling on this and continue
> the discussion here.
>
> Not being too familiar with VP8 myself, I started reading RFC 6386 and
> couldn't really understand how the named header fields in the RFC match up
> to Emeric's structure definitions.
>
> One of the proposed alternatives was to just pass the entire picture
> including the header and let the hardware handle the decoding.  I guess this
> would mean the calling application would still need to parse out the
> refresh_golden_frame and refresh_alternate_frame bits to keep track of the
> reference surfaces it needs to pass in?

Pretty much. You also have to watch out for the fact that every key
frame can specify a new frame size, and the decoder is expected to
scale all frames to the video's natural dimensions as required. So, if
you expect the calling application to allocate decoding surfaces, as
is the case now, it has to parse the header to see if the frame size
has changed and recreate surfaces. The other option is handling all of
that internally and hiding it from the app, which is what Emeric's
code does, but it's just malloc'd memory for him so it's nothing
special. IIRC there's also a flag in there that tells you whether or
not the frame is intended for display or just for prediction.


More information about the VDPAU mailing list