/

Red5 Product Glossary


Broadcaster - The source of a live data stream, usually a camera and microphone with an internet browser or smartphone. The term broadcaster encompasses the user, network session, or function of stream generation.

Cauldron - Real-time stream processor. Cauldron is written in native code enabling fast encoding/decoding of video and audio streams. Cauldron supports "brews" which allow developers to write custom code that intercepts the stream after the decoding process to manipulate it as they see fit before it is then reencoded and pushed through to be streamed. A Cauldron node is also called a transcoder node. As one of its typical use cases, Cauldron handles generating multiple bitrates streams for use in adaptive bitrate.

  • Brew - A module of native code (written in C or C++) loaded into Cauldron to be executed for specific functionality. Examples: Live face detection that puts a mask around the face; splitting streams into multiple bitrates for transcoding.

Cluster - A set of multiple active servers which make real-time data streams available for consumption. Typically streams consist of audio or video data, and clusters of servers are used to handle more connections/streams than a single server could do on its own.

  • Origin (cluster role) - An Origin accepts publishers (or encoders). In a non-autoscaling cluster application, origins can also be configured to accept subscribers. The server can be in a hybrid mode where it repeats streams from another origin. A stand-alone server is an origin and an edge all in one.
  • Edge (cluster role) - An Edge delivers streams to subscribers who want to view/listen to the streams. An Edge is required to have at least one origin in which to repeat content. Edge nodes can be configured to communicate with more than one Origin.

Clustering - Clustering is how we configure interconnected server nodes to be edges, origins, relays, and transcoders in order to distribute real-time video, audio, and data to all receiving (Subscriber) clients.

HTML5 SDK - Integrates live streaming video into your desktop and mobile browser. By default, uses WebRTC where possible and falls back to RTMP/Flash and HLS as needed. The HTML5 SDK abstracts much of the complexity of building a live streaming app from scratch.

Mobile Streaming SDK - Integrates live streaming video into your native app. Uses RTSP as the protocol and features a low latency (real-time) player and broadcaster. The Mobile SDK abstracts much of the complexity of building a live streaming app from scratch.

Publisher - Senders of the broadcast, also known as the ingest client.

Publisher Buffer Time - A setting in the Red5 Pro Mobile SDK that allows you to set how long you want to hold on to the packets in the queue. The larger the value, the more time it will keep them around, and the lower the value, the less time it will keep them around.

Red5 - Open-source media server for live streaming solutions that our team started in 2005. It was the first implementation of an RTMP server other than the Flash Communication Server owned by Adobe.

Red5 Pro - Proprietary software built on top of the open-source Red5. It features support for WebRTC streaming, mobile SDKs, and Stream Manager which allows for automatic (autoscale) large-scale, real-time (less than 500 ms) live streaming on cloud networks.

Server Node - A server instance that is part of an active cluster.

Stream Manager - Red5 Pro's streaming architecture management and information service that helps to automate the process of creating and deleting Red5 Pro server instances. Stream Manager also coordinates between broadcasters and subscribers to help find the right server nodes for their broadcast and subscribe actions respectively.

Stream Provisioning - Refers to the setup of a stream by a broadcaster client via the Stream Manager using its API.

Subscriber - Everyone receiving the messages sent by publishers. Also known as the egress client.

Subscriber Buffer Time - A setting in the Red5 Pro Mobile SDK that allows you to set the amount of time you allow video packets to build up on the server-side before delivering to the client. In the case of receiving video, the higher the buffer_time the more you allow for backup in network congestion. The lower the number, the less time you allow for this queued video to get through.

WebRTC Failover - When publishing or subscribing with a WebRTC application, a platform that does not support WebRTC will attempt to failover to HLS.