Creating an AWS Elemental MediaLive channel means connecting an upstream source to a channel configuration and a downstream destination. Create the input first, configure the channel and output plan around your actual workflow, then start only when the source and destination are ready.
MediaLive does not supply your programme source or decide where viewers receive the result. You need to know how content reaches MediaLive and where its output must go; those choices determine the input, channel class, output group and settings.
Prepare the source and downstream workflow
Before opening the channel wizard, write down the path from source to audience. Identify the system that provides the video and audio, the protocol it uses, whether it pushes content or MediaLive pulls it, and the downstream service or endpoint that will receive the encoded output. Also note the video, audio and caption renditions that workflow requires. These are decisions for your source and destination, not generic values to copy from another channel.
AWS describes an input as a connection between an upstream address and a MediaLive address. Content can arrive as a push from the upstream system or a pull by MediaLive. The protocol determines the setup, and the upstream operator may need to configure its side before you can use the input. Review AWS’s input setup documentation for the input type you plan to use.
For a push, arrange with the source operator who will configure the sending system and which source IP addresses it will use. For a pull, obtain the source URL or URLs and any credentials or access arrangements required. Do not assume that a camera, capture card or local encoder is necessary: your source might already be another service or production system.
Then trace the other end. Is the destination an HLS workflow, an RTMP endpoint, or something else supported by the output group you intend to use? Ask the receiving service for its required destination details, authentication method and stream requirements. HLS destinations documented by AWS include S3, MediaStore, MediaPackage and HTTP servers; MediaPackage is one example, not a prerequisite. See the AWS overview of HLS output groups and verify destination-specific instructions before configuring anything.
A short worksheet prevents the common mistake of creating a channel before anyone has arranged its source or delivery path:
| Decision | Confirm before setup | Why it matters |
|---|---|---|
| Source and protocol | The upstream system, protocol and push or pull arrangement | Input configuration is protocol-specific |
| Pipeline arrangement | Whether the source can provide the endpoints needed for the intended class | Standard and single-pipeline arrangements have different source-side details |
| Destination | The receiving service, output type and its connection requirements | A channel needs an output plan that matches its downstream workflow |
| Encodes | Required video, audio, captions and any manifest or ad-marker needs | These choices shape the output group and stream settings |
If the destination is YouTube Live, confirm the ingest details from YouTube’s current live streaming help and coordinate an output that the receiving workflow supports. Do not assume that a MediaLive channel is itself a YouTube destination, or that a YouTube stream key can be used in every output configuration. The receiving platform’s requirements and the MediaLive output type have to match.
Create the MediaLive input
Create the input before building the channel. In the MediaLive console, select the input type that matches how the source will deliver content, then supply the source-side details that type requires. The console’s available fields and required configuration vary by protocol; follow the relevant AWS instructions rather than transplanting values from an example using a different input.
For a public RTMP push, coordinate the application and stream names with the upstream operator and identify the public IP addresses from which the source will send. Configure an input security group to allow those source IPs. This is a source access control, not a destination setting. AWS provides the input destinations for the upstream system to use after the input is configured. For a standard arrangement, AWS documents two destinations; for a single-pipeline arrangement, it documents one. Make sure the source operator has the appropriate endpoint details for the class you intend to use.
An HLS input is a different case: MediaLive pulls from the source URLs when the channel starts. Gather the required URLs and credentials before creating it. AWS documents two source URL fields for a standard HLS input and one for a single-class input. Those are protocol-specific details, not a general rule for RTMP or all other inputs. If access depends on credentials, follow the AWS and source-provider instructions for storing and providing them; avoid putting secrets in shared notes or publishing them in a configuration example.
Once you create the input, keep its name and details with the channel plan. Creating it does not start delivery, and it does not prove the source is already sending or reachable. The upstream system still needs to be configured for a push, or the pull source still needs to be available when MediaLive attempts to fetch it. If you are building a long-running YouTube workflow from a local machine, this distinction is useful alongside a separate guide to configuring an Ubuntu VPS for FFmpeg and YouTube Live; that guide addresses a different streaming path, not a substitute input configuration for MediaLive.
Create the channel and select its IAM role
After the input exists, create a regular channel in MediaLive and give it a useful name. Select the IAM role requested for the channel according to your AWS account’s policy and the permissions needed for the resources in your workflow. The role is part of authorising the channel to work with related AWS resources; do not choose a role merely because its name looks familiar. If the required role is unclear, ask the AWS administrator for the account or consult the relevant AWS permissions documentation before proceeding.
The channel wizard asks for channel details, including class, input specification and output delivery configuration. The AWS channel creation instructions describe the fields and choices. Treat the wizard as a configuration sequence, not as a magic setup that fills in a source or destination: you still need to attach your input and configure the intended output group.
If your plan involves a MediaLive Anywhere channel, stop and follow its specific placement requirements rather than selecting placement options arbitrarily. AWS documents additional constraints for Anywhere, including channel-class and delivery requirements. Those settings are not a general instruction for regular channels, so readers creating a regular channel should not add Anywhere placement choices without a reason.
Choose a channel class and input specification
For a regular channel, choose between standard and single-pipeline based on the source arrangement and the pipeline design you want. Standard and single-pipeline do not mean that every input has identical redundancy behaviour. Check what the source can provide and what the rest of your workflow expects, then ensure the input’s endpoints or URLs line up with that class. For public RTMP push, AWS documents two destinations for standard and one for single-pipeline; for HLS, it documents the corresponding source URL fields for those arrangements.
| Choice | Source-side arrangement to plan for | Consider it when |
|---|---|---|
| Standard | The input setup may require two source destinations or URL fields, depending on protocol | Your source and intended pipeline arrangement support the documented standard setup |
| Single-pipeline | The input setup may require one source destination or URL field, depending on protocol | Your source and intended pipeline arrangement match the single-pipeline design |
This table is a planning aid, not a promise that a particular input behaves the same way across protocols. Check the AWS instructions for your specific input type before locking in the class. If the source cannot provide the required arrangement, resolve that with the source operator or revise the design before you create a channel around it.
The input specification should reflect the source content’s characteristics as required by the channel configuration. Use the source’s actual format and the choices presented in the console and documentation; do not pick a setting by copying a tutorial that uses different content. A mismatch can create avoidable configuration or processing problems, while a suitable selection does not replace the need to check the output’s requirements.
This is also a good moment to distinguish the input from the encoded outputs. The input describes what MediaLive receives. The output settings describe what it produces for the destination. A channel can have a correctly selected input specification and still be incomplete if its output group does not fit the receiving service.
Attach the input to the channel
In the channel configuration, select the input you created and attach it to the channel. Confirm that you have selected the intended input, especially if your account contains multiple sources with similar names. The channel’s input selection is the link between its processing configuration and the upstream content path; merely having an input listed in MediaLive does not attach it automatically to every channel.
Check the input details against the source plan before moving on. For a push input, confirm the upstream operator has the correct AWS-provided destination details and that the relevant access controls reflect the source addresses. For a pull input, check the URLs and credentials against the source provider’s current details. These checks establish that the configuration corresponds to the agreed workflow; they are not a guarantee that content is flowing or that the source will remain available.
When you work with an external source team, keep a record of which input and channel they are discussing, without copying secrets into general-purpose documents. If you are managing a YouTube channel alongside other production tools, keep its stream-key handling separate from MediaLive’s input credentials. A guide to custom YouTube stream keys can help with encoder-side key management, but it does not change the MediaLive input’s protocol-specific setup.
Configure output groups and encodes
Add an output group that matches the receiving workflow you identified at the start. Select HLS, RTMP or another supported type according to the destination’s requirements, then configure its destination and stream settings. The destination is not created just because you choose a group type: you need the actual endpoint or service details and any required access information from the receiver.
For HLS, configure the destination and the outputs and stream settings the receiving workflow needs. Depending on the delivery plan, the group can also involve manifest options, encryption or DRM, captions, and ad markers. Include these only where the destination and programme workflow call for them. AWS’s HLS output-group guide describes the configuration path, while the destination service’s own documentation determines its requirements. HLS is not limited to MediaPackage; AWS documents several possible destination types.
For an RTMP output group, configure the destination and connection settings for the receiver. AWS documents one output in an RTMP output group, with stream settings for that output. That does not mean every destination should use RTMP; select it only where it suits the receiving workflow. If the receiver is YouTube, compare its current ingest instructions with the MediaLive options and confirm that the chosen connection details are supported before saving.
Plan each encode from a requirement, not from a universal recipe. A small devotional channel, a local news loop and a study stream may have different content, audio, caption and distribution needs. Start with what the destination accepts and what the programme actually contains. If you do not need captions, ad markers or DRM, do not add them simply because the console offers a field. Conversely, if a downstream workflow requires them, treat that as a dependency and configure it before starting.
Handle credentials with care. In AWS’s getting-started example for MediaPackage, destination URLs and credentials are configured in the HLS group, and the example stores passwords in Systems Manager Parameter Store. Follow current AWS and destination guidance for your own account; do not publish credentials in a tutorial, paste them into an unsecured shared document, or assume that an example password mechanism is appropriate for every workflow.
The distinction between an output group and a finished broadcast is worth keeping clear. The output group describes where and how MediaLive should send encoded content. It does not confirm that the downstream service has provisioned the destination, accepted credentials, or is ready to receive. If the receiving end is not ready, resolve that first rather than using a start attempt as a substitute for coordination.
Save, verify readiness, and start
Save the channel configuration after the input, class, input specification and output group reflect your plan. Review the summary for the intended input and destination, and check that required fields and access arrangements have been addressed. AWS setup documentation supports the sequence of configuring the channel and then starting it, but it does not provide one universal operational checklist for every protocol and destination.
Before starting, coordinate with both ends. The upstream source should be ready to push or available for MediaLive to pull, as appropriate. The downstream service should have the destination and any required credentials or receiving configuration in place. For an HLS pull input, remember that MediaLive connects and pulls when the channel starts. This makes source availability at start time an important dependency, not a setting you can fix by creating the channel earlier.
Start the channel only when those dependencies are in place, then use the MediaLive and destination monitoring guidance appropriate to your input and output types. Look for the relevant indicators in the AWS console and receiving service, but consult their current protocol-specific documentation rather than assuming a particular status label or universal readiness test. If content does not appear as expected, check the path in order: source delivery and access, selected input, channel configuration, output destination and receiver-side acceptance.
For a channel intended to run continuously, plan who will respond when the source or destination changes and how you will notice interruptions. AWS MediaLive configuration does not remove the need to monitor the wider workflow. A practical troubleshooting guide for a 24/7 YouTube stream that stops on a streaming service can help frame incident checks on the broader delivery path, without substituting for AWS’s service-specific monitoring instructions.
If your actual need is simply to keep one prepared video running as a YouTube live broadcast, rather than operate an AWS source-to-destination encoding workflow, choose a process that fits that need. StreamNeo is useful in that narrower case because uploading the file once avoids keeping your own computer switched on to relay it continuously; it is not a MediaLive replacement for workflows that need custom live sources, output groups or AWS control.
Once you have confirmed that MediaLive is the right fit, the order is straightforward: prepare the source, create its input, create and configure the channel, attach the input, build the output for the receiving service, and start after both ends are ready.
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 creating a MediaLive channel provide a video source?
No. You must have an upstream source and create the appropriate MediaLive input to connect it. The source may push content or MediaLive may pull it, depending on the protocol and workflow.
Should I create the input or the channel first?
Create the input first, then create the channel and attach that input. This makes the source configuration available as a channel dependency and helps expose protocol-specific details before you configure the rest.
Is MediaPackage required for HLS output?
No. MediaPackage is one documented HLS destination example. AWS also documents HLS destinations such as S3, MediaStore and HTTP servers, so select the destination that fits your receiving workflow and follow its current setup requirements.
When should I start the channel?
Start when the source is configured and available, the channel and output group are saved, and the downstream system is ready to receive. The exact checks depend on the input protocol and destination, so use the relevant current AWS and receiver documentation rather than relying on a generic status rule.