Media Server

Streaming

Streaming is built around one-to-many delivery. A publisher sends a stream to WCS, where it can be repackaged, transcoded, or processed as needed. The server then distributes it to viewers over WebRTC, RTMP, RTSP, HLS, and other supported protocols.

Streams are typically long-running. Viewers can join and leave at any time without interrupting the broadcast or affecting other viewers.

The main challenge is scale: one stream, potentially thousands of viewers. WCS is optimized to distribute media efficiently to large audiences.

This architecture is ideal for live broadcasts, video surveillance, video blogs, live gaming, and online events.

SFU

SFU (Selective Forwarding Unit) is built for many-to-many, real-time communication — video conferences, online meetings, and interactive rooms.

Unlike long-running broadcasts, conferences typically consist of shorter, highly dynamic sessions. Participants join and leave, mute and unmute their microphones, turn cameras on and off, and share their screens — often simultaneously.

These changes must be reflected across the room immediately, so everyone stays in sync.

The architectural challenge is different from Streaming. Instead of distributing one stream to a large audience (1 × N), an SFU manages media distribution among multiple participants, where each participant may send streams to and receive streams from many others (K × K).

WCS SFU is optimized for this dynamic, interactive workload, using selective forwarding to deliver the right media streams to the right participants with minimal latency.

Mixing

If Streaming is about delivering one stream to many viewers (1:N), Mixing does the opposite: it combines multiple incoming streams into a single output (N:1).

WCS decodes the incoming video streams, arranges them on a shared canvas — for example, in a grid — and encodes the resulting composition into a single H.264 video stream.

The viewer receives just one video stream, with all participants displayed together in a single frame.

But there’s a cost. Mixing is resource-intensive: decoding multiple streams, compositing video frames, and encoding the result require significant CPU or GPU processing power and memory.

You’re spending server resources to produce just one stream. Why?

Because sometimes one stream is exactly what you need.

Mixing is particularly useful when the receiving device or player cannot handle multiple simultaneous video streams or display separate video tracks — for example, a conventional HLS player.

Instead of assembling the layout on the client, WCS does the heavy lifting on the server and delivers a single, ready-to-play video stream.

SIP

SIP integration deserves special attention. WCS can communicate with external PBX systems and SIP conference servers, bridging traditional telephony and browser-based real-time communication.

A typical use case is a one-to-one call between a browser-based phone and a remote SIP device, including mobile or landline phones connected through a PBX.

SIP also opens up scenarios that combine telephony and streaming. For example, WCS can establish a SIP session with a remote device, receive its RTP media stream, and deliver that media to viewers over WebRTC or RTMP.

This allows SIP-based communication systems to become part of a modern streaming infrastructure.