[VDPAU] [PATCH] Add a progressive frame flag to VdpVideoSurfaces.

[Jose Soltren]

Hi,

On 2015/09/15, 15:22 , "Stephen Warren" <swarren at nvidia.com> wrote:

>Jose Soltren wrote at Tuesday, September 15, 2015 12:54 PM:
>> This change adds two top level functions to the VDPAU API:
>> 
>>     VdpVideoMixerSetProgressive
>>     VdpVideoMixerGetProgressive
>
>It seems to add VdpVideoSurface[GS]etProgressive.

Yes, that's right; simple typo.

>Does it make sense to introduce a VdpVideoSurfaceSetAttributeValues()
>instead to avoid a proliferation of APIs, and to be consistent with
>other object types?

That seems okay to me. I can work up a change with this interface instead.

>> Next generation codecs - such as H.265/HEVC - do not support
>> interlaced content natively. Rather, they leave it to imple-
>> mentations to decide the correct behavior for handling legacy
>> interlaced content.
>> 
>> Prior to the introduction of such codecs, this specification
>> left the designation of a particular VdpVideoSurface as a
>> _TOP_FIELD, _BOTTOM_FIELD, or _FRAME to the enumeration
>> VdpVideoMixerPictureStructure, passed to VdpVideoMixerRender.
>> It is possible, and permitted by this API specification, for
>> an implementation to set internal state on the backing store
>> of a VdpVideoSurface when handling a call to VdpVideoMixerRender.
>> 
>> Not all use cases of a VdpVideoSurface will involve a trip
>> through a call to VdpVideoMixerRender. It is a legal use of the
>> VDPAU API to access a VdpVideoSurface directly using
>> VdpVideoSurfaceGetBitsYCbCr and VdpVideoSurfacePutBitsYCbCr.
>> In such a situation, it is helpful to be able to specify,
>> explicitly, and from outside of the implementation, whether
>> a VdpVideoSurface contains either one full frame, or two
>> half frames.
>
>How does this interact with the surface layouts exposed via GL/CUDA video
>surface interop?

I don't know. I have not researched this yet.

>> diff --git a/include/vdpau/vdpau.h b/include/vdpau/vdpau.h
>
>> +typedef VdpStatus VdpVideoSurfaceSetProgressive(
>> +    VdpVideoSurface      surface,
>> +    VdpBool *            is_progressive
>
>I think that only needs to be a pointer for the Get API?

Yes, but if we move to an Attributes API this may be obsoleted. I'm not
sure how valuable a Get function is. Then again, the implementation can
change these attributes in addition to the client so perhaps it does make
sense after all.

I'll work on sending a revised version of this patch in the next few days.

Thanks,

--José

--

nvpublic