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

[José Hiram Soltren]

Hello -

On 12/08/2014 09:00 PM, Karthikeyan Sreenivasan wrote:
> Hello,
> 
> On 12/08/2014 11:08 AM, José Hiram Soltren wrote:
>> 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é
> 
> I have sent out the patch for review with residual_color_transform_flag
> as mentioned in the SPS structure.
> 
> I also noticed the mention of separate_colour_plane_flag in the H.264
> specification.
> 
> From the specification : Rec. ITU-T H.264 (04/2013) [Sec. 6.2]

(fwiw, I'm looking at the current version, Rec. ITU-T H.264 (02/2014))

> In 4:4:4 sampling, depending on the value of separate_colour_plane_flag,
> the following applies:
> –
>  If separate_colour_plane_flag is equal to 0, each of the two chroma
> arrays has the same height and width as the
> luma array.
> –
>  Otherwise (separate_colour_plane_flag is equal to 1), the three colour
> planes are separately processed as
> monochrome sampled pictures.
> 
> Should we continue with residual_color_transform_flag or change to
> separate_colour_plane_flag as mentioned in the spec?

I think separate_colour_plane_flag is the better choice. I was mistaken:
residual_color_transform_flag is an ffmpeg-ism. I don't see it in the spec.

--José

> Thanks,
> -- Karthikeyan S
> 
>>
>>> 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
>>>
>> _______________________________________________
>> VDPAU mailing list
>> VDPAU at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/vdpau
>>
>