[VDPAU] [PATCH] Add support for Hi444PP in VDPAU API

[Rémi Denis-Courmont]

Le 2014-12-10 18:13, José Hiram Soltren a écrit :
> If we are going this route I propose adding any of the profiles in 
> Rec. ITU-T
> H.264 (02/2014), Annex A, Section A.2 that we do not currently offer. 
> If I'm
> reading this correctly we need to add:
>
> VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE
> VDP_DECODER_PROFILE_H264_EXTENDED
> VDP_DECODER_PROFILE_H264_PROGRESSIVE_HIGH
> VDP_DECODER_PROFILE_H264_CONSTRAINED_HIGH

Those four are already in git as of now. And drivers should be updated 
to support at least Constrained Baseline, Constrained High and 
Progressive High. I guess no real hardware supports Extended.

> VDP_DECODER_PROFILE_H264_HIGH_10

I think that one should be postponed. If I understand the specification 
correctly, High 10 is really just High without the 8 bits per component 
limit.

There are no ways to deal with those bits in VDPAU as yet. 
Specifically, there are no ways for the application to tell the VDPAU 
driver that it intends to use 9, 10... or 14 bits when querying decoder 
capabilities and when creating a decoder. There are also no adequate 
defined surface chroma types.

> VDP_DECODER_PROFILE_H264_HIGH_422
> VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE (being added here)

Yes to both.

> VDP_DECODER_PROFILE_H264_HIGH_10_INTRA

Tricky. If the hardware can decode High, it can decode High 10 Intra so 
long as chroma_idc == 1 but... I would postpone it alongside High 10.

> VDP_DECODER_PROFILE_H264_HIGH_422_INTRA
> VDP_DECODER_PROFILE_H264_HIGH_444_INTRA
> VDP_DECODER_PROFILE_H264_CAVLC_444_INTRA

Yes thrice.

> Some of these need to be added in line, between other values, which 
> will ruin
> the enumeration values regardless. We can either make the enum values 
> out of
> order, or force a major API change as we alter these values. I vote 
> for the
> former as ugly as it is.

I don't think anybody cares that the order in vdpau.h is different from 
the order in the specification. VDPAU never matched profile_idc anyway.

> While we're at it we may as well add the additional decoder level 
> from Rec.
> ITU-T H.264 (02/2014) Table A-1:
>
> VDP_DECODER_LEVEL_H264_5_2

Sure. Existing application code already effectively assumes that this 
is equal to 52.

-- 
Rémi Denis-Courmont