[VDPAU] [PATCH 2/2] [PATCH] Enable lossless video playback via VDPAU

[Rémi Denis-Courmont]

    Hello,

Le 2014-10-31 21:11, Jose Soltren a écrit :
>>> Added H264_HIGH_444PP profile which was not present before.
>>
>>Since all defined VDPAU video surface chroma types so far have 8-bits
>>depth, I assume this only supports 8-bits... Probably that should be
>>documented.
>
> Perhaps. The VDPAU API could conceivably provide enumerations for 
> 10-bit,
> 12-bit, etc. decoding; it is up to an implementation to support them. 
> My
> understanding is that lossless encoding is a only defined in the 
> H.264
> High 444PP profile, which also defines higher bit depth encodings.

I know. But at the very least, new chroma types would need to be 
defined, otherwise applications cannot create video surfaces to render 
into.

>>> +typedef struct {
>>> +    /**
>>> +     * This field must be filled with VDP_H264_EXTENDED_VERSION
>>> +     */
>>> +    uint32_t struct_version;
>>> +    /** Performs lossless decode
>>> +     * 0: no lossless decode
>>> +     * 1: x264 lossless decode
>>> +     * 2: JM lossless decode
>>> +     * >2: unsupported lossless decode stream
>>> +     */
>>> +    uint8_t transform_bypass;
>>> +} VdpPictureInfoH264Extended;
>>> +
>>
>>It's not clear where/when that structure should be used by 
>> application.
>>I think the documentation should probably explain that.
>
> I believe this is a workaround for the fact that VdpPictureInfoH264 
> is not
> versioned. Ideally we would add this new transform_bypass structure 
> to the
> end of VdpPictureInfoH264, were it versioned.
>
> There are a number of workable solutions, and I am curious to know 
> what
> others on this list believe would be a good solution.
(...)
> I'm curious to know, which of the proposals (regarding both 
> versioning,
> and the intra8x8 workaround) are most favorable to a VDPAU 
> implementation
> implementor? To a decoder application maintainer?

Considering how it's done in libavcodec, I would suggest:

- Append the new members at the end of the existing structure.
- Leave VDPAU_INTERFACE_VERSION as it is.
- Forbid drivers from accessing the appended members if the decoder 
profile value is less than 22.

That should preserve both source and binary compatibility, with minimal 
difficulty for applications. This does however require well-behaving 
drivers.

Regarding source compatibility, an old application would allocate space 
for the new members, but fail to initialize them. Regarding binary 
compatibility, an old application will not allocate space for the new 
members. Either way, the new driver should detect that the decode 
profile is less than 22 and not attempt to read the uninitialized 
structure members.

If an application wants to support both the old and new vdpau.h header 
versions at source level, it can use an #ifdef on the codec profile.

-- 
Rémi Denis-Courmont