[VDPAU] VP8 support in the VDPAU interface

[Emeric Grange]

2012/2/28 Aaron Plattner <aplattner at nvidia.com>

> A while ago, Emeric Grange did a GSoC project to add support for VP8:
> http://cgit.freedesktop.org/~**emericg/libvdpau-vp8/commit/?**id=**
> d861763cce90b4e4f3e46ef624307e**512dc63a28<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?
>
> -- Aaron
> ______________________________**_________________
> VDPAU mailing list
> VDPAU at lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/vdpau<http://lists.freedesktop.org/mailman/listinfo/vdpau>
>


Now about the VP8 support for libvdpau. I'll split the support in two
parts. The first is the one I'm currently using, the second is build on top
of the first.
- You will need the RFC 6386, the closer thing we have to a VP8
specification : http://datatracker.ietf.org/doc/rfc6386/
- I made a prettier document "VP8 bitstream specification" (the look and
feel of the document is based on an old pdf version of the RFC) :
https://github.com/downloads/emericg/libvdpau-vp8/vp8_bitsream_specification_r6.pdf

The two patches I referred to are from not used by my VP8 VDPAU decoding
stack (the libvdpau "vp8" branch) and are made for the purpose of this
discussion (the libvdpau "upstream-wip" branch). I also rename some fields
to match the RFC (which names bitstream fields horribly by the way, one
time we have golden_frame, one time gf, one time golden...), and if fields
names are different I did mention from which bitstream fields they are
derivated from.


- The first patch (
https://github.com/emericg/libvdpau-vp8/commit/f7e3e25cadace8b5dff2f4ee9870f7e86faf30d8
)
* Add 4 new profiles (VDP_DECODER_PROFILE_VP8_V0-3) and a "default" level
(VDP_DECODER_LEVEL_VP8_NA). VP8 "versions" are equivalent of mpeg
"profiles" and they are not subdivided into "levels".
* Requires to include all VP8 frames (the VP8 bitstream is only divided
into "frames", no SPS, PPS, SEI or slices).
* I used the H.264 example and made mandatory the inclusion of a start code
(0x9D012A, usually found into the key frame header) before each frame sent
through VDPAU (at the start of the buffer or inside a separate one). As a
VP8 frame will only need one buffer anyway (no slice partitioning, no
interlacing) I'm not sure if this feature is useful ?
* A VdpPictureInfoVP8 structure is added with 3 VdpVideoSurface as
reference and 8 fields from the uncompressed VP8 frame header (4 of them
are for key frames only).

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


- The second patch is an add-on to the VdpPictureInfoVP8 structure (
https://github.com/emericg/libvdpau-vp8/commit/564ba5f1c822f6a336c092a1af90f26e87f67269
)
* With this approach every fields from the frame header are decoded by the
client application.
I do not really like this because there would be a lot of fields into the
VdpPictureInfoVP8 structure (43 actually). The other big problem is that
the datas following the frame header, which is the header of the first
macroblock, are not byte aligned, so it will be needed to pass an 1-7 bit
offset along with the buffer.
The fields of this second patch are not used in the current implementation
so there can contain minor mistakes. Some are "pre-processed". For example
should I pass 4 times mb_mode_delta_update_flag, delta_magnitude
and delta_sign, or just filter_mode_value[4] ?


I'm not sure which method would match better the goal of the VDPAU API,
but I hope the VP8 support can move forward with your help !

Regards,
Emeric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/vdpau/attachments/20120229/bbeb725a/attachment.htm>