Configuration - TVIP™ (TV over IP®)

Since FFmpeg is the industry standard for programmatic encoding and OBS is the go-to for desktop streaming, let’s break down how to set both up.

Keep in mind that LL-HLS is a “packaging” format. Often, your encoder sends a stream (via RTMP or SRT) to a Media Server (like Nimble, Wowza, or AWS Elemental), which then converts it into those tiny LL-HLS parts. However, you can also do this directly.

1. FFmpeg Configuration (Direct LL-HLS)

To generate an LL-HLS stream directly from FFmpeg, you need to use the fmp4 segment type and define your “partial segment” duration.

Bash

ffmpeg -re -i input_source -c:v libx264 -preset veryfast -tune zerolatency \
-g 60 -sc_threshold 0 -c:a aac -b:a 128k \
-f hls \
-hls_time 2 \
-hls_list_size 10 \
-hls_flags independent_segments \
-hls_segment_type fmp4 \
-hls_fmp4_init_filename init.mp4 \
-hls_part_duration 0.5 \
-master_pl_name master.m3u8 \
index.m3u8

Key Parameters Explained:

-g 60: Sets the GOP (Group of Pictures) size. If you’re at 30fps, this is a 2-second keyframe interval. This must match or be a multiple of your -hls_time.
-hls_part_duration 0.5: This is the LL-HLS magic. It tells FFmpeg to break the 2-second segments into 500ms chunks.
-hls_segment_type fmp4: LL-HLS requires Fragmented MP4, not the old .ts chunks.
-tune zerolatency: Forces the x264 encoder to output frames immediately rather than buffering them.

2. OBS to LL-HLS Workflow

OBS doesn’t “output” an LL-HLS playlist directly very well. The standard way to do this is to send an SRT or RTMP feed to a server that handles the LL-HLS packaging.

Step A: OBS Settings (The Feed)

Settings > Output > Output Mode: Advanced.
Keyframe Interval: Set this to 2s. (Crucial: LL-HLS will fail or lag if this is “Auto”).
CPU Usage Preset: veryfast or superfast.
Tune: zerolatency.

Step B: The Server (The Packager)

You would point OBS to a service that supports LL-HLS. Common choices include:

Nimble Streamer: Known for the best LL-HLS implementation.
AWS Elemental MediaStore: High-scale enterprise delivery.
Cloudflare Stream: Handles the packaging and CDN delivery automatically.

3. Playback Verification

You can’t test LL-HLS in a standard browser like Chrome without a library. To see if your low-latency is actually working, use:

Safari: Native support on macOS/iOS.
HLS.js Demo: Use the official HLS.js player test page and look for the “Latency” metric in the stats.

A Quick Tip on CDNs

If you are using a CDN (like Akamai or CloudFront), ensure HTTP/2 is enabled. LL-HLS creates a high volume of small requests (the partial segments); without HTTP/2’s “request multiplexing,” those requests will queue up and actually increase your latency.

To set up Low Latency HLS (LL-HLS) using AWS Elemental MediaLive for delivery to Apple devices, you need a three-part architecture: the Encoder (MediaLive), the Packager (MediaPackage v2), and the Edge (CloudFront or other CDNs compliant with Apple’s specifications).

“Apple’s Edge Nodes” typically refers to the requirement that your CDN (Content Delivery Network) must support specific LL-HLS features like HTTP/2, Blocking Playlist Reloads, and Query String forwarding to qualify as a valid delivery point for Apple’s protocol.

1. AWS Elemental MediaLive (The Encoder)

MediaLive needs to produce a high-quality, fragmented stream with very short keyframe intervals so the downstream packager can “slice” it into partial segments.

Output Group: Use HLS or CMAF Ingest.
Segment Length: Set to 1 or 2 seconds. (1s is preferred for ultra-low latency).
GOP Structure:
- GOP Size: Must match your segment length exactly (e.g., 1.0 seconds).
- GOP Size Units: Seconds.
Container Format: Use fMP4 (Fragmented MP4). LL-HLS does NOT support the older .ts segments.
B-Frames: Set to 0 or 1. (Too many B-frames increase encoding delay).

2. AWS Elemental MediaPackage v2 (The Packager)

While MediaLive encodes the video, MediaPackage v2 is the service that actually generates the “Partial Segments” (parts) and the specific LL-HLS manifest tags.

Channel Type: Create a MediaPackage v2 Channel.
Origin Endpoint: Create an LL-HLS endpoint.
Partial Segment Duration: Set this to 200ms – 500ms. This is the secret to the low latency.
Manifest Settings: Ensure Low-latency HLS is toggled ON.
CORS: Ensure “Access-Control-Allow-Origin” is set to * to allow Apple’s AVPlayer to fetch segments across different domains.

3. Apple-Compliant Edge Nodes (CloudFront)

Apple’s specification (RFC 8216) requires the edge nodes (the CDN) to behave intelligently rather than just being a “dumb” file cache.

Necessary CloudFront Policies:

To make CloudFront act as an “Apple-ready” edge node, you must configure a Cache Policy that forwards these specific query strings:

_HLS_msn: The Media Sequence Number.
_HLS_part: The specific partial segment.
_HLS_skip: Used for playlist delta updates.

Protocol Requirements:

HTTP/2 or HTTP/3: Required. Standard HLS can run on HTTP/1.1, but LL-HLS will fail or lag significantly without the multiplexing features of HTTP/2.
Origin Request Policy: You must enable Origin Shield to prevent “thundering herd” issues where thousands of players request the same tiny 200ms part at the exact same millisecond.

Technical Summary Table

Component	Setting	Recommendation
MediaLive	GOP / Keyframe	1 second
MediaLive	Container	fMP4
MediaPackage v2	Part Duration	300ms
Edge (CDN)	Protocol	HTTP/2 (Mandatory)
Edge (CDN)	Cache Key	*Include `_HLS_` Query Strings**

Pro-Tip: Testing with Apple’s Tools

If you want to verify that your MediaLive output is truly “Apple-compliant,” use the Apple Media Stream Validator (Apple Developer website). Run this command against your CloudFront URL: mediastreamvalidator -p -l trace https://your-cdn.com/master.m3u8

It will give you a “Pass/Fail” specifically for Low Latency requirements.

For Apple’s Low Latency HLS (LL-HLS) to work, CloudFront (acting as the “Edge Node”) must be configured to support the specific signaling Apple uses to request data before it exists.

Below is the standard configuration for AWS Elemental MediaLive feeding MediaPackage v2, delivered via CloudFront.

1. CloudFront Cache Policy (JSON)

The most critical part of an LL-HLS edge node is the Cache Key. You must tell CloudFront to treat a request for playlist.m3u8?_HLS_msn=10 as a different object than playlist.m3u8?_HLS_msn=11.

Create a Custom Cache Policy with these settings:

JSON

{
  "CachePolicyConfig": {
    "Name": "LLHLS-Cache-Policy",
    "DefaultTTL": 1,
    "MaxTTL": 31536000,
    "MinTTL": 1,
    "ParametersInCacheKeyAndForwardedToOrigin": {
      "EnableAcceptEncodingGzip": true,
      "HeadersConfig": { "HeaderBehavior": "none" },
      "CookiesConfig": { "CookieBehavior": "none" },
      "QueryStringsConfig": {
        "QueryStringBehavior": "whitelist",
        "QueryStrings": {
          "Items": [
            "_HLS_msn",
            "_HLS_part",
            "_HLS_skip",
            "_HLS_report"
          ]
        }
      }
    }
  }
}

Why these Query Strings?

_HLS_msn: The Media Sequence Number the player is waiting for.
_HLS_part: The specific “Partial Segment” (the tiny 300ms chunk).
_HLS_skip: Used for “Delta Updates” (only sending what changed in the playlist).
_HLS_report: Used for “Rendition Reports” so the player can switch bitrates quickly.

2. CloudFront Origin Request Policy

Even if you cache based on these strings, you must forward them to the origin (MediaPackage). If you don’t forward them, the origin won’t know the player is requesting a “Blocking Reload” and will just send the old playlist.

Policy Type: Custom
Query Strings: All (or the whitelist above)
Headers: Forward the Origin header (required for CORS on Apple devices).

3. MediaPackage v2 LL-HLS Endpoint

In the AWS Console for MediaPackage v2, create an HLS Endpoint and ensure the following:

Segment Duration: 2 seconds.
Partial Segment Duration: 333ms (this creates 6 parts per segment).
Low-Latency HLS: Enabled (Toggle).
Manifest Filtering: Enabled.

4. Critical “Edge” Requirements

For CloudFront to qualify as an Apple-compliant edge node, verify these three final settings:

HTTP/2 or HTTP/3: You must enable this in the CloudFront General settings. Standard HLS over HTTP/1.1 will experience “Head-of-Line blocking,” which destroys low latency.
Origin Shield: Enable this in the Origin settings. It ensures that multiple edge nodes don’t “hammer” MediaPackage for the same 300ms chunk simultaneously; instead, they pull from a single regional cache.
Response Timeout: Set the Origin Response Timeout to at least 30 seconds. In LL-HLS, the player might request a segment that doesn’t exist yet. The server “holds” the connection open until the segment is ready. If CloudFront’s timeout is too short (default is 30s, but check yours), it will drop the connection before the video frame is actually captured.

Summary of the “Glass-to-Glass” Path

Encoder (MediaLive): Chops video into 1s or 2s chunks.
Packager (MediaPackage): Slices those chunks into 300ms “Parts.”
Edge (CloudFront): Forwards the “I’m waiting for Part 5” query string to the packager.
Player (Safari/AVPlayer): Downloads Part 5 the instant it’s encoded, before the full 2s segment is even finished.

To verify that your AWS/CloudFront setup is truly “Apple-compliant” for Low Latency HLS, you should use the official Apple Media Stream Validator.

This tool is a command-line utility (available for macOS via the Apple Developer website) that simulates a real player and flags any protocol violations that would cause lag or playback failure on iPhones and Apple TVs.

1. The Validation Command

Run this command in your terminal to perform a deep-trace validation of your LL-HLS stream:

Bash

mediastreamvalidator -p -l trace https://your-cloudfront-url.com/master.m3u8

Breakdown of Flags:

-p: Crucial. This tells the validator to prioritize Low Latency checks. Without this, it might treat your stream as standard HLS and ignore partial segment errors.
-l trace: Provides a line-by-line log of every request. This is helpful to see if CloudFront is correctly handling the _HLS_msn and _HLS_part query strings.
https://...: Your CloudFront distribution URL pointing to the master playlist.

2. Generating a Visual Report

The terminal output can be dense. Apple provides a companion tool called hlsreport to turn that data into a readable HTML dashboard.

Save the validation data to a file: Bashmediastreamvalidator -p -O validation.json https://your-cloudfront-url.com/master.m3u8
Generate the HTML report:Bashhlsreport validation.json
Open the result: This creates a file named validation.html. Open it in your browser.

3. What to Look For in the Report

When you open the HTML report, look specifically for these LL-HLS indicators:

Must Fix Issues: If you see “Playlist update took too long,” your CloudFront cache policy or Origin Shield is likely misconfigured.
Partial Segment Presence: The report should confirm it sees EXT-X-PART tags. If it doesn’t, your MediaPackage v2 settings are likely still set to “Standard HLS.”
Preload Hints: Ensure EXT-X-PRELOAD-HINT is present. This is what allows the player to “pre-fetch” the next chunk of video before it even exists.

4. Alternative: Web-Based Debugging

If you don’t have access to a Mac, you can use the HLS.js Functional Demo. This is the industry-standard way to debug LL-HLS in a browser (Chrome/Edge/Firefox).

Go to the HLS.js Demo Page.
Paste your CloudFront URL.
Check the “Real-time Metrics” tab.
Look for “Latency”—if your setup is working, this number should stay consistently between 1.5s and 4s.

Paste the error message or a snippet from your validation.json report here. In the meantime, here is a guide to interpreting the most common “Must Fix” errors that appear when using MediaLive, MediaPackage, and CloudFront.

1. Common Validator “Must Fix” Errors

