OpenRV, an open source media review viewer for VFX pipelines

What OpenRV is and who it is aimed at

OpenRV is an image and sequence viewer for VFX and animation artists. The repository describes it as the open source version of RV, the Sci-Tech award-winning media review and playback software, and the README summarises the goal plainly: high performance, hardware accelerated and pipeline friendly.

That position matters for the audience. Studios that use commercial review software often hit the same wall: the tool is capable but closed, so fixes wait for a vendor release and pipeline glue has to be built around a black box. An ASWF project gives a studio the option of reading the source, patching it and building it in house. The ASWF is the Academy Software Foundation, and hosting a media review tool under that umbrella is a statement about who the tool is for.

It is also worth being precise about the scope. OpenRV is a viewer. It is not a shot tracker, not a render farm manager and not an asset management system. If your problem is playback and review of rendered shots inside an existing pipeline, that is the target. If your problem is tracking approvals, that belongs in a different tool.

The documentation is hosted on Read the Docs under the aswf-openrv project, and the README points there for the full detail rather than duplicating it.

Cloning the source and what the recursive flag protects

The README gives two ways in, and the distinction between them matters for planning. The quick route is a plain clone:

git clone --recursive https://github.com/AcademySoftwareFoundation/OpenRV.git

The README is emphatic about the recursive flag, and the reason is visible in the repository layout: there is a .gitmodules file at the top level, so parts of the tree arrive as Git submodules. Without the recursive option those directories come back empty and the build fails later with missing files rather than a clear error at clone time.

The README then says that if you intend to build Open RV or contribute, you should follow the platform setup instructions before cloning, because that path involves considerably more setup. That ordering advice is unusual and worth taking seriously: the platform packages for macOS, Windows and Rocky Linux are prepared first, and only then does the clone and the common build instructions follow.

For contributors, the README sets out the expected workflow: be comfortable with git and GitHub, fork the repository, clone the fork rather than the main repository, create a branch from the main branch of that fork, resolve conflicts before opening a pull request, and update the branch with a pull and rebase before submitting.

Supported platforms and the build stack

The supported platform list is narrow and deliberate. Open RV currently runs on macOS Ventura 13.x and later, Windows 10 and later, and Rocky Linux 8.x and 9.x. The README also records a removal: as of 2025 CentOS 7 is no longer supported, since CentOS reached end of life in the summer of 2024.

Support for other current operating systems, and the README typically means other Linux distributions, is described as being on an if-we-can-find-time basis, because the primary mandate is supporting immediate customer needs on official VFX reference platforms. Community-driven contributions to add platforms are welcome. In practice this means a studio on Ubuntu or Debian should expect to do the dependency work themselves.

The stack behind the viewer tells you what building it involves. The repository carries a CMakeLists.txt, a cmake/ directory, a conan/ directory with a conanfile.py, an openrvcore-conanfile.py, a packages/ directory and dockerfiles/. There is a requirements.txt for the Python build requirements, listing pyyaml, requests, wheel, pyzstd, py7zr and pre-commit, with the comment that these are build requirements and are not packaged with the application. The README badge names Python 3.11 as the supported version, and the badges also name VFX Platform 2025 as the supported platform version.

So the build is C++ with CMake and Conan for dependencies, plus a Python tooling layer. Source style is enforced in the tree itself through.clang-format,.clang-tidy and cmake-format.json configuration, and there is a.pre-commit-config.yaml for the Python side.

Limitations a studio should price in before switching

The first limitation is platform coverage, which follows directly from the supported list. If your artists run a distribution that is not on it, you are not looking at a supported configuration, and the README frames such work as community driven. On a mixed estate that can be decisive.

The second is the absence of a packaged installer path in the repository. The README describes building the workstation, and the build documentation is split into platform specific pages and a common build page, which means assembling a working binary on each workstation is a real task rather than a download. Studios that expect a binary on every artist's machine need a packaging pipeline of their own.

The third is the licence. The repository's licence field on the repository says it is a custom licence that GitHub cannot classify, so the code is not under MIT, Apache 2.0 or any of the licences most open source policies recognise. The README also points at a separate THIRD-PARTY.md file for licence information about portions of Open RV that have been imported from other projects, which means a mixed licence picture for any part you redistribute. Whether that is acceptable is a decision for your legal team, and this article does not offer legal advice on it, but it must be read before the code enters a studio pipeline.

Finally, a product-level point: this is a viewer built by a foundation around a commercial reference implementation. Parity with the full commercial feature set is not something the README promises, and it does not document which RV features are out of scope.

Where OpenRV sits against commercial review tools

The difference in approach between OpenRV and a commercial review package is ownership rather than feature list. A commercial tool gives you a vendor roadmap, support contracts and a feature set that keeps growing without your input. OpenRV gives you the source, the ability to build it, and a governance structure through the ASWF where contributions land in the open rather than in one company's product.

The realistic alternative for a studio that wants review capability without running its own build is to keep the commercial product and accept the vendor dependency. A third path, if the need is simple playback and approval rather than deep pipeline integration, is a general purpose media player used alongside a dedicated review tool, which is cheaper and gives up the annotations, versioning and side-by-side comparison that a purpose-built review tool provides.

What OpenRV specifically changes for a pipeline is that the viewer becomes an artefact you build and control. Studios that need custom sidecar behaviour, an unusual codec path or a patched build for a pipeline quirk can make that change, because the code is there. The cost is the engineering time to build, package and support it across artist workstations, which the README's platform-specific setup instructions make plain.

Editorial conclusion

Adopt OpenRV if your studio wants a review and playback viewer it can build and modify without waiting on a vendor roadmap, and if you can meet the documented platform list of macOS Ventura 13, Windows 10 and Rocky Linux 8 or 9. Do not adopt it if your requirement is a turnkey install on an unsupported Linux distribution, since other distributions are supported only on an if-we-can-find-time basis, and do not treat it as stock open source software, because the licence field on the repository says it is a custom licence that GitHub cannot classify. Verify first by reading the LICENSE file at the repository root and the THIRD-PARTY.md file, then by following the git clone --recursive instruction and the common build instructions for your platform.

Frequently asked questions

Official sources

1. AcademySoftwareFoundation/OpenRV on GitHub
2. Issues
3. README
4. Releases