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

[Karthikeyan Sreenivasan]

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]

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?

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
> 

-- 
Karthikeyan S
ksreenivasan at nvidia.com
(408)562-7102 Ext: 27102
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------