Skip to main content
Live streaming involves a wide vocabulary spanning server architecture, networking protocols, media codecs, and encoder tooling. This glossary covers the terms you will encounter most often when building, deploying, and troubleshooting with Red5 Pro — organized by category so you can find what you need quickly.

​
Red5 product terms

Open-source media server for live streaming solutions, first built in 2005. Red5 was the first implementation of an RTMP server outside of Adobe’s Flash Communication Server.
A managed service built on Red5 Pro that provides autoscaling, clustering, and stream management. Red5 Cloud lets you deploy and manage Red5 Pro servers across multiple regions without operating the underlying infrastructure yourself.
Proprietary software built on top of the open-source Red5 platform. Red5 Pro adds WebRTC streaming support, mobile SDKs, and Stream Manager — enabling automatic, large-scale, real-time (sub-500 ms) live streaming on cloud networks.
A set of multiple active servers that make real-time data streams available for consumption. Clusters handle more concurrent connections and streams than a single server can sustain on its own.
A server node that accepts streams from publishers (encoders). In non-autoscaling deployments, an Origin can also be configured to serve subscribers directly. A standalone server acts as both an Origin and an Edge simultaneously.
A server node that delivers streams to subscribers. An Edge requires at least one Origin to source content from, and it can be configured to communicate with more than one Origin for redundancy.
An intermediary node that connects an Origin to an Edge when a direct connection is impractical due to distance or network constraints. Relays allow a cluster to scale stream delivery to tens of millions of subscribers.
Red5 Pro’s streaming architecture management and orchestration service. Stream Manager automates creating and removing server instances, coordinates publishers and subscribers to the right nodes, and manages autoscaling operations through a cloud provider’s APIs via a Cloud Controller.
The process by which a broadcaster client configures a stream through the Stream Manager API before publishing begins.
The client that sends a live stream to the server — also called the ingest client or encoder. Publishers initiate the broadcast that subscribers later receive.
The client that receives a live stream from the server — also called the egress client or viewer. Subscribers consume the broadcast that a publisher originates.
An autoscaling nodegroup is a cluster of any number of Origin, Edge, Relay, and Transcoder nodes. Nodegroups are created based on a scale policy and a launch configuration, and Stream Manager manages them dynamically.
A cluster node that runs Red5 Pro’s Cauldron transcoding engine. The Transcoder node converts an incoming stream into multiple resolutions and bitrates, then pushes the output to an Origin for distribution.
A cluster node that runs Cauldron for real-time stream mixing. The Mixer node combines multiple video and audio sources into a single output stream, then pushes it to an Origin.
Integrates live streaming into desktop and mobile browsers. Uses WebRTC where the browser supports it, with fallback to RTMP and HLS. The HTML5 SDK abstracts the complexity of building a live streaming app from scratch.
Integrates live streaming into native iOS and Android applications. Uses RTSP as the transport protocol and provides a low-latency broadcaster and player. The Mobile SDK abstracts the complexity of building a live streaming app from scratch.
A Red5 Pro Mobile SDK setting that controls how long the SDK holds packets in the send queue. A larger value increases tolerance for brief network hiccups; a smaller value reduces buffering.
A Red5 Pro Mobile SDK setting that controls how many video packets are allowed to queue server-side before delivery to the client. A higher buffer time tolerates more network congestion; a lower value reduces playback latency.
A single server instance that is part of an active cluster. Each server node has an assigned role — Origin, Edge, Relay, Transcoder, or Mixer.

​
Protocols

A universal, plugin-free browser-based communication standard that adds real-time communication (RTC) capabilities to browsers via JavaScript APIs. WebRTC is the primary protocol Red5 Pro uses to achieve sub-500 ms end-to-end latency.
A TCP-based protocol for streaming audio, video, and data over the internet. Originally developed by Macromedia for the Flash Player, RTMP remains the most common ingest protocol today. Professional encoders, OBS, and FFmpeg all support RTMP publishing to Red5 Pro.
RTMP transported over a TLS/SSL connection. Use RTMPS when your encoder requires an encrypted ingest path.
RTMP encapsulated within HTTP requests to traverse firewalls. RTMPT sends traffic over TCP ports 80 and 443, allowing the stream to pass through most corporate firewalls. The tunneled session can carry plain RTMP, RTMPS, or RTMPE packets.
RTMP transported over UDP instead of TCP. RTMFP is technically a peer-to-peer protocol that the Adobe Flash Player could use for direct client-to-client communication.
A network control protocol designed to establish and control media sessions between endpoints. The media payload is typically carried over RTP or SRTP. The Red5 Pro Mobile SDK uses RTSP for low-latency publishing and playback.
A media streaming protocol created by Apple that works by breaking a continuous stream into a sequence of small HTTP-based file segments (chunks). HLS is widely supported and is used by Red5 Pro as a fallback delivery format.
An open-source video transport protocol that optimizes streaming performance across unpredictable networks. SRT provides secure streams and easy firewall traversal, and it is supported in the Red5 Pro Mobile SDK.
A signaling protocol that standardizes how a WebRTC publisher connects to a streaming server over HTTP. Red5 Pro uses WHIP for WebRTC ingest, making it straightforward to publish from browsers and encoders that support WHIP natively.
A signaling protocol that standardizes how a WebRTC subscriber connects to a streaming server over HTTP. Red5 Pro uses WHEP for WebRTC playback delivery to viewers.
A protocol for delivering audio and video over IP networks. RTP is used extensively in streaming media and forms the media-plane transport underneath RTSP sessions.
An encrypted version of RTP. WebRTC mandates SRTP for all media transport, sending and receiving encrypted video and audio between peers.
A text-based format for describing the parameters of a streaming media session — codecs, transport addresses, and timing. WebRTC uses SDP to negotiate capabilities between a publisher and a server during the offer/answer exchange.

