Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions src/torchcodec/_core/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,21 @@ function(make_torchcodec_sublibrary
# Avoid adding the "lib" prefix which we already add explicitly.
set_target_properties(${library_name} PROPERTIES PREFIX "")

# On macOS, add Homebrew's FFmpeg library path to the rpath so that users
# with Homebrew-installed FFmpeg can use torchcodec without setting
# DYLD_LIBRARY_PATH. See https://github.com/pytorch/torchcodec/issues/570
if(APPLE)
if(DEFINED ENV{HOMEBREW_PREFIX})
set(HOMEBREW_FFMPEG_LIB "$ENV{HOMEBREW_PREFIX}/opt/ffmpeg/lib")
else()
# Default Homebrew location on Apple Silicon
set(HOMEBREW_FFMPEG_LIB "/opt/homebrew/opt/ffmpeg/lib")
endif()
Comment on lines +60 to +65
Copy link
Contributor

@NicolasHug NicolasHug Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that the handling of a custom HOMEBREW_PREFIX is only going to work for users building from source. For users installing the built wheels with e.g. pip install, the HOMEBREW_PREFIX will be hard-coded to opt/homebrew/opt/ffmpeg/lib which may or may not be the current location of the user's homebrew.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, can you think of a better alternative? I included the HOMEBREW_PREFIX path specifically for this case where a user would use homebrew in a non-default location, in which case he will be able to build from source.

set_target_properties(${library_name} PROPERTIES
INSTALL_RPATH "${HOMEBREW_FFMPEG_LIB}"
)
Copy link
Contributor

@NicolasHug NicolasHug Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On this:

It should not impact in any form the current resolution of the conda-installed libraries

I think the change will impact the resolution of conda-installed ffmpeg, because (IIUC) the rpath will now take precedence for the path resolution order. So, if FFmpeg is installed in both the conda env and with homebrew, it's the homebrew FFmpeg that is going to be resolved first.

Copy link
Author

@mscheltienne mscheltienne Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right. From what I could figure out, it seems that on main, libtorchcodec_core*.dylib doesn't have any LC_RPATH entries and thus the resolution relies on torch's rpath entries (which include conda paths and thus torchcodec finds the conda FFmpeg.

With this change, libtorchcodec_core*.dylib now has one LC_RPATH which gets added to the rpath list and likely searched first. Thus, we have the following scenarios:

  • Only conda FFmpeg: no change in behavior, homebrew path is searched first but no lib found, falls back to conda paths through the same path as before.
  • Only homebrew FFmpeg, fails on main, works on this PR.
  • Both installed, on main it would use the conda FFmpeg, on this PR it would likely resolve the homebrew FFmpeg first.

In this last scenario, torchcodec should still work and thus the change should be transparent to the user- the only way I can think of to retain control on which path to search first would be to add the conda path as well, but this is now a more invasive change, something along the lines of:

        set_target_properties(${library_name} PROPERTIES
            INSTALL_RPATH "@loader_path/../../..;${HOMEBREW_FFMPEG_LIB}"
        )

endif()

target_link_libraries(
${library_name}
PUBLIC
Expand Down
Loading