MSL5 Origin Low-Latency HLS output without encoder changes

Live streaming audiences expect near-real-time experiences — whether they are watching a penalty kick, a breaking news event, or a live auction. Yet today, most live streaming workflows built on standard HLS deliver content with 16 seconds or more of end-to-end latency, leaving viewers perpetually behind the live edge.

Reducing that latency has traditionally required a costly, disruptive overhaul: replacing or upgrading encoders to produce Low-Latency HLS (LL-HLS) output, re-qualifying the entire ingest pipeline, and revalidating player behavior. For many operators, the cost, effort, and risk of such a migration have kept low-latency streaming out of reach.

MSL5 Origin changes the equation entirely.

With the new LL-HLS Output capability, MSL5 Origin accepts standard HLS segments from any existing encoder and automatically generates a fully compliant LL-HLS output — complete with Preload Hints, Blocking Playlist Reloads, Rendition Reports, and Delta Playlists. Customers cut end-to-end latency from over 16 seconds down to 6–8 seconds using the same encoder, the same ingest workflow, and the same Akamai CDN delivery — with no additional cost.

No encoder swap. No workflow disruption. No price increase. Just dramatically lower latency.

The Latency Problem in Standard HLS

How Standard HLS Latency Accumulates

In a conventional HLS workflow with 4-second segments, latency accumulates across every stage of the delivery chain:

The largest contributor — player buffering — is inherent to the standard HLS protocol design. Players typically buffer three or more segments before starting playback, and must poll for playlist updates on a fixed interval, adding further delay.

Why Low-Latency HLS (LL-HLS) Exists

Apple's Low-Latency HLS extension (RFC 8216bis) was designed to attack each source of delay:

• Partial Segments (Parts): Content is made available in sub-segment chunks, reducing the time viewers wait for new media.
• Preload Hints: The server tells the player what to request next before the content is ready, enabling speculative fetching.
• Blocking Playlist Reloads: Instead of polling on a timer, the player sends a request that the server holds open until new content is available — eliminating polling delay.
• Rendition Reports: Players can monitor the state of alternate renditions without fetching every playlist, enabling faster ABR switching.
• Delta Playlists: Only the changed portion of the playlist is transmitted, reducing bandwidth and parse time.

Together, these mechanisms can bring end-to-end latency down to 2–5 seconds — but traditionally, they require the encoder to produce LL-HLS-native output (partial segments, updated manifests with part tags, etc.).

This is where MSL5 Origin breaks the mold.

The MSL5 Origin LL-HLS Output Solution

Standard Input, Low-Latency Output

MSL5 Origin introduces a transformative capability: it accepts standard HLS segments from any encoder and performs server-side LL-HLS conversion, producing a fully compliant Low-Latency HLS output stream — without requiring any changes to the encoder.

How It Works

When an MSL5 Origin Stream is configured with LL-HLS output enabled, the origin performs the following server-side processing on incoming standard HLS segments:

1. Short Segment Handling: The encoder is configured to produce short HLS segments (1–2 s) rather than the typical 4–6 s. MSL5 Origin accepts each short segment immediately upon arrival and serves it directly as an LL-HLS part on the /hls/live-ull/ path, making it available to viewers the instant it lands at the origin. Simultaneously, the origin concatenates multiple short segments (e.g., 4 × 1 s) into a 4–6 s composite segment for the standard HLS output path, ensuring backward compatibility with legacy players.
2. LL-HLS Manifest Generation: MSL5 Origin generates compliant LL-HLS playlists on the /hls/live-ull/ output path, including:
   • EXT-X-PART tags for each partial segment
   • EXT-X-PART-INF with the part duration target
   • EXT-X-SERVER-CONTROL with CAN-BLOCK-RELOAD=YES, CAN-SKIP-UNTIL and PART-HOLD-BACK
   • EXT-X-PRELOAD-HINT pointing to the next expected part
   • EXT-X-RENDITION-REPORT for cross-rendition state awareness
   • EXT-X-SKIP for delta playlist delivery
3. Blocking Playlist Responses: The origin supports _HLS_msn and _HLS_part query parameters, holding the response until the requested content is available. This eliminates client-side polling and ensures players receive updates at the earliest possible moment.
4. Dual Output Paths: Both standard HLS (/hls/live/) and LL-HLS (/hls/live-ull/) output paths are served simultaneously from a single ingest, giving operators full flexibility in player targeting.

Encoder Compatibility

The LL-HLS Output feature is designed to work with any encoder that produces standard HLS output:

Latency Comparison

Before: Standard HLS with 4-Second Segments

After: Encoder Reconfigured to 1–2s Segments, MSL5 LL-HLS Output Enabled

