Beyond Hardware Mixers: A Resilient Cloud-Native Architecture for Real-Time Remote Video Production

Abstract

Professional live video production has traditionally been limited by proprietary hardware mixers and monolithic desktop applications, which impose prohibitive costs and restrict scalable, command-line-based implementation for remote integration (REMI) workflows. To address these limitations, this article presents Voctomix 2.0, a containerized and enhanced live video mixing architecture based on the open-source Voctomix framework. This research introduces a production-ready extension layer that adds dynamic multi-layer overlays, operator-level stream-blanking control with coupled audio muting, and an asynchronous AMQP telemetry framework on top of the upstream mixing engine. The architecture was empirically evaluated in local, Docker, and single-node Kubernetes environments under varying workloads, ranging from 1080p25 to 2160p50 (4K). Results under a continuous four-source 1080p25 workload showed that, in a single-node deployment, containerization and orchestration impose no appreciable processing overhead, with a median host-level CPU utilization near 90% and a stable RAM working set of around 13 GB on standard hardware. The median command-to-output latency within the mixer was 293 ms, an internal switching latency that does not include camera capture or wide-area transport. Forced-failure experiments validated the architecture’s self-healing capability, which autonomously recovered blocked camera signals in approximately 1.8 s while maintaining a continuous live program feed.

1. Introduction

Although the transition from Serial Digital Interface (SDI) [1] to IP-based workflows has revolutionized the signal transport in the broadcasting industry and drastically reduced the associated routing costs, the basic functions of live video mixing and compositing remain deeply rooted in proprietary, hardware-defined ecosystems. Conventional live production systems tightly integrate switchers, routing matrices, and control devices within closed, vendor-specific architectures. This hardware-centric paradigm not only imposes prohibitive capital expenditures but also forces organizations to follow rigid technological refresh cycles, creating a significant barrier to entry for small-scale broadcasters, academic institutions, and research groups seeking professional-grade production capabilities [2].

To overcome the limitations of fixed-purpose hardware, the broadcasting industry has increasingly adopted software-defined video and the Remote Integration Model (REMI) [3]. This architectural shift has been significantly accelerated by the proliferation of modern media transport protocols, notably Secure Reliable Transport (SRT), Reliable Internet Stream Transport (RIST), and Network Device Interface (NDI). By facilitating the transmission of high-quality, low-latency video contribution over both private networks and the public Internet, these technologies successfully decouple production logic from the physical chassis. As a result, compositing processes can be centralized on standard IP-connected servers, while camera signals and broadcast endpoints remain strictly on-premises [4].

