A live stream travels through several stages before it appears on a viewer’s screen: a source is captured, encoded, sent to a service, prepared for delivery and played by a device. Knowing where a term belongs in that path helps you distinguish, for example, bitrate from latency or an ingest protocol from a playback format.
The same workflow can be arranged differently by different services, so the glossary below is a map rather than a universal equipment list. For a simple YouTube loop, you may not operate every stage yourself; understanding the stages still helps when you diagnose quality, delay or interruptions.
The path from camera to viewer
Start with a camera, screen capture, prerecorded file or other source. An encoder prepares its video and audio for transmission, usually compressing them so they can be sent over a network. The encoder may be software or hardware. Google Cloud’s Live Stream API documentation, for example, identifies FFmpeg as an encoder program.
The encoded stream reaches an ingest or input endpoint: the point where a platform or media service accepts the contribution. RTMP, RTMPS and SRT are common terms at this stage, although platform configurations can use other arrangements. YouTube also documents HLS and DASH ingestion in specific configurations, so it is safer to ask what role a format has in a particular workflow than to assume it can only be used one way.
After ingest, a service may transcode the stream into multiple versions. It can then package the encoded tracks and their information for delivery, serve the result from an origin, and distribute it through a CDN towards viewers. Finally, a player on a phone, browser, television or other device requests and plays the media. Google Cloud documents a channel that ingests input, creates multiple renditions and publishes HLS or DASH outputs; that is one documented implementation, not a claim that every provider has identical stages.
These terms describe different jobs. An encoder creates a sendable media stream; a transcoder decodes and re-encodes it into another form; a packager arranges media and metadata for delivery. Packaging need not change the encoded picture, whereas transcoding does. Keeping those distinctions in mind makes service diagrams and troubleshooting notes easier to interpret.
Capture, resolution and frame rate
Capture is the creation or selection of the video and audio that will be streamed. For a live camera, it begins with the camera and microphone. For a continuous music or ambience channel, the source may instead be a prepared video file. A capture problem can therefore mean different things: a camera may be out of focus, a screen capture may omit a window, or a media file may have a black section.
Resolution describes the dimensions of the image, commonly written as width by height. A 1280×720 frame has 1280 pixels across and 720 down. Resolution is not a complete measure of perceived quality: motion, focus, compression, source detail, device display and available bitrate also matter. Enlarging a small or soft source does not create the detail that was never captured.
Frame rate, often abbreviated to FPS, is the number of frames displayed each second. More frames can make motion appear smoother, but at a given resolution and codec they typically require more data and processing. A static devotional image or a slowly moving ambience scene may not need the same motion handling as a camera covering a busy event. Choose settings around the material and the delivery path, rather than raising every value by habit.
Resolution and frame rate are related to, but not interchangeable with, bitrate. A high-resolution stream may still look poor if it is heavily compressed or the source is poor. Conversely, increasing resolution can add load without a visible benefit on the screens most of your audience uses. Test with representative content and the actual playback devices when possible.
Encoding, codecs and bitrate
An encoder converts source audio and video into a format suitable for sending. It compresses media because raw video is too large for practical network delivery. Software encoders run on a computer or other software environment; hardware encoders perform the work in dedicated equipment. Either way, encoding settings affect the amount of data produced, the detail retained and the work required to prepare each frame.
A codec is the method used to encode and decode audio or video. H.264/AVC, H.265/HEVC and VP9 are video codec names found in platform documentation; AAC is an audio codec. Codec compatibility depends on the receiving service and playback devices. A codec that can represent media efficiently does not, by itself, guarantee the best end-to-end picture: source quality, settings, network capacity, transcoding and player support remain relevant.
Bitrate is the amount of encoded data sent per second, often expressed in kilobits or megabits per second. Raising it can preserve more detail, but it also needs more upload capacity at the contribution end and more delivery capacity for viewers. It is not a quality score. If your upload connection cannot sustain the chosen bitrate, the stream may become unstable; if the source is a still image, adding data may bring little visible improvement.
Do not confuse bitrate with resolution. Resolution states the image dimensions; bitrate describes data flow. A video can have the same resolution at different bitrates, with different compression results. Frame rate adds another variable: more motion frames usually need more data to represent well. For a practical discussion of choosing settings for a continuous prerecorded channel, see this bitrate guide for a 24/7 YouTube stream.
A rendition is one encoded version of the stream, often defined by a resolution and bitrate. Adaptive bitrate (ABR) delivery makes several renditions available so a compatible player can select one suited to current network and device conditions. If bandwidth falls, a player may use a lower-rate version to reduce interruptions; if conditions improve, it may switch up. Selection behaviour varies by player and service, so ABR is a way to adapt, not a guarantee that playback will never pause.
| Term | What it describes | Practical consequence |
|---|---|---|
| Resolution | Image width and height | Affects picture dimensions and encoding work |
| Frame rate | Frames displayed per second | Affects motion smoothness and data needs |
| Bitrate | Encoded data sent per second | Affects detail and required network capacity |
| Rendition | One encoded version of a stream | Gives a player another quality level to choose |
| Codec | Method for encoding and decoding media | Determines compatibility and compression behaviour |
When a stream looks soft, changing bitrate may help only if compression is the limiting factor. If the source itself is low-detail, the codec is unsupported, or the player is using a lower rendition, the cause lies elsewhere. If audio and picture drift apart, that is a synchronisation issue rather than a bitrate definition; this guide to keeping audio in sync on an FFmpeg YouTube stream discusses that separate problem.
Streaming protocols: RTMP, HLS, SRT and WebRTC
A protocol is a set of rules for exchanging data. The useful question is not merely “Which protocol?” but “Which part of the path is it serving?” A creator might contribute RTMP or SRT to ingest, while a service packages media as HLS for viewer playback. Some platforms support more than one arrangement, and a protocol name is not a codec name.
RTMP (Real-Time Messaging Protocol) is widely associated with sending a live contribution to a platform. RTMPS is its secure counterpart; YouTube says RTMPS encrypts the live contribution connection. YouTube’s published ingestion comparison describes RTMP and RTMPS as options for normal, low or ultra-low latency, subject to the platform’s configuration. Those labels are specific to YouTube’s documented choices and should not be read as a promise about every end-to-end stream.
SRT (Secure Reliable Transport) is another contribution protocol. Google Cloud’s best-practices guidance favours SRT over RTMP in the context of its Live Stream API, citing capabilities such as packet-drop recovery and forward error correction, and notes that the encoder or transcoder must support it. That is service-specific guidance, not a universal verdict: your source tool, destination and network determine whether SRT is usable or useful.
HLS (HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP) are associated with segmented, HTTP-based delivery. A manifest or playlist tells a player about media segments and, where available, renditions; the player requests segments as playback proceeds. HLS is commonly used for device delivery, and some implementations have low-latency variants. Configuration and implementation affect delay, so the format name alone does not specify how quickly a viewer sees an event.
WebRTC and RTP are associated with real-time communications, including situations where interaction and very low delay matter. That does not mean WebRTC is automatically the right format for a one-way continuous broadcast. Network variation, platform support and the tolerance for visible media artefacts all matter. RFC 9317 discusses the trade-off: very low delay can be challenging when network conditions vary, and may require accepting degraded media rather than waiting for a larger buffer.
A useful comparison is by job, not by a single ranking:
| Term | Common role in a workflow | What to check |
|---|---|---|
| RTMP/RTMPS | Contribution to ingest | Whether the platform accepts it and which latency modes it documents |
| SRT | Contribution to ingest | Whether both the sender and receiver support it and whether its recovery features fit the route |
| HLS/DASH | Segmented delivery and playback; also ingest in some documented configurations | Device/player support and the service’s latency configuration |
| WebRTC/RTP | Real-time communications | Whether interaction needs justify the trade-offs and all components support it |
For a YouTube channel, follow the current YouTube live encoder settings and ingestion documentation rather than assuming a term from another platform’s guide transfers unchanged. A protocol describes transport or exchange rules; the codec still describes how media is represented inside that workflow.
CDNs and delivery
A CDN, or content delivery network, is a distributed set of servers used to deliver content towards viewers. In a typical delivery chain, packaged media is available from an origin, and CDN servers distribute it downstream. AWS describes its CDN in those terms: the network serves content from an origin or packager to viewers. A CDN is not an encoder and does not, simply by existing, improve the source image.
Delivery design helps distribute requests and bring content nearer to audiences, but viewer experience depends on more than geography. The origin must have the media, the delivery path must remain available, and the player must be able to request a compatible rendition. A weak home Wi-Fi connection, a congested mobile connection or an unsupported playback format can still cause trouble even if the CDN is functioning as intended.
The distinction between packaging and transcoding is useful here. A packager places encoded audio and video into a delivery arrangement, such as segments with a manifest. A transcoder creates new encoded media, perhaps at a different resolution or bitrate. Some systems combine these steps in one service; the terms still refer to different operations. AWS’s CloudFront documentation explains the CDN role in relation to content origins.
Live-to-VOD is a service feature that turns a live event into a video-on-demand asset during or after the broadcast. It is separate from the live delivery path itself. If your channel is built around scheduled loops, you may need to think about both: the live version for current viewers and the archived version for later viewing. A guide on switching between scheduled YouTube radio programmes covers a related programming concern.
Latency and glass-to-glass delay
Latency is delay between an event and its playback. In live video, people often use the word without saying which two points they measured. Network latency is not the same as total live-video delay: the latter includes work at several stages and is often called glass-to-glass latency.
Glass-to-glass latency measures the time from the real-world event being captured to the corresponding media playing on a viewer’s device. Encoding, ingest, processing, packaging, distribution, buffering and decoding can all contribute. It is therefore possible for a network connection to be responsive while the live picture still trails the event because other stages or player buffering add delay. RFC 9317 distinguishes glass-to-glass delay from network latency and discusses streaming behaviour in more detail.
A buffer is temporary media storage that helps playback continue when delivery varies. Waiting for more data in the buffer can smooth playback, but adds delay. If the buffer runs short, the viewer may see a pause or spinner. The trade-off is especially visible in interactive streams: a longer cushion may improve continuity while making conversation feel less immediate.
Choose the latency target around the purpose of the channel. A devotional loop, music station or study ambience stream may value steady playback more than a conversation that must respond to viewers in near real time. A local news discussion with live responses may place more value on immediacy. Low-latency labels are not interchangeable guarantees; check what the platform means, what modes it supports and whether the full capture-to-playback path fits the use case.
Playback quality and reliability terms
Playback is what the viewer’s device does with the delivered media. A player reads the manifest or stream information, requests media and decodes it. The player’s device, app, network and supported codecs all affect the result. A creator can send a healthy contribution and still have viewers report trouble due to a device-specific playback issue or a local connection.
Buffering is the visible wait when the player lacks enough media to continue. It can result from inconsistent delivery, limited bandwidth, a rendition that asks for too much capacity, or other issues along the path. ABR may let a player switch to a lower rendition, but selection rules vary and cannot repair every failure. When investigating, ask whether the problem affects all viewers or only one device or connection before changing encoder settings.
Reliability describes whether the stream and its components continue to work as intended, not a single setting. For an always-on channel, the source must keep producing media, the contribution connection must remain available, and the service must continue delivering playback. A restart or health check can help identify a stopped process, but it does not establish that every viewer can play the stream. The guide to checking whether FFmpeg is still streaming to YouTube covers one part of that operational picture.
For prerecorded 24/7 channels, the source does not need to be a camera feed. If the practical burden is keeping a computer running and recovering a dropped broadcast, StreamNeo removes that specific chore: you upload a video, provide your YouTube stream key, and the broadcast runs with your computer off, with monitoring and automatic restarts if it drops. It is for YouTube streams, so it is not a general-purpose delivery platform for other destinations.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is bitrate the same as internet speed?
No. Bitrate is the encoded media data sent each second, while internet speed describes the capacity of a network connection. Your upload capacity needs to sustain the contribution bitrate with room for variation; viewers need adequate delivery capacity for the rendition they receive.
Is RTMP the same thing as HLS?
No. RTMP is commonly used to send a contribution to ingest, while HLS is commonly associated with segmented HTTP delivery to viewers. Platforms can support additional arrangements, so check the current documentation for the specific service and configuration.
Does a CDN encode my video?
A CDN distributes content downstream from an origin or packager; it is not the encoder. A service may combine CDN delivery with encoding or transcoding elsewhere in its workflow, but those are distinct functions.
What does glass-to-glass latency tell me?
It describes the time from capturing an event to its playback on a viewer’s device. It includes more than network transit, such as encoding, processing and buffering, so it gives a fuller picture of live delay than network latency alone.