[VDPAU] [PATCH 0/1] Add new frame and field mode chroma types. Add VdpDecoderQueryProfileCapability API

Manoj Bonda mbonda at nvidia.com
Wed Oct 17 12:16:25 UTC 2018


The new API proposed here addresses the request to provide a new mode,
where the VDPAU OpenGL interop surfaces are frame or field based.
(Reference : https://patchwork.ffmpeg.org/patch/4172/ )

Existing VDPAU OpenGL interop supports field-based surfaces only.
Applications are not aware of the picture structure of the video surface nor
can they allocate the video surface with a specific picture structure.

The picture structure can be either "field" or "frame". In a video surface with
field picture structure, odd lines are part of the top field and even lines are
part of the bottom field. In the case of a video surface with frame structure, 
there are no top/bottom fields; all lines are stored sequentially as a 
progressive frame.

The new API allows applications to allocate surfaces with the required 
picture structure. Chroma types defined in the VDPAU API are extended for 
this purpose.

For the below chroma types that already exist,
    VDP_CHROMA_TYPE_420
    VDP_CHROMA_TYPE_422
    VDP_CHROMA_TYPE_444 

The VDPAU implementation can either directly decode into the video surface 
passed or decode to another internal surface with a different picture structure 
type it supports. When used with VDPAU OpenGL interop, the decoded data may be 
copied from a driver internal surface to the application allocated surface. 

With the existing interop API, the surface is always treated as having field 
picture structure. With the updated interop API, surfaces can be registered for 
either field or frame surface type and used accordingly.

Applications can allocate video surfaces with this enum and use those 
video surfaces with the interop API. This usage allows more flexibility for 
applications and VDPAU implementations to support various use cases. 
E.g: The application expects a frame but vdpau implementation can provide field.

This change proposes new enums:
    VDP_CHROMA_TYPE_420_FIELD
    VDP_CHROMA_TYPE_422_FIELD
    VDP_CHROMA_TYPE_444_FIELD
    VDP_CHROMA_TYPE_420_FRAME
    VDP_CHROMA_TYPE_422_FRAME
    VDP_CHROMA_TYPE_444_FRAME

Video surfaces can now be allocated with a specified field/frame picture structure
using the existing video surface allocation API. The VDPAU implementation 
will return an error during VdpDecoderRender () if it cannot decode using the 
picture structure of the video surface passed. When used with the new 
VDPAU OpenGL interop API, surfaces can be registered with the same picture 
structure type which was used at the time of surface creation.

When used with the existing VDPAU OpenGL interop API, irrespective of the 
picture structure type provided at the time of creation, surface registration 
will always assume the surface has field picture structure.

Applications can allocate video surfaces with this enum and use those 
video surfaces with the interop API. This usage is less flexible than the one 
described above, but should give a better performance – it avoids an extra 
internal surface and copy.

A new proposed VDPAU OpenGL interop spec (NV_vdpau_inteop2.txt) is available at 
https://github.com/KhronosGroup/OpenGL-Registry/pull/223/files for reference.

A new function, VdpDecoderQueryProfileCapability(), is added to return supported 
picture structures along with other existing capabilities of a given profile.
VdpDecoderQueryProfileCapability is designed to be extended in the future to query 
more capabilities. VdpDecoderCapabilities defines the capabilities that can be 
queried.

Thanks,
ManojGupta.

manoj (1):
  [VDPAU] Add new frame and field mode chroma types. Add
    VdpDecoderQueryProfileCapability API

 include/vdpau/vdpau.h | 93 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 90 insertions(+), 3 deletions(-)

-- 
2.19.1



More information about the VDPAU mailing list