Error Message	Meaning	Likely Fix
“Playlist update took X seconds (Target: Y)”	The player requested a new playlist, but the server didn’t respond fast enough.	Origin Shield: Enable CloudFront Origin Shield. Timeout: Increase CloudFront “Origin Response Timeout” to 30s+.
“Missing EXT-X-PART tags”	The validator sees a standard HLS stream, not a Low Latency one.	MediaPackage: Ensure the “Low-latency HLS” toggle is ON in your endpoint settings.
“Preload hint refers to a non-existent part”	The server promised a part was coming but never delivered it.	Encoder: Check if MediaLive is dropping frames or has an unstable GOP (ensure Keyframe Interval is exactly 1s or 2s).
“Measured latency exceeds target”	The stream is technically working, but it’s too slow for LL-HLS.	CDN: Verify HTTP/2 is enabled. Standard HTTP/1.1 cannot handle the rapid-fire requests LL-HLS requires.

2. CloudFront & MediaPackage Errors (HTTP Codes)

If you are looking at your CloudFront Access Logs or browser console, these codes point to specific misconfigurations:

HTTP 403 (Forbidden)

The Cause: MediaPackage is rejecting the request from CloudFront.
The Fix: Check your MediaPackage Endpoint Policy. If you use “CDN Authorization,” ensure the CloudFront secret (header) matches what MediaPackage expects.

HTTP 404 (Not Found)

The Cause: The player is asking for a “Part” that has already “rolled off” the playlist or hasn’t been created.
The Fix: Increase the “Startover Window” or “Manifest Window” in MediaPackage. If it’s too short, the parts disappear before the CDN can cache them.

HTTP 504 (Gateway Timeout)

The Cause: This is unique to LL-HLS “Blocking Reloads.” The player asks for a segment that is 200ms away from being finished. CloudFront waits, but its internal timer runs out before the video frame arrives.
The Fix: Go to CloudFront > Origins > Edit and set Origin Response Timeout to 60 seconds.

3. How to read the “HLS Report”

When you run hlsreport validation.json, pay attention to the “Media Playlist” section.

Green: Your tags (EXT-X-PART, EXT-X-SKIP) are correctly formatted.
Yellow (Should Fix): Usually minor bitrate mismatches. Safari will still play these.
Red (Must Fix): These will cause the “Low Latency” toggle in the Apple player to disappear, and the stream will lag by 20+ seconds.

Apple’s Edge Cache (AEC) is a proprietary network of servers and hardware managed by Apple and deployed directly within Internet Service Provider (ISP) networks. While most companies use third-party CDNs (like CloudFront or Akamai), Apple uses AEC to deliver its own high-traffic content—including App Store downloads, iOS updates, and Low Latency HLS (LL-HLS) streams—from the “deepest” possible point in the network.

In the context of LL-HLS, AEC acts as the specialized delivery node that understands the protocol’s advanced signaling, such as “blocking reloads” and “preload hints.”

The 4 Core Behaviors of AEC in LL-HLS

For LL-HLS to reach sub-3-second latency, the AEC does more than just store files; it acts as a smart proxy that manages the “future” of the stream.

1. Blocking Playlist Reloads

AEC implements the _HLS_msn (Media Sequence Number) and _HLS_part query parameters. When a player asks for a segment that doesn’t exist yet, the AEC doesn’t return a 404. Instead, it holds the request open (blocks) and responds the exact millisecond the origin produces the data.

2. Preload Hints

The AEC understands the EXT-X-PRELOAD-HINT tag. It allows the player to request the next partial segment before it is even encoded. The AEC coordinates this “long-poll” request so the data flows to the player with zero discovery overhead.

3. HTTP/2 and HTTP/3 Multiplexing

Standard HLS can run on old HTTP/1.1, but LL-HLS creates a “thundering herd” of tiny requests (every 200–300ms). AEC uses HTTP/2 multiplexing to send these small parts over a single connection, preventing “Head-of-Line blocking” which would otherwise cause the video to buffer.

4. Delta Updates

AEC can serve “Playlist Deltas.” Instead of sending a massive 100KB playlist every time a 200ms part is added, AEC sends only the few lines that changed, reducing the “overhead-to-video” ratio significantly.

