Liquidsoap for Stream Graphs, Web Radio and Media Automation

Liquidsoap's Scope for Netradio and Streaming Pipelines

Liquidsoap addresses the gap between playing a fixed media file and maintaining a continuously running stream. Its intended users include netradio and web TV operators, streaming engineers and developers who need to describe media processing as a script rather than assemble it through a graphical interface. The README describes the project as a statically typed general-purpose scripting language with dedicated operators and backends for media, streaming, file generation, automation and HTTP.

That scope makes Liquidsoap more than a transcoder. A script can connect sources and processing components into a stream, which fits workloads where an input remains live, multiple transformations are needed, or output must be tied to a media protocol. It is also relevant when the resulting behavior must be reproducible from a text file. The repository's Unix-oriented framing is explicit: simple components are designed to work together.

The trade-off is breadth. A large collection of stream operators creates room for expressive automation, but it also increases the amount of project-specific knowledge required. The README calls Liquidsoap a complex framework with many operators and advanced implementations. Engineers should therefore treat it as programmable stream infrastructure, not as a minimal player for a single file.

Typed Operators, Stream Graphs and Liquidsoap Scripts

The central mechanism is composition. A Liquidsoap script combines operators that represent sources, processing actions and destinations. The language is statically typed, so those connections are checked against types rather than assembled only through untyped runtime configuration. This model is useful for pipelines whose structure matters: the script records how media enters the graph, which transformations apply and where the resulting stream goes.

The README also identifies dedicated backend areas for HTTP, streaming and file generation. Those destinations affect deployment because a script can describe more than an in-memory transformation. Automation is another documented area, allowing stream behavior to be represented within the same language model rather than delegated to an unmentioned external scheduler. The exact signatures and behavior of individual operators are not reproduced in the README, so scripts must be checked against the documentation for the selected version.

This architecture is a meaningful distinction from a fixed conversion pipeline. A conventional conversion command normally centers on taking an input file and writing an output file. Liquidsoap instead models connected, potentially continuous media components. That makes it a better conceptual fit for a permanent stream service, while adding the responsibility of understanding operator types and stream lifecycle.

Installing Liquidsoap Through opam and dune

For a developer working from the repository, the README requires OCaml 5.4 or newer and dune 3.23 or newer. Install the package dependencies from the two opam package files, then build the project. These commands build the local source tree; they do not install the result into the system.

opam install --deps-only ./opam/liquidsoap.opam ./opam/liquidsoap-lang.opam
dune build

The repository root contains a `liquidsoap` wrapper. It runs the binary directly from the build tree and points the standard library at `src/libs/`, so the first use does not require a separate installation step. The README uses `your_script.liq` as the script filename.

./liquidsoap your_script.liq

For an installed source checkout, the documented opam route first pins the local tree and then installs `liquidsoap`.

opam pin -ny .
opam install liquidsoap

The README does not provide a complete stream script, so it does not support inventing a first playlist, source or output configuration. The verifiable first operation is launching an existing `.liq` script through the wrapper. The script itself must use operators and backends documented for the installed release.

Binary Repository Setup for Debian, Ubuntu, Fedora and Alpine

Liquidsoap publishes one binary repository per release for Debian, Ubuntu, Fedora and Alpine. The setup script asks which release to follow, after which the operating system's normal package command can install Liquidsoap and receive later upgrades through the configured repository.

curl -fsSL https://repo.liquidsoap.info/setup.sh | sudo sh

The README identifies `apt-get install liquidsoap`, `dnf install liquidsoap` and `apk add liquidsoap` as the subsequent package commands for those respective distributions. Choose the command that matches the system configured by the setup script.

The documented channels cover the current Debian stable and testing releases, the current Ubuntu LTS and latest release, the current Fedora release, and Alpine edge. The listed architectures are `amd64` and `arm64` for Debian and Ubuntu, and `x86_64` and `aarch64` for Fedora and Alpine. The repository site is the authoritative place to inspect what each channel currently carries.

For an unattended or organization-controlled setup, the README also links manual configuration. That matters because piping a remote script into a privileged shell changes the installation path. The README does not document the manual keys in the excerpt, so they should be taken from the linked project documentation rather than reconstructed from the short command.

Liquidsoap Release Channels and Upgrade Exposure

The repository distinguishes fixed releases from rolling releases. At the listed release state, `2.5.x` has `2.5.0-rc1` as its latest fixed release and a `2.5.x` rolling release. Branch `2.4.x` has fixed release `2.4.6` and its own rolling release. Branch `2.3.x` is shown as ending at `2.3.3`, with neither support nor a rolling release. The release matrix is generated from `.github/release-matrix.json`, which the README identifies as the file to edit.

Liquidsoap follows semantic versioning, but the project qualifies that convention in ways that matter operationally. Different major versions are incompatible. Different minor versions may be incompatible. Releases that differ only by bugfix version should be compatible, although the README warns that a bugfix can correct an operator's intended behavior and thereby break a script that relied on the previous result.

This is the clearest operational limitation in the repository information. A deployment should not equate a patch release with zero behavioral risk for media pipelines. The README specifically recommends maintaining a staging environment for testing new versions. The repository is not archived, but recency does not remove the stated compatibility boundary.

The documented upgrade path for binary installations is the system package manager after repository setup. For source-based use, the local `opam pin` and `opam install` commands provide the stated route. Neither path removes the need to validate stream behavior before production promotion.

When Liquidsoap Is the Wrong Tool

Liquidsoap is the wrong choice when the task is merely converting one finite media file and does not benefit from a persistent stream graph. A general-purpose conversion command is the practical alternative in that case: its job is centered on a bounded input and output, whereas Liquidsoap's documented design centers on connected operators, continuous streams and backends. Adding a stream language to a one-shot task would introduce syntax and runtime concepts without a matching need.

It is also a poor match for a user who cannot inspect or maintain the script. Static typing and text-based configuration help detect structural mistakes, but the project still requires knowledge of stream sources, destinations, codecs and the exact operators available in the chosen release. The README does not claim that Liquidsoap automatically selects an appropriate operator or hides protocol configuration.

Licensing also requires an explicit review. The repository declares `GPL-2.0` and includes a `COPYING` file. The README does not explain how a particular hosting, distribution or modification model interacts with that licence, so the licence file and applicable obligations must be reviewed directly. That is a compliance check, not a recommendation.

Editorial conclusion

Liquidsoap is appropriate for engineers building repeatable netradio, web TV, streaming, file-generation or HTTP-backed media workflows. It is a poor fit for a one-off media conversion when a dedicated converter would be simpler. Before adoption, check operator and codec availability for the intended pipeline, then test the selected `2.4.x` or `2.5.x` release against real streams in a staging environment because minor versions may be incompatible and even a bugfix can change an operator's behavior.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. savonet/liquidsoap on GitHub