#EXT-X-TARGETDURATION Explained: The Segment Timing Contract at the Heart of HLS

Every HLS media playlist carries one tag that almost never changes, is almost never discussed, and yet underpins every live polling schedule, every CDN cache lifetime, and every segment duration validation in the protocol: #EXT-X-TARGETDURATION. Understanding exactly what it declares — and what breaks when something misreads it — matters for anyone building a player, a converter, or a download tool on top of HLS.

What the tag declares

#EXT-X-TARGETDURATION appears once in a media playlist (never in a master playlist) and carries a single integer value:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:1482

#EXTINF:5.994,
seg-1482.ts
#EXTINF:5.994,
seg-1483.ts
#EXTINF:4.128,
seg-1484.ts

The value 6 means: no segment in this playlist will ever be longer than 6 seconds. RFC 8216 is unambiguous — TARGETDURATION is the declared maximum segment duration, and every #EXTINF value in the playlist must be at or below it. A segment that exceeds the declared ceiling makes the playlist invalid.

Typical values by stream type:

• Standard live streams: 6–10 seconds. Six-second segments are common because they give ABR players a reasonable switching granularity while keeping the segment count manageable.
• VOD streams: 6–10 seconds. Some publishers use longer segments (up to 10s) for VOD to reduce the number of HTTP requests per hour of content.
• Low-Latency HLS streams: 6 seconds for full segments, with a separate #EXT-X-PART-INF PART-TARGET of 0.2–0.5s for partial segments. TARGETDURATION governs full segments only.

Why it is mandatory

RFC 8216 classifies #EXT-X-TARGETDURATION as a Required tag for every Media Playlist, live or VOD. A playlist without it is not a valid HLS playlist. In practice, most players handle the absence gracefully — they pick a default value or measure the first few segments — but the spec gives them no obligation to do so.

The mandatory status is not arbitrary. Three distinct systems depend on the declared ceiling:

1. Polling interval calculation (live). The spec recommends that a client wait one TARGETDURATION after receiving a playlist before re-fetching it. Without a known value, a client has no principled basis for its polling schedule — it either polls too often (wasting bandwidth) or too rarely (falling behind the live edge).
2. CDN cache lifetime. Many CDN configurations set the cache TTL for a live media playlist to one TARGETDURATION. A segment that runs over the declared ceiling would be served from cache when it should already be stale, causing some clients to miss new segments entirely.
3. Buffer duration assumptions. Players size their buffer in multiples of TARGETDURATION (typically 3×). An encoder that silently exceeds the declared value skews those calculations, potentially causing players to stall before the network is actually congested.

How live polling works in practice

A live stream client follows roughly this loop:

1. Fetch the media playlist. Note the #EXT-X-MEDIA-SEQUENCE value.
2. Read #EXT-X-TARGETDURATION. Start a reload timer.
3. Download any segments that have appeared since the last fetch, appending them to the playback buffer.
4. When the timer fires (approximately one TARGETDURATION later), re-fetch the playlist. If the sequence number advanced, new segments are available. If it hasn't, the live edge hasn't moved yet — back off slightly before the next poll.

The spec's exact wording is "wait for one-half the Target Duration" if the playlist has not changed. The full TARGETDURATION wait applies when the playlist did change and the client loaded new segments. This half-duration backoff is what prevents thundering-herd behavior when many clients hit the same CDN simultaneously.

This is also why polling faster than once per TARGETDURATION is counterproductive. The CDN will serve a cached — and therefore unchanged — playlist until the cache expires, so extra requests just consume CDN quota without delivering new segments.

TARGETDURATION vs. actual segment duration

TARGETDURATION is a ceiling, not a target in the "aim for exactly this value" sense. Individual segments are typically a little shorter than the declared maximum because encoder GOP boundaries rarely fall exactly on the declared interval. A TARGETDURATION of 6 with #EXTINF:5.994 entries is normal and correct.

The last segment in a VOD playlist is often the shortest, because the content's natural endpoint doesn't align with the segment boundary. A final segment of 1.3 seconds on a TARGETDURATION-6 playlist is fine.

What the spec forbids is the reverse: a segment with an #EXTINF value larger than TARGETDURATION. Encoders that produce variable-GOP streams or that cut segments at scene changes rather than fixed intervals can produce this by accident. The most common symptom is a player that stalls exactly once per occurrence — it allocated buffer for a 6-second segment, then received 8 seconds of data and ran out of space.

Low-Latency HLS and PART-TARGET

Low-Latency HLS introduces a second timing constant: #EXT-X-PART-INF PART-TARGET. This declares the target duration for partial segments — the sub-second chunks that LL-HLS uses to deliver content before a full segment is complete:

#EXT-X-TARGETDURATION:6
#EXT-X-PART-INF:PART-TARGET=0.33334

PART-TARGET is a floating-point value, not an integer, because partial segments are measured in fractions of a second. TARGETDURATION still caps full segments at the usual integer ceiling; PART-TARGET caps partial segments within those full segments. A partial segment that exceeds PART-TARGET by more than the tolerance allowed by the spec makes the playlist invalid in the same way an over-length full segment does.

For a download tool or converter that only cares about complete segments, PART-TARGET is irrelevant — but TARGETDURATION still matters for validating the #EXTINF values it reads.

What this site's parser does with TARGETDURATION

The converter at /convert reads TARGETDURATION when parsing a media playlist but does not use it for polling — the converter fetches all segments sequentially and has no need for a live reload schedule. It does check that no individual #EXTINF value exceeds the declared ceiling. If one does, the converter logs a warning but continues, treating it as a malformed-but-recoverable playlist.

The live player at /play delegates polling to hls.js, which implements the RFC 8216 polling schedule correctly — including the half-duration backoff. The player itself never reads TARGETDURATION directly; hls.js handles it internally.

To detect and open HLS streams from any page, install the Stream Video Downloader extension. The extension captures the M3U8 URL as the page loads it and opens the converter or player with a single click — no manual DevTools inspection required.