We are delighted to announce the release of Liquidsoap 2.2.0! It is now available on our release page and should be available via opam shortly!
Liquidsoap is a statically typed scripting general-purpose language with dedicated operators and backend for all thing media, streaming, file generation, automation, HTTP backend and more.
This release comes almost 4 months after the last stable release from the 2.1.x release cycle and 14 months (!) after forking the 2.2.x release branch! It includes some exciting changes in track muxing/demuxing, HLS, sound processing and more. See below for a detailed list!
New features
Here are the highlights:
Multitrack
This is by far the biggest change in this relase! This brings the ability to demux and remux tracks inside sources, making it possible to:
- Encode video with multiple audio tracks
- Create audio-only and audio/video streams from the same content, for instance a regular audio stream and one with the studio’s video.
- Drop or specify which metadata or track marks track should be used.
- Apply specific audio effect or encoding to different tracks
And much more! The full documentation is here. We plan on expanding this support in the future in particular to allow track selection based on language, encoded content etc.
HLS metadata
At last! We now support metadata in HLS streams using a timed ID3 stream for mpegts container and plain ID3v2 tags for adts, mp3, ac3 and eac3 formats. There is currently no support for metadata with mp4 containers.
This feature is enabled by default so you might want to check if it impacts your listeners before pushing it to production. It can be turned off by setting id3 to false on your HLS streams.
Full documentation is here.
Colored logs
Small change but not the least important! Logs are now colored by default when printed on the console. This finally makes it possible to read logs with high level of details!
We are aware of the need for more developer tooling and quality of life improvements! In the next release cycle, we hope to work on code formatting, highlighting and more!
New HTTP API
Interacting with your scripts is essential and, for this, web interfaces and APIs are really useful. In order to make our HTTP server easier to use, we wrote a new web API that is very close to node express’ API and should be fairly easy to use! The documentation is here
These changes also included a revamping of our SSL support which is now modular and with a new TLS optional support!
Native stereotool support
While commited to open-source through and through, we also do want to meet our users where they are. To this end, it seems that a lof of them want to use the proprietary stereotool audio processing. Up until this version, the only option was via the external command line encoder and this was not satisfactory.
With this release, it is now possible to use the shared library distributed by the author, which provides support for a new stereotool internal operator that is much easier to integrate. See the documentation here.
Records enhancements
As part of the language changes requred for multitrack, we now support the following operations on records:
Record spread:
let {foo, bar, ...rest} = someRecord
let otherRecord = { bla = "blo", ...someRecord }
Additionally, we now support optional record methods, for instance:
def f(x) =
if x?.foo == null() then
print("x does not have method foo")
else
print("x has method foo")
end
end
Support for YAML parsing/rendering
Following the recent JSON parsing feature, we now support YAML parsing in a very similar way as json.
Memory optimization
While we are aware that memory consumption with this release may have increased a bit due to on-going changes, we have done our best to introduce more ways to control it and understand its usage.
In particular, we now support the alternative jemalloc memory allocator, enabled in all our release assets and configurable via the internal settings.
We also introduced two new audio content formats, pcm_s16 and pcm_f32 that can be used to store audio internally as, resp., 16-bit signed integers or 32-bit floating point numbers. Our default internal format being OCaml’s native 64-bit floating point numbers.
We also added a new track.audio.defer operator that can be used to buffer large amount of audio data without impacting performances.
You can read more about memory utilization in liquidsoap here.
Switch to dune and javascript runtime
While perhaps more exciting to developers, the project has now fully moved to the OCaml dune builder. This provides an extra level of flexibility, In particular, we were able to extract the code that is specific to the liquidsoap language, that is everything that pertains to parsing/evaluating/type checking without the streaming and system specific operators and export it as an online playground. We’re not sure yet what we’ll do with it. It might be possible, for instance, to write a javascript backend to use liquidsoap scripts with the Web media APIs!
Versioning and release assets
For a little over a year now, we have switched to rolling release cycles with maintenance and bugfixes applying only to the current release cycle. Regular releases are tagged vX.Y.Z (for instance v2.2.0) on github and docker while on-going releases are tagged rolling-release-vX.Y.Z.
When an initial release, for instance 2.2.0, is being worked on, bugfixes and user issues are addressed for users using the 2.1.x releases. While we would like to extend support, this is the best that we can do with our limited resources!
rolling-release-vX.Y.Z tags denote the releases being worked on. For stable release branches, this would be for instance, rolling-release-v2.2.1 after release v2.2.0. For a yet-to-be released initial version, this would be for instance rolling-release-v2.3.x. We try our best to make those releases as bug-free as possible. Using one of them to test your production script also guarantees the fastest response to bugs and issues!
For release assets, we try to maintain two packages for debian and ubuntu distributions, one with the latest LTS or stable and one with a recent release. The new minimal assets are, as the name suggests, minimal builds. They contain a limited set of features and standard library operators. Minimal builds are intended for most production run and should limit the risk of issues such as segfault and etc. If your script can run with it, we recommend it over the fully featured builds.
For each release asset, you can consult the associated .config file to see which features are enabled.
Docker release images are located at: savonet/liquidsoap:v2.2.0. The release tag may be updated if needed. You can use git sha-based images to pick a fixed build, e.g. savonet/liquidsoap:<sha>
Lastly, we may update the list of release assets on the github release page. If you are looking for permanent release asset links make sure to checkout savonet/liquidsoap-release-assets.
Migration guide
We listed most of the migration issues you might run into on this page.
As a reminder, we strongly recommend to test your script in a stagging environment, even between minor releases, to make sure that everything is working correctly before pushing a new liquidsoap version to production!