Version history

version 2.0.0.206 Beta

25.07.2026

  • Meshwork (multi-domain) — several servers are joined into named domains, and a domain serves as an isolation boundary: node membership, the resource catalog and alerts propagate only within their own domain, and nothing is passed between domains. A node may belong to several domains at once without mixing their data. For details, see Meshwork.

  • Node auto-discovery — it is sufficient to set the domain and a single entry point: the nodes exchange neighbor lists and build up a full mesh of direct links on their own. The shared domain key is derived automatically and is transferred only over a protected channel — TLS or a trusted local network segment.

  • Distributed resource library — UDP, RTP, Pro-MPEG and RIST outputs, UDP, RTP and RIST multicast inputs, and also PS1 and SRT links are published in the shared catalog of the domain (/data/library): a single list of multicast groups, ports, VLANs, SSM sources and point-to-point links with the node and the stream indicated. The catalog shows which addresses and ports are already taken, and a new input is connected directly from it — by picking a stream already delivered on another node of the domain, without entering the address manually.

  • Domain node overview — for every node the status, the time of the last contact, the role, the region, the build version, the CPU load, the traffic per physical interface and the number of on-air streams are shown, and for every inter-node PS1 or SRT link — the bitrate, the RTT, the retransmission and loss ratio and the state verdict.

  • Operation behind NAT — a node behind NAT takes part in the domain in full and without forwarding inbound ports: it connects on its own, its public access point is derived from the actually observed address and the announced port, and its state is relayed by the neighbors one hop further — the node is visible even to those that cannot reach it directly.

  • Auto-login of links inside a domain — PS1 and SRT links between nodes of the same domain no longer require a login and password to be created for every link: on the calling side (PS1 input, SRT input, SRT output in caller mode) it is enough to enable the “Meshwork peer auth” setting, and authorization is performed with the shared domain secret. The confirmed peer node and its stream are shown in the resource library and in the session list.

  • Low-Latency HLS and MPEG-DASH over CMAF — a new delivery mode, “OTT / LL-HLS / DASH”: the built-in multiplexer produces fragmented MP4 (CMAF), on top of which MPEG-DASH is served at /dash and Low-Latency HLS at /llhls; adaptive bundles are assembled for these formats as well. For details, see Delivery modes.

  • LL-HLS low latency — the media playlist is split into parts, blocking playlist reload and the preload hint are applied, so the player starts playback without waiting for a complete segment to be ready. CMAF segments carry Producer Reference Time, the DASH manifest advertises UTCTiming and the target latency, and the “LL part target duration (ms)” setting is applied on the fly, without restarting the stream.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS and MPEG-TS over HTTP are served over QUIC on a separate UDP port, with optional 0-RTT; the client requests the switch to QUIC with the ?h3 parameter. The administrative routes remain on TCP only.

  • Segment alignment to IDR — the segmenter distinguishes an IDR frame from an ordinary I-frame: on closed-GOP sources every segment starts with a full entry point, so the player can open the stream at any segment; on open-GOP sources the nearest I-frame serves as the boundary.

  • Content protection (DRM) — the OTT delivery of a stream can be encrypted: HLS AES-128 with a key from the server itself or from an external key server and with optional rotation by time windows, or MPEG Common Encryption (ISO/IEC 23001-7) with the cenc and cbcs schemes for CMAF and DASH. Encryption is performed once, at the moment the segment is produced, so the DVR archive is stored encrypted and plays back across any number of key changes. For details, see Content protection (DRM).

  • DVR (network archive) — every OTT channel is written to disk in parallel with delivery, with the same segmentation and without a separate recorder; in low-latency mode the archive is kept in two lines, MPEG-TS and CMAF, so the recording is available in the same container as the live broadcast. For details, see DVR.

  • Archive playback (VOD) — the archive is served over the same HLS, DASH and LL-HLS URLs as the live broadcast: t=<time> switches on VOD mode and sets the start of the window, d=<seconds> sets its duration. The HLS playlist is then closed, the DASH manifest is static and the recording gaps are presented as separate periods; adaptive bundles play the archive back with the same parameters.

  • EPG-based catch-up — instead of t and d it is enough to pass epg=<time>: the server itself finds the programme running at that moment on the bound EPG channel and takes its start and duration as the boundaries of the playback window.

  • Subtitles in the archive — WebVTT tracks are written to disk together with the segments and are played back in VOD over the same URLs; windows with no cues take up no disk space.

  • DVR storages — there may be several storages, each with its own fill limit and its own cleanup order. The archive depth (“Retention (hours)”, up to 90 days) and the protected floor are set separately for every stream, and the cleanup by free space touches neither the protected floor nor the windows of open VOD sessions.

  • DVR monitor — a dedicated screen shows the state and the fill of the storages, the size and the depth of the archive per stream and the read and write latencies, while the coverage histogram (/data/dvrstat) marks not only the gaps in the archive but also their cause — an input loss, a PMT change, scrambling, a cleanup run. The archive of an individual stream and the directories of deleted streams are erased from the same screen.

  • Alerter — a new alerting service: every failure becomes an incident that is raised, updated and cleared automatically, while the deduplicated active set shows only what is happening now. Severity is set on a single scale — from information to requires administrator action; such an incident is cleared by an operator acknowledgement. For details, see Alerts (alerter).

  • Alert code catalog — more than fifty incident types in a single list: streams and their inputs and outputs, TR 101 290 violations, node resources, DVR storages and recording health, DVB and CI/CAM reception, transcoders, OTT, certificates and domain nodes. The trigger thresholds are configured in the alerts section.

  • External alert delivery — alerts leave the web console: by email over SMTP (STARTTLS, implicit TLS, AUTH), by a message to Telegram and by running an arbitrary command, to which the incident is passed in environment variables and as full JSON on standard input. Each channel has its own switch and its own severity threshold.

  • Domain-wide alerts — the operator on duty sees the alerts of any node from any other one: the active set propagates together with the keep-alive and is cleared as soon as it disappears at the source, and every row indicates the source node. Hardware and system alerts remain local by default and are promoted to domain-wide with a separate setting.

  • Log in a database — the service messages are written to SQLite: typed records with a source and a severity level, collapsing of consecutive repeats into a single row with a counter, retention limited by age and by size. Unlike the active alert set, the log survives a restart.

  • TR 101 290 monitor — continuous monitoring of the conformance of the input stream to the standard: a single verdict (“OK”, “Problem”, “Checking…”) and a structured report by priorities 1, 2 and 3, where the clause of the standard, the measured value and the limit are given for every indicator. An MPTS multiplex is evaluated as a whole — across all PIDs, programs and SI tables. The stream is automatically classified as CBR or VBR, and the checks that are meaningful only at a constant bitrate are not evaluated on a VBR source and produce no false triggers. For details, see TR 101 290 monitor.

  • Reference clock drift — the systematic divergence of the source clock frequency is measured by linear regression in ppm against the ISO/IEC 13818-1 tolerance of ±30 ppm and is reported as a separate metric. A slow divergence is handled by smooth micro-shifts of the synchronization point (“Sync drift compensation”, enabled by default), so there are no jumps at the output.

  • T-STD buffer model — analysis of the video buffer of the reference decoder per ISO/IEC 13818-1 with overflow and underflow counters for MPEG-2, H.264 and HEVC; the timing is taken from the PCR clock, and the drain rate follows the actual video bitrate. Switched on with the “Analyze T-STD video buffer” setting.

  • Ad insertion analysis — parsing of SCTE-35 sections with splice events, transport-layer splice points with a configurable advance notification and random access indicators. The data is shown in the stream statistics when deep analysis is enabled.

  • Complaint assistant — for a stream with persistent violations a ready-made text prompt for an AI chat is produced, from which the chat composes a formal complaint letter to the stream provider: the list of persistent violations, the measured values, the clauses of the standard and the impact on the decoder. The prompt is served by the GET /data/stream/<id>/ai-complaint-prompt request; the stream name and the source address are not included in the text.

  • CI/CAM (EN 50221) — a built-in Common Interface host: detection of the module, reading its name and the list of supported CA_system_id values, selection of the programs to descramble and delivery of CA_PMT for each of them. A module combined with the DVB receiver descrambles the selected programs of the received multiplex inline, several of them at a time; the state of the slots and the verdict for every program are visible in the interface.

  • Software BISS-1 / BISS-E descrambler — applied not only to reception from a DVB card but to any stream input: the key is set for the whole SPTS or per program of the multiplex and is changed on the fly, without restarting the input. On reception from a DVB card the result is additionally verified against the stream itself, so a wrong key does not look like successful descrambling but raises a dedicated alert.

  • Conditional access cleanup on DVB reception — a separate adapter setting removes the ECM and EMM PIDs from a multiplex received by a DVB card, and the CA descriptors of the cleared programs from the PMT: a clean FTA stream goes further down the path. When the key is lost, the conditional access signalling is restored so that a receiver further down the chain can request access again.

  • Transcoder telemetry — for every encoder the media information of the transcoded output is published: the frame format, the video codec, the set of audio codecs and the current bitrate, and for every process — the CPU load and the memory occupied.

  • RTMP and RTMPS — a channel is published to any RTMP receiver, including YouTube and Facebook: H.264 or HEVC video (HEVC through Enhanced RTMP) and a single AAC track; for rtmps:// the node connects as a TLS client. In the opposite direction the input pulls the stream from an rtmp:// or rtmps:// source itself and remultiplexes FLV into MPEG-TS.

  • Seamless source switchover — when the active input is changed on the transmitter, the receiving PS1 peers do not reconnect: the numbering and the timestamps remain continuous, a queue burst is absorbed by dropping the oldest packets, and the gap is filled in by the regular retransmission.

  • Adaptive PS1 retransmission — the receiver measures the actual RTT to the transmitter and adjusts the repeat request intervals to it on its own; the measured RTT, the current re-request interval and the indication of an insufficient latency are reported in the link statistics. The latency of the receiving tunnel is set directly in milliseconds instead of the former multiple of the RTT.

  • The “Reconnecting” and “Administrator action” states — an input or output that has lost its source is reopened in place and stays in the “Reconnecting” state for the whole time of the attempts, raising one warning per episode instead of a message on every attempt. A cause that a retry cannot resolve — a busy port, a missing interface, data that is not MPEG-TS, an SRT failure on encryption — puts the input or output into the “Administrator action” state with a sticky alert, while an edit of the settings is applied immediately.

  • MPTS multiplexer: original identity — the programs can keep their original PIDs, and the order of the programs in the PAT, SDT and NIT is set manually, so a multiplex is migrated to Perfect Streamer without changing the stream identity for the receiving equipment. Programs with TS scrambling are migrated with their original timestamps.

  • Integration with external billing — every viewer session is authorized in an external billing or CRM system, is held by periodic re-authorization and is reported to the same system when it ends: a RADIUS-style Start / Interim / Stop lifecycle, and a subscription revocation drops the session mid-viewing. OTT, PS1 peering and SRT outputs are covered, and the billing system itself is connected with request and response parsing templates, without any software modification.

  • Built-in ACME client (Let’s Encrypt) — issuance and automatic renewal of the certificates for the web server, the HTTP/OTT server and the EPG server: a certificate is ordered for every configured host name, the renewal is checked daily, and an alert is raised on failure. An arbitrary certificate authority and external account binding are supported, and a new certificate is applied without restarting the service.

  • New web interface — node management has moved to a new console, which is opened at the node address (the /admin path): the overview, streams, system monitoring, DVB, DVR, transcoders, clients, the log, alerts and all server settings. Dedicated diagrams show the topology of the Meshwork domain and the path of the selected stream from the inputs to the outputs. The former interface is preserved at /classic. For details, see Web interface.

  • Real-time updates — the node publishes its state as an event stream at /data/events: on connection a full snapshot arrives, after which the frames of the streams, the system resources, the clients and the DVB adapters are updated once a second, while alerts and state changes arrive as events. The interface and external dashboards work without periodic polling.

  • Context-sensitive help — every screen and every important window of the new interface is provided with a help call that opens the documentation section for exactly what is open at the moment: the common help button for the screen, the “?” button in the window header for that window. The section opens in the language of the interface.

  • Languages, themes and layouts — the interface is translated into six languages (Russian, English, German, French, Spanish, Portuguese), supports a light and a dark theme and adapts the layout density on its own to a phone, a tablet, a workstation and a video wall.

  • Other improvements and bug fixes.