A 24/7 linear channel with AWS Elemental MediaTailor is assembled from on-demand assets and, if needed, scheduled live sources. MediaTailor composes playback manifests; your configured origin, not MediaTailor, delivers the underlying media segments.
That separation is the key to a reliable setup. First make sure the origin and assets are ready, then register them with MediaTailor, define channel outputs and a schedule, and test the resulting playback URL in the player and delivery path you intend to use.
Map the channel architecture
Think of the workflow as three cooperating parts: an origin, MediaTailor channel assembly, and a playback client. The origin hosts the media manifests and segments. MediaTailor uses those manifests to assemble a linear playback window that presents individual programmes in schedule order. The player requests that assembled manifest and then fetches the referenced segments from the origin.
This is not a transcoding or storage workflow. Channel assembly does not make incompatible files compatible, and it does not become the delivery location for every segment. If an origin is unreachable or a referenced segment is missing, a well-formed assembled manifest cannot fix that underlying delivery problem. AWS describes channel assembly as manifest-only and explains that segments are delivered from the origin in its channel assembly overview.
A source location tells MediaTailor where the content origin is. A VOD source represents an item of content available there, together with one or more package configurations that describe a manifest and format. A channel output exposes a corresponding source group and playback format. A schedule then arranges configured VOD programmes and, where appropriate, live programming.
| Choice | What it affects | Practical question |
|---|---|---|
| Origin and access method | Where manifests and segments are retrieved | Can the service and the eventual viewer path reach the required objects? |
| HLS or DASH output | Manifest format presented by the channel | Which format does your target player support and actually use? |
| VOD loop or mixed schedule | How the channel fills its running schedule | Does the channel repeat a library, or need live windows as well? |
| Slate break or personalised ad insertion | What happens at scheduled break points | Do you only need a timed placeholder, or an ad decision workflow? |
Decide these points before entering console settings. For example, a devotional channel repeating a prepared programme library may need a VOD loop and a single HLS output for its chosen player. A local news channel may need scheduled clips between live bulletins, and may publish more than one output format if its player requirements call for it. These are planning examples, not guarantees of player compatibility.
If you are planning the viewer-facing playlist as well as the backend schedule, the advice in organising a 24/7 YouTube playlist can help with programme order and repetition. MediaTailor channel assembly is distinct from a YouTube encoder workflow: do not assume that creating a MediaTailor channel automatically sends it to YouTube. Confirm the ingest and distribution path you need separately.
Prepare the media origin and assets
Before creating a source location, confirm that your origin hosts accessible manifests and all media segments those manifests reference. AWS lists Amazon S3, standard web servers, CDNs such as CloudFront, and packaging origins such as AWS Elemental MediaPackage as possible source locations. Choose according to where the content already lives and how the origin is made available to the services and players in your path; the origin choice does not remove the need to test real playback.
Organise assets with predictable paths. Keep a record of each programme's manifest path, intended format, duration and any alternate versions. If a source location has a base URL and an asset manifest is at a relative path beneath it, check that the combined location resolves to the intended manifest rather than to an unrelated directory or a browser-only landing page.
Compatibility deserves attention before you build a long schedule. AWS documents that assets within a package configuration need compatible manifest-derived durations and the same number of child streams. A package set assembled from encodes with different durations or variant counts may not meet that requirement. Per-title or automated ABR workflows can produce such differences; AWS documents them as unsupported where they result in incompatible durations or stream counts. See the VOD source requirements and inspect the manifests rather than relying only on filenames or export labels.
For assets you are preparing specifically for a YouTube-facing output, keep the delivery requirements of that later leg separate from MediaTailor's source requirements. Our guide to YouTube Live settings for a 24/7 nature playlist covers a different ingest path, but is useful when you are checking the player or platform side of a broader workflow. Do not infer that an AWS channel output is itself a YouTube live broadcast.
If your origin requires authentication, set up the access method that matches that origin and your account configuration. AWS documents optional SigV4 authentication for S3 source locations. Keep credentials and access policies within your organisation's usual security practices, and verify access from the actual MediaTailor configuration rather than assuming that an object visible in your own browser is public or service-accessible.
Configure a MediaTailor source location
In the MediaTailor console, create a source location with a recognisable name and the HTTP(S) base URL for the origin. Use a name that makes sense when you return to the configuration later, such as one that identifies the content library or environment. Enter the origin base rather than the individual programme manifest if the intention is to register multiple assets underneath it.
Choose the source access and authentication settings to match the origin. Then check the resulting path with one representative manifest before adding the whole library. Confirm that the manifest is the expected HLS or DASH document, that its referenced child playlists or representations resolve, and that the segments those references name are available through the intended origin.
It helps to distinguish a manifest retrieval test from a complete playback test. Being able to fetch a top-level manifest only proves that one document is reachable. A player must also resolve the child streams and media segments. If a CDN sits in front of the origin, for instance, a stale or inconsistent path can leave the master manifest reachable while one of its segments is not. Test a complete programme through the access path that the channel will use.
The AWS guide to source locations describes the origin options and configuration concept. Console labels may change, so use the current AWS documentation when a field or authentication option differs from what you see. Avoid copying a production URL into a test configuration until you know whether that configuration can access the same content and whether the origin permits it.
Add VOD sources and package configurations
Add each content item as a VOD source under the source location. Give it a useful identifier and point it to the relative location of its manifest. A VOD source is not simply an uploaded file: it is a reference to content that the origin already makes available in a supported package format.
For every format you intend to expose, define a package configuration with the format, manifest location and source group. AWS documents HLS and DASH for this workflow. The channel output is later associated with the source group, so use consistent names and keep a small mapping of asset, package configuration and source group. This becomes especially helpful when a library has both HLS and DASH versions or when a schedule is being updated by someone other than its original author.
Before adding dozens of items, register a small representative set and verify the package assumptions. Check manifest-derived programme duration and the number of child streams for each asset in a package configuration. If one item differs, correct or re-encode the asset set as appropriate before treating it as part of the same compatible group. MediaTailor assembles references; it does not repair an incompatible rendition set.
A practical inventory might look like this:
| Programme | Origin manifest | Package format | Source group | Check before scheduling |
|---|---|---|---|---|
| Morning prayer | Relative HLS manifest path | HLS | hls-main | Duration and child-stream count match the group |
| Bhajan collection | Relative HLS manifest path | HLS | hls-main | Variant set and segment references are reachable |
| News bulletin | Relative DASH manifest path | DASH | dash-news | Intended player accepts the output format |
The entries are examples, not required formats or a recommendation to publish both formats. Your player ecosystem determines which outputs are useful. Do not add an output merely because the console permits it; additional formats also create another path to validate and maintain.
For a channel whose final destination is YouTube, remember that the MediaTailor package configuration is not a substitute for the encoder or ingest setup required by the separate YouTube live workflow. If your current operation uses OBS and a local machine, our guide to keeping a study channel running from a spare PC explains some of the operational questions on that side, without changing what MediaTailor does.
Create the channel and its outputs
Create the channel after the source location and at least the necessary package configurations are in place. Select the playback mode that matches the intended operation. AWS's getting-started example uses loop mode for a continuously repeating VOD channel; that is a useful fit when the schedule is meant to cycle through a library rather than depend on a finite end point.
Define channel outputs to correspond to the source groups in the VOD package configurations. Keep the mapping explicit: an HLS package group should feed the relevant HLS output, and a DASH group should feed its intended DASH output. Check output naming and format before building the schedule, because a schedule entry that references content without a matching output cannot solve a format or package mismatch.
A continuously running channel still needs operational ownership. Decide who can change the source inventory, who may alter the schedule, and how you will notice if a source URL or origin permission changes. Keep a simple change record with the source, programme and output affected. This is more useful during a late-night fault than relying on memory about which asset was edited last.
If you are comparing looped VOD with a schedule that includes live programming, the main trade-off is control versus flexibility. A VOD loop is straightforward to repeat and test. Live sources let you put a real-time programme into the channel, but they introduce another source path and transition behaviour to validate. Plan the schedule and testing around the output formats your viewers actually use, not around the number of options in the console.
Build the schedule and add live programming
Add programmes to the channel schedule by selecting configured sources and arranging them in the intended order. A schedule is the editorial running order. For a simple channel, that might be a set of prepared programmes with a repeated sequence. Check transitions near the end of each item as well as the opening, since incorrect durations or missing segments can become apparent only when one programme hands over to the next.
AWS also documents live sources that can be scheduled alongside VOD-to-live content. Treat a live source as a separate input to configure and validate, not as a magic conversion of any incoming feed. Confirm the live source's manifest and timing behaviour, then test a transition from VOD into live content and back again. If the channel needs a specific wall-clock bulletin time, verify the current schedule options and the eligibility rules in the console documentation; AWS distinguishes relative VOD transitions from absolute wall-clock transitions in eligible configurations.
Ad breaks are optional. For a simple VOD break, AWS's getting-started workflow uses a slate source and an offset. The slate duration sets the break duration, and the offset must fall before the end of the programme and align with segment boundaries across tracks. If those conditions do not hold, the break may be skipped. Check the getting-started channel assembly tutorial for the current workflow and do not treat a configured break as proof that ads will be filled.
A slate provides a defined placeholder, not personalised advertising by itself. If you need viewer-specific ads, that requires an ad insertion or decision workflow and its own testing, policy and inventory arrangements. Neither channel assembly nor the presence of an ad break establishes revenue, filled inventory or an approval outcome. Start by testing a slate break on a non-critical programme, including its timing across the tracks you intend to publish.
Start the channel and test playback
When the sources, outputs and schedule are ready, start the channel and use its playback URL for validation. Open the URL with the player you expect viewers to use. Confirm that it plays, advances through a programme boundary, and continues into the next scheduled item. If you publish multiple formats, test each output separately; success on an HLS player says nothing conclusive about a DASH player.
Watch the requests as well as the picture. The assembled manifest should reflect the expected programme order, while media-segment requests should go to the configured origin or its delivery path. If the manifest loads but video stalls, inspect the referenced segment paths, origin access and player behaviour before changing schedule settings. If a programme transition fails, compare the two package configurations and their manifest-derived characteristics, then check whether their media remains accessible at the transition point.
Test the awkward cases before calling the channel ready: a short asset at a schedule boundary, the end of the loop, a live-to-VOD transition if used, and any slate break. Do this in the actual output format and player combination. A browser preview is useful, but it is not a universal player compatibility test; a mobile app, smart television or downstream platform may handle manifest features differently.
Keep a small runbook with the playback URL, origin paths, package groups, expected schedule and the first checks for a failed programme. If you are sending the output onwards to another platform, document that bridge as a separate system and test it independently. MediaTailor's role remains channel assembly: the configured origin is still responsible for the media segments.
When the operating model you need is an uploaded file turned into a YouTube live stream without keeping your own computer running overnight, StreamNeo removes that specific machine-running burden; it does not replace this AWS channel assembly workflow or act as an AWS-to-YouTube bridge.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does MediaTailor deliver the video segments?
No. MediaTailor channel assembly composes manifests that reference media segments at the configured origin. Your origin or its delivery path must make those segments available to the player.
Can I make a channel from VOD only?
Yes. A VOD schedule can be configured for repeated playback, and AWS's getting-started tutorial uses loop mode. Check asset compatibility and test the transition between items before relying on the schedule.
Can I mix VOD and live programming?
AWS documents live sources that can be scheduled alongside VOD content. Configure and test the live source and each transition in the output format and player you intend to use.
Does an ad break mean an ad will play?
No. A slate break can define a placeholder interval, while personalised ads require an ad insertion workflow and suitable inventory. Confirm the current AWS documentation and your own ad arrangements before relying on a break.