​
Codecs

A widely used block-oriented, motion-compensation video compression codec. H.264 delivers good video quality at substantially lower bitrates than older standards and is compatible with virtually every streaming protocol, device, and browser. Red5 Pro uses H.264 for video in WebRTC, RTMP, and RTSP streams.
The successor to H.264, offering roughly 40–50% better compression at the same visual quality. H.265 reduces bandwidth requirements for high-resolution streams but requires more processing power to encode and decode.
A block-based transform coding video format developed by Google. VP8 is very similar in approach to H.264 and is one of the video codecs supported in WebRTC streams through Red5 Pro.
A lossy digital audio compression standard designed as the successor to MP3. AAC generally achieves better sound quality than MP3 at the same bitrate. Red5 Pro uses AAC for audio in RTMP and RTSP streams.
A lossy audio codec designed for efficient coding of both speech and general audio in a single format. Opus is low-latency enough for real-time interactive communication and is the audio codec used in WebRTC streams through Red5 Pro.
A widely supported lossy digital audio coding format. MP3 is supported as an audio codec for RTMP ingest in Red5 Pro alongside AAC.
A free, open-source lossy audio codec specifically tuned for human speech, often used in VoIP applications. Speex prioritizes low-bitrate speech reproduction over general audio quality.

​
Codec-to-protocol reference

ProtocolVideo codecsAudio codecs
WebRTCH.264, VP8Opus
RTMPH.264AAC, MP3
RTSPH.264AAC

​
General networking and web technologies

A distributed network of servers that caches and delivers content from locations close to end users. Most CDNs operate over HTTP. Red5 Pro can integrate with CDNs for large-scale HLS delivery, though real-time WebRTC streams require a different approach.
The total amount of data that can be transferred or processed in a given time period — typically measured per second. Both bandwidth and bitrate are expressed in kilobits per second (kbps) or megabits per second (Mbps).
The number of bits transferred from one point to another per second. Higher bitrates generally mean better video or audio quality, but require more bandwidth. Measured in kbps or Mbps.
The delay between an event being captured and it being seen or heard by a viewer. End-to-end latency is the time from camera capture at the publisher to playback at the subscriber. Red5 Pro WebRTC streaming targets sub-500 ms end-to-end latency.
A method of remapping one IP address space to another by modifying IP header information in packets as they pass through a router. NAT traversal (also called “hole punching”) is required to establish peer-to-peer connections in WebRTC when devices sit behind firewalls or private networks.
A protocol that describes how to coordinate STUN and TURN servers to establish a connection between two hosts. WebRTC relies on ICE to negotiate the best available network path between a publisher and the Red5 Pro server.
A protocol a host uses to discover its public IP address when it is behind a NAT or firewall. The discovered address is then shared as a candidate connection point during WebRTC negotiation. Red5 Pro examples use Google’s public STUN servers; for production, you should run your own (CoTurn is a popular choice that supports both STUN and TURN).
A relay server that forwards WebRTC media between two peers when a direct connection via STUN fails — for example, when both peers are behind symmetric NATs. TURN is a fallback and introduces slightly higher latency than a direct connection.
A variant of TLS adapted to work over UDP. WebRTC uses DTLS to exchange the symmetric encryption keys that protect media streams. DTLS ensures that the key exchange itself is secure before any media flows.
A full-duplex communication protocol over a single TCP connection. Unlike HTTP, WebSocket keeps the connection open, allowing the server and client to exchange messages in real time. Red5 Pro uses WebSocket for signaling in WebRTC sessions.
An interface that allows software components to interact with each other. Red5 Pro and Stream Manager expose REST APIs for managing streams, nodes, and autoscaling operations programmatically.
A hierarchical, decentralized naming system that maps human-readable domain names to IP addresses. Correct DNS configuration is required for SSL certificates and for routing publishers and subscribers to the right Red5 Pro server.
A browser security standard that restricts web pages from making requests to a different domain than the one that served them. Red5 Pro’s server and Stream Manager APIs include CORS configuration options so your web application can communicate with them from a different origin.
A connection-oriented protocol that guarantees delivery and ordering of packets. TCP is used for RTMP, RTSP signaling, HLS, and WebSocket connections. It is easier to pass through corporate firewalls than UDP but adds latency overhead from retransmission.
A connectionless protocol that sends packets without guaranteed delivery or ordering. UDP is required for the low-latency media transport in WebRTC (via SRTP over UDP). The Red5 Pro server uses UDP ports 40000–65535 for WebRTC ICE, STUN, and TURN traffic.
A cryptographic protocol that provides encrypted communication over TCP. Red5 Pro requires TLS (HTTPS and WSS) for all WebRTC sessions because browsers will not grant camera or microphone access over plain HTTP.
The predecessor to TLS. The term “SSL certificate” is still commonly used in practice, but modern deployments use TLS. Red5 Pro’s SSL configuration guide covers installing TLS certificates for HTTPS and secure WebSocket connections.
A set of tools, libraries, and documentation for developing software targeting a specific platform. Red5 Pro provides an HTML5 SDK, an iOS SDK, and an Android SDK for integrating live streaming into your applications.
The process of decoding an already-compressed media stream and re-encoding it into a different format, resolution, or bitrate. Red5 Pro Transcoder nodes perform transcoding to produce multiple quality tiers for adaptive bitrate (ABR) playback.
A category of protocols and hardware that provide real-time communication guarantees. In the context of Red5 Pro, RTC is most commonly used as shorthand for WebRTC.
In standard use, a browser-based application. In the context of Red5 Pro and Java EE / Tomcat, a webapp refers to a Java-based server-side application deployed to the Red5 Pro server. You can write custom server-side logic as a Red5 Pro webapp.

