Add support for video encoding

[bbredesen]

XML file for externally defined video encoding types in similar format to vk.xml is available at https://github.com/KhronosGroup/Vulkan-Docs/blob/main/xml/video.xml

Types for video components are currently placeholders in exceptions.json. The linked XML file above has enums, structs etc. for the video components. On first review, it appears that several include types patterned like "vk_video/vulkan_video_codec*.h" will be needed in exceptions.json

Several structs are actually encoded bitfields that will need to be handled. See StdVideoH264PpsFlags for an example.

[bbredesen]

Need to read more than one file at runtime for this. Remove -inFile command line flag and accept all names after flags as input files.

[bbredesen]

Will have to address bitfield handling as part of this. One major concern is that C bitfield ordering is platform dependent. Can start with hardcoding to IA32 and/or AMD64 ordering, covering the bulk of usage, but will need a more sustainable solution. Possibly a small Cgo block called by Vulkanize to ensure the ordering is done by the platform's C compiler?

package vk

/*
uint32_t encode_StdVideoH264SpsVuiFlags(uint32_t aspect_ratio_info_present_flag, uint32_t overscan_info_present_flag, ... ) {
  StdVideoH264SpsVuiFlags rval = {
    .aspect_ratio_info_present_flag = aspect_ratio_info_present_flag,
    .overscan_info_present_flag = overscan_info_present_flag,
    ...
  };
*/
import "C"

func (s *StdVideoH264SpsVuiFlags) Vulkanize() *_vkStdVideoH264SpsVuiFlags {
  rval := _vkStdVideoH264SpsVuiFlags{}
  rval.uint32_bits = C.encode_StdVideoH264SpsVuiFlags(s.aspect_ratio_info_present_flag, s.overscan_info_present_flag, ...)

  // potentially other fields to translate
  return &rval
}

[gabereiser]

Wouldn't that be done by the compiler? since it's platform specific? The bitfield order will match since it's being compiled together (compiler chooses bitfield order). It's safe to assume that the bitfields will match unless you're linking pre-compiled binary for SPARC or ARM AArch64 with the ended-ness switched to big endian, which no one does anymore. In 2018 Fedora & Red Hat switched to little endian to ease porting x86 to SPARC which is now bi-endian (like aarch64, defaulting to little-endian for x86 compatibility), the last holdouts. Safe to proceed. Also, I may end up implementing x11 and wayland for you here. I need a decent vk wrapper that's not as low level as C library, but also not necessarily as simple as OpenGL, for my game engine rewrite 3.0

[bbredesen]

You are probably right...I think most compilers will build the struct below from least to most significant bit, and handle endian-ness automatically. I don't know if that is universally true though, and I haven't dug into the C spec to see if bit order on a struct like this is specified by platform or at all.

I think I was assuming there was a specific reason for defining it that way, and I never dug into the specifics before other work got in the way over the last few months.

Example struct from vulkan_video_codec_h264std.h for reference:

typedef struct StdVideoH264SpsVuiFlags {
    uint32_t    aspect_ratio_info_present_flag : 1;
    uint32_t    overscan_info_present_flag : 1;
    uint32_t    overscan_appropriate_flag : 1;
    uint32_t    video_signal_type_present_flag : 1;
    uint32_t    video_full_range_flag : 1;
    uint32_t    color_description_present_flag : 1;
    uint32_t    chroma_loc_info_present_flag : 1;
    uint32_t    timing_info_present_flag : 1;
    uint32_t    fixed_frame_rate_flag : 1;
    uint32_t    bitstream_restriction_flag : 1;
    uint32_t    nal_hrd_parameters_present_flag : 1;
    uint32_t    vcl_hrd_parameters_present_flag : 1;
} StdVideoH264SpsVuiFlags;

Of course, it could just be a code style/safety/readability choice from the codec authors:

  vuiFlags->video_signal_type_present_flag = 1;
  // vs.
  uint32_t VIDEO_SIGNAL_TYPE_PRESENT_FLAG = 1 << 3;
  vuiFlags |= VIDEO_SIGNAL_TYPE_PRESENT_FLAG ;

[gabereiser]

The C spec is clear it's implementation specific and I'm sure gcc knows what to do.