Adaptive streaming, and why DynTube live streaming is simple RTMP-to-HLS

If you publish one video at one quality, every viewer gets the same stream regardless of the connection they are on. That works until it does not: the viewer on hotel wifi stalls, the viewer on fibre gets a softer picture than their screen deserves, and both blame your product rather than their network.

Adaptive bitrate streaming addresses this by publishing several versions of the same video and letting the player choose between them, second by second, based on what the connection is actually delivering. The whole mechanism rests on one condition that is easy to skip past: those versions have to exist first. That single condition is what separates the two delivery paths on DynTube, so it is worth starting with the one that does not have them.

DynTube live streaming is simple, and simple means one quality

A DynTube live stream has two halves. Your encoder — OBS or another encoder you already use — sends one contribution to a private RTMP ingest address using the server URL and stream key issued for that stream. DynTube then prepares the viewer-facing stream for HLS playback. That is the whole path, and it is why the product is described as simple live streaming.

your encoder
  → private RTMP ingest
  → DynTube processing
  → HLS viewer playback

What that path does not include is a rendition ladder. DynTube does not build several quality versions out of a live contribution, so a live viewer receives the quality your encoder sent — there is no lower rung for a player to fall back to and no higher rung to climb to. Everything below about a player stepping down mid-playback is therefore about uploaded video, not about your live event.

The practical consequence is that on live the quality lever is yours, not the platform’s. DynTube prescribes no live resolution, bitrate or keyframe setting: what you configure in your encoder, and how much upstream headroom you have above it, is what your audience gets. Choosing conservatively matters more on live than on upload for exactly that reason — a bitrate your connection cannot sustain has nowhere to degrade to. The RTMP article and the RTMP ingest page cover the setup and the states in full.

Where adaptive selection does apply: uploaded video

On DynTube, adaptive selection is a property of uploaded, on-demand video. Whether a video has HLS output at all is a per-project setting that can be off, and which heights are produced is a per-project choice from an enumerated list. There is no single fixed ladder applied to every upload, and settings apply to material processed after they are set — so an older video keeps whatever it was given at the time. A project may also be configured for CMAF instead of HLS — certified DRM in fact requires it — in which case HLS adaptive selection is not what is in play for that material. The adaptive bitrate streaming page sets out those conditions in full, along with the plan and client conditions that also bound the result.

How an adaptive ladder works, for an uploaded file

When a source file is processed into more than one rendition, the result is the same content at different resolutions and bitrates. Each rendition is cut into short segments, typically a few seconds long, and a manifest file lists what is available.

The player downloads the manifest first, picks a rendition to start with, then measures how quickly each segment arrives. If segments are arriving comfortably ahead of playback, it can step up to a higher rendition. If the buffer starts draining, it can step down — provided a lower rung exists. The switch happens at a segment boundary, which is why a quality change usually looks like a brief softening rather than an interruption.

• The uploaded source file is processed into the renditions that project is configured to produce.
• Each rendition is segmented, and a manifest describes the set.
• The player measures throughput and switches renditions at segment boundaries.
• A ladder with no low rung has nothing to fall back to, however good its top rung is.
• A simple live stream has no ladder at all, which is the case above.

HLS is what the two paths share

HLS — HTTP Live Streaming — is the transport on both sides of this boundary: it is how a live contribution reaches viewers, and it is the format adaptive selection works over for uploaded video. Sharing a transport is not the same as sharing a ladder, which is the confusion this article exists to remove. Because HLS is delivered over ordinary HTTP, it passes through CDNs, caches and corporate proxies that would block a specialised streaming protocol. Support in a given browser, operating system or television is a property of the viewer’s client rather than of this platform, so it is worth verifying against the device mix your audience actually uses instead of assuming it.

HLS also gives you a natural place to attach access control. The manifest can point at a key that the player must request before it can decrypt the segments, which is how encrypted delivery and domain restrictions work in practice — subject, on live, to the eligibility note above.

What each path changes for your bandwidth

This is the part people miss when they plan capacity. For uploaded video, if you estimate bandwidth by multiplying your highest bitrate by your audience and their watch time, you will tend to overestimate, because not every viewer receives the highest rendition for the whole of their watch time. For a simple live stream there is no such margin: viewers receive the bitrate you are sending, so the figure you broadcast at is the figure to plan with.

The arithmetic for an upper bound is straightforward either way. Take the bitrate in kilobits per second, divide by eight for kilobytes per second, multiply by sixty for one minute of watching, then multiply by average watch time and by monthly viewers — or, for live, by concurrent viewers and event duration. Divide by one billion for terabytes per month.

For uploaded video, use the highest bitrate you actually publish for a worst-case figure, then expect real delivery to land below it. For live, use the bitrate you intend to broadcast at and treat it as the figure rather than the ceiling. If you want to sanity-check your own numbers, the bandwidth calculator does this arithmetic interactively.

Match adaptive streaming to the playback conditions

• Use a rendition ladder for uploaded video when viewers arrive on varied networks, screens and devices.
• Plan a DynTube live stream around its single broadcast quality because the viewer receives the bitrate the encoder sends.
• Use the best available source master so the generated ladder has enough detail at every useful rendition.
• Inspect the renditions actually produced for a representative project before basing bandwidth or quality decisions on the ladder.

The short version

For uploaded video, adaptive streaming trades a little extra work and storage at processing time for a player that can meet a struggling connection with a lower rung instead of a stall. It is worth having where your audience is varied and outside your control, and it is worth checking rather than assuming: open the project and look at which renditions actually exist.

For live, none of that machinery is in play. Plan the broadcast bitrate you can sustain, confirm encryption and retention if the event needs them, and test the viewer page as well as the encoder connection. Two delivery paths, one transport, and only one of them has a ladder.