When choosing segment duration for an HLS or MPEG-DASH video service, what do shorter segments gain and cost, given each must start on a keyframe?
answer
- granularity of every player decision
- first frame and the next switch
- keyframes are the expensive frames
- a whole multiple of the interval
- identical timestamps in every rendition
basics
~20 sShorter segments speed startup, let the player switch bitrate sooner and cut live delay, but usually need more keyframes, which costs compression efficiency, and add requests and manifest size; keyframes must also align across renditions so switches stay seamless.
solid answer
~50 sSegment duration sets the granularity of everything the player does. With shorter segments, say 2 seconds instead of 6, the first segment arrives sooner, the player can react to a bandwidth drop at the next boundary rather than seconds later, and a live stream sits closer to real time because each segment is published as soon as it closes. The costs: every segment must begin with a **keyframe**, an independently decodable frame that is much larger than the predicted frames around it, so if shorter segments force a shorter keyframe interval you spend more bits for the same quality; you also get more HTTP requests, more objects to store and longer manifests to refresh. Segment duration must be a whole multiple of the keyframe interval, and every rendition must place keyframes at the **same timestamps**, using a fixed interval and closed groups of pictures, or segment N will not cover the same time in every rendition and switches will glitch.
go deeper
Recall that each segment starts with a keyframe, and that shorter segments mean faster startup and switching but more requests and, often, more bits spent on keyframes.
Explain the keyframe interval, closed groups of pictures, why segment duration is a multiple of that interval, and why every rendition must place keyframes at identical timestamps.
Diagnose glitches at quality switches by checking keyframe alignment across renditions, and justify a chosen duration from startup, switch speed, live delay and encoding efficiency.
Decide whether one segment length should serve both on-demand and live catalogues, and whether a short keyframe interval's bitrate cost is worth the re-packaging flexibility it buys.
## Vocabulary: keyframes and groups of pictures Compressed video stores most frames as **predicted frames**: they encode only the difference from other frames. A **keyframe** is the exception — a complete picture that a decoder can show without any earlier frame. The run of frames from one keyframe to the next is a **group of pictures (GOP)**, and the distance between keyframes is the **keyframe interval**. A GOP is **closed** when none of its frames reference frames outside it. Closed GOPs matter for segmented delivery because a player must be able to decode a segment with nothing but that segment (plus the rendition's initialisation data). That is why every segment in HLS or MPEG-DASH must **start on a keyframe**, and why a segment's duration is a whole multiple of the keyframe interval — for example a 2-second interval allows 2-, 4- or 6-second segments. ## What shorter segments buy - **Faster startup**: the player needs the first segment (often a couple) before it plays; a smaller first segment arrives sooner. - **Faster adaptation**: the player can only change rendition at a segment boundary, so short segments mean more frequent decision points and a quicker reaction to a bandwidth drop. - **Lower live delay**: a live segment can be published only once it is complete, and players hold back a few segment durations from the live edge, so delay scales with segment length. - **Finer seeking**: with one keyframe per segment, a seek lands closer to the requested time. ## What shorter segments cost | Factor | Shorter segments (about 2 s) | Longer segments (about 6–10 s) | |---|---|---| | Compression efficiency | more keyframes if the interval must shrink, so more bits at equal quality | fewer keyframes, better efficiency | | HTTP requests | many; per-request overhead adds up | fewer | | Manifest size | long lists, larger live playlist refreshes | shorter lists | | Stored objects | more files per rendition | fewer files | | Throughput samples | frequent but noisy, since small downloads are dominated by round-trip time | fewer, smoother | | Live delay | lower | higher | Keyframes are commonly several times larger than predicted frames, so halving the keyframe interval raises the bitrate needed for the same visual quality noticeably. If the keyframe interval is already short (say 2 seconds inside 6-second segments), shortening segments to 2 seconds adds no keyframes — only requests and manifest entries. ## Why keyframes must align across renditions Adaptation works by splicing a segment from one rendition after a segment from another. That only plays smoothly if segment N covers **exactly the same time range** in every rendition, which requires keyframes at the **same timestamps** everywhere. A transcode pipeline enforces this by: 1. Encoding every rendition with the **same fixed keyframe interval**, expressed in time rather than a frame count when renditions differ in frame rate. 2. **Forcing keyframes** at those exact timestamps. 3. Disabling scene-change keyframe insertion, or configuring it so extra keyframes cannot shift the forced ones. 4. Using **closed GOPs**, so no segment depends on frames in its neighbour. 5. Verifying alignment after packaging, before publishing the manifest. If one rendition drifts, a switch into it produces a segment that starts at a different moment, and the viewer sees a skip, a repeat or a visual corruption until the next clean keyframe. ## Choosing a value There is no universal number, but the reasoning is consistent: - On-demand catalogues with no latency pressure can use longer segments for efficiency and fewer requests. - Live streams want shorter segments, or the sub-second partial segments of low-latency modes, because delay grows with segment length. - A short keyframe interval (such as 2 seconds) inside longer segments keeps the option of re-packaging the same encode into shorter segments later without re-encoding, at the price of the extra keyframes. - The manifest's declared maximum (`#EXT-X-TARGETDURATION` in HLS) must reflect the real longest segment, so irregular segments do not confuse player timing. ## Common mistakes - Treating shorter as strictly better and ignoring the bitrate and request cost. - Letting each rendition's encoder choose its own keyframe placement. - Cutting segments at exact clock times without checking that a keyframe sits there. - Forgetting that live delay, not just startup, is driven by segment length.
- What goes wrong if one rendition's encoder inserts extra keyframes at scene changes and shifts its fixed interval?That rendition's keyframes stop lining up with the others, so its segment boundaries fall at different times. A player switching into it gets a segment that starts at a different moment, producing a skip, a repeat or corruption, or the packager cannot cut there at all. The fix is forcing keyframes at fixed timestamps in every rendition, with scene-change keyframes disabled or unable to move the forced ones.
- Why might a service use a keyframe interval shorter than its segment duration?A segment only has to start on a keyframe; it may contain more. A 2-second interval inside 6-second segments lets the packager later re-cut the same encode into 2- or 4-second segments without re-encoding, and lets seeks land nearer the requested time. The price is the bits spent on the extra keyframes, so the interval is a compromise between packaging flexibility and efficiency.
- How does segment duration drive live delay?A live segment can be published only once it is complete, and players typically start a few segment durations back from the live edge so they do not run dry. Delay therefore grows roughly in proportion to segment length: 6-second segments commonly leave viewers around twenty seconds or more behind, while shorter segments or sub-second partial segments bring that down at the cost of more requests and a thinner buffer.
saying these in an interview costs you the question
- Segments can be cut at any frame because players decode from anywhere.
- Shorter segments are always better since they only improve responsiveness.
- Each rendition can choose its own keyframe placement independently.
- Segment duration has no effect on compression efficiency or request count.
- Longer segments lower live delay because manifests update less often.