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

[José Hiram Soltren]

Hello,

On 12/04/2014 03:24 PM, José Hiram Soltren wrote:
> Hello,
> 
> On 12/04/2014 08:34 AM, Rémi Denis-Courmont wrote:
>> Le 2014-12-04 01:44, Karthikeyan Sreenivasan a écrit :
>>>> Extending the existing VdpPictureInfoH264 structure will perturb its ABI.
>>>> If different software in the system uses the structure in a way that
>>>> relies on its size (e.g., an array of VdpPictureInfoH264s, or a structure
>>>> with a VdpPictureInfoH264 member and other members afterwards), and
>>>> those are passed between software components that were compiled with
>>>> different VdpPictureInfoH264 definitions, bad things will happen.
>>
>> Fair enough. Lets not change the existing structure then.
>>
>>>> For name: I'd recommend a name that describes the usage of the profile.
>>>> E.g., VdpPictureInfoH264Predictive.  If we expect the structure to
>>>> be useful for other profiles, then maybe a little more general; e.g.,
>>>> VdpPictureInfoH264TransformBypass ?  But really, the bikeshed can be
>>>> any color.
>>>
>>> The names correspond to the structure as such:
>>>
>>> 1. VdpPictureInfoH264Extended, Will contain the current transform_bypass
>>> field and a struct_version so as to add more fields in the future if
>>> need arises.
>>
>> Adding a version number does not solve this the binary compatibility issue
>> above. I would leave versioning out and rely on the decoder profile -
>> effectively treating lossy H.264 and lossless H.264 as two different codecs.
>>
>>> 2. VdpPictureInfoH264Predictive, will contain all the fields necessary for
>>> VDP_DECODER_PROFILE_H264_HIGH_444_PREDICTIVE and the structure will not
>>> change and will be used exclusively for Hi444PP [w/ or w/o lossless decode].
>>
>> Yes.
>>
> 
> This seems fine to me.
> 
> If we only have one chance to add VdpPictureInfoH264Predictive as a structure
> definition it should include all of the features related to the Hi444PP
> profile. There are two. Lossless is one of them and separate color plane coding
> is the other. I think that, reading through this paper [1], for our purposes a
> frame level flag should be enough. So I propose adding to
> VdpPictureInfoH264Predictive a single new flag, separate_color_planes.

Correction. Karthik I think you should instead call this flag
residual_colour_transform_flag, to match the name of the bit field in the H.264
SPS.

Thanks,
--José

> If there are no other objections I hope we can get this checked in soon.
> 
> [1] http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=4106880
> 
> --José
> _______________________________________________
> VDPAU mailing list
> VDPAU at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/vdpau
>