876: Fixes to allow building on macOS

[mcoliver]

Linked issues

Fixes #876

Summarize your change.

Tried a vanilla clone and build using rvbootstrap on a m4 macbook. It fails building OIIO because it finds my homebrew installed ffmpeg 8 (recently supported in RV) and hits the issue that avcodec_close has been removed in favor of avcodec_free_context. This was fixed in OIIO 2.5.19.1 https://github.com/AcademySoftwareFoundation/OpenImageIO/releases/tag/v2.5.19.1

An upgrade to OIIO subsequently requires upgrades to Imath to 3.2.2 and OpenEXR 3.4.2

As for the openexr patch file, I am currently unclear on the logic and if it is required with 3.4. I have left a stub file in place for future use and to keep the cmake logic intact.

OIIO 2.5 is EoL and we should be moving to OIIO 3.1 as noted in #893 however I have a feeling that could be a bigger upgrade so have left that for another commit.

Describe the reason for the change.

Tried a vanilla clone and build using rvbootstrap on a m4 macbook and it fails.

Describe what you have tested and on which operating system.

only tested on macos 26.0.1

Add a list of changes, and note any that might need special attention during the review.

oiio, imath, and openexr version bumps. I was unclear on the logic for the openexr patch file and if it is still necessary for 3.4 so I left an empty stub file.

Also opportunistically updated dav1d though it is not necessary for proper compilation.

[cedrik-fuoco-adsk]

Hello @mcoliver,

Thank you for taking time to contribute to OpenRV!

By default, OpenRV still builds with FFmpeg 6.x. If you want to build for another version, you need to add RV_FFMPEG=7 or RV_FFMPEG=8 when you build. Currently, this is not covered through rvbootstrap. You can execute the commands manually:

rvsetup
rvcfg -DRV_FFMPEG=8
rvmk

About the build issue

