Create hardware device context with flags

[l0rem1psum]

Despite the official doc claiming that the flags are not used (see: hwcontext.c File Reference), it is in reality used by AVCUDADeviceContext (see: hwcontext_cuda.h).

[asticode]

I've added flags this way in the lib (example is for codec context flags):

• list of flag values: https://github.com/asticode/go-astiav/blob/master/codec_context_flag.go
• struct capable of manipulating flag values: https://github.com/asticode/go-astiav/blob/master/flags.go#L48 (this file is generated automatically with this command)
• using the flag: https://github.com/asticode/go-astiav/blob/master/codec_context.go#L127

We should do the same thing for the new flags you're mentioning.

It would mean:

• create a HardwareDeviceContextFlag type in a new hardware_device_context_flag.go file with both AV_CUDA_USE_PRIMARY_CONTEXT and AV_CUDA_USE_CURRENT_CONTEXT as possible values with go constants named HardwareDeviceContextFlagCudaUsePrimaryContext and HardwareDeviceContextFlagCudaUseCurrentContext
• modify the generate flags command to generate a HardwareDeviceContextFlags struct and run it to actually add it to flags.go
• use HardwareDeviceContextFlags instead of int in CreateHardwareDeviceContext

[l0rem1psum]

Thanks for the reply. My main concern is such a flag (AV_CUDA_USE_CURRENT_CONTEXT in this case) wouldn't be available to users who didn't build ffmpeg with CUDA, rendering this binding strongly coupled to a particular hardware device.

As such, I still strongly recommend using a int flag and avoid adding custom types not available in the C code. (And avoid adding additional logic in FFI bindings in general.)

edit: It still needs to be verified whether ffmpeg without CUDA has those #defines, but the same logic applies.

[l0rem1psum]

I just added the suggested code but it wouldn't compile without linking CUDA. Hence my above argument still stands.

[asticode]

You're right, unfortunately I don't see a workaround for this 🤔

Thanks for this PR too! ❤️