AWS Elemental MediaPackage has no YouTube-specific input type. For a live encoder feeding a MediaPackage v2 channel, choose the documented HLS or CMAF ingest type that matches the encoder; for a recording, use the documented VOD asset workflow instead.
A YouTube playback URL is not the same thing as an ingest stream or a source asset. The AWS documentation reviewed here does not describe direct ingestion from a YouTube URL, so first establish what source you actually control and which MediaPackage workflow it fits.
What “input type” means in MediaPackage
“Input type” describes how a MediaPackage v2 live channel receives content, not the website or platform where the content was originally published. AWS lists HLS and CMAF as live ingest types. The choice is about the output provided by an upstream encoder and how it packages and sends the media.
That distinction matters because people often use “YouTube stream” to mean several different things. It could mean a live broadcast being sent to YouTube by an encoder, a recording that was previously broadcast, or simply the public watch-page URL for a video. Those are not equivalent sources for MediaPackage configuration.
In the v2 API, the InputType field accepts HLS, CMAF, or MULTIVIEW. Multiview is a channel mode that composites other channels; it does not take its own ingest. For a channel receiving an encoder’s media directly, the relevant documented choices are HLS and CMAF. See the MediaPackage v2 CreateChannel API reference for the field and its allowed values.
AWS defines InputType as immutable after channel creation. The API defaults it to HLS when it is omitted, but relying on a default is a poor substitute for checking what your encoder actually sends. Confirm the input before creating the channel, because a mismatch is not simply a setting to casually switch later.
Is there a YouTube-specific input type?
No. The documented MediaPackage input choices are based on media ingest, not on YouTube as an origin. AWS’s live input documentation describes supported formats and requirements for an upstream source or encoder; it does not list a YouTube video URL as a channel input. The AWS supported inputs page is the appropriate place to verify the current live ingest requirements.
This does not establish a categorical AWS prohibition on every conceivable way of obtaining media from YouTube. It means the reviewed AWS pages do not document a direct URL-ingestion path for a YouTube playback page. Do not infer that pasting a watch URL into a MediaPackage channel is supported merely because the video itself can be played in a browser.
If you are the channel owner and have the source file, work from that authorised asset and the documented VOD workflow. If you have a live production pipeline, identify the encoder output and configure the channel for that. If all you have is a playback URL, pause before channel creation and establish a supported source route rather than treating the URL as an ingest format.
Choose HLS or CMAF for a documented v2 live input
HLS and CMAF are alternatives for a live encoder workflow, not categories for deciding whether a video is prerecorded. The encoder’s output format determines which applies. In AWS’s channel creation guidance, HLS input uses HLS with transport stream segments, while CMAF input follows the DASH-IF Live Media Ingest Protocol. The AWS channel creation guide describes these requirements.
| Your actual source | MediaPackage route documented here | What to check before setup |
|---|---|---|
| Live encoder output packaged as HLS with TS streams | MediaPackage v2 HLS input | Confirm the encoder sends the expected HLS output using HTTP PUT. |
| Live encoder output following the CMAF ingest protocol | MediaPackage v2 CMAF input | Confirm the encoder supports the specified DASH-IF live ingest workflow. |
| A finished recording that should be packaged as VOD | Classic MediaPackage VOD asset workflow | Prepare the source in S3 and check the supported VOD format. |
| Only a YouTube watch-page URL | No direct route established by the AWS pages reviewed | Obtain an authorised source asset or an encoder-delivered supported stream. |
Do not choose CMAF because it sounds more modern, or HLS because the finished programme was once streamed on YouTube. Those facts do not tell you what an encoder is sending now. Ask the person who operates the encoder, inspect its output configuration, or consult the system that generates the ingest stream.
The documented live ingest requirements also include unencrypted media segments, at least one video track, and a channel policy when sources are outside the AWS account. Audio and video can be muxed together or supplied as separate tracks. Check the current AWS documentation for the complete requirements before wiring up a production workflow; matching the broad label alone does not ensure that the actual stream conforms.
If you are building the live side with OBS or FFmpeg, keep the role of each component clear: it is an encoder or producer that must send a supported ingest to MediaPackage. For a different use case where an encoder sends directly to YouTube, the practical steps in running a continuous YouTube live stream with OBS on Ubuntu may help clarify that separate route. Remove the space after the opening parenthesis when using the Markdown link: OBS on Ubuntu.
Treat recorded content as a VOD asset workflow
A recording is an asset, even if it was originally broadcast live. In the classic MediaPackage documentation, VOD source content resides in an Amazon S3 bucket and is handled through a VOD asset workflow. That is different from configuring a live channel to receive a stream from an encoder. The AWS MediaPackage concepts page distinguishes the service’s live and VOD concepts.
A practical first question is whether the content is still being produced in real time. If an encoder is continuously creating and sending a supported live ingest, investigate the v2 live-channel route. If the programme has already been recorded and saved, look at the VOD route and prepare the source as an asset. The fact that viewers may later watch the asset continuously does not turn the source file into a live encoder input.
This is also a useful point to consider rights and provenance. A recording that you own or are authorised to distribute is a much clearer starting point than a playback URL from somebody else’s YouTube upload. A browser-accessible video page does not itself tell you whether you possess a source asset suitable for packaging or permission to reuse it.
For a YouTube-first always-on channel made from your own recorded programme, there may be a simpler path than inserting MediaPackage into the workflow. The guide to making a 24/7 YouTube live stream from recorded yoga classes is relevant if your goal is to turn a prepared recording into an ongoing YouTube broadcast, rather than to build an AWS packaging pipeline.
Check the classic VOD source formats AWS describes
The classic MediaPackage VOD documentation identifies HLS and MP4 with a SMIL manifest as supported source formats for its VOD asset workflow. In this context, HLS and MP4 with SMIL describe VOD source formats. They are not a reason to label the asset as a MediaPackage v2 live input, and they do not make a YouTube watch URL a valid source asset.
Before preparing a VOD asset, establish where the source file lives and which documented format it uses. For the workflow described by AWS, the source content is in S3. If a file is currently on a workstation, that is not yet the same as having completed the S3-based VOD asset setup. If the source is a playlist or package, check that it meets the applicable requirements rather than assuming a single video file can be substituted without preparation.
Do not conflate the classic service’s VOD formats with the v2 channel’s live input types. HLS appears in both discussions, but its appearance does not collapse the workflows into one. A live HLS ingest is sent by an upstream encoder to a channel; VOD HLS is source content in an asset workflow. The operational steps, source location, and purpose differ.
AWS service documentation can change, and the notes here reflect the pages reviewed for this question. Confirm the current classic MediaPackage VOD documentation and supported asset formats before implementation, particularly if you are following older instructions or using a different MediaPackage generation.
Identify the source and workflow before setup
Write down the source in plain terms before opening the channel configuration. Is it a live encoder output, a finished file stored in S3, or only a YouTube playback page? That short inventory usually prevents the most consequential mistake: choosing an input type based on the word “YouTube” rather than on the data that will actually reach AWS.
Then answer the practical questions below:
- Is content being generated live now, or is it already recorded?
- If live, which system encodes it and what ingest format does it send?
- If recorded, do you have the original authorised asset and is it staged in S3 for the VOD process?
- Are you following MediaPackage v2 live-channel documentation or classic VOD asset documentation?
- Have you confirmed the current input and format requirements in AWS’s documentation?
If the answers point to a v2 live channel, match HLS or CMAF to the encoder output and review the channel requirements before creation. If the answers point to a recorded asset, follow the classic VOD path and its source-format rules. If the only input you can name is a YouTube URL, you have not yet identified a documented MediaPackage ingest source.
For channels whose actual destination is YouTube rather than MediaPackage, keep the architecture question separate from the AWS terminology question. A continuous YouTube workflow may use a computer and encoder, as described in keeping an FFmpeg YouTube playlist stream running with systemd. That article is about maintaining an encoder process, not about making a YouTube URL an AWS input.
Avoid assuming URL ingestion
A URL can refer to very different things: a watch page, a manifest, a media segment, or an asset location. MediaPackage’s documented input type is not a generic field for any URL you happen to possess. The reviewed documentation describes the live ingest formats and the S3-based VOD asset source; it does not document a direct YouTube playback URL route.
This distinction helps avoid wasted setup work. Creating a channel with HLS selected will not convert a watch page into HLS ingest from an encoder. Selecting CMAF will not retrieve a recording and package it as VOD. If the source is a playback URL, first locate an authorised source file or establish an encoder workflow that delivers a supported live stream. Do not build an architecture around an undocumented assumption.
Also avoid assuming that a YouTube live broadcast and a YouTube recording are interchangeable. A live encoder may be sending a stream to YouTube while independently producing another output for MediaPackage, but that is a separate configured path. Once a broadcast has ended, a replay page is still not, by itself, proof of an available VOD source asset in S3.
For a small channel, the right answer may be to omit MediaPackage entirely if the need is simply to run a prepared video continuously on YouTube. StreamNeo can remove the specific burden of keeping your own computer running and restarting the broadcast process when it drops: you upload the video, provide your YouTube stream key, and the cloud-run stream continues with monitoring and automatic restarts. It is YouTube-only, so it is not a substitute for MediaPackage when you need AWS packaging or delivery workflows.
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
Can MediaPackage ingest a YouTube video URL?
The AWS pages reviewed for this article do not document direct ingestion from a YouTube playback URL. They describe supported live ingest from an upstream source or encoder and a classic VOD workflow whose source content resides in S3. Check current AWS documentation before implementation, and do not treat a watch page as a supported input by assumption.
Is a prerecorded YouTube video HLS or CMAF input?
Not simply because it was published on YouTube. HLS and CMAF are the documented live ingest choices for MediaPackage v2 channels, selected according to what the encoder sends. A recorded programme belongs in the VOD asset discussion, for which AWS’s classic documentation describes HLS or MP4 with a SMIL manifest.
Should I create a MediaPackage channel or a VOD asset?
Use the live-channel route when an encoder is sending a supported live stream and configure the input to match its output. For a finished recording, use the documented VOD asset workflow and check the S3 source and format requirements. If your goal is only to broadcast a prepared file continuously to YouTube, assess whether you need MediaPackage at all.
Can I change the input type after creating a v2 channel?
AWS documents the InputType field as immutable, so verify the encoder output and intended workflow before creating the channel. The API lists HLS, CMAF, and MULTIVIEW, with HLS as the default if the field is omitted. Consult the current API reference rather than relying on an implicit default.