Live Linear
A live linear stream typically establishes a 24/7 audio/video feed from content captured via SDI or UDP. In addition to mirroring the input signal, it also supports content and ad replacement.
Basic Setup
Set up a live linear stream by configuring the following components:
-
A live channel represents a live linear stream that contains a timeline that identifies live and on-demand content and when it should be played.
-
Slicer
Use a Live Slicer, Cloud Slicer Live, or both to capture and push audio/video content to a live channel's timeline.
-
Live Slicer: A Live Slicer is a Linux daemon.
Use the Channel API to populate a live channel's timeline with pre-encoded content and/or live feeds from additional Live Slicers.
- Cloud Slicer Live: Cloud Slicer Live allows you to run a slicer in our cloud. This allows you to ingest and encode content without on-premise hardware.
-
-
Once a live linear feed has been processed into a stream, it may be played back from anywhere in the world.
If you are setting up a HLS player, you may add support for fast forwarding, rewinding, or pausing and resuming through the Live Timeshifting capability.
How Does it Work?
The following diagram illustrates the flow through which a live linear feed is processed and then streamed to users around the world.
As illustrated above, a stream is generated from a live linear feed through the following phases:
-
Push to Live Slicer
The existing broadcasting infrastructure pushes a live linear feed to a Live Slicer via either UDP or SDI.
-
Slicing
Both the Live Slicer and the Cloud Slicer Live slices, encrypts, and then uploads content to the cloud.
-
Encoding and Storage
Our cloud encoders encode audio/video into H.264/H.265 and AAC. After which, the encoded media is added to cloud storage.
As viewers request the live linear feed, it will be served via our CDN service ensuring an optimal viewing experience by efficiently delivering data all over the world.
Prevent hotlinking by digitally signing the playback URL.
Security measures, such as Blackout, may be applied to the stream to restrict playback to authorized users.
Latency
Latency measures the delay between the capture of the source video and when it is displayed to the viewer.
If you do not see the Playback Latency option, contact Support.
The following illustration provides an overview of components involved in the workflow from video capture to playback.
A short explanation of how each of the above components adds latency is provided below.
| Component | Latency Factors |
|---|---|
|
Slicer |
The amount of time it takes to slice and deliver processed media to our Streaming service. This may be exacerbated by using underpowered hardware or insufficient bandwidth for your encoding profile. |
|
Streaming Service |
The amount of time it takes to decode, encode, and package sliced media into an adaptive bitrate format. |
|
Digital Rights Management (DRM) |
The amount of time it takes to request and generate licenses for content protected by DRM. |
|
|
|
CDN |
The amount of time it takes to cache and deliver your stream to the player. |
|
Player |
The amount of time it takes to initialize and then play your stream. This may be exacerbated by clients that use underpowered hardware or that have insufficient bandwidth. |
| Manifest Engine | Decisioning logic that controls the timing and creation of individual manifests for playback by users. |
Best Practices for Reducing Latency
Reduce latency by applying the following best practices:
The following optimizations are listed in descending order according to the degree to which they will reduce latency.
| Type | Optimization(s) |
|---|---|
|
Playback Profile |
Selectable, pre-figured control file that contains the parameters related to reduced-latency options. Used during manifest creation and driven by selectable latency options. Use the drop-down on the Channel's Details tab and the Live Event's Config tabs. See Selecting playback latency to choose latency options. Selecting a low latency playback option (other than default) may increase the probability of missing content slate and decrease the number of ad fills. Contact our Professional Services Group for assistance on how to optimize this setting for your environment. In addition to the selectable latency settings, a variety of factors, such as the hardware on the computer hosting the Live Slicer, ad workflow, encoding profile, and platform/ player affect the latency achieved, the quality of the customer viewing experience, and the ad monetization. Any latency numbers associated with settings are estimates, and your individual results may vary. Chopping / Dropping Ads Reduce ad-related latency by either chopping or dropping ads upon exceeding ad break duration. Use ad.flex to determine the number of seconds that an ad can extend beyond an ad break before being chopped or dropped. |
|
Player |
Client Use a player (e.g., THEOplayer) that supports two second media segment files and fast startup times. The HLS specification requires that a player wait for three media segments prior to initiating playback. DASH, on the other hand, can initiate playback immediately. This, in theory, allows DASH to offer lower latency than HLS, but in practice, testing has shown little difference between the latencies achieved by HLS or DASH. Different HLS players offer varying degrees of latency. Different protocols and platforms may affect latency beyond the control of Edgio. |
|
|
|
Re-encode Slate (Two Second Media Segments) A player may only switch from slate to your main content once it finishes playing the current media segment. Use slate that has been encoded in two second media segments to reduce the potential amount of time that the player must wait before switching to your main content. This recommendation should be applied regardless of whether your account has been configured to generate two second media segments for your main content. System slate has already been encoded using two second media segments. |
|
|
|
|
Ads |
|
|
Automation / Playout System |
Ad Break Notifications Ensure that upcoming ad breaks are added to the video stream (e.g., via SCTE triggers) with sufficient lead time to allow the ad decisioning server to provide ad creatives to our service. |
|
Adaptive Bitrate Streaming |
Format Both DASH and HLS are supported. |
|
Cloud |
Network Connection If streaming to a cloud-based slicer, ensure optimal egress for your encoded media. Leverage newer streaming protocols such as SRT and RIST, with settings that limit the latency to the recommended minimal values based on the network round-trip time. |
Select the Playback Latency
Default latency for Live Channels and Live Events is 60+ seconds. To reduce latency to ~15 seconds, refer to the Playback Latency for channels and events for setup instructions.
Latency options:
Default: ~60 seconds
Low: Low 20s, 5+ second buffering, Missing Content Slate (MCS) is possible
Lower: Upper teens, 2+ seconds buffering, MCS is possible
Lowest: As low as 15 seconds, minimal buffering, no MCS
Different protocols and platforms may affect latency beyond the control of Edgio.
Important Considerations:
- Many factors are in play for reduced latency. Any latency numbers referenced by Edgio documentation are estimates. Actual results may vary.
- Reducing latency does not currently work with Time Shifting.
- Inconsistent Slate Slice Duration is not recommended and will give unpredictable latency results.
- Four- second profiles may still work but won’t achieve the desired latency results and are unlikely to produce any video at the lowest setting.
- Two-second profiles without Playback Latency settings will give default delays.
- Existing V1 channels will not see the Playback Latency drop-down.
- MCS latency can only be removed via ad-break opportunities or new sessions.
- Player buffering can not be controlled via Edgio's Streaming service.
- Platform specificity may vary latency by multiple seconds.
- Many factors contribute to latency, so playback latency may vary.
- If using a Channel Scheduler with historical, four-second segment assets, you cannot schedule those assets onto an Edgio-enabled channel.
- The act of ‘Creating’ a CSL slicer will always create (/override) a profile to slicer ID mapping, even if using the default profile. Slicer Resets will not update the mapping.
- Due to continued testing, new technology, and other factors, playback profile parameters used by the manifest engine may change from time to time, without notice.
More Information