Expose TorchCodecConfig.cmake

[dvrogozh]

This commit exposes torchcodec core library to be used by third party modules on the C++ level. The primary purpose is to allow non-CUDA device interfaces out-of-tree implementations. There are the following major changes:

• Exposed TorchCodecConfig.cmake which defines torchcodec targets to be linked with

• Provided Python level APIs to faciliate out-of-tree device interfaces work with torchcodec:

  • torchcodec.cmake_prefix_path - path which points to TorchCodecConfig.cmake configuration
  • torchcodec.variant - variant of the torchcodec library which was loaded, i.e. N in libtorchcodec_core{N}.so (currently ffmpeg_major_version)
  • torchcodec.core_library_path - full path of the loaded torchcodec core library

• src/torchcodec/_core/ dropped from include paths to allow using of the core library out-of-tree

TorchCodecConfig.cmake has 2 working modes:

• By default config works by checking available version of FFmpeg libraries via pkg-config and configures corresponding (single) version of torchcodec
• Altenatively, if TORCHCODEC_FFMPEG{N}_INSTALL_PREFIX is set (N=4,5,6,7 - version of FFmpeg), then config defines torchcodec target corresponding to the specified FFmpeg version. Note that multiple prefixes can be specified at the same time allowing to build against few torchcodec versions at once.

Config will define TORCHCODEC_VARIANTS variable with value corresponding to FFmpeg major versions of available torchcodec core libraries. Further, config will also define torchcodec::ffmpeg${N} and torchcodec::core${N} targets where N takes values from TORCHCODEC_VARIANTS.

See the following repository for an actual out-of-tree device interface torchcodec plugin:

• https://github.com/dvrogozh/torchcodec-xpu

I suggest to pay attention on these:

• https://github.com/dvrogozh/torchcodec-xpu/blob/59bfef60e9b41244e804c112729c42d9176ae368/src/torchcodec_xpu/__init__.py#L44 for plugin ;loading in respect to the loaded torchcodec library
• https://github.com/dvrogozh/torchcodec-xpu/blob/59bfef60e9b41244e804c112729c42d9176ae368/src/torchcodec_xpu/CMakeLists.txt#L81 for building multiple plugin targets depending on the available ffmpeg and torchcodec versions

CC: @scotts, @NicolasHug

[NicolasHug]

Thanks @dvrogozh , I left some questions and some comments below. It looks good overal, but I hope we can simplify and unify the logic with the one that already exists within our own cmake files.

On the #include path changes, I will have to pre-import your PR internall to verify that this isn't breaking our internal build (and to try to find internal workarounds if needed).

[NicolasHug]

Can you help me understand why in

https://github.com/dvrogozh/torchcodec-xpu/blob/59bfef60e9b41244e804c112729c42d9176ae368/src/torchcodec_xpu/__init__.py#L43

we only need to load the libtorchcodec_core?.so file, and not the other .so like libtorchcodec_pybind_ops?.so and libtorchcodec_custom_ops?.so

[dvrogozh]

That's because torchcodec_xpu does not use any of TorchCodec Python/C++ APIs defined in libtorchcodec_pybind_ops?.so or libtorchcodec_custom_ops?.so. The only thing which torchcodec_xpu does is registering XPU device interface on the C++ level, i.e. calling analogue of:

torchcodec/src/torchcodec/_core/CudaDeviceInterface.cpp

Lines 18 to 22 in 169484d

	static bool g_cuda = registerDeviceInterface(
	DeviceInterfaceKey(torch::kCUDA),
	[](const torch::Device& device) {
	return new CudaDeviceInterface(device);
	});

Note that if we will consider to support use cases when some application wants to link against TorchCodec C++ APIs, then libtorchcodec_pybind_ops?.so or libtorchcodec_custom_ops?.so or both might be needed. In this case the TorchCodecConfig.cmake will need to be updated to expose these targets as well.

[dvrogozh]

On the #include path changes, I will have to pre-import your PR internall to verify that this isn't breaking our internal build (and to try to find internal workarounds if needed).

I've rebased the PR and resolved conflicts, but I will take a look and start address review comments later today or early next week. Please, let me know how #include story goes. If this change is ok (I hope so), then we may consider to make it separately to reduce the scope of this PR and simplify/focus review on the cmake aspects.

[meta-codesync]

@NicolasHug has imported this pull request. If you are a Meta employee, you can view this in D85451979.

[NicolasHug]

Can confirm the header #include changes are OK internally! Yes, happy to consider a separate diff that does just that. Thank you!

[dvrogozh]

Can confirm the header #include changes are OK internally! Yes, happy to consider a separate diff that does just that.

Thank you! Here is includes PR: #1002.

[dvrogozh]

@NicolasHug, I've addressed all your comments and completed the 2nd iteration of the PR. Can you, please, help to review it again?

[NicolasHug]

Thanks for the PR and the refac @dvrogozh , this looks good! I made some minor cosmetic changes, I'll merge it soon. Thank you!