I think it due to the latest changes in cmake/dependencies/oiio.cmake (117e146#diff-dfafcb39538a61a8b8d645a4633e32611680204179434c586eeb8ede6a492b69). I haven't tested it, but since we are not passing the variables to OIIO, OIIO finds the FFmpeg on your machine (instead the one that OpenRV builds), and fails because the build was not setup to use FFmpeg 8.

If we revert the change to cmake/dependencies/oiio.cmake, it should fix the build issue because it will use the FFmpeg that OpenRV builds.

The above (passing RV_FFMPEG=8 and after OIIO.cmake is reverted) will be your best way forward to use FFmpeg 8.

About OpenEXR

Unfortunately, we can not upgrade the version of OpenEXR for CY2024 because of the standardization with https://vfxplatform.com. For CY2024, OpenEXR version must be 3.2.x.

Based on https://vfxplatform.com, OpenEXR can only be updated to 3.4.x with CY2026.

[mcoliver]

yeah thought it was weird that rvcfg was reporting 6 but then during the oiio build process it was referencing my homebrew ffmpeg 8. Didn't dig deeper into it. Really just trying to unblock people that want a player.

I'll admit I like to live on the bleeding edge :D and understand the use of the reference platform to the industry. I started a 2026 branch in my fork. Has a lot of updates to dependencies with performance improvments and bug fixes. Would it be worthwhile to have a branch in the official openrv project as well? I know it hasn't been finalized yet but happy to put some time and effort to get ahead of things

[cedrik-fuoco-adsk]

I am not that familiar with how OpenRV uses OIIO, but I don't think OpenRV is using FFmpeg through OIIO. Therefore, I think the CMake option -DUSE_FFMPEG=OFF could be passed to OIIO in oiio.cmake to prevent OIIO to look for FFmpeg and fix the issue you had with building.

About your changes for CY2026, if they are dependencies changes, you could open PRs and add the version changes under CY2026 with the RV_VFX_SET_VARIABLE macro.

And if you have changes in the C++ code, you can put them under a preprocessor like this (if they are specific to CY2026):

#if defined(RV_VFX_CY2026)
// ...
#endif

Just note that we haven't done anything for CY2025 yet. @mcoliver

[cedrik-fuoco-adsk]

An upgrade to OIIO subsequently requires upgrades to Imath to 3.2.2 and OpenEXR 3.4.2

Did you see that somewhere or is it based on tests? Based on slack messages on the ASWF channels, it seems like even OIIO 3.1.x support OpenEXR 3.1+, but I haven't tested it. Also, I haven't looked at Imath though. @mcoliver

[mcoliver]

Thanks for all of this @cedrik-fuoco-adsk . My main focus was getting the repo to a place where someone could following the instructions and build the app. That is not the case. The revert still does not allow a clean build. OpenRV config wants to build with ffmpeg 6.1.2 but the build process fails at OIIO and when it does it references my homebrew install of ffmpeg 8 (see below).

There are a few avenues we could pursue to get the repo to a state where it will build properly for users. Which direction do you advise me to pursue? I understand the need for CY2023/2024/2025, but also think we should have a version where people who don't care about the reference platform and just want a framecycler can clone/build in one easy step.

I'm hesitant to put the effort into CY2024/2025 when 2026 is 2 months away and would also like to have a branch that is a bit more forward leaning for those not constrained by the VFX reference platform limitations.

Another thing I thought about was adding a cli shell script to the repo to build the project with all the various options and updating the build instructions to reference it accordingly.

Thanks for any input/advice on where to put my time here.

-- Using FFMPEG:       n6.1.2


/Users/moliver/dev/tmp/OpenRV/_build/RV_DEPS_OIIO/src/src/include/OpenImageIO/platform.h:610:13: warning: '__ARM_NEON__' macro redefined [-Wmacro-redefined]
  610 |     #define __ARM_NEON__
      |             ^
<built-in>:487:9: note: previous definition is here
  487 | #define __ARM_NEON__ 1
      |         ^
[ 68%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/fits.imageio/fits_pvt.cpp.o
1 warning generated.
1 warning generated.
[ 69%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/hdr.imageio/hdrinput.cpp.o
[ 70%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/hdr.imageio/hdroutput.cpp.o
1 warning generated.
/Users/moliver/dev/tmp/OpenRV/_build/RV_DEPS_OIIO/src/src/ffmpeg.imageio/ffmpeginput.cpp:570:9: error: use of undeclared identifier 'avcodec_close'; did you mean 'avio_close'?
  570 |         avcodec_close(m_codec_context);
      |         ^~~~~~~~~~~~~
      |         avio_close
/opt/homebrew/Cellar/ffmpeg/8.0_1/include/libavformat/avio.h:693:5: note: 'avio_close' declared here
  693 | int avio_close(AVIOContext *s);
      |     ^
/Users/moliver/dev/tmp/OpenRV/_build/RV_DEPS_OIIO/src/src/ffmpeg.imageio/ffmpeginput.cpp:570:23: error: cannot initialize a parameter of type 'AVIOContext *' with an lvalue of type 'AVCodecContext *'
  570 |         avcodec_close(m_codec_context);
      |                       ^~~~~~~~~~~~~~~
/opt/homebrew/Cellar/ffmpeg/8.0_1/include/libavformat/avio.h:693:29: note: passing argument to parameter 's' here
  693 | int avio_close(AVIOContext *s);

[mcoliver]

An upgrade to OIIO subsequently requires upgrades to Imath to 3.2.2 and OpenEXR 3.4.2

Did you see that somewhere or is it based on tests? Based on slack messages on the ASWF channels, it seems like even OIIO 3.1.x support OpenEXR 3.1+, but I haven't tested it. Also, I haven't looked at Imath though. @mcoliver

Unclear. Perhaps you can with flags. I was brute forcing it from the OpenRV build logs.

When I updated the OpenRV oiio.cmake to 2.5.19.1 and subsequently attempted a clean build, it reported the following which leads me to believe the default looks for Imath 3.2 and OpenExr 3.4. So I updated those and subsequently was able to cleanly build OpenRV. That led to this PR request. I was attempting minimal changes without digging deep into alternative solutions modifying build flags.

[100%] Linking CXX shared library ../../lib/libOpenImageIO.dylib
ld: warning: ignoring duplicate libraries: '/Users/moliver/dev/tmp/OpenRV/_build/RV_DEPS_WEBP/install/lib/libwebp.a'
Undefined symbols for architecture arm64:
  "void OpenImageIO_v2_5::convert_type<Imath_3_2::half, float>(Imath_3_2::half const*, float*, unsigned long, float, float)", referenced from:
      OpenImageIO_v2_5::pvt::convert_to_float(void const*, float*, int, OpenImageIO_v2_5::TypeDesc) in imageio.cpp.o
  "void OpenImageIO_v2_5::convert_type<float, Imath_3_2::half>(float const*, Imath_3_2::half*, unsigned long, Imath_3_2::half, Imath_3_2::half)", referenced from:
      OpenImageIO_v2_5::pvt::convert_from_float(float const*, void*, unsigned long, OpenImageIO_v2_5::TypeDesc) in imageio.cpp.o
      OpenImageIO_v2_5::convert_pixel_values(OpenImageIO_v2_5::TypeDesc, void const*, OpenImageIO_v2_5::TypeDesc, void*, int) in imageio.cpp.o
  "Iex_3_4::IoExc::IoExc(char const*)", referenced from:
      OpenImageIO_v2_5::OpenEXRInput::valid_file(OpenImageIO_v2_5::Filesystem::IOProxy*) const in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, OpenImageIO_v2_5::ImageSpec&, OpenImageIO_v2_5::ImageSpec const&) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInputStream::seekg(unsigned long long) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInputStream::read(char*, int) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXROutput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, OpenImageIO_v2_5::ImageSpec const&, OpenImageIO_v2_5::ImageOutput::OpenMode) in exroutput.cpp.o
      OpenImageIO_v2_5::OpenEXROutput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int, OpenImageIO_v2_5::ImageSpec const*) in exroutput.cpp.o
      OpenImageIO_v2_5::OpenEXROutputStream::write(char const*, int) in exroutput.cpp.o
      ...
  "Iex_3_4::IoExc::~IoExc()", referenced from:
      OpenImageIO_v2_5::OpenEXRInput::valid_file(OpenImageIO_v2_5::Filesystem::IOProxy*) const in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, OpenImageIO_v2_5::ImageSpec&, OpenImageIO_v2_5::ImageSpec const&) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInputStream::seekg(unsigned long long) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXRInputStream::read(char*, int) in exrinput.cpp.o
      OpenImageIO_v2_5::OpenEXROutput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, OpenImageIO_v2_5::ImageSpec const&, OpenImageIO_v2_5::ImageOutput::OpenMode) in exroutput.cpp.o
      OpenImageIO_v2_5::OpenEXROutput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int, OpenImageIO_v2_5::ImageSpec const*) in exroutput.cpp.o
      OpenImageIO_v2_5::OpenEXROutputStream::write(char const*, int) in exroutput.cpp.o
      ...
  "Imf_3_4::OutputFile::copyPixels(Imf_3_4::InputPart&)", referenced from:
      OpenImageIO_v2_5::OpenEXROutput::copy_image(OpenImageIO_v2_5::ImageInput*) in exroutput.cpp.o
  "Imf_3_4::OutputFile::writePixels(int)", referenced from:
      OpenImageIO_v2_5::OpenEXROutput::write_scanlines(int, int, int, OpenImageIO_v2_5::TypeDesc, void const*, long long, long long) in exroutput.cpp.o
  "Imf_3_4::OutputFile::setFrameBuffer(Imf_3_4::FrameBuffer const&)", referenced from:
      OpenImageIO_v2_5::OpenEXROutput::write_scanlines(int, int, int, OpenImageIO_v2_5::TypeDesc, void const*, long long, long long) in exroutput.cpp.o
  "Imf_3_4::OutputFile::OutputFile(Imf_3_4::OStream&, Imf_3_4::Header const&, int)", referenced from:
      OpenImageIO_v2_5::OpenEXROutput::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, OpenImageIO_v2_5::ImageSpec const&, OpenImageIO_v2_5::ImageOutput::OpenMode) in exroutput.cpp.o

[cedrik-fuoco-adsk]

Hi @mcoliver,

Are you on the latest commit? Recently, we realized that OIIO was compiling with FFmpeg (which is causing your issue), but OpenRV is not using FFMpeg through OIIO. Therefore, we added a param when building OIIO to disable the usage of FFMpeg. Your errors about FFmpeg and OIIO should be gone (after a clean build).

I'll get back to you about the rest.

[mcoliver]

Hi @mcoliver,

Are you on the latest commit? Recently, we realized that OIIO was compiling with FFmpeg (which is causing your issue), but OpenRV is not using FFMpeg through OIIO. Therefore, we added a param when building OIIO to disable the usage of FFMpeg. Your errors about FFmpeg and OIIO should be gone (after a clean build).

I'll get back to you about the rest.

Correct. @cedrik-fuoco-adsk Latest commit. Clean build attempt. Build log attached from clone to error.
failed_build.log.zip

[mcoliver]

I'm closing this pull request since it requires an upgrade to openexr 3.4 which does not conform to CY2024 as noted above. I'll open a new one with a CY2026 option, and also attempt to fix the current macOS compilation issues with CY2024 by ensuring cmake does not attempt to link thing in /opt/homebrew