The README has no build commands, and the build instructions live on a wiki

The README carries no build commands, and sends you to a wiki for them

Read the README as a document and the absence is the first fact about it. It defines the project in two sentences, then lists links. Build instructions are one of those links, pointing at an Install-Instructions page on the project wiki rather than giving a command to run. There is no configure line, no make target, no package name in the README, and the only tool it names is a static analyzer.

So the procedure for compiling the software is genuinely not in this document. The tree offers two places to look instead: an `INSTALL` file at the top level and a `docs` directory. The wiki page is the one the README points at.

That has a practical cost for anyone working offline or automating a build. A README that says what the software is and links to how to build it is a reasonable choice, but it means the build recipe is one network fetch away from a clone, and a mirror of the repository does not carry it. Teams that vendor this source internally have to fetch the instructions separately and re-check them, because nothing in the repository tells them when they changed.

CMake presets and a .gitmodules file decide whether your checkout configures

The build system is CMake, and the tree shows the modern arrangement for it. `CMakeLists.txt` sits at the root, `CMakePresets.json` sits beside it, and there are `cmake` and `build-aux` directories for the supporting scripts. The presets file is the notable one, because it means the build variants are declared in the repository rather than reconstructed from memory or from a wiki page.

Next to that sits `.gitmodules` and a `deps` directory, so third-party code may be pulled in as submodules. The README does not describe submodule setup.

The combination shapes the first ten minutes of any build. The README does not walk through the presets or any submodule setup.

One directory per graphics API, and your build touches only one of them

The rendering code is not one directory. Alongside the core `libobs` there are `libobs-d3d11`, `libobs-metal`, `libobs-opengl` and `libobs-winrt`, one per graphics API, plus a `frontend` directory and a `plugins` directory alongside them. The names are the documentation here: the project keeps a separate tree per API rather than branching inside one.

The README does not say which of these directories a given platform builds, so check the wiki build instructions for the platform you target.

Translations go through Crowdin, and the project says pull requests are not the way

The contribution section is unusually specific about translations. It says that if you wish to contribute translations, do not submit pull requests, and to use Crowdin instead, linking a wiki page on how to contribute translations. The README also carries a Crowdin localisation progress badge at the top.

This closes off the route most contributors would guess. Finding a wrong or missing string, editing the file, and opening a pull request is the default move in most repositories, and here it is the wrong move. The change has to be made on Crowdin, per the README.

The build badge covers one pipeline, and a second CI config sits in the tree

The README's status badge points at a GitHub Actions workflow named push.yaml on the master branch. The tree also contains `.cirrus.yml`, which is the configuration file for a second, different continuous integration service. So the project has at least two pipeline configurations, and the badge on the front page reports the status of one of them.

Nothing in the README explains the division of labour, so a reader cannot tell from the badge whether a green mark means every platform passed or only the one the workflow covers. That is a small thing to be uncertain about and a real thing when you are deciding whether to trust a specific commit.

The related files point the same way. There is a `.clang-format` for the C and C++ sources, a `.swift-format` for Swift, and a `.gersemirc`, which is the configuration for a CMake formatter. Three formatters for three languages, alongside a `.git-blame-ignore-revs` file. That last file is the interesting one: it records the commits that reflowed the whole codebase so that `git blame` skips them, which is a concession that formatting churn is frequent enough to be worth hiding from history.

The newest tag is a beta, and the maintained line is on patches

Three releases are listed: 33.0.1 on 2026-10-29, 33.0.0 on 2026-10-23 and the release candidate 33.0.0-rc3 on 2026-10-20. The most recent push to the master branch was 2026-10-29, and the repository is not archived. The newest release is therefore a stable patch release, not a beta.

The licensing is worth stating plainly while the versioning is fresh, since it constrains redistribution. The README says the software is distributed under the GNU General Public License v2 or any later version, and directs readers to the accompanying COPYING file for the details. Anyone shipping a modified build should read that file rather than take this summary as sufficient, because the obligations attach to the distributed artifact and not to the download.

The project asks its community to defer to official channels

One line in the contribution section sets a norm that is easy to miss. It asks people helping others to limit their support to topics they fully understand, on the grounds that bad advice is worse than no advice, and to defer to the official help or official channels for anything else. The same paragraph points at the forums and the community chat as places to help.

That is the project declining to let its community become an unofficial documentation channel. The reason given is a good one, and the effect is specific: for anything outside your own expertise, the forum answer is not a substitute for the wiki, and treating a confident forum reply as authoritative is the failure the sentence warns about.

For someone evaluating the project, this is worth weighing alongside the rest. The help material is a wiki, the API documentation is on the project site, and the build instructions are on the wiki too, so the official surface is real and reachable. What the project declines to do is vouch for community answers.

Editorial conclusion

OBS Studio is a sound choice when you want a capture, compositing and streaming tool under a copyleft licence and are willing to follow the project's build instructions where it actually keeps them, which is the wiki rather than the README. Before you start, settle two things. First, pick a release deliberately: the newest listed release is 33.0.1 (2026-10-29), followed by 33.0.0 and the release candidate 33.0.0-rc3. Second, expect the tree to carry separate libobs-d3d11, libobs-metal, libobs-opengl and libobs-winrt directories, and check the wiki build instructions for the platform you build on.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes