What is Video Bandwidth?
Video bandwidth is the network transfer capacity required or consumed to deliver video over time. The requirement depends on encoded bitrate, protocol overhead, concurrent streams, and variation in available throughput.
How Video Bandwidth works
The term covers two different quantities, and mixing them causes most planning errors. One is what a stream demands: the bits per second a rendition needs, which is its encoded video bitrate plus audio and container overhead. The other is what a connection supplies: the throughput a viewer’s network can sustain, which changes from moment to moment. Streaming formats publish the first so that players can compare it with their own measurement of the second. In HLS, every variant in the multivariant (master) playlist carries a required BANDWIDTH attribute in bits per second, defined as the peak segment bit rate, and an optional AVERAGE-BANDWIDTH; both include container overhead but not HTTP, TCP, or IP overhead. In MPEG-DASH, each Representation carries a @bandwidth value, which the DASH-IF guidelines explain with a leaky-bucket model alongside the minimum buffer time. A player estimates throughput from its recent segment downloads and selects a rendition whose declared rate fits within that estimate. For an operator, the same per-stream figures multiplied across concurrent viewers give aggregate delivery throughput at the edge, and that throughput multiplied by viewing time gives delivery volume.
Key facts
- 1Which number goes in the playlist, average or peak? In HLS,
BANDWIDTHis the peak: for a variant with a single media playlist, the largest bit rate of any contiguous run of segments lasting between 0.5 and 1.5 target durations.AVERAGE-BANDWIDTHis the total size of the segments divided by the playlist duration. When audio or other renditions are packaged separately, RFC 8216 requires each value to be the largest sum across the playable combinations of renditions, so measuring the video playlist alone under-declares the variant. These measurements need finished segments. When the playlist is published before all segments are encoded, as in a live event, the RFC says to use the value from a representative period of similar content encoded with the same settings. It also warns that an inaccurate value can cause playback stalls or prevent clients from playing the variant. With variable-bitrate encoding the two diverge: for on-demand content, Apple’s authoring specification says the peak should be no more than 200% of the average and requires the measured peak to be within 10% of the declaredBANDWIDTH. An encoder’s video bitrate setting is neither figure, because the playlist values are computed from packaged segments and include audio and container overhead. - 2How much faster than a rendition does a viewer’s connection need to be? Faster by the player’s safety margin, not merely equal. hls.js, for example, documents two default factors: its normal selection check for the current or a lower level requires that 0.95 times its bandwidth estimate exceeds the level’s bitrate, and switches up only when 0.7 times the estimate exceeds the higher level’s bitrate. For a level compared at 5 Mbit/s, the up-switch condition is an estimate above about 7.1 Mbit/s. Which bitrate is compared depends on the buffer: by default the hls.js source uses
AVERAGE-BANDWIDTH, when the playlist declares it, while at least two segment durations are buffered and no rebuffering is expected, andBANDWIDTHotherwise. It also applies further checks, such as the expected time to fetch a segment. The estimate is a moving average of recent downloads, so it lags behind a network that has just recovered. Treat the result as a condition on the player’s estimate, not as a guaranteed connection speed. The factors are the configuration defaultsabrBandWidthFactorandabrBandWidthUpFactor; other players apply their own rules, so check the one you ship. - 3How do I estimate delivery volume for an audience? Multiply the average bit rate of each rendition by the number of viewers watching it to get throughput, then by the viewing time to get volume; use the peak figures to size for bursts. For example, 1,000 concurrent viewers of a rendition that averages 3 Mbit/s need about 3 Gbit/s of edge throughput, which is roughly 1.35 TB per hour. That figure describes what the edge sends to viewers. It does not describe origin traffic, which depends on how many requests the CDN answers from cache, and it leaves out HTTP, TCP, and IP overhead, which the HLS bit rate definitions exclude. Viewers are also spread across the ladder, so a per-rendition share from player analytics gives a closer figure than assuming the top rendition for everyone.
- 4How low should the bottom rendition go? For iOS, Apple’s HLS authoring specification requires a multivariant playlist delivered over cellular networks to contain a variant whose peak
BANDWIDTHis 192 kbit/s or less. Include such a fallback variant for cellular audiences on iOS devices; the specification does not set it as a general rule for other platforms.
When Video Bandwidth matters
Estimate aggregate bandwidth when sizing CDN capacity and constructing an adaptive rendition ladder. Renditions above viewers’ available throughput cause stalls, while overly conservative rates reduce quality.
How Transloadit helps with Video Bandwidth
Transloadit produces the renditions and playlists that these figures describe. The /video/encode Robot encodes one rendition per Step, with hls/ and dash/ presets at fixed resolutions, and the /video/adaptive Robot bundles those Steps into HLS, MPEG-DASH, or CMAF output and generates the manifest and playlist files. Your ladder is therefore the set of /video/encode Steps you pass to /video/adaptive. Any preset setting, including bitrate, can be overridden through the ffmpeg parameter, and segment_duration on /video/adaptive sets the segment length.
The preset table lists the hls/ and dash/ presets as VBR without a bitrate figure, and the Robot pages do not say how the bandwidth attributes in the generated playlist are computed. Inspect the generated playlist for the declared values, and check them against the segment sizes, before using them in capacity estimates.
Sources
- RFC 8216: HTTP Live Streaming (segment bit rate definitions, BANDWIDTH, AVERAGE-BANDWIDTH)
- Apple: HLS Authoring Specification for Apple Devices
- DASH-IF Interoperability Points v4.3: bandwidth and minimum buffer time
- hls.js API documentation: abrBandWidthFactor and abrBandWidthUpFactor
- hls.js ABR controller source: which bitrate level selection compares