📘

Note on Player Compatibility

To realize the latency benefits, the player must support LL-HLS playback (e.g., hls.js, AVPlayer on Apple platforms, Shaka Player, THEOplayer, Bitmovin). The standard HLS output path (/hls/live/) remains available for legacy players — both paths are served simultaneously.

Where the Latency Savings Come From

LL-HLS Features Delivered by MSL5 Origin

Preload Hints (EXT-X-PRELOAD-HINT)

MSL5 Origin appends a Preload Hint to every LL-HLS playlist response, indicating the URI of the next partial segment the player should request. This allows LL-HLS players to issue a request for the upcoming part before it exists on the server. When combined with blocking media responses, the part is delivered to the player the instant it becomes available.

#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part1005.3.mp4"

• Impact: This enhancement removes the latency associated with the iterative process of identifying new content and subsequently requesting it.

Blocking Playlist Reloads (CAN-BLOCK-RELOAD)

Instead of polling the playlist on a fixed interval, LL-HLS players include _HLS_msn (media sequence number) and _HLS_part query parameters in their playlist request. MSL5 Origin holds the response until the playlist contains the requested segment or part, then responds immediately.

GET /hls/live-ull/{stream}/playlist.m3u8?_HLS_msn=1005&_HLS_part=3
→ Server holds until part 1005.3 is available, then responds instantly

• Impact: This enhancement replaces polling latency (typically half a segment duration) with zero-wait notification.

Rendition Reports (EXT-X-RENDITION-REPORT)

Each LL-HLS playlist response includes Rendition Reports indicating the latest media sequence number and part index available on other renditions. This allows the player to make informed ABR switching decisions without fetching every variant playlist.

#EXT-X-RENDITION-REPORT:URI="../1080p/playlist.m3u8",LAST-MSN=1005,LAST-PART=2
#EXT-X-RENDITION-REPORT:URI="../480p/playlist.m3u8",LAST-MSN=1005,LAST-PART=3

• Impact: Enhanced speed and precision in adaptive bitrate switching, which is particularly critical during live events characterized by variable bandwidth conditions.

Delta Playlists (EXT-X-SKIP)

When a player requests a playlist with the _HLS_skip=YES query parameter, MSL5 Origin returns a delta playlist that omits segments the player has already seen. Only new segments and parts are included, prefixed with an EXT-X-SKIP tag indicating how many segments were skipped.

#EXT-X-SKIP:SKIPPED-SEGMENTS=15

• Impact: This enhancement decreases the playlist payload size by up to 90%, significantly reducing bandwidth utilization and parsing time for extended-duration live streaming sessions.

Blocking Media Segment Responses

For partial segments that are still being produced, MSL5 Origin supports holding the HTTP response open until the part is fully available. Combined with Preload Hints, this creates a push-like delivery model where content flows to the player at the earliest possible moment.

• Impact: Achieves sub-second media delivery immediately upon content arrival at the origin server.

Deployment: A Three-Step Migration

Migrating from standard HLS to LL-HLS output on MSL5 Origin requires no encoder changes and minimal configuration:

Step 1 — Enable LL-HLS Output on the MSL5 Origin Stream

In the MSL5 Portal, enable the LL-HLS Output option on the target Stream. This activates the /hls/live-ull/ output path alongside the existing /hls/live/ path.

Step 2 — Update the Akamai AMD Property (if needed)

Add or update the AMD property to serve the LL-HLS output path. Typical configuration includes:

• Origin path routing: Route /hls/live-ull/ requests to the MSL5 Origin
• Cache TTLs: Playlists: short TTL (e.g., 1–2 s); Segments/Parts: long TTL
• Query string forwarding: Forward _HLS_msn, _HLS_part, and _HLS_skip query parameters to origin for blocking playlist and delta playlist support

Step 3 — Point LL-HLS Players to the New Output Path

Update the player configuration to request the master playlist from the /hls/live-ull/ path:

# Standard HLS (unchanged, still available):
https://us-sea-myorigin.mslorigin.net/hls/live/{stream-id}/{event}/master.m3u8
# LL-HLS Output (new):
https://us-sea-myorigin.mslorigin.net/hls/live-ull/{stream-id}/{event}/master.m3u8

Legacy players continue to use the standard /hls/live/ path with no disruption.

That's it. The encoder continues publishing standard HLS segments exactly as before. MSL5 Origin handles the rest.

Cost & Business Impact

Zero Incremental Cost

The LL-HLS Output feature is included as part of the MSL5 Origin service. There is no additional charge for enabling LL-HLS conversion — customers pay the same MSL5 Origin rate they pay today.

Business Value Summary

Architecture Summary

Frequently Asked Questions

