CasparCG Server: broadcast playout that has run since 2006

What the server actually does

CasparCG Server is the part of the system that talks to the hardware. It plays out and records professional graphics, audio and video to multiple outputs, and it has been in round-the-clock broadcast production since 2006, which is a long time to be responsible for a picture going to air. The split of responsibilities is the thing to understand before anything else. The server is the output engine: it renders, it mixes, it sends. What tells it what to show is a client application, and the CasparCG Client is a separate download. That means running the server is not the same as playing a video, and a workstation with the server installed and no client connected will do nothing interesting. The engine is written in C++ and the source lives in the src/ directory of this repository.

The hardware requirements are the binding constraint

The system requirements section is short and it is the part of the README to read first. A graphics card capable of OpenGL 4.5 is required, and an Nvidia GPU is recommended, with Intel and AMD processors tested and known to work. The sentence that catches out most people is the one about bandwidth: the PCIe path between the GPU and the CPU matters, and so does the path between a Decklink card and the CPU, and the advice is to avoid chipset lanes where possible. In other words a machine that is nominally capable can still underperform because the display outputs and the capture cards sit behind a chipset rather than talking to the processor directly. On a machine built for office work rather than for video, that is a hardware change, not a configuration change, and it is the reason the project asks you to look at the requirements before anything else.

Windows and Linux, with a clear preference for each

The server runs on both major desktop platforms, and the README is candid about how well. On Windows, version 11 is recommended and version 10 is supported on a best effort basis. On Linux, Ubuntu 24.04 is recommended, and the note for other distributions is explicit: they will work, but you will have to compile the server yourself and they have not been tested. That is a meaningful distinction for an operator, because an untested combination in a 24/7 chain is an operational risk, and a distribution you compile yourself is one more thing to own. The project publishes ready-to-use downloads on its own site, with newer testing builds on a separate host, and a BUILDING document in the repository for the case where you want to compile it anyway.

Installing, configuring and starting the server

The documented path is a short numbered sequence. Download a release from the downloads page, install the optional non-GPL modules if you need them, edit the configuration file, and start the server. The configuration is a file called casparcg.config, and the README describes it as self-documented, so an operator can read the file to find the settings rather than hunting through a manual. On Windows, the start step is a batch launcher that restarts the server, or you can start the server executable and the scanner executable separately:

casparcg_auto_restart.bat

On Linux the equivalent is a shell script, and there is a Docker route as well, where a helper script in the tools directory brings the server up inside a container and carries its own documentation at the top of the file:

run.sh
tools/linux/start_docker.sh

The last step is to connect a client such as the CasparCG Client, which is a separate download rather than part of this repository.

The optional modules and the boundary of the GPL

The getting started section includes an optional step for installing non-GPL modules, and the example given is Flash template support on Windows. That step asks you to remove any previous Flash Player, download the archived installer package and install the pinned version of Adobe Flash Player from it, which is a dated instruction for a technology the web has moved past, and the module exists so that legacy graphics workflows keep working. The interesting part is the architecture rather than the module. Keeping the parts that are not GPL in separate, optional modules is what allows the core server to be distributed under the GNU General Public License without dragging proprietary components into it, and it is a design decision that shows how seriously a broadcast vendor treats licence hygiene. If you do not need a module, you do not install it, and the core server carries no trace of it.

The libraries underneath and what the licence obliges

The server is distributed under the GNU General Public License, version 3 or higher, with the details in the LICENSE file, and the README lists the third party libraries it uses with their own terms. FFmpeg is used under the GPLv2 licence, and the project notes that FFmpeg is a trademark of its originator. Threading Building Blocks is under GPLv2 as well. SFML comes under the zlib and libpng licence, GLEW under a modified BSD licence, and boost under the Boost Software Licence version 1.0. Reading that list tells you a lot about the engineering. FFmpeg and TBB are the heavy lifting for media and for threading, SFML and GLEW cover the windowing and the OpenGL extension loading, and boost supplies the general purpose pieces. For an organisation deploying this, the practical consequence is that the licence of the installation is a combination, and anyone repackaging the server has to carry those obligations.

Building from source and the shape of the repository

The source tree is small in description because most of it is the C++ implementation under src/, with a tools/ directory holding the operational helpers such as the Linux start scripts. The BUILDING document is the reference for compiling manually, and the tree also carries a CHANGELOG, a code of conduct, a clang-format configuration, an editor configuration and a typo checker configuration, which is the small set of files that usually tells you a project intends to keep its source tidy. Continuous integration lives under the .github/ directory. The release naming is also worth noting, because it tells you how the project handles stability: the published tags are v2.5.1-stable from 2026-09-16, v2.5.0-stable from 2025-12-10 and v2.4.3-stable from 2025-02-26, with the last push on 2026-10-15, so a stable line is maintained separately from the testing builds on the other host, and an operator pins a stable tag rather than tracking the branch.

Where CasparCG fits, and what it will not do

CasparCG Server is a playout engine, not a media player and not an editor. The nearest alternatives are doing the same job with general purpose software, a browser rendering the graphics over the network, or a video server that plays files to a display. The difference in approach is what broadcast actually demands. The server renders to multiple outputs at frame accurate times, it holds up under continuous operation, it integrates with capture and playout cards, and it keeps the show control in a separate client that an operator can drive live. A browser based approach can produce an attractive animation but cannot promise frame accuracy, cannot be relied on for a channel that must not drop a frame, and turns a video feed into a network dependency. A file based video server plays what it is given and has no concept of a live graphic layer at all. If your output is a broadcast chain, that difference decides it.

Editorial conclusion

CasparCG Server fits a broadcast operation that needs frame accurate playout to several outputs from one machine, with local client software driving it and a configuration file an operator can edit. It does not fit a web-first team, a workstation without a discrete GPU, or anyone who needs a media player rather than a playout engine, since the client side is a separate download and the server is the only part in this repository. Before deploying it, read the system requirements rather than the feature list, confirm the PCIe layout between the GPU, the CPU and any Decklink cards, and note that the server is GPLv3 or later, so the licence of the whole installation has to be checked with whoever owns it.

Frequently asked questions

Official sources

1. CasparCG/server on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases