[VDPAU] [PATCH] Enable Lossless Decode Capabilities via VDPAU API

[Rémi Denis-Courmont]

    Hello,

Le 2014-11-25 18:21, Jose Soltren a écrit :
> 1. Name. Is there a preference for calling the new structure
> VdpPictureInfoH264Extended versus VdpPictureInfoH264Hi444PP ?

If I recall the previous discussion on the list, the new parameter can 
be appended to the existing structure.

> 2. Versioning. Is there a preference to make this a versioned
> structure or not? Aaron Plattner expressed a preference for not 
> making
> this versioned; I'll let him explain why here.

In practice, the decoder profile defines the type and layout of the 
picture info structure. A version field does not seem to bring any added 
value.

> 3. Containment. Should VdpPictureInfoH264Extended contain an entire
> VdpPictureInfoH264, or simply a pointer to one?

I would prefer the container approach over the pointer approach. Then 
again, I would prefer extending the existing structure over the 
container approach.

> 4. Flags. Are there any opinions on accepting values greater than 1
> for transform_bypass for internal use, or should we write these into
> the specification? NVIDIA video decoding hardware contains a mode to
> work around the recently-fixed ipred8x8 bug in x264; the NVIDIA 
> driver
> would accept a value of 2 to enable that workaround.

I don't know. It depends if there is demand for legacy compatibility 
with the x264 bug.

> 5. Scope. If this change really adds
> VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE, it will also need to 
> add
> anything else related to Hi444PP, not just lossless decode. Namely it
> would need to introduce separate color plane coding, 4:4:4 chroma
> subsampling (a misnomer; not subsampling at all), and bit depths up 
> to
> 14 bits per sample. If we choose to make VdpPictureInfoH264Extended
> versioned we can add those in a follow-on change. If not, we need to
> add those now.

4:4:4 surface chroma sampling is already defined by the API. Only high 
depths are missing. So I think the patch is self-sufficient if it sticks 
to 8-bits.

It would be nice to mention which surface format are supported for 
PutBits/GetBits, if any... presumably NV12 and YV12, as YUYV and UYVY 
would not make sense.

-- 
Rémi Denis-Courmont