To send an FFmpeg RTMP stream to AWS MediaLive, create an RTMP Push input and publish to the endpoint MediaLive generates. Attach that input to a channel, start the source first, then start the channel; MediaPackage is a possible destination after MediaLive processing, not the input endpoint.
The distinction between sending a stream into AWS and delivering a processed stream onward is the key to avoiding a dead-end configuration. Your network path, input class and chosen output all affect what to configure, so confirm each before you start the encoder.
Separate source, ingest and delivery
Think of the workflow as three separate jobs. FFmpeg is the source: it reads your media and encodes a live stream. MediaLive is the ingest and processing service: it accepts the incoming stream through an input, then processes it according to a channel’s settings. A downstream destination receives the channel’s output.
That distinction matters because an RTMP address can refer to different points in a workflow. The address FFmpeg publishes to belongs to the ingest input. An RTMP server or MediaPackage channel selected in MediaLive belongs to the output side. Sending FFmpeg directly to an output destination when you intended to use MediaLive skips the input-and-channel relationship entirely.
AWS documents both RTMP Push and RTMP Pull inputs. In the push case, FFmpeg publishes to an endpoint associated with the MediaLive input. In the pull case, MediaLive connects to an RTMP source that already exists elsewhere. The MediaLive input and protocol documentation is the primary reference for supported input types and protocols; check it again before deployment because service procedures and support can change.
If your final destination is YouTube, that is another downstream step, not a reason to send your FFmpeg source to YouTube and call it a MediaLive input. The separate guide to where a YouTube RTMP stream key goes covers YouTube’s own ingest address. Keep the two workflows distinct in your notes: source-to-MediaLive, then MediaLive-to-destination.
Choose RTMP Push or RTMP Pull
Choose based on which system can reach the RTMP server and which system should initiate the connection. With Push, your encoder initiates publication to a MediaLive-created input endpoint. With Pull, MediaLive reaches an existing RTMP endpoint and retrieves the stream. Neither is universally better; the sensible choice follows the location and reachability of the source.
| Choice | Connection direction | Fits when | Main check |
|---|---|---|---|
| RTMP Push | FFmpeg publishes to MediaLive | Your encoder can reach the input endpoint and should initiate the session | Use the generated endpoint, correct application and stream path, and input class requirements |
| RTMP Pull | MediaLive connects to an external RTMP source | A reachable RTMP server already hosts the stream and can remain available | Confirm MediaLive can reach that server and that its address and access details are correct |
For a source running on a workstation or a small always-on computer, Push is often the more direct mental model: configure the encoder to publish to the destination MediaLive gives you. But the documented VPC input procedure produces private addresses. If FFmpeg is outside that VPC, do not assume those addresses are publicly reachable. Network placement and routing must be resolved before you spend time debugging FFmpeg flags.
Pull can be more appropriate when an existing contribution encoder or RTMP service is already acting as a stable server and MediaLive can connect to it. It shifts the connection responsibility: instead of opening an outbound publish from FFmpeg, you must make the source endpoint available to MediaLive. Review AWS’s description of push and pull inputs and test connectivity from the relevant network, not merely from a laptop on a different route.
Also decide whether the stream is genuinely live. AWS describes RTMP inputs as supporting live sources, and its guidance distinguishes live sources from file-based workflows. A video file that you want to replay continuously is still being presented by your encoder as a live stream; it is not automatically a MediaLive file input. The FFmpeg and OBS comparison for looping YouTube videos may help you decide how to run the source, but it does not replace MediaLive’s input requirements.
Create a MediaLive RTMP Push input
In the MediaLive workflow, create an RTMP Push input before building or starting the channel that will use it. AWS’s detailed procedure cited here covers an RTMP VPC push input. Follow the current console flow for the network mode you actually need rather than assuming every RTMP input produces an internet-facing address.
The VPC procedure asks you to configure VPC networking and a MediaLive role, select an input class, and supply an application name and application instance. The instance is also described as a stream or stream key. These values form part of the destination path used by the publisher. Treat the generated endpoint and the application/stream path as a single destination assembled according to the console’s details, not as interchangeable pieces.
The example procedure uses port 1935 and creates endpoint addresses in the VPC context. A private subnet address is only useful to a sender that can route to that network. If your FFmpeg machine is in an office, home or cloud account without that path, pause here and resolve network reachability or select a suitable input/network arrangement. Repeatedly changing codec flags will not fix a routing problem.
Input class changes the publishing requirement. For a standard-class VPC input, AWS documents two endpoints and requires the upstream system to publish to both. For a single-class VPC input, the source uses the first endpoint. Build your sender configuration around the actual class shown for the input. Do not copy a one-endpoint setup from a different input class and assume redundancy is automatic.
Keep a record of the input name, class, endpoint addresses, application name, stream identifier and network placement. Avoid putting credentials or sensitive stream details in public logs. The official RTMP input creation procedure is the appropriate place to verify the current steps and endpoint behaviour.
Publish FFmpeg output to the generated endpoint
Once the input exists, configure FFmpeg’s output destination to use the endpoint and application/stream path generated for that input. The important point is not a generic RTMP URL copied from an example on the web; it is the exact destination MediaLive presents for your chosen input. Confirm the complete path, including the application and stream instance, before starting a long run.
The research for this guide did not identify an AWS-provided FFmpeg command, so no command here is presented as tested or verified. FFmpeg installations and input sources differ, and a command that works for one local file, encoder build or network may fail for yours. Use FFmpeg’s documentation for the syntax appropriate to your source and output, then compare the destination you construct with the MediaLive input details. Do not guess at an extra path component or omit one because another RTMP platform used a different convention.
Check the encoded media against MediaLive’s documented support. AWS lists H.264 (AVC) video and AAC audio for RTMP inputs and states that RTMPS input is unsupported. That is a compatibility check, not a guarantee that every H.264/AAC profile, bitrate or packet arrangement will work in every workflow. Consult the current codec support by input type before settling on an encoder profile.
For a standard-class VPC input, configure the upstream publishing arrangement to send to both listed endpoints as AWS requires. For a single-class input, use the first endpoint as specified in the procedure. If your FFmpeg setup cannot publish to both destinations, do not silently treat one destination as equivalent to the documented standard-class arrangement. Review the supported source design and decide whether the input class or publishing tool should change.
Test in a short, controlled session before leaving the system unattended. Confirm that the source process starts, the destination resolves and is reachable, and MediaLive recognises the incoming stream. If it does not, work through the chain in order: network route, endpoint and path, input state, codec compatibility, then FFmpeg source and output behaviour. For unattended FFmpeg operation, the monitoring guide using systemd and journalctl explains why process supervision and readable logs matter; adapt any operating-system steps to the machine and service you actually run.
Attach the input to a MediaLive channel
An input does not by itself produce a processed output. Create or edit a MediaLive channel and attach the RTMP Push input as that channel’s source. AWS documents input attachment as a separate operation; use the channel input attachment procedure for the current console sequence.
Then configure the channel’s processing and output settings for the destination you intend to use. The input answers “where does MediaLive receive the source?” The channel defines how that input is processed and where the resulting output goes. Keep those decisions visible in your setup notes so that a later change to a delivery destination is not mistaken for a change to the FFmpeg ingest URL.
Before starting, check that the attached input is the intended one, that the channel configuration has an output, and that output codecs and containers are compatible with the downstream system. MediaLive’s downstream systems and container documentation helps map output choices to destinations. A working input is only one part of a working pipeline.
A useful test is to verify each boundary separately. First confirm FFmpeg is publishing to the input. Then confirm the channel starts and processes that input. Finally confirm that the selected destination receives the channel output. This makes failures easier to locate than changing source, channel and delivery settings at once.
Start the source before the channel
For RTMP Push, the order of operations matters. AWS says the source must be pushing when the MediaLive channel starts. If the channel is stopped, MediaLive does not respond to the RTMP handshake, and the sender pauses. This means an FFmpeg process started before the channel may appear idle or may wait rather than deliver a stream immediately.
A practical sequence is to start FFmpeg and verify that it is attempting publication, then start the MediaLive channel. Watch both sides during startup: the encoder’s output and the input/channel state in AWS. If the channel is stopped while FFmpeg is already running, do not assume a successful handshake will happen until you start the channel again.
For a standard-class input, include both endpoints in the startup and monitoring plan. If you restart the source, confirm the publishing arrangement again rather than checking only one endpoint. For single class, use the first endpoint as AWS specifies. The precise start and retry behaviour can depend on the encoder and process supervisor, so observe your own setup rather than relying on an assumed automatic recovery.
Plan for interruptions deliberately. A system that restarts FFmpeg after a crash is useful, but it does not remove the need to check whether the MediaLive channel is running and whether the source can complete its publish handshake. A devotional stream, local news loop or study channel can be silent while a process still exists, so monitor actual ingest and output state as well as process status.
If you are moving from a one-machine YouTube loop to a managed processing path, document who starts each component and in what order. StreamNeo is useful for the separate case where an uploaded video needs to keep airing on YouTube without your computer staying on; it does not replace MediaLive’s RTMP input and channel configuration.
Consider downstream delivery separately
After MediaLive ingests and processes the source, choose an output suited to the destination. AWS documents output to an RTMP server as one route and a MediaPackage channel as another. MediaPackage is therefore a possible downstream destination for MediaLive’s channel output, not the RTMP endpoint to which FFmpeg publishes for a MediaLive RTMP Push input.
A MediaPackage path can make sense when you need its packaging and distribution workflow. AWS’s workflow wizard describes a possible progression from an RTMP source through MediaLive to MediaPackage and onward to CloudFront. That example is not a requirement that every RTMP input use MediaPackage. If your destination is an RTMP server, configure the channel for that route instead and verify the server’s supported output format.
| Pipeline point | Example component | What it does | What to configure |
|---|---|---|---|
| Source | FFmpeg | Encodes and publishes the contribution stream | MediaLive-generated input endpoint and stream path |
| Ingest and processing | MediaLive input and channel | Receives and processes the stream | Input attachment, channel settings and channel start order |
| Downstream output | RTMP server or MediaPackage channel | Receives processed output for onward use | A channel output suited to the selected destination |
| Further distribution | For example, CloudFront after MediaPackage | Distributes a packaged stream to viewers | The relevant delivery workflow and destination configuration |
Pick the downstream route from the delivery need, not because a service name appears in an example diagram. Check supported output codecs and containers for the exact destination, and account for the extra configuration and operational work each stage introduces. More stages can be useful, but they also create more boundaries to test and monitor.
For a small operator, keep a simple diagram with arrows and addresses labelled by role: FFmpeg to MediaLive input, MediaLive channel to output, then output to any packaging or distribution layer. Do not place the MediaPackage channel address in FFmpeg’s RTMP Push destination field unless you are deliberately building a different, supported workflow. The MediaLive workflow wizard guide is useful for understanding an example route, while the separate Liquidsoap-to-YouTube radio guide covers a different source and destination pattern.
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 I send FFmpeg directly to MediaPackage?
Not as the RTMP Push input described here. For this route, FFmpeg publishes to the endpoint generated by a MediaLive RTMP Push input; MediaPackage can be selected later as a destination for MediaLive channel output. Keep the ingest endpoint and downstream destination separate.
Does MediaLive support RTMPS input?
AWS’s cited RTMP input documentation says RTMPS input is unsupported and lists H.264 (AVC) video and AAC audio for RTMP inputs. Check the current official codec and protocol pages before deployment, since support details can change. Do not assume an RTMPS URL will work just because an encoder offers it.
Why does FFmpeg wait when the MediaLive channel is stopped?
AWS documents that MediaLive does not respond to the RTMP handshake while the channel is stopped. Start the source, then start the channel so the push stream is active when the channel starts. If the channel is stopped later, check the source and channel state again when resuming.
Do I need two FFmpeg destinations?
That depends on the input class in the documented VPC setup. AWS specifies two endpoints for a standard-class input and says the upstream system must push to both; a single-class input uses the first endpoint. Follow the details for your actual input rather than applying one setup to every RTMP input.