The Complete LL-HLS Workflow with AEC

To deliver a stream via Apple’s Edge Cache, the workflow follows this path:

Capture & Encode (MediaLive): The live source is encoded into fMP4 with a strict 1s or 2s GOP (Group of Pictures).
Packaging (MediaPackage v2): MediaLive pushes the stream to a packager that slices the video into “Partial Segments” (e.g., 300ms chunks) and adds the LL-HLS tags to the playlist.
Origin Store: The packager acts as the origin. It stores the .m3u8 playlists and .m4s segments.
AEC Ingest (The Edge):
- When an Apple device (iPhone/Apple TV) requests the stream, it hits the AEC node inside its own ISP’s network.
- AEC fetches the playlist from the Origin and caches the static segments.
The Blocking Loop: The player sends a request to AEC: “Give me Part 5 of Segment 100 when it’s ready.” 6. Delivery: The AEC holds that request until the Origin pushes Part 5. The AEC then instantly “streams” that part to the user.

AEC vs. Standard CDN

Feature	Standard CDN (e.g., CloudFront)	Apple Edge Cache (AEC)
Location	Global PoPs (Points of Presence)	Inside ISP Data Centers (Closer to user)
LL-HLS Knowledge	Requires custom Cache Policies	Natively optimized for HLS spec
Request Handling	Often treats queries as static files	Handles “Blocking” and “Holding” logic
Primary Goal	General web traffic / Video	Last-mile delivery for Apple Ecosystem

Pro-Tip: If you are an enterprise broadcaster, you don’t “buy” AEC directly. Instead, you ensure your origin (like MediaPackage) is configured correctly to Apple’s specs. When Apple devices play your content, the network is designed to prefer AEC nodes if they are available in the user’s ISP, effectively “boosting” your stream performance for iOS/macOS users automatically.

Verify if a user’s device is successfully pulling from an AEC node versus a standard origin?

To verify if your traffic is hitting Apple’s Edge Cache (AEC) instead of a general-purpose CDN (like standard CloudFront or Akamai), you need to look for specific “fingerprints” in the HTTP response headers.

AEC is unique because it isn’t just a “storage bucket” at the edge; it is a protocol-aware proxy that understands the state of your live stream.

1. How to Identify AEC in your Logs

If an Apple device (iPhone, iPad, Apple TV) is pulling your LL-HLS stream, Safari’s Web Inspector or a proxy tool (like Charles or Proxyman) will show these specific headers if AEC is active:

X-Apple-Edge-Response-Time: This is the most definitive “smoking gun.” It represents the internal processing time (in milliseconds) of the Apple Edge node. If you see this, you are on Apple’s internal infrastructure.
X-Responding-Instance: Often contains a string like carddav:... or a unique ID that identifies the specific hardware node inside the ISP.
Server: Apple or Server: AppleS3: While many origins mask the server header, AEC often identifies itself simply as Apple.
IP Ownership: If you perform a “WhoIs” lookup on the IP address delivering the data, it will often belong to a local ISP (e.g., Comcast, AT&T, Swisscom) but the headers will remain Apple-branded. This is because AEC nodes are physically located inside those ISP data centers.

2. The AEC + LL-HLS Workflow

The AEC doesn’t just pass traffic; it actively manages the “Blocking Reload” mechanism that makes Low Latency HLS possible.

The “Holding” Step

In a standard HLS workflow, if a player asks for a segment that isn’t ready, the CDN returns a 404 Error. In an AEC-optimized workflow:

Player Request: The iPhone sends a request with _HLS_msn=100&_HLS_part=2.
AEC Interception: The AEC node sees that Segment 100, Part 2 isn’t in its cache yet.
The “Block”: Instead of failing, the AEC node holds the connection open. It knows the origin (your CloudFront/MediaPackage setup) is about to produce this part.
Instant Delivery: As soon as your origin finishes the 200ms part and sends it to AEC, the node immediately flushes that data to the player.

3. Why This Workflow Matters for You

If you are using AWS CloudFront, you are essentially using a “Multi-CDN” strategy without realizing it.

