C Specification
When calling vkGetPhysicalDeviceVideoCapabilitiesKHR with
pVideoProfile->videoCodecOperation specified as one of the encode
operation bits, the VkVideoEncodeCapabilitiesKHR structure must be
included in the pNext chain of the VkVideoCapabilitiesKHR
structure to retrieve capabilities specific to video encoding.
The VkVideoEncodeCapabilitiesKHR structure is defined as:
// Provided by VK_KHR_video_encode_queue
typedef struct VkVideoEncodeCapabilitiesKHR {
VkStructureType sType;
void* pNext;
VkVideoEncodeCapabilityFlagsKHR flags;
VkVideoEncodeRateControlModeFlagsKHR rateControlModes;
uint32_t maxRateControlLayers;
uint64_t maxBitrate;
uint32_t maxQualityLevels;
VkExtent2D encodeInputPictureGranularity;
VkVideoEncodeFeedbackFlagsKHR supportedEncodeFeedbackFlags;
} VkVideoEncodeCapabilitiesKHR;Members
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkVideoEncodeCapabilityFlagBitsKHR describing supported encoding features. -
rateControlModesis a bitmask of VkVideoEncodeRateControlModeFlagBitsKHR indicating supported rate control modes. -
maxRateControlLayersindicates the maximum number of rate control layers supported. -
maxBitrateindicates the maximum supported bitrate. -
maxQualityLevelsindicates the number of discrete video encode quality levels supported. Implementations must report at least 1. -
encodeInputPictureGranularityindicates the granularity at which encode input picture data is encoded. -
supportedEncodeFeedbackFlagsis a bitmask of VkVideoEncodeFeedbackFlagBitsKHR values specifying the supported flags for video encode feedback queries.
Description
Implementations must include support for at least
VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_BUFFER_OFFSET_BIT_KHR and
VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_BYTES_WRITTEN_BIT_KHR in
supportedEncodeFeedbackFlags.
The input content and encode resolution (specified in
VkVideoEncodeInfoKHR::codedExtent) may not be aligned with the
codec-specific coding block size.
For example, the input content may be 1920x1080 and the coding block size
may be 16x16 pixel blocks.
In this example, the content is horizontally aligned with the coding block
size, but not vertically aligned with the coding block size.
Encoding of the last row of blocks may be impacted by contents of the input
image in pixel rows 1081 to 1088 (the next vertical alignment with the
coding block size).
In general, to ensure efficient encoding for the last row/column of blocks,
and/or to ensure consistent encoding results between repeated encoding of
the same input content, these extra pixel rows/columns should be filled to
known values up to the coding block size alignment before encoding
operations are performed.
Some implementations support performing auto-fill of unaligned pixels beyond
a specific alignment for the purposes of encoding, which is reported in
encodeInputPictureGranularity.
For example, if an implementation reports 1x1 in
encodeInputPictureGranularity, then the implementation will perform
auto-fill for any unaligned pixels beyond the encode resolution up to the
next coding block size.
For a coding block size of 16x16, if the implementation reports 16x16 in
encodeInputPictureGranularity, then it is the application’s
responsibility to fill any unaligned pixels, if desired.
When the application does not fill these unaligned pixels, there may be an
impact on the encoding efficiency but there will be no effect on the
validity of the generated bitstream.
If the implementation reports 8x8 in encodeInputPictureGranularity,
then for the 1920x1080 example, since the content is aligned to 8 pixels
vertically, the implementation will auto-fill pixel rows 1081 to 1088 (up to
the 16x16 coding block size in the example).
The auto-fill value(s) are implementation-specific.
The auto-fill value(s) are not written to the input image memory, but are
used as part of the encoding operation on the input image.
Document Notes
For more information, see the Vulkan Specification
This page is extracted from the Vulkan Specification. Fixes and changes should be made to the Specification, not directly.