[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