[VDPAU] VP8 support in the VDPAU interface

[Emeric Grange]

2012/4/24 Aaron Plattner <aplattner at nvidia.com>

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

Yes the caller must read the three "refresh_*_frame" flags by decompressing
just enough data from the first compressed partition, with its own
arithmetic decoder.


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


Problem is, the first partition go way further the frame header. The
RFC6386 says about it:
"The first compressed partition has two subsections:
1. Header information that applies to the frame as a whole.
2. Per-macroblock information specifying how each macroblock is predicted
from the already-reconstructed data that is available to the decompressor."

As only 1/ is useful to us, I don't think that we should decompress the
whole first partition inside the client and pass the content through the
VdpPictureInfoVP8 structure.

 - The first patch (https://github.com/emericg/**libvdpau-vp8/commit/**
>> f7e3e25cadace8b5dff2f4ee9870f7**e86faf30d8<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?
>

No I meant all of the VP8 frames type ("golden" "altref" and "previous")
must go through a VDPAU bitstream buffer, but this comment may be
unnecessary. I was trying to match the descriptions of the other codecs
that mentioned what type of slices must be included. At a media player
level there is not much distinction between the different partitions of a
VP8 frame (unlike mpeg slices), so I don't think that's necessary to
mention that all partitions must be passed.
Regarding VDPAU bitstream buffer, the patch ask for the inclusion of a
start code (0x9D012A, usually found in the headers of VP8 uncompressed
key-frame only) before each buffer containing a frame. This behaviour also
matches the one of the other codecs. As this is maybe more an issue of
compatibility with hardware decoders, and because there is none available
for VP8 (in graphic hardware anyway), does the mandatory inclusion of the
start code made sense?


Emeric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/vdpau/attachments/20120426/33f58bce/attachment.html>