Despite the operational flexibility this model offers, implementing real-time video mixing and compositing in cloud-orchestrated environments poses significant technical challenges related to bandwidth management, internal network routing, and computational efficiency. Processing uncompressed or high-bitrate video in virtualized clusters requires efficient data flows to prevent frame loss and latency accumulation. However, existing software implementations have critical architectural shortcomings in this context. Widely adopted open-source platforms, such as OBS Studio (https://obsproject.com/, accessed on 20 May 2026), feature a monolithic design that inextricably couples media capture, compositing, and graphical user interfaces, limiting their deployment to local desktop environments with a single operator. In contrast, commercial alternatives such as vMix (https://www.vmix.com/, accessed on 20 May 2026), impose strict operating system dependencies and prohibitively expensive licensing models, and lack the native containerization necessary for scalable cloud orchestration. Although pioneering open-source solutions such as Voctomix (https://github.com/voc/voctomix, accessed on 20 May 2026) introduced a client-server architecture with a remote graphical interface and a configurable compositing and transition engine, they were conceived for event recording rather than continuous, cloud-orchestrated production: they lacked an operator-facing production layer (dynamic lower-thirds with automatic deactivation, blanking-coupled audio control), a decoupled machine-readable telemetry channel, and reproducible container-orchestration manifests. This work builds directly on that upstream engine and contributes precisely that missing layer, as detailed in Table 1.

Table 1. Capabilities provided by upstream Voctomix versus the extensions contributed by this work.

Capability	Upstream Voctomix	This Work (Voctomix 2.0)
Client–server split (voctocore/voctogui)	Yes	Inherited
Configurable composites, transitions, mirror	Yes	Inherited
TCP line-based control protocol	Yes	Inherited
Three-path stream blanker module	Yes	Inherited
Operator blanking control with coupled audio muting	No	Added
Dynamic dual-text lower-thirds with auto-off on cut	No	Added
Compositing path modifications	Yes	Extended
Decoupled AMQP/RabbitMQ JSON telemetry	No	Added
Docker Compose stack (11 services, shared netns)	No	Added
Kubernetes manifests (Pod, ConfigMap, PVC)	No	Added
Empirical evaluation (3 tiers × 4 formats)	No	Added

This work introduces a resilient and advanced cloud-native remote video production architecture based on Voctomix 2.0. The proposed system transforms the traditional desktop-limited compositing model into a fully containerized, platform-agnostic infrastructure, enabling multiple remote operators to collaboratively control a real-time, synchronized mixing process with a graphical interface. By running natively on standard Linux environments and leveraging an underlying GStreamer engine, this lightweight architecture runs on commodity CPU hardware without depending on the GPU acceleration that heavier monolithic applications often require. This approach offers a cost-effective alternative, particularly well-suited for distributed university campuses, distance learning production networks, and collaborative research initiatives. Furthermore, its open-source foundation eliminates dependence on a single vendor and maintains the system’s extensibility, allowing developers to integrate custom plugins or adapt the TCP-based control protocol for specialized automation workflows. Delivery is deliberately kept outside the mixing core: the programme output is handed to standard distribution paths, such as an SRT or RTMP egress to a campus streaming server or a public platform, so audiences watch through the clients they already use, with no dedicated hardware on the receiving side. The cost argument is therefore one of accessibility, bringing professional-grade live production within reach of institutions currently priced out of it.

The main goal of this research is the establishment of a comprehensive and reproducible methodology for cloud-native live streaming. Specifically, this work presents the following contributions:

• Production-Grade Extension Layer: The development of a processing layer that integrates dynamic multi-layer overlays, operator-level stream-blanking control with coupled audio muting, and an asynchronous telemetry exporter, implemented as modular additions to the upstream mixing engine.
• Asynchronous Telemetry Framework: A decoupled monitoring architecture that converts pipeline events into structured JSON messages published to a RabbitMQ broker, enabling non-intrusive monitoring and state consistency across multiple clients.
• Standardized Deployment Topology: The design of Docker Compose and Kubernetes manifests that eliminate manual configuration overhead and confine uncompressed internal traffic to a shared network namespace, so that raw video does not traverse a physical network interface between the ingest and mixing processes.
• Empirical Evaluation: A rigorous analysis of the proposed architecture’s performance in different deployment environments (physical, containerized, and orchestrated servers) under high-definition and 4K video formats, with the full set of metrics and methodology detailed in Section 4.

This work is organized as follows: Section 2 reviews the literature on live video production systems and containerized multimedia workflows. Section 3 details the architecture of the Voctomix 2.0 system, the deployment scenarios, and the experimental setup used for evaluation. Section 4 presents the validation results and performance metrics. Section 5 discusses and interprets these results together with the main limitations of the study. Finally, Section 6 presents the main conclusions and outlines future research directions.

2. Related Works

2.1. The Shift to the Remote Integration Model (REMI)

Historically, professional live video production has been severely limited by its reliance on dedicated hardware switchers and proprietary desktop applications. Production mixers have traditionally been dedicated hardware units. For example, the Blackmagic ATEM line ranges from a few hundred dollars for compact models to approximately $15,000 for high-end units, such as the ATEM 4 M/E Constellation 4K Plus version 10.4.1 [2], with comparable systems from Ross Video falling in a similar price range. When combined with SDI matrix routing, specialized control devices, redundant infrastructure and on-site engineering staff, complete production facilities typically require a capital expenditure ranging from hundreds of thousands to millions of dollars. This hardware-centric paradigm creates a significant barrier to entry, effectively excluding small-scale broadcasters, academic institutions, and research groups from professional live production.

To mitigate these logistical and financial dependencies, the audiovisual industry developed the REMI model. This model partially addresses these challenges through the structural separation of production components: cameras and feed contribution encoders remain on-site, while mixing and compositing functions are centralized in a single facility connected via IP. The operational feasibility of this approach has been confirmed by large-scale implementations in the sector, such as the REMI workflows used by Olympic Broadcasting Services at the Tokyo 2020 Olympic Games [5], and the SRT-based contribution network deployed by Telefónica Servicios Audiovisuales and Appear for LaLiga [6]. However, even in these advanced implementations, centralized installations often rely on the same monolithic, vendor-specific software stacks as the legacy hardware they are intended to replace, limiting true deployment flexibility and remote cloud operability.

2.2. Media Transport Protocols and Network Constraints

Remote production is based on a set of transport protocols organized into layers, each specifically tailored to the different stages of the signal path. In cloud-based implementations, these protocols increasingly terminate at containerized capture points, sharing standard infrastructure to reduce the physical space occupied by the contribution chain.

• Contribution Links: For camera-to-facility transport, where high fidelity and minimal latency are prioritized over broad reach, SRT protocol provides critical packet-loss recovery over UDP with sub-second latency, establishing itself as the de facto standard [7].
• Monitoring and Feedback Signals: WebRTC, standardized by the W3C [8], achieves latencies between 100–500 ms over UDP and incorporates DTLS/SRTP encryption. However, since its point-to-point signaling is not well suited for mass audiences, it is suitable only for monitoring channels, rather than for global distribution.
• Streaming to Multimedia Platforms: Despite its age, Real-Time Messaging Protocol (RTMP) remains the most widely supported format on platforms such as YouTube Live and Twitch, remaining the most widely supported ingest format among content creators [4].
• On-site Routing: Professional broadcasting has shifted from routing via hardware SDI matrices, in accordance with the SMPTE ST 2022-6 standard [9], to uncompressed IP media via the SMPTE ST 2110 standard [10], as part of a broader industry shift toward “glass-to-glass” latency of less than one second [11]. Although SMPTE ST 2110 standard offers ultra-low latency by splitting video, audio, and ancillary data into separate streams, it requires complex routing in multicast networks and strict hardware synchronization using the Precision Time Protocol (PTP) [12], which poses significant integration challenges for commercial cloud environments.

2.3. Software-Defined Video and Existing Frameworks

Software-defined media aim to reduce economic barriers by relocating the mixing function into software processes connected via standard IP networks. However, current implementations introduce critical architectural limitations. Open-source platforms such as OBS Studio offer comprehensive capture and streaming capabilities with WebSocket-based automation [13,14]. However, they integrate these features into a desktop application designed for direct local operator interaction, making them unsuitable for server-side headless environments. In contrast, commercial alternatives such as vMix support the mixing of multiple sources and 4K output, but their commercial licensing (ranging from $60 to over $1000 per seat), the requirement to use the Windows platform, and the lack of a container-based deployment option exclude them from reproducible cloud deployments running on Linux [15].

At the underlying pipeline level, tools such as FFmpeg offer broad codec support, but are primarily designed for file-based or single-stream workflows from the command-line. GStreamer [16], on the other hand, models multimedia processing as directed graphs of elements connected via pads, using a bus-based architecture, caps negotiation, and hardware-accelerated elements (VA-API, NVENC) that are highly suited for modular real-time processing, which can be inspected at runtime.

Within the open-source ecosystem, previous initiatives have typically focused either on tight hardware integration on a single host (as is the case with GPU-accelerated mixers [17,18]), or on headless network operation, but they have rarely combined both aspects. Voctomix [19,20], originally developed by the C3VOC team, pioneered a true client-server topology, decoupling a GStreamer-based engine from a graphical user interface for the operator via a TCP control channel. In a previous study [21], the operational viability of Voctomix 1.3 was demonstrated through its implementation as the production backbone for a large-scale sporting event. While it successfully validated the client-server model under real broadcast conditions, it served as a baseline whose upstream engine we extend with an automated production layer, decoupled AMQP telemetry, and reproducible container-orchestration workflows aligned with modern cloud standards (Table 1).

2.4. Cloud Orchestration and Containerized Media Workflows

More recently, the mixing function itself has been virtualized: instead of a fixed physical infrastructure, the production process has become a set of container images that can be instantiated on any host with sufficient resources, from a local workstation to a managed cloud cluster [22], a transition that is increasingly extending beyond its original scope of web services to demanding, compute-intensive workloads [23].

Containerization can reduce environment drift by packaging application dependencies and runtime configuration together with the software [24]. Docker Compose extends this approach to multi-service deployments through declarative service and network definitions [25]. The Docker Compose and Kubernetes scenarios evaluated here reuse the same application container images but require different orchestration definitions: compose services are represented by a separate Kubernetes Pod specification together with ConfigMap and PersistentVolumeClaim resources. Therefore, the deployment artifacts are related but are not interchangeable without prior conversion.

However, managing these real-time multimedia workloads imposes stringent requirements for which general-purpose container platforms were not originally designed, such as limited scheduling latency and headless operation without a display server. To address the first requirement, scheduling schemes specifically optimized for latency-sensitive workloads, such as live video streaming, have been proposed to overcome the limitations of the default Kubernetes scheduler [26]. Furthermore, the requirement for privileged access to hardware for GPU acceleration expands the attack surface of containers, leading to significant security trade-offs, as analyzed in the study by Jarkas et al. [27]. In a closely related evaluation, Shih et al. [28] compared a DeepStream-based streaming service on a containerized edge infrastructure to quantify the overhead of real-time multimedia processing. These constraints, rather than the feasibility of containerization itself, are what a production-oriented live mixer must address, and they are the direct motivation behind the design evaluated in this work.

2.5. Qualitative Comparison and Research Gap

To clearly illustrate the structural limitations of current live production systems, Table 2 compares Voctomix 2.0 as our proposed extended framework, with the main industry alternatives analyzed in this section: OBS Studio [13], vMix [15], and the Blackmagic’s ATEM family [2].

Table 2. Feature comparison of live video production tools.

Feature	Proposed Solution: Voctomix 2.0	OBS Studio	vMix	ATEM Family
Licensing cost	Free	Free	$60–1000	$295–15,000 (HW)
Open-source	Yes (MIT)	Yes (GPL)	No	No
Linux operation	Yes	Yes	No	No
Native containerization a	Yes	Partial	No	No
Machine-readable API	TCP (text)	WebSocket	TCP (limited)	SDK (proprietary)
Client-server split	Yes (TCP API)	No	No	Yes (HW controller)
Multi-operator	Yes	Partial	No	No
Advanced telemetry	Yes	Partial (WS events)	No	No

^a Partial indicates a capability achievable only through unofficial or community-maintained configurations, rather than through an integrated, vendor-supported deployment path. OBS Studio’s obs-websocket plugin supports concurrent clients and state events, but not a decoupled telemetry stream or native multi-operator mixing, hence Partial.

Of the four systems considered in Table 2, the proposed architecture is the only option that combines zero licensing cost, headless Linux deployment, native container packaging, a machine-readable API, and a client-server topology. Therefore, the research gap addressed here is the evaluated integration of these properties into an open, remotely operable mixing architecture, rather than the absence of all comparable alternatives.

3. System Architecture and Experimental Setup

This section details the internal architecture of Voctomix 2.0, describing the core processing workflow, the newly integrated production extensions, the telemetry framework, and the network topologies designed for cloud deployment. Finally, it describes the experimental setup and the parameters used to evaluate the final system.

3.1. Voctomix 2.0 Core Pipeline

Voctomix 2.0 is derived from the upstream C3VOC codebase at branch voctomix2, commit 558489d (https://github.com/voc/voctomix/tree/558489d187958efac1d8285c77b2ad368487335f, accessed on 10 March 2025), on top of which the extensions described in this section were implemented. It operates under a strict client-server separation (Figure 1). The processing server, voctocore, hosts a GStreamer media pipeline that accepts up to six simultaneous video/audio input streams via TCP, performs compositing, and delivers the programme signal. voctocore creates a single static pipeline upon startup. By default, the internal video format is 8-bit YUV (I420, 4:2:0) at 1920 × 1080 pixels and 25 frames per second. This format was chosen as the native raw format that most GStreamer components and H.264 encoders can process without the need for intermediate color space conversions, thereby minimizing memory consumption for the infrastructure. Audio is processed as 16-bit linear PCM (S16LE) at 48 kHz stereo.

Figure 1. Voctomix 2.0 system architecture.

Data flow between modules uses GStreamer’s appsrc/appsink pairs, allowing each processing module to run as a standalone Python object without the need to rebind the processing chain at runtime. A NetTimeProvider element broadcasts a network clock over UDP port 9998, with which all camera capture containers are synchronized for presentation-time alignment.

Six logical source slots are defined: cam1–cam4 for live camera feeds, break for a pre-recorded loop, and intro for an opening video sequence. The default network plugin accepts a raw stream wrapped in a Matroska container from an upstream FFmpeg process, which decodes and remultiplexes each camera signal and the additional content. The video mixing module maintains two logical channels, A and B, updating the GStreamer compositor element on each source-switch command to perform sharp, clean cuts at buffer boundaries. There are four main compositing modes available (Figure 2): Fullscreen, Picture-in-Picture (PiP) (source B in a configurable corner), Side-by-Side (equal width split), and Lecture (75% of the image for source A, and 25% for source B).

Figure 2. Geometric layout of the main composite modes supported by the video mixing module.

3.2. Production-Grade Extension Layer

To raise the upstream engine to production standards, three capabilities were added on top of it:

• Blanking-Coupled Audio Control: The operator interface couples audio to the programme blanking state, muting the active source when the output enters PAUSE or NOSTREAM and restoring it on return to LIVE. While the output is blanked, a source cut deliberately changes video without altering audio, so no audio from the internal mix reaches air.
• Stream Blanking Control: The upstream blanker distributes the programme output across three paths using GStreamer compositor elements, LIVE (unmodified mix), PAUSE (still image or video loop with background audio), and NOSTREAM (silent black frame), independently of the internal mixing state. This work adds the operator-facing control that exposes these states in the interface and keeps the audio coupling described above consistent with the state on air.
• Dynamic Overlays: Lower-thirds graphics, annotations and logos are composited in real-time using the gdkpixbufoverlay and textoverlay elements. Fade transitions linearly animate the alpha property over 300 ms. The control protocol automatically applies a show_overlay false command before scene transitions to prevent graphics from inadvertently persisting between cuts.

3.3. Control Interface and Asynchronous Telemetry

The user interface, voctogui (Figure 3), is a GTK 3 desktop application that runs an asyncio event loop alongside the main GTK loop, with non-blocking TCP I/O. All mixer control is handled via a line-delimited ASCII protocol on TCP port 9999. When a command is executed, voctocore broadcasts a response event to all connected clients, ensuring that multiple instances of voctogui share a synchronized view of the mixer state without needing to restart the engine.

Figure 3. The voctogui operator interface. Camera content: Big Buck Bunny (© 2008, Blender Foundation), CC BY 3.0.

To address the observability shortcomings inherent in distributed media architectures [29], an asynchronous telemetry subsystem was implemented. A state exporter polls the voctogui widget tree and publishes structured JSON objects to a telemetry service, which in turn forwards them to a RabbitMQ AMQP exchange. CHANGE events are emitted immediately on any state transition to enable responses in less than a second, while STATE events act as periodic pulses, leveraging the AMQP publish/subscribe model for non-intrusive monitoring and automated session recording.

Each snapshot is a complete, timestamped record of the mixer, sampled once per second in the form of a nested JSON document; Table 3 summarizes its structure and the information provided by each field.

Table 3. Nested structure of the one-second JSON telemetry snapshot: top-level state objects, their fields, and the operational insight that monitoring each one provides.

State Object	Nested Fields	What Its Monitoring Provides
preview	channel_a, channel_b	Active sources on the A and B mixing buses
composite	name, fullscreen, pip, side_by_side, lecture	On-air layout selected at each instant
insertion	overlay, logo1, logo2, text1, text2	Active graphics and lower-thirds, and their current text
audio	cam1–cam4, break, intro (dB)	Per-source audio levels, confirming the blanking-coupled audio state
system_health	cpu, ram, ram_available	Host resource load correlated with the mixer state
mode, mirror	(scalar)	Programme output state (live, pause, no stream) and mirror flag
timestamp, gui_ip	(scalar)	Snapshot ordering and the originating interface

This machine-readable stream records what was on air at any given moment, keeps operators working in sync, and provides a non-intrusive foundation for auditing, session logging, and the dashboards described as future work. In the current implementation the state exporter runs embedded inside voctogui (Figure 1), so a graphical client instance must be connected to voctocore for telemetry to be produced; a fully unattended, GUI-less deployment does not currently emit telemetry. A native voctocore-side exporter that removes this dependency on the graphical client is left as future work. Note that the CPU and RAM figures reported in Section 4 are sampled directly from the host/proc interfaces on the mixing machine, independently of this telemetry path.

3.4. Container Networking and Standardized Topologies

A key challenge in containerized video production is managing uncompressed internal bandwidth. To enable compositing, an FFmpeg ingest process decodes incoming H.264 streams and forwards them to voctocore as raw I420 frames. Each 1080p25 stream carries a substantial data payload:

$$B={\displaystyle \frac{1920\times 1080\times 1.5\times 25}{{10}^6}}\approx 77.8\mathrm{MB}/\mathrm{s}\approx 622\mathrm{Mbps}.$$

Bandwidth varies linearly with the number of active sources. With four simultaneous sources, the aggregate internal traffic reaches approximately 2.49 Gbps. In the evaluated Docker topology, network_mode: service:voctocore places the ingestion and voctocore processes in a shared network namespace; in Kubernetes, the corresponding containers share a network namespace when running in the same Pod. Therefore, uncompressed internal flows remain within the host and do not traverse a physical network interface. The study did not include a bridged network control condition or a direct measurement of jitter, so it does not quantify the performance improvement attributable to this topology or establish jitter-free operation. The external transmission rate to the network continues to be determined by the compressed contribution sources.

3.5. Experimental Setup and Evaluation Criteria

To evaluate the performance, scalability, and resilience of the proposed architecture, a controlled benchmarking environment was set up on a dedicated high-performance workstation. Table 4 details the hardware and software specifications used.

Table 4. Test environment and software versions.

Component	Specification
CPU	Intel Core i9-10900X @ 3.70 GHz (10 cores/20 threads)
RAM	128 GB DDR4
Operating system	Ubuntu 22.04.5 LTS
Docker	Engine 29.1.3/Compose 2.37.1
Kubernetes	k3s v1.36.2 + k3s1, single-node/kubectl v1.36.0
Runtime	GStreamer 1.20/Python 3.10

To quantify the overhead introduced by the different virtualization layers, the pipeline was implemented and subjected to testing in three different scenarios (Figure 4):

Figure 4. Architectural and networking layout of the three evaluated deployment topologies: (top) Local native setup; (middle) Containerized microservice stack via Docker Compose; and (bottom) Orchestrated multi-container Pod deployment within a Kubernetes cluster.

1.

Local Native Deployment (Baseline): All components run as operating system processes on a single host, establishing the absolute performance baseline without the overhead of containers.

2.

Docker Compose Stack: The pipeline is modularized into a microservices stack of 11 containers, using the shared network namespace to route raw traffic through the local loopback interface.

3.

Orchestration with Kubernetes: The core mixing architecture is defined as a multi-container Pod (studio). The main and ingestion containers run as sidecars that share the network namespace, using the ConfigMap and PersistentVolumeClaim primitives required for distributed configuration and telemetry persistence. A single-node k3s cluster was deployed on the same workstation as the other two scenarios, so that the measured differences reflect the orchestration and virtualization overhead in isolation, without confounding effects from inter-node networking.

This multi-scenario approach directly highlights the structural flexibility of the proposed architecture. Unlike commercial software, which is limited to bare-metal Windows environments or monolithic desktop systems, this system scales from a local developer machine to a Kubernetes-orchestrated deployment without requiring any changes to the core codebase.

In addition to evaluating the three deployment scenarios, this study analyzes the system’s scalability with different video resolutions and frame rates. The broadcasting industry is undergoing a steady transition from High Definition (HD) to 4K Ultra-High Definition (UHD), driven by the demand for higher spatial resolution and greater temporal smoothness to deliver superior audiovisual quality to end-users. This evolution significantly increases the volume of uncompressed data that the mixing engine must process in real time. Consequently, to rigorously evaluate the performance and resource consumption of the proposed architecture in the face of these ever-increasing data requirements, the testing methodology was expanded beyond the 1080p25 reference format to include three additional high-bandwidth profiles: 1080p50, 2160p25 (4K), and 2160p50 (4K).

For each combination of deployment scenario and video format, three sets of metrics were collected:

• System Resource Utilization: CPU and RAM usage were periodically sampled from the operating system’s /proc interfaces (the same source used by standard tools such as htop), so the reported values reflect the whole-host load during each run.
• Switching and Transition Latency: Latency was measured on the mixed video output itself, detecting the frame in which the switch becomes visible in the programme signal, rather than at the control-protocol layer. This is an internal command-to-output latency of the mixer and does not include camera capture or wide-area network transport, so it is not an end-to-end REMI figure. Both direct camera cuts and composite-layout changes were characterized over 100 repetitions each.
• Failover Resilience: The FFmpeg ingest process of the active camera was terminated with a SIGKILL (kill-9), rotating across all four sources, to simulate an ungraceful dropout. The Mean Time To Repair (MTTR) was measured on the programme output as a detection phase, until the missing source is signalled at its input pad, followed by a recovery phase, until a live signal from the restarted source is restored. Output continuity during this window was maintained by the stream blanker. Each failure was injected 100 times per configuration.

4. Results

4.1. System Resource Utilization

To evaluate the computational consumption of the mixing architecture, systematic samples of CPU and RAM usage were collected across the three deployment environments and the four video formats. The data reflect the total host load during each execution.

Figure 5 reports the median CPU utilization as cameras are activated sequentially. The CPU load increases steadily with both the number of active sources and the resolution and frame rate of the video format. An idle 1080p25 pipeline uses approximately 30% of the CPU, while an idle 2160p50 (4K) pipeline already consumes nearly 50% of the host’s capacity before any camera signals are composited. With four simultaneous 1080p25 sources, the median CPU load reaches nearly 90% in the local and Docker deployments (89.6% [IQR 84.0–94.3%] and 89.1% [IQR 84.1–94.1%], respectively), while Kubernetes deployments show slightly lower utilization (81.5% [IQR 76.3–87.5%]). In all scenarios, the load approaches but does not exceed the capacity of the ten-core host. The three deployment tiers remain very close to one another across all operating points. The Kubernetes median falls below the native baseline, which is not physically expected of an added orchestration layer; given that the interquartile ranges of the three tiers overlap and the host operates close to saturation at this point, this difference should be attributed to measurement variance rather than read as evidence that orchestration reduces computational load.

Figure 5. CPU utilization scaling as a function of the number of currently active cameras for various video resolutions and execution environments.

Figure 6 illustrates the corresponding memory consumption in absolute terms. RAM usage increases linearly with the number of sources and rises sharply with spatial resolution, since each 4K frame buffer is four times larger than its 1080p equivalent. At 1080p25, the memory usage across the three environments remains very close, ranging from 12 to 14 GB, with four active sources. The most significant divergence occurs in the Docker Compose deployment at 4K resolution, where the memory consumption escalates to approximately 23 GB with four sources. This peak is well above both local and Kubernetes memory consumption for the same format, which is consistent with the additional buffering per container required by the stack of eleven services under extreme pixel performance.

Figure 6. RAM usage scaling as a function of the number of currently active cameras for various video resolutions and execution environments.

Figure 7 details the long-term operational stability and resource utilization at the server level during a continuous 24 h stress test in which the 1080p25 profile was run with four active sources in the local environment. CPU usage remained high and stable throughout the entire test, recording a median of 88.5%. At the same time, RAM utilization showed a stable pattern, maintaining an hourly median of 10.4% (approximately 13 GB) with a variation of no more than 0.2 percentage points throughout the entire 24 h period. This stable curve indicates the absence of memory leaks in this specific configuration under sustained load.

Figure 7. Long-term operational stability and resource consumption during a 24 h sustained load test on a local environment.

To confirm that the reported utilization corresponds to useful work rather than to a pipeline shedding load, output integrity was measured at the programme sink. As Table 5 shows, every deployment tier and video profile delivered the full expected frame count at the nominal output rate, with a drop rate of 0.00%, reproduced across two independent campaigns.

Table 5. Output integrity at the programme sink with four active sources: frames delivered against the nominal count over 60 s windows, three repetitions per cell across two independent campaigns.

Video Profile	Frames Delivered/Expected	Drop Rate (%)	Output Rate (fps)
1080p25	1500/1500	0.00	25.0
1080p50	3000/3000	0.00	50.0
2160p25	1500/1500	0.00	25.0
2160p50	3000/3000	0.00	50.0

Identical results were obtained in the local, Docker and Kubernetes tiers, for 72 measurements in total.

Frame cadence alone does not prove that new content is being processed, since a starved compositor sustains the nominal rate by repeating its last frame. Each capture was therefore also analysed for duplicate frames. At 1080p25 the output is frame-fresh, with a median of 22 distinct frames per second; the shortfall from 25 corresponds to brief repetitions when the looping test clips restart, an artefact of the synthetic source that would not occur with live cameras. At the higher profiles distinct frames fall to a median of 1.5 per second at 1080p50 and below one at 2160p50. Replacing the simulated cameras with pre-rendered raw frames restored full freshness at 1080p50 and 2160p25, which places the limitation there in the four concurrent 4K decodes performed by the test harness rather than in the mixer; at 2160p50 the ceiling persists and belongs to the host. The figures for profiles above 1080p25 therefore characterise the complete test configuration, ingest included, rather than the mixer at full content load. This also explains the Kubernetes reading above: a pipeline that repeats frames performs less work, so utilization falls as nominal load rises.

4.2. Switching and Transition Latency Analysis

The latency metrics were obtained directly from the mixed video output, rather than through the control protocol layer. The values shown reflect the delay between the command and the output: the time elapsed from the operator sends a command until the requested visual change appears in the program signal. This metric is inherently limited by the pipeline’s frame period and internal buffering.

Figure 8 presents the latency distribution for camera cuts in each format environment. At 1080p25, the median latency is close to 300 ms in all three environments, with tight dispersion in each: 293 ms (IQR 291–294 ms) in Docker, 293 ms (IQR 292–294 ms) in Kubernetes, and 330 ms (IQR 294–331 ms) in the local deployment. When the frame rate is doubled to 1080p50, the median latency is effectively halved, down to about 190 ms. The transition to 2160p25 yields a median in the same 250–300 ms range, confirming that latency from command to output is primarily determined by the frame rate rather than spatial resolution. The 2160p50 profile, however, is an exception; although the median remains low, the distribution widens significantly, exhibiting tail latencies of up to 800 ms. In this extreme format the pipeline approaches saturation, and although it sustains the nominal output frame rate, the timing of individual switches becomes less predictable.

Figure 8. Camera switching latency distributions across different video formats and execution environments with median value in red.

Figure 9 replicates this analysis for compound layout changes, such as the transition from a source layout to a Picture-in-Picture layout. The observed behavior is similar to that of direct camera cuts: the medians remain close to 300 ms at 25 fps and 195 ms at 50 fps, staying stable and consistent across all the three environments for all formats except for 2160p50. With the 2160p50 workload, latency variation increases significantly, and the Docker deployment generates the longest queue, exceeding one second in the most severe cases.

Figure 9. Layout transition and composition latency distributions across video formats and deployment scenarios with median value in red.

4.3. System Resilience and Self-Healing

System resilience was quantified by forcibly interrupting the active camera process and measuring the MTTR upon program output signal. This MTTR value is subdivided into a detection phase (time elapsed until the blocked source is identified) and a recovery phase (time elapsed until the live signal is restored). During each fault injected in the 100 repetitions per configuration, the stream blanker maintained a valid live program signal using the remaining active sources.

Figure 10 breaks down the MTTR into its detection and recovery components. A structural trade-off can be observed between the two phases: higher resolutions are detected far more quickly, going from approximately 790 ms at 1080p25 to tens of milliseconds at 4K in local and Docker environments, while recovery times are longest at the 4K profiles, reaching roughly 1500 to 1800 ms. For the 1080p25 baseline format, the total recovery time is approximately 1.8 s in both local and Docker deployments (1797 ms, IQR 1796–1797 ms, and 1794 ms, IQR 1757–1797 ms, respectively), while Kubernetes is both slower and more dispersed at this format (2078 ms, IQR 2037–2607 ms). The total MTTR is not monotonic in bitrate, which follows from the two-phase structure of the metric. Detection time decreases markedly as bitrate increases, since a source failure is signalled by an end-of-stream event on the GStreamer bus once the already-buffered data drains, rather than by a fixed wall-clock timeout, so higher-bitrate streams cross this threshold sooner. Recovery time does not follow the same trend: it stays comparable between 1080p25 and 1080p50, then rises substantially at the 4K profiles, where re-establishing the larger decoded buffer state is more costly. MTTR therefore falls at 1080p50, dominated by the drop in detection time, and rises again at 4K, dominated by the rise in recovery time. The component restarted differs per tier: Docker Compose restarts the container via its restart policy; Kubernetes restarts it through the kubelet’s observation cycle, which also explains the greater variability seen in that environment; the native deployment has no orchestrator, so the equivalent restart (a supervisor relaunching the terminated ingest process, akin to a systemd Restart=always unit) was reproduced by the test harness for this benchmark rather than being a standing component of the deployment. One limitation of the measurement should be noted: detection is observed on the programme image, so its temporal resolution is bounded by the rate at which that image changes. At 1080p25, this is a few tens of milliseconds and is negligible against recovery times of approximately 1.8 s. At the higher profiles, where distinct frames arrive around once per second, the quantisation is of the same order as the values being measured, and the recovery times reported for those profiles should therefore be read as approximate.

Figure 10. System resilience breakdown evaluating failure detection and recovery times across video formats and deployment scenarios.

Figure 11 displays the distribution of the total MTTR. The local and Docker deployments maintain tight and highly repeatable recovery distributions across all formats. In contrast, Kubernetes exhibits greater dispersion with occasional long tails, reflecting the additional scheduling and pod lifecycle operations inherent to its self-healing mechanisms. Despite this variation, the median total recovery time remains consistently within the one-to-two-second range across all three environments.

Figure 11. Total Mean Time to Repair (MTTR) distributions grouped by video format across scenarios.

Finally, Figure 12 presents the mean MTTR cross-referenced by failing channel and video format. At 1080p25, recovery times are remarkably consistent, regardless of which specific camera feed is interrupted. In higher bandwidth profiles, the averages per channel show greater variation, which is consistent with the larger overall dispersion observed at these resolutions. Nonetheless, automatic recovery was successfully completed on all four channels across all formats, and the 1080p50 profile registered the fastest overall recovery times, indicating that no specific channel acts as an architectural bottleneck during the self-healing process.

Figure 12. Heatmap of Mean Time to Repair (MTTR, in ms), averaged across the three deployments, categorized by targeted stream failure (cam1–cam4) and video format profiles.

5. Discussion

The empirical results demonstrate that a fully software-defined, container-based live production workflow can successfully orchestrate a multi-camera broadcast on standard hardware without introducing unacceptable performance penalties resulting from virtualization. This corroborates the central hypothesis of this work: modern cloud-native architectures can replace purpose-built hardware in live video compositing while maintaining operational stability.

In a realistic workload with four 1080p25 cameras, the process used nearly 90% of a ten-core processor and consumed approximately 13 GB of RAM. The RAM footprint is not governed by the latency-critical buffer depth: at approximately 3.1 MB per uncompressed 1080p25 frame, even a generous few-frame buffer per source accounts for well under 1 GB in aggregate, two orders of magnitude below the observed 13 GB. The steady-state resident set is instead dominated by process- and pipeline-level overhead, including the per-source JPEG preview pipelines, the FFmpeg decode processes, and the baseline footprint of GStreamer, Python, and (in Docker) the container runtime. This working set is bounded rather than growing, as confirmed by the flat 24 h memory profile. It is crucial to note that the resource consumption of the single node Docker Compose and Kubernetes environments closely matched the baseline value of the physical server. This finding is significant for the broadcasting industry, as it shows that, in this single-node deployment, containerizing the mixing engine and integrating it into an orchestrator does not impose a noticeable processing overhead on the host; multi-node scaling, where inter-node networking and scheduling come into play, is left for future validation. Consequently, the benefits of containerization, including portability, rapid deployment and reproducibility, can be achieved without sacrificing raw computational performance.

In terms of responsiveness, the latency between the command and the output had a median of 293 ms at 1080p25, dropping to roughly half that approximately 190 ms at 50 fps. This confirms that the transition delay is primarily limited by the frame period rather than by spatial resolution. Although this measurement strictly reflects the mixer’s internal delay, rather than the total end-to-end latency, its magnitude falls well within the sub-second tolerance required by modern IP-based REMI models. Performance degraded noticeably only in the highly demanding 2160p50 profile, indicating the maximum processing limit of a single standard host rather than a structural flaw in the software architecture.

From an operational standpoint, the system’s automated self-healing capabilities represent a major breakthrough for unattended or minimally staffed productions. Following the sudden failure of an active camera feed, the architecture successfully restored the signal in approximately 1.8 s using the 1080p25 profile. More importantly, the integration of the stream blanker module ensured that the program broadcast remained live and valid by utilizing feeds that remained operational during this recovery interval. This transforms what would traditionally be a broadcast interruption into an automated and manageable failover event. Combined with the stability demonstrated during 24 h continuous operation without memory degradation, the system proves to be well-suited for the academic, small-scale, and remote production environments targeted by this research.

When observed in the context of the current state of the art (as summarized in Section 2), Voctomix 2.0 does not aim to surpass mature, monolithic applications such as OBS Studio or vMix in terms of the sheer number of features. Instead, it addresses a specific architectural shortcoming. By providing a workflow that is natively containerized and multi-operator, equipped with a machine-readable control API and asynchronous AMQP telemetry, it enables the orchestration of live video mixing using the same DevOps methodologies currently applied to standard web microservices.

Despite these promising results, several limitations of the experimental design must be taken into account. First, all benchmark scenarios were run on a single physical workstation, meaning that the Kubernetes deployment used a single-node k3s cluster. While this effectively isolates virtualization overhead, it does not evaluate network constraints, internal bandwidth routing between nodes, or the scheduling latencies inherent in a fully distributed, multi-node cloud cluster. Second, latency measurement is limited to the path from the command to the output; a comprehensive screen-to-screen measurement that incorporates camera capture, wide-area network transmission (e.g., via SRT or RIST), and end-user display is still necessary to fully characterize the user experience.

Finally, a single controlled measurement against OBS Studio was additionally carried out on the same workstation to move part of this comparison onto an empirical footing (Table 6); vMix was excluded because its Windows-only, GUI-driven design precludes the same scripted, single-pass measurement.

Table 6. RAM usage (128 GB total) of Voctomix 2.0 and OBS Studio 27.2.3 under a comparable workload on the same workstation (OBS software-encoded via x264).

Active Sources	Voctomix 2.0 RAM (GB)	OBS Studio RAM (GB)
0 (idle)	9.22	7.55
1	10.11	7.94
2	11.01	8.32
3	11.78	8.45
4	12.80	8.83

The workload was designed to resemble Voctomix 2.0’s own resource-footprint test: the same 1080p25 source material, zero to four concurrently active sources, and whole-host CPU and RAM sampled. OBS Studio 27.2.3 was used, the stable release packaged for the Ubuntu 22.04 test environment. OBS Studio 27.2.3, the stable release packaged for the Ubuntu 22.04 test environment, was configured to encode exclusively with the software x264 encoder, never NVENC, and to record continuously in every phase, including idle, so that its measured cost reflects genuine delivery-ready operation.

A direct CPU comparison between the two systems is not reported, because it would primarily reflect two architectural differences rather than a difference in implementation efficiency. First, OBS composites video on the GPU via OpenGL, whereas Voctomix’s compositor executes entirely on the CPU by design, keeping the mixing core deployable on GPU-less, horizontally orchestrated containers. Second, the measured Voctomix pipeline never performs a full-resolution delivery encode, muxing and transmitting raw frames, consistent with a microservice philosophy that decouples compositing from encoding; OBS, having no equivalent raw-passthrough mode, always pays the cost of a full 1920 × 1080 software H.264 encode. RAM usage is far less affected by these two factors and is therefore fairer to compare directly: as shown in Table 6, Voctomix consumes roughly 2–4 GB more than OBS across all camera counts, consistent with holding uncompressed frame buffers for a larger number of concurrent raw streams. Taken together, these results should be read not as a verdict on raw computational efficiency, but as a quantification of the trade-off this paper argues for: a lighter, GPU-independent, and horizontally orchestrable compositing core, obtained in exchange for a higher, but predictable, CPU cost.

The telemetry subsystem is presented as an architectural contribution; its event-delivery latency, message loss, and runtime overhead were not measured and are left for future evaluation.

The current implementation also assumes a trusted network: the TCP control channel, the telemetry HTTP endpoint, and the RabbitMQ broker carry no encryption or client authentication, so any host with network reachability could issue mixer commands or read state. Remote production therefore requires confining these services to a trusted segment, a VPN, or Kubernetes NetworkPolicies, and placing them behind a TLS reverse proxy with authenticated broker credentials. Native token-based authentication and TLS in the control protocol are left for future work.

6. Conclusions

6.1. Summary of Main Findings

This study has demonstrated that a cloud-native, software-defined architecture can effectively address the operational and financial limitations of traditional live video production. By designing a production-level extension layer on top of the open-source Voctomix 2.0 engine, this research has successfully integrated dynamic multi-layer overlays, operator-level blanking control with coupled audio muting, and a decoupled telemetry exporter. These additions demonstrate that advanced broadcast capabilities can be decoupled from proprietary hardware and orchestrated as microservices without compromising workflow stability.

The empirical evaluation validated the feasibility of this architecture in local, Docker Compose, and Kubernetes environments. Under a continuous workload of four 1080p25 streams, the containerized deployments handled the processing demands with CPU consumption comparable to that of the local environment (a median of nearly 90% on a 10-core host), confirming that virtualization and orchestration do not introduce a noticeable processing overhead in a single-host deployment. Responsiveness remained within professional tolerance limits, with a median internal command-to-output latency of approximately 293 ms at 25 fps, a mixer-internal figure that excludes camera capture and network transport. Furthermore, the system demonstrated robust self-healing capabilities; when faced with a forced camera failure, it autonomously recovered the signal in approximately 1.8 s, while the stream blanker module successfully maintained a valid live program output without human operator intervention.

6.2. Future Work

While the current implementation establishes a solid foundation for orchestrated production on a single node, future research should evaluate scaling across multi-node clusters and the limitations of wide-area networks. Building on the enhanced open-source architecture presented in this study, several promising avenues for future work emerge:

• Native integration of the SRT transport layer: The development of direct GStreamer plugins for SRT will enable the mixing engine to securely connect to public Content Delivery Networks (CDNs) and cloud endpoints, circumventing the limitations of uncompressed local TCP networks.
• Native Web Control Panel: Migrating the operator interface from a GTK 3 desktop application to a lightweight, browser-based web GUI will eliminate dependencies on the display server. This will allow operators to securely manage remote live mixes from any standard thin client or connected device.
• Advanced Observability Dashboards: Using RabbitMQ’s existing asynchronous AMQP telemetry stream, future versions will be able to send real-time performance metrics to a Prometheus time-series database. This will enable comprehensive monitoring through Grafana dashboards without placing an additional computational load on the mixing core.
• AI-Based Transcription Overlays: The decoupled, event-driven architecture can be scaled by routing the isolated program audio to a separate automatic speech recognition engine, feeding the transcribed text back as automated caption commands. Because such captions would be inserted unattended, the principal operational risk is not recognition latency but the insertion of fluent yet factually incorrect text into the live programme. Any such extension should therefore be paired with a confidence-gated insertion policy, so that the overlay module suppresses low-confidence segments rather than rendering them on air.