Non-Apple Devices: (e.g., Android/Chrome) will hit CloudFront Edge Locations.
Apple Devices: Will often bypass CloudFront’s edge and hit the AEC node inside their ISP if Apple has peered there.

The “Critical Path” for LL-HLS

Component	Responsibility
Origin (AWS)	Must support `_HLS_msn` and `_HLS_part` query parameters.
CloudFront	Must be configured to “Forward all Query Strings” so the AEC node’s requests reach the origin.
AEC Node	Maintains the “Long-poll” connection to the user to reduce the Time to First Byte (TTFB).

4. Verification Checklist

To confirm your AEC workflow is healthy, check for these three things in your Safari Web Inspector:

Status 200 (not 404): Even for parts that “don’t exist yet,” you should see the request pending (greyed out) and then suddenly turn into a 200 OK.
Protocol HTTP/2 or HTTP/3: AEC requires these. If you see HTTP/1.1, the low-latency features are disabled and the player will fall back to standard 12-second latency.
Presence of X-Apple-Edge-Response-Time: If this is missing, the request is likely going through a generic proxy or a misconfigured CDN path that is stripping Apple’s optimizations.

To finalize your setup, the most important step is ensuring that the Apple Edge Cache (AEC) can communicate effectively with your origin (MediaPackage).

AEC acts as a middleman. For it to “hold” requests and handle “blocking reloads,” CloudFront must be configured to pass through the specific signals Apple uses.

1. CloudFront Cache Policy JSON

Create a custom Cache Policy in AWS CloudFront. This policy ensures that the AEC and CloudFront are looking for the same data segments by including Apple’s specific query strings in the Cache Key.

JSON

{
  "CachePolicyConfig": {
    "Name": "Apple-LLHLS-Policy",
    "DefaultTTL": 1,
    "MaxTTL": 31536000,
    "MinTTL": 0,
    "ParametersInCacheKeyAndForwardedToOrigin": {
      "EnableAcceptEncodingGzip": true,
      "HeadersConfig": { 
        "HeaderBehavior": "whitelist",
        "Headers": { "Items": ["Origin"] }
      },
      "CookiesConfig": { "CookieBehavior": "none" },
      "QueryStringsConfig": {
        "QueryStringBehavior": "whitelist",
        "QueryStrings": {
          "Items": [
            "_HLS_msn",
            "_HLS_part",
            "_HLS_skip",
            "_HLS_report"
          ]
        }
      }
    }
  }
}

Critical Component: The Header

Origin Header: You must whitelist this header to ensure CORS (Cross-Origin Resource Sharing) works. Apple devices will block your stream if the Access-Control-Allow-Origin header isn’t properly handled between the AEC and your AWS origin.

2. Origin Request Policy

A common mistake is configuring the Cache Policy but forgetting the Origin Request Policy.

Action: Set your Origin Request Policy to “AllViewerExceptHostHeader” or a custom policy that forwards all query strings.
Reason: If CloudFront doesn’t forward the _HLS_msn parameter, your MediaPackage origin won’t know it needs to “hold” the request until the next video frame is ready.

3. Architecture Overview: The Path to AEC

When an iPhone user plays your stream, the workflow looks like this:

Request: The iPhone sends a request to an AEC node located inside their ISP (e.g., AT&T or Comcast).
The Wait: The request includes _HLS_msn=100. The AEC node checks its cache. If Segment 100 isn’t there, it forwards the request to CloudFront.
The Origin: CloudFront forwards it to MediaPackage v2.
The Blocking Reload: MediaPackage sees the player is asking for a future segment. It “hangs” the request for up to 3x the target duration.
The Delivery: As soon as MediaLive finishes encoding that segment, it flows:MediaPackage $\rightarrow$ CloudFront $\rightarrow$ AEC $\rightarrow$ iPhone.

4. Final Verification

Once deployed, open your stream in Safari on macOS and use the Web Inspector (Cmd+Option+I).

Go to the Network tab.
Click on a .m3u8 or .m4s request.
Look for the header: X-Cache: Miss from cloudfront but Status: 200.
If the request stayed in a “Pending” state for a fraction of a second before finishing, your Blocking Reload is working perfectly through the AEC.