Fallback streams

Fallback streams and default streams

Some inputs allow configuring a fallback stream (this is always possible through the API by setting the "fallback_stream" property for a stream's configuration), and a global "defaultStream" within the general panel setting exists as well.

When, for any reason (including a stream not being configured at all, or a stream being a currently offline live stream), an output is unable to connect to the input for a given stream, this mechanism is activated.

First, the fallback stream configuration is used. If this setting is set, the stream will be re-routed to the given stream name internally, and all configuration is applied recursively. This means a fallback stream may itself have another fallback stream, and so further. There is no check for infinite recursion in fallback streams, so care must be taken to never introduce a 'loop' of fallback streams.

If no fallback stream is configured, the default stream is attempted instead. This is a global setting, but may be overridden by by the "" trigger for more control. Default streams are safer to use as they do check for loops (defaulting to the current stream will not apply) and will only recurse once at most.

Both default streams and fallback streams will apply on the new stream name before using it.

DEFAULT_STREAM trigger

There is also a trigger that allows for a far more flexible configuration when it comes to fallbacks. The DEFAULT_STREAM trigger allows you redirect viewers on both unavailable and non-existing streams using your own scripts. Using this trigger will allow you to change the stream to redirect towards and also implement your own viewer tokenization.