HLS Streaming Output: Adaptive Bitrate for Web Delivery

What is HLS?

HLS (HTTP Live Streaming) is an adaptive bitrate streaming protocol developed by Apple. It works by breaking a continuous video stream into short segments (typically 2-6 seconds each) and serving them over standard HTTP. A manifest file (.m3u8) tells the player which segments are available and at what quality levels. The player downloads segments sequentially, switching between quality tiers based on the viewer’s network conditions.

HLS has become the dominant protocol for video delivery to end users. It works in every modern web browser, on every mobile platform, and behind every CDN. When you watch live video on a website or mobile app, you are almost certainly watching HLS.

HLS in the Vajra Cast Architecture

Vajra Cast supports HLS as an output protocol. This means you can receive streams via SRT, RTMP, or any supported ingest protocol, and distribute them as HLS for web playback. The architecture follows the standard Vajra Cast three-stage flow:

1. Ingest: receive via SRT, RTMP, HTTP/TS, or UDP
2. Process: optional transcoding for adaptive bitrate ladder (hardware-accelerated with Intel QSV/VAAPI)
3. Redistribute: HLS output with configurable segments, served via Vajra Cast’s built-in HTTP server

The HLS output includes a built-in web player with a live latency indicator, so you can verify playback quality without any external tools.

Configuring HLS Output

Basic HLS Output

Adding HLS output to a Vajra Cast route:

1. Create or select an existing route with an active input
2. Add an output and select the HLS protocol
3. Configure segment duration and playlist length
4. The HLS endpoint becomes available immediately at the generated URL

Segment Duration

The segment duration controls the trade-off between latency and reliability:

The total latency is approximately 3x the segment duration (the player typically buffers 2-3 segments before starting playback) plus any encoding and network delay.

Playlist Length

The playlist length determines how many segments are listed in the .m3u8 manifest at any time. A longer playlist gives viewers more buffer to recover from network interruptions, but uses more disk space.

• Minimum recommended: 3 segments
• Standard: 5-10 segments
• DVR-style: 30+ segments (allows viewers to rewind)

HLS Output URL Structure

Vajra Cast generates HLS outputs accessible at:

http://your-server:port/hls/[route-id]/index.m3u8

This URL can be handed directly to any HLS-compatible player (Safari, hls.js, Video.js, VLC) or used as an origin URL for a CDN.

Adaptive Bitrate Streaming

Adaptive bitrate (ABR) is the core value proposition of HLS. Instead of serving a single quality, you encode multiple renditions of the same stream at different resolutions and bitrates. The player automatically selects the best rendition based on available bandwidth.

Building an ABR Ladder

A typical ABR ladder for live streaming:

Transcoding for ABR in Vajra Cast

Creating multiple renditions requires transcoding. Vajra Cast supports hardware-accelerated transcoding via Intel QSV and VAAPI, which means you can generate a full ABR ladder without saturating your CPU:

1. Set your route input to the full-quality source (e.g., 1080p SRT ingest)
2. Add multiple HLS outputs, each configured with a different resolution and bitrate
3. Vajra Cast uses FFmpeg with hardware acceleration to generate each rendition
4. A master playlist references all renditions, and the player selects automatically

For passthrough use cases (single quality, no transcoding), HLS output adds minimal latency and near-zero CPU usage. The stream is simply repackaged from MPEG-TS into HLS segments.

HEVC/H.265 Support

For higher efficiency, Vajra Cast also supports HEVC (H.265) encoding via hardware acceleration. HEVC delivers the same quality at roughly half the bitrate of H.264, reducing bandwidth costs for your CDN. However, HEVC playback support in browsers is still limited (Safari supports it natively; Chrome and Firefox require specific conditions). For maximum compatibility, use H.264 for your ABR ladder and consider HEVC only for controlled playback environments (set-top boxes, native apps).

CDN Integration

HLS is designed for CDN delivery. The segments are standard HTTP files that CDN edge servers cache and distribute efficiently.

Origin Configuration

Vajra Cast acts as the origin server for your HLS stream. The CDN pulls segments from Vajra Cast and caches them at edge locations worldwide:

Origin: http://vajracast-server:port/hls/[route-id]/index.m3u8
         |
         v
CDN Edge (cached) --> Viewer A
CDN Edge (cached) --> Viewer B
CDN Edge (cached) --> Viewer C

CDN Compatibility

Vajra Cast’s HLS output is compatible with all major CDNs:

• Cloudflare Stream / R2: pull from origin, global edge caching
• AWS CloudFront: configure origin with TTL matching segment duration
• Akamai: standard HLS origin pull configuration
• Fastly: real-time caching with instant purge for segment updates
• Bunny CDN: cost-effective option for smaller deployments

Cache Configuration

For live HLS, configure your CDN cache TTL to match your segment duration. If your segments are 4 seconds, set the cache TTL to 4 seconds. This ensures the CDN always serves fresh segments while maximizing cache efficiency.

The .m3u8 manifest should have a shorter TTL (1-2 seconds) so that viewers discover new segments promptly.

Live Viewer Count

Vajra Cast’s HLS output includes built-in viewer counting. Since the HLS server runs inside Vajra Cast, it can track the number of active manifest requests and report an approximate live viewer count in the dashboard. This is useful for monitoring audience size without relying on CDN analytics (which typically have a delay).

Note that when using a CDN, the viewer count in Vajra Cast reflects CDN edge requests to the origin, not individual end-user viewers. For accurate end-user counts with a CDN, use the CDN’s own analytics.

Low-Latency HLS (LL-HLS)

Standard HLS has an inherent latency of 10-30 seconds due to segment buffering. Apple’s Low-Latency HLS (LL-HLS) extension reduces this to 2-5 seconds by:

• Using partial segments (sub-second chunks pushed via HTTP/2)
• Preloading hints that tell the player about upcoming segments
• Blocking playlist requests until new segments are available

LL-HLS is well-suited for interactive use cases (live auctions, sports with real-time engagement). For standard broadcast where 10-15 seconds of latency is acceptable, regular HLS is simpler and more reliable.

HLS vs SRT: Different Jobs

HLS and SRT serve different roles in a streaming architecture:

SRT moves your stream from the source to the gateway. HLS delivers it from the gateway to your audience. Vajra Cast handles both ends of this pipeline.

Next Steps

• Return to the SRT Streaming Gateway Guide for the full architecture overview
• Learn about SRT protocol details for ingest configuration
• See how to bridge RTMP to SRT for legacy encoder compatibility
• Explore OTT streaming infrastructure for building a full streaming platform