Sorry for the long wait since 3.1, but 3.2 is now finally available! Downloads can be found here.

A big under-the-hood improvement in this release is full support for the Meson build system, which will take care of automatically building all the needed dependencies as well. If you're one of our users that likes building their own binaries, definitely take it for a spin! (Those that simply download builds from our website, you will not notice any difference.)

Official Windows and Mac releases are still not available for this version while we're in the middle of upgrading our build system, but users wanting a MacOS build can already compile from source from this version onward (3.2 code is fully MacOS compatible again).

We also temporarily reverted support for LLHLS (just plain HLS in this build), due to many reported issues with inter-track syncing. We hope to bring full support back somewhere in the coming months. For those that only need to use single-track playback (without adaptive bit rate), you can reach out to us for a 3.2 build that has LLHLS re-enabled, or simply keep using the 3.1 build of course.

The full changelog can be found here.

Noteworthy features

New sessions system

What: Until now, Mist has already had a concept of a “session”, but it was hardcoded to our predetermined definition: a session is considered to be a single view action, over a single protocol, a single IP address, and for a single stream name. This new sessions system makes this definition configurable, and splits out the session management into a new MistSession binary that collates connection stats into session stats, and passes those on to the rest of the system as a single thing.

Why: Somebody’s definition of “session” might not match ours, and the work of matching connections to sessions was quite a bit of strain on the MistController binary, which turned this into a single point of failure in the system. This change not only allows more use cases to work without needing to make changes to the code, but also speeds up the whole system and increases reliability and predictability.

Custom variables support

What: MistServer already supports using various variables in places, mostly covering the current date and time, stream name, etcetera. This functionality would add support for custom-defined variables, which may be either static or the result of running some command or calling some URL (similar to the trigger system) at a configurable interval.

Why: This makes re-using paths, hostnames, and other similar types of configuration while allowing them to change in the future easy. It's also a step up for another upcoming feature: the ability to use these variables to configure arbitrary recording times/intervals, allowing for much more powerful advance scheduling of recordings and pushes.

Scheduled Pushes

What: So far, MistServer's ability to "push" streams (which is a single concept that encompasses both recording to disk as well as sending the stream elsewhere over various protocols for replication) has been limited to two styles of pushes: Regular pushes, which are started whenever they are configured and disappear once they end. Automatic pushes, which are started whenever their corresponding stream is active, and automatically restarted as needed while the stream is still active/available, even if it fails or gets disconnect. The new scheduled pushes system lets you use arbitrary variable comparisons to determine when a push should and shouldn't be active, giving extra flexibility on top of and alongside the existing features.

Why: The perfect use case for this is a stream that may be active continuously, but only should be pushed out and/or recorded at set intervals or times. The flexibility of this new system lets you call out to external sources to set variables and then write rules to interpret those variables into a decision to push or not. For example, MistServer could be linked to a calendar that decides when pushes are active, or some kind of external toggle/switch system that can be polled for the current wanted state.

WebRTC WHIP/WHEP/WISH support

What: Support for WebRTC ingest using WHIP/WISH and egress using WHEP.

Why: Our WebRTC support required a proprietary WebSocket connection for signalling. This adds support for industry standard WHIP/WISH ingest and WHEP egress in addition to our existing signalling WebSocket (which is still supported, and usually preferred because it supports more features). WHIP/WISH/WHEP can (for example) be interesting if there is an expected change in the IP address of the user, as it can survive such changes while the existing WebSocket-based method cannot.