1. Does my encoder need to support LL-HLS?
   No. MSL5 Origin accepts standard HLS segments (fMP4 or MPEG-TS, typically 4–6 seconds) and generates the LL-HLS output server-side. Your encoder continues to operate exactly as it does today.
2. Can I achieve the same 2–3 second latency as native LL-HLS?
   The 6–8 second latency target reflects the reality of server-side conversion from 4-second segments. Because the encoder still produces full segments, the origin cannot serve parts until segment data begins arriving. Native LL-HLS from the encoder (with sub-second parts) can achieve 4–5 s latency. MSL5 Origin also supports native LL-HLS input on the /hls/live-ull/ ingest path for customers who choose to upgrade their encoder in the future.
3. Is there any additional cost?
   No. LL-HLS Output is included in the MSL5 Origin service. There is no incremental charge.
4. Do both output paths work simultaneously?
   Yes. When LL-HLS Output is enabled, MSL5 Origin serves both /hls/live-ull/ (LL-HLS) and /hls/live/ (standard HLS) from the same ingest. Legacy players and LL-HLS players can consume the same stream concurrently.
5. What player changes are needed?
   The player must support LL-HLS playback. Most major players already do: Apple AVPlayer (iOS/tvOS/macOS), hls.js, Shaka Player, THEOplayer, Bitmovin, and others. The only change is pointing the player to the /hls/live-ull/ master playlist URL.
6. What if I want even lower latency in the future?
   MSL5 Origin also supports native LL-HLS ingest on the /hls/live-ull/ path. When you are ready to upgrade your encoder to produce native LL-HLS output (published as part files rather than complete segments), you can achieve 4–5 second latency. The migration path is seamless — only the encoder output changes; the origin and CDN configuration remain the same.
   An important video quality benefit comes with this approach: because the encoder publishes individual part files, the IDR frame interval (GOP size) does not need to match the part duration. The encoder can maintain a longer GOP (e.g., 2–4 seconds) across multiple parts, avoiding the video quality degradation that typically accompanies small GOP sizes. Short GOP intervals force frequent intra-coded frames, consuming bitrate that would otherwise be used for motion detail — native LL-HLS part publishing eliminates this trade-off entirely.
   Contact MediaKind for encoders that support native LL-HLS part file output and are qualified for use with MSL5 Origin.
7. Does this work with Akamai's redundant origin architecture?
   Yes. The LL-HLS Output feature is fully compatible with MSL5 Origin's redundant origin architecture. Both primary and backup origins generate LL-HLS output independently, and the AMD property routes requests using the same path-based rules (-b suffix for backup streams).

Conclusion

MSL5 Origin's LL-HLS Output feature represents a paradigm shift in live streaming latency reduction. For the first time, operators can cut their live stream latency by more than half — from over 16 seconds to 6–8 seconds— without touching their encoder, without changing their ingest workflow, and without paying a penny more.

The value proposition is simple and compelling:

Same encoder. Same workflow. Same cost. Half the latency.

By performing LL-HLS conversion at the origin layer, Akamai eliminates the single largest barrier to low-latency adoption: the encoder upgrade. Customers who have invested in reliable, production-proven encoding infrastructure can now unlock the benefits of LL-HLS — Preload Hints, Blocking Playlist Reloads, Rendition Reports, and Delta Playlists — without any disruption to their existing workflows.

For customers who demand the absolute lowest latency, MSL5 Origin also provides a path forward: native LL-HLS ingest is supported on the same platform, so when the time comes to upgrade the encoder, the transition is seamless.

Low-latency live streaming is no longer a costly, complex migration project. With MSL5 Origin, it is a configuration toggle away.

📘

The feature is planned in 3 phases.

Phase I (supported today):

• The encoder must publish standard HLS with a minimum segment duration of one second.
• LL-HLS egress capabilities enabled:
  • Block playlist reload.
  • Calculated preload-hint: computes the next segment name as a preload hint to enable players to pre-establish network connections.

MSL5 will append the preload-hint segment to the ingested manifest. Playlists can leverage block playlist reload and the preload hint for playback with LL-HLS–compatible players.

Phase II (in roadmap planning), with plans to introduce the following capabilities:

• Rendition report delta playlist.
• Multi-part segments (concatenation of input segments into larger output segments).
• Generation of I-frame-only playlists.

Phase III (in roadmap planning):

• Dual output support (standard HLS and LL-HLS).

There is no standardized plan to enable encoders to publish native LL‑HLS directly into MSL5 at this time, due to the absence of a globally accepted specification for LL‑HLS push workflows and the prevalence of proprietary implementations. Support for native LL‑HLS ingest will be delivered on a project‑by‑project basis.