Representation declares no bandwidth
@bandwidth is required, and adaptive bitrate selection depends entirely on it.
What it means
A <Representation> omits the required @bandwidth attribute, so the manifest never states how many bits per second that rendition needs. Every other attribute may be present and correct; this one is what selection depends on.
Why it matters
Bandwidth is the primary input to ABR: it is how a player decides whether a representation fits the current connection. A representation without it cannot be ranked, so players either ignore it — wasting the encode — or treat it as zero and select it always.
How to fix it
- Add bandwidth to every <Representation>, in bits per second.
- Use the peak sustained bitrate, not the average, so the player budgets for the worst case.
Check your own stream
The free DASH validator runs this check on every analysis and links each finding straight back here.
Open the DASH validator →Frequently asked questions
- What does "Representation declares no bandwidth" mean?
- A <Representation> omits the required @bandwidth attribute, so the manifest never states how many bits per second that rendition needs. Every other attribute may be present and correct; this one is what selection depends on.
- Why does it matter?
- Bandwidth is the primary input to ABR: it is how a player decides whether a representation fits the current connection. A representation without it cannot be ranked, so players either ignore it — wasting the encode — or treat it as zero and select it always.
- How do I fix it?
- 1. Add bandwidth to every <Representation>, in bits per second. 2. Use the peak sustained bitrate, not the average, so the player budgets for the worst case.
- Can a validator catch this before viewers do?
- Yes. The free DASH MPD validator checks this on every run, together with UTCTiming, clock drift and segment addressing — the live problems that only appear on other people's devices.
- What is the first thing to try?
- Add bandwidth to every <Representation>, in bits per second.
Related DASH checks
- DASH manifest has no UTCTiming elementA live MPD without UTCTiming forces players to trust the device clock, so any skew on the viewer’s machine becomes stalls or missing segments.
- DASH availabilityStartTime is in the futureThe manifest claims the presentation starts later than the current time, so no segment is available yet and playback cannot begin.
- The DASH manifest is not well-formed XMLThe document could not be parsed as XML, so nothing else could be checked.
- The document has no MPD root elementThe XML parsed, but its root is not <MPD>, so it is not a DASH manifest.
- MPD declares no profileWithout @profiles a player cannot tell which DASH feature set the manifest expects.
- MPD declares no minBufferTimePlayers use this required attribute to size the initial buffer before starting playback.