Best practices for using Live Ingest

Live Ingest is an Azion service designed to receive Live Streaming signals and distribute them through Applications. To ensure high-quality transmission, resilience, and availability, it’s essential to follow a set of best practices that maximize the platform’s potential.

This guide presents the main recommendations for configuring and operating Live Ingest, including redundancy strategies, encoder configuration, automated switching usage, and robust player implementation.

Prerequisites

An active Azion account with Live Ingest service enabled.
An encoder compatible with the RTMP protocol.
Basic knowledge of Applications and Cache Settings.
Familiarity with the Rules Engine for Applications.

Configure redundancy with multiple RTMP Endpoints

High availability is fundamental for live broadcasts. Live Ingest supports the configuration of multiple RTMP endpoints, allowing you to create a redundant architecture.

Use Primary and Backup endpoints

Configure two RTMP Endpoints in different geographic regions:

Primary endpoint: main endpoint that will receive the video stream during normal operation.
Backup endpoint: secondary endpoint that will take over the transmission if the primary fails.

This configuration ensures that if there’s degradation or failure at the primary endpoint, the player can automatically redirect the stream to the backup endpoint, keeping the transmission active without interruption for viewers.

Choose different geographic regions

When configuring endpoints, select different regions to minimize the risk of simultaneous failures. For example:

Primary: region closest to your content source for lower latency.
Backup: alternative region with good connectivity and infrastructure equivalent to the primary.

Geographic separation protects against localized problems such as power failures, network issues, or natural disasters that might affect a specific region.

Use approved encoders

Live Ingest requires encoders that support the RTMP protocol with username and password authentication. Using Azion-approved encoders ensures compatibility and optimized performance.

Check the list of approved encoders

Before starting your transmission, verify if your encoder is on the list of Azion-approved equipment. Approved encoders have undergone compatibility tests and offer:

Complete support for the RTMP protocol.
Integration with the switching mechanism.
Optimized configurations for Azion’s infrastructure.
Joint technical support when needed.

Correctly configure the encoder

When configuring your encoder, follow these recommendations:

Ingestion URL: use the URLs provided by Azion for primary and backup endpoints.
Credentials: configure the username and password provided by Azion for RTMP authentication.
Video codec: use H.264 for wide compatibility with players.
Audio codec: use AAC to ensure universal playback.
Keyframe interval: configure to 2 seconds (1 frame every 2 seconds) for HLS.
Bitrate: define bitrates appropriate for your audience and desired quality.

Configure players with fallback support

The video player is the endpoint of the distribution chain and must be prepared to handle failures and degradations. Modern players like hls.js offer advanced fallback features.

Implement live stream fallback

Configure your player to:

Detect loading failures: monitor error events in segment or playlist loading.
Attempt reconnection: implement retry logic with exponential backoff.
Switch between sources: if available, alternate between multiple manifest URLs.
Display clear messages: inform the user about connection issues in a user-friendly way.

Use hls.js for greater robustness

hls.js is a JavaScript library that implements an HLS client. It offers:

Live stream fallback support.
Automatic error detection and recovery.
Advanced buffer and latency configurations.
Compatibility with various browsers.

Example basic configuration with hls.js:

const video = document.getElementById('video');
const hls = new Hls({
  liveDurationInfinity: true,
  liveBackBufferLength: 0,
  maxBufferLength: 30,
  maxMaxBufferLength: 60
});

hls.loadSource('https://your-domain.hls.live.azion.com/stream.m3u8');
hls.attachMedia(video);

hls.on(Hls.Events.ERROR, function(event, data) {
  if (data.fatal) {
    switch(data.type) {
      case Hls.ErrorTypes.NETWORK_ERROR:
        console.log('Network error, trying to recover...');
        hls.startLoad();
        break;
      case Hls.ErrorTypes.MEDIA_ERROR:
        console.log('Media error, trying to recover...');
        hls.recoverMediaError();
        break;
      default:
        console.log('Fatal error, cannot recover');
        hls.destroy();
        break;
    }
  }
});

Monitor your transmissions with Real-Time Metrics

Real-time monitoring is essential for quickly identifying problems and taking corrective actions before they impact viewers.

Track Live Ingest metrics

Real-Time Metrics offers specific indicators for Live Ingest:

Connected users: number of active viewers in the transmission.
Data transferred: volume of distributed data.
Connection status: health of the connection between encoder and endpoint.
Latency: delay time between ingestion and delivery.

Use the GraphQL API for detailed data

The Real-Time Metrics GraphQL API offers the connectedUsersMetrics dataset, which provides real-time aggregated data about users connected to your transmissions.

See the documentation on how to query connected users data with GraphQL API to implement custom monitoring dashboards.

Configure proactive alerts

Set up alerts for:

Drop in the number of connected users (possible transmission failure).
Latency increase above acceptable limits.
Connection failures with ingestion endpoints.
Signal quality degradation.

Optimize cache policies for HLS

Live Ingest automatically converts the RTMP signal to HLS for distribution. Correctly configuring cache policies is fundamental for transmission performance.

Configure cache for video chunks

Chunks (video segments .ts) should have a short TTL (Time To Live) to ensure viewers receive the most recent content:

Browser Cache TTL: 0 seconds (do not store in browser cache).
CDN Cache TTL: 60 seconds (store briefly at the edge for high demand).

Configure cache for playlists

Playlists (.m3u8 files) should have even shorter TTLs to reflect frequent updates:

Browser Cache TTL: 0 seconds.
CDN Cache TTL: 5 seconds or less.

Use Rules Engine to apply policies

Create rules in the Rules Engine to automatically apply the correct cache policies:

Rule for chunks (.ts):

Criteria: if ${uri} matches ".*\.ts$"
Behavior: Set Cache Policy for chunks policy.

Rule for playlists (.m3u8):

Criteria: if ${uri} matches "\.m3u8$"
Behavior: Set Cache Policy for playlists policy.

See the guide Implement HLS cache for detailed instructions.

Prepare for high-demand events

Broadcasts with large audiences require additional preparation to ensure the infrastructure supports the access peak.

Test your configuration before the event

Conduct load tests simulating the expected number of viewers:

Configure your application and ingestion endpoints.
Start a test transmission.
Simulate simultaneous access using load testing tools.
Monitor real-time metrics.
Adjust configurations as needed.

Consider Tiered Cache

Tiered Cache creates an intermediate cache layer that reduces load on origin servers and improves performance for large audiences. For live transmissions with HLS, Tiered Cache can be used as an ingestion component.

Have a contingency plan

Prepare a documented plan with:

Manual failover procedures.
Azion support contacts.
Communication with the audience in case of problems.
Transmission alternatives (social networks, backup platforms).