xSTUDIO is a studio playback and review application for post production

A studio tool, and the version number is confusing

xSTUDIO is a media playback and review application designed for professionals working in the film and TV post production industries, particularly the Visual Effects and Feature Animation sectors.

The design intent is stated as two things in tension: an intuitive, easy to use interface, and a high performance playback engine at its core. That combination is the whole pitch. Review tools for studios are not consumer video players, and the performance claim is about the engine, not the chrome.

Around that core sit C++ and Python APIs for pipeline integration and customisation, described as providing total flexibility. A C++ API lets a studio embed the playback engine in its own tools, and a Python API lets a pipeline artist script against it. For a facility with an existing asset management and review workflow, those two interfaces are the reason to care.

There is a version detail worth flagging before anything else. The README is titled Welcome to xSTUDIO, v1.3.0, and says this codebase will build version 1.3.0 of xSTUDIO. The recent releases in the repository, however, are v0.11.2 from 2023-08-07, v.0.11.1 from 2023-07-19 and v0.11.0 from 2023-07-18. So the source tree is on the 1.x line while the published tags stop at 0.11.x, which is what you would expect from a project that moved to a 1.0 after its last GitHub release and then kept going without cutting further tags.

The repository is not archived, the last push was on 2026-10-06, and the project lives under the Academy Software Foundation with an Apache-2.0 licence and a NOTICE.TXT file at the root.

The build matrix: four Linux guides, Windows 10 and 11, macOS

Building is documented per platform, and the README links a separate guide for each, describing the release as buildable on various Linux flavours, Microsoft Windows and MacOS.

For Linux there are four guides rather than one, and the choice of guide is a real decision. There is a Linux Generic guide, and then guides for CentOS 7, for Rocky Linux 9.1 and for Ubuntu 22.04. A generic guide plus three distribution-specific ones tells you that the project supports the long-lived enterprise distributions as well as the current Ubuntu, and that the differences between them are documented rather than left to the reader.

Windows has one guide covering Windows 10 and 11, and macOS has one guide.

All of them live under docs/reference/build_guides/, with the filenames linux_generic.md, centos_7.md, rocky_linux_9_1.md, ubuntu_22_04.md, windows.md and macos.md. The README describes them as comprehensive build steps.

The choice of target versions is itself information. CentOS 7 is long past end of life, so its presence in the build guides is either legacy or an intentional statement about where studio infrastructure sits, since many facilities still run long-lived enterprise Linux on render and review machines. Ubuntu 22.04 and Rocky Linux 9.1 are the current enterprise choices.

For a team evaluating the project, the practical step is to read the guide for the platform you actually have rather than the generic one, because the distribution guides are where the dependency versions live.

CMake, vcpkg and a source tree laid out for a desktop application

The repository listing shows a C++ project of some size, and the structure says what kind of project it is.

The build is CMake, with a CMakeLists.txt at the root, a CMakePresets.json so the configurations are named rather than typed, and a cmake directory for the build logic. There is a xStudioConfig.cmake.in template, which is the standard way a project generates a configuration header at configure time. Dependencies come through vcpkg, with a vcpkg.json manifest, and an extern directory for vendored third-party code.

The source is divided into the layers an application of this kind needs. There is include for the public headers, src for the implementation, ui for the interface layer, share for shared resources, scripts for tooling, python for the Python API and its bindings, and test_resource for test fixtures. The docs directory holds the documentation, and there is a separate docs/reference/build_guides tree for the platform build instructions.

The code quality tooling is checked in, which is what you would expect from a project hosted under a foundation. There is a .clang-format for formatting, a .clang-tidy for static analysis, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md with a COMMITTERS.md, a GOVERNANCE.md and a SECURITY.md. The .github directory holds the workflows, and CHANGELOG.md records the history.

For an adopter who wants to build rather than download, the practical entry points are the CMake presets, the vcpkg manifest and the platform guide. The three together are the whole build story, and the fact that they are versioned in the repository is what makes a studio build reproducible.

The user guide ships prebuilt, on purpose

There is a documentation note in the README that explains an otherwise odd decision, and it is a good example of a project optimising for its users rather than for itself.

The xSTUDIO user guide is built with Sphinx using the Read-The-Docs theme. The package dependencies for building the docs can be challenging to install, so the project includes the fully built docs as part of the xSTUDIO repository, as well as the source for building the docs. The build setup disables the building of the docs by default to make life easy.

That is a small thing with a large effect on adoption. A studio that downloads a source tarball or a binary does not have to install a Sphinx toolchain, resolve theme versions, or discover that the docs build is what is failing. The documentation is present, and the default build does not try to regenerate it.

The same reasoning appears elsewhere in the repository. The Python API is a first-class directory rather than a script folder, the C++ headers are separated from the implementation so the public surface is explicit, and there is a NOTICE.TXT alongside the LICENSE, which is the conventional pairing for an Apache-2.0 project with third-party content.

For anyone reading the source to understand how the playback engine fits together, the presence of both the built docs and their sources means the reference material is available without a build step, and the sources are there when you need to change it.

Where xSTUDIO is the wrong tool

The boundaries are clear and they come from the category the application sits in.

First, this is a desktop application, not a library or a service. A team that wants to review footage through a browser, or that wants a review workflow with comments and approvals on a web page, is looking for a different class of product. The Python and C++ APIs make xSTUDIO embeddable and scriptable, but they do not turn it into a web review service.

Second, it is not a general purpose video editor. The scope is playback and review for post production, which means the workflows, the media handling and the integration points assume a studio pipeline with real shots and real round trips to a render farm. A team that wants to cut a video will find nothing here for that.

Third, the version story needs work before you pin anything. The README announces 1.3.0, the tags stop at 0.11.2, and there has been no GitHub release since 2023 even though the source has moved on by two minor versions and a major one. Anyone building from source needs to read the CHANGELOG to understand what changed, and anyone looking for a maintained binary should establish whether a current build exists for their platform before committing to it.

Fourth, the build is not free of friction. CMake with vcpkg on four documented Linux distributions plus Windows and macOS is a well-trodden path, but it is still a desktop C++ application with a third-party dependency tree, and a team without a build engineer will feel that. The documentation is generous, but a prebuilt binary for your platform is the thing to check first.

Editorial conclusion

Post production teams and pipeline engineers who need a review and playback tool that fits a studio pipeline should evaluate xSTUDIO, because it ships from the Academy Software Foundation with C++ and Python APIs and a build matrix covering Linux, Windows 10 and 11 and macOS. It is the wrong tool for a general video editor, for a web-based review workflow, or for a team that needs a supported release cadence, since the newest tag is v0.11.2 from 2023 while the source tree is building 1.3.0. Before adopting, read the build guide for your platform, check the CHANGELOG for what changed after 0.11.2, and note that the user guide is shipped prebuilt because its Sphinx dependencies are awkward to install.

Frequently asked questions

Official sources

1. AcademySoftwareFoundation/xstudio on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases