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

[Aaron Plattner]

On 11/03/2014 10:30 AM, José Hiram Soltren wrote:
> Hello,
>
> On 11/03/2014 04:39 AM, Rémi Denis-Courmont wrote:
>>     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.
>
> Yes. I support adding addition bit depths here. To be somewhat future-proof we
> could add 10, 12, 14, and 16 bits.
>
>>>>> +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 is a simple enough solution. Since we only support lossless decode with
> H264_HIGH_444PP that seems workable for an implementation as well. We would
> need to document this of course.

I agree that this seems the simplest.  Unlike VdpProcamp and structures 
like it, the version of VdpReferenceFrameH264 is implicit in the profile 
number.  I.e. the version of the structure is specified externally to 
the structure itself, but it does still exist.

It would be interesting to hear what application developers would prefer.

>> That should preserve both source and binary compatibility, with minimal
>> difficulty for applications. This does however require well-behaving drivers.
>
> Yes. Again, it only works well here due to the quirk of the H.264 specification
> that ties lossless decoding to H264_HIGH_444PP.
>
>> 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.
>
> Yes.
>
>> 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.
>
> That does work, yes.
>
> Thanks,
> --José

-- 
Aaron