Migration

Migrate from Flussonic

Import your configuration, keep your channel names, SRT ports, passphrases and auth backends, compare both servers side by side, and cut over when you are ready. Nothing is dropped silently: every directive that maps differently is in the import report.

Start the free trial Install guide

Four steps

Import, disabled

Run the importer on flussonic.conf — from the command line, the REST API (dry run by default) or the web UI under Settings → Import from Flussonic.

Review the report

Errors, warnings and infos per stream, directive and line. Typical work: set up the auth hook, replace skipped input types.

Enable and compare

Enable channels one by one or by label (e.g. all that ran in Flussonic), and compare renditions, audio languages, subtitles and latency.

Cut over

Move DNS, the virtual IP or the load balancer. Encoders and SRT viewers keep their port numbers and passphrases.

alteoxms import-flussonic -disable-all -merge /etc/alteoxms/config.json \
    -o /etc/alteoxms/config.new.json -json-report import-report.json \
    /etc/flussonic/flussonic.conf
alteoxms -check-config -config /etc/alteoxms/config.new.json

The emitted configuration always passes the config check. Secrets the new model cannot use (stream passwords, auth backend tokens) are not copied; SRT passphrases and input headers are, and the file is written with mode 0600.

Your control plane keeps working

Auth backend protocol

With auth.backend_protocol: flussonic the server asks your existing HTTP auth backends with Flussonic’s request format — including multiple backends in parallel and periodic re-checks via X-AuthDuration.

Event sinks

Flussonic-style event sinks with the same JSON array format: play_started, play_closed and source events.

HTTP API v3 subset

/streamer/api/v3 with streams, config/stats and event_sinks, so a control plane that monitors Flussonic edges can monitor this server.

config_external

Dynamic channels from the same configuration backend: a requested stream name is looked up and run on demand.

What maps to what

Flussonic	Alteox Media Server
`template NAME { … }`	Channel template + transcode profile; streams store only their own settings
`stream NAME { … }`	Channel (same name, sanitized); the original name and title kept as labels
`input URL (repeated)`	Inputs in the same order = failover priority; priority=N kept
`srt://, tshttp(s)://, hls(s)://, udp://, rtp://, copy://`	Same input types (tshttp → http)
`publish:// + srt_publish { port; passphrase; }`	Dedicated SRT publish port, same port and passphrase
`srt_play { port; passphrase; }`	Dedicated SRT play port, same port and passphrase
`input option header.NAME=VALUE / user_agent=`	Input request headers and User-Agent
`transcoder vb=… ab=… hw=nvenc deviceid=N …`	Transcode profile: renditions, audio rules, nvidia:N
`segment_duration, segment_count`	HLS/DASH segment length and window
`on_demand, clients_timeout`	on_demand, on_demand_idle
`push udp://…`	UDP output
`source_timeout N`	failover.loss_timeout
`config_external URL`	Dynamic channels from the same lookup server
`on_play / password / auth_backend`	Access check switched on; point the auth hook at your backend (Flussonic protocol)

URLs

HLS stays /<channel>/index.m3u8, HTTP MPEG-TS stays /<channel>/mpegts, DASH is /<channel>/manifest.mpd. A single ABR rung is selected by rendition name in the path (/<channel>/720p/mpegts, SRT read:<channel>/720p) instead of a track filter.

Not supported

We say it up front, so you can plan for it.

DVR / timeshift, thumbnails, EPG
RTMP and RTSP ingest
Flussonic-to-Flussonic inputs (m4ss://, m4f://) and cluster_ingest
Flussonic-specific URL variants (video.m3u8, tracks-v1a1/…, index.ts)
Prefix templates (template t prefix…)

On-demand behaviour

Like Flussonic, the first viewer wakes an on-demand channel and waits until data flows. A transcoded on-demand stream is expected to need about 5–12 s with NVENC. transcode_on_demand (no Flussonic equivalent) keeps the source running and only starts the transcoder for viewers of a rendition.