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

[Stephen Warren]

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.

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

> 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?

> 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?

-- 
nvpublic