​
Encoder software

A free, open-source suite for recording and live streaming on Windows, macOS, and Linux. OBS supports RTMP and SRT publishing directly to Red5 Pro and uses FFmpeg internally for media processing.
A comprehensive open-source suite of libraries and command-line tools for handling video, audio, and multimedia streams. FFmpeg is commonly used for transcoding, re-streaming, and testing Red5 Pro ingest. OBS uses FFmpeg internally, and many automation workflows call FFmpeg directly.
# Example: Publish a test stream to Red5 Pro via RTMP using FFmpeg
ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv rtmp://your-server/live/streamName

​
Streaming issues

These terms describe common problems you may encounter during live streaming. Knowing the precise term helps you communicate accurately when troubleshooting with the Red5 Pro support team.
Audio pausing or cutting out for under 2 seconds. Often caused by network congestion, insufficient upload bandwidth, or encoder performance issues.
Video pausing or freezing for under 2 seconds. Common causes include dropped frames at the encoder, packet loss, or CPU overload.
Both audio and video pausing simultaneously for under 2 seconds. Usually indicates a network bandwidth or packet-loss issue affecting the entire stream.
Audio pausing or cutting out for longer than 2 seconds. Typically indicates a more severe or sustained connectivity problem than stuttering.
Video pausing for longer than 2 seconds. May indicate the encoder has stopped sending frames, a network timeout, or server-side processing delays.
Both audio and video pausing simultaneously for longer than 2 seconds. Often points to a complete interruption of the stream connection.
Noticeable distortions in the video image — for example, unexpected color shifts, images bleeding into one another, or ghost images from previous frames superimposed on the current frame. Video artifacts typically indicate missing keyframes or corrupted data in the stream.
Noticeable distortions in the audio — pops, breaks, static, garbled speech, or repeated segments. Audio artifacts typically point to packet loss, encoder issues, or buffer underruns.
Degraded video quality where individual pixels are visible, but the content is still recognizable. Pixelation is usually caused by an insufficient bitrate relative to the resolution and motion in the scene.
Audio and video that are out of alignment at the subscriber — the audio track is ahead of or behind the video. A/V sync problems can originate at the encoder, in the network, or from mismatched buffer settings.
The subscriber receives audio but the video element shows a black screen. Common causes include a missing or unsupported video codec, keyframe issues, or browser permissions blocking the video element.
Video or audio freezes briefly and then plays back at an accelerated speed to catch up to real time. This typically results from large buffer backlog being flushed after a congestion event.
The video reverses direction and the playback counter goes backward for at least one second’s worth of frames before continuing normally. This rare issue usually indicates a timestamp discontinuity in the encoded stream.