To stream a video stored in Amazon S3 to YouTube Live with FFmpeg, run FFmpeg on a computer or host that can read the object and reach YouTube’s ingest endpoint. For a private object, give FFmpeg temporary access with a presigned URL, then send its output to the RTMPS address and stream key shown in YouTube Live Control Room.
This is a file being transmitted as a live broadcast, not a camera feed or a built-in S3-to-YouTube connection. You are responsible for the host, access credentials, encoding choices and recovery plan; each part can stop the stream for a different reason.
How S3-to-YouTube streaming works
The path is straightforward: S3 stores the source video; FFmpeg requests that video and reads it at a suitable pace; FFmpeg encodes or packages the result and sends it to YouTube. S3 is the file source, not the broadcaster. YouTube receives a live ingest, not a link to the S3 object.
That distinction matters when troubleshooting. If FFmpeg cannot retrieve the file, check the URL, permissions and expiry. If FFmpeg can read the file but YouTube does not receive a broadcast, check the output endpoint, stream key and encoder output. If YouTube receives the feed but playback is unstable, investigate host connectivity and the encoding configuration rather than changing bucket permissions at random.
FFmpeg accepts an input URL and writes to an output URL. Its -re option reads a file at its native rate instead of consuming it as quickly as possible, which is useful when presenting a prerecorded file as a live stream. Consult the FFmpeg command-line documentation for input and option behaviour, and its protocol documentation for supported output protocols. Do not assume a command written for another workflow is a universal YouTube preset.
The YouTube destination is stream-specific. Open the current or scheduled broadcast in Live Control Room and use the RTMPS URL and key displayed there. YouTube describes RTMPS as a secure extension to RTMP in its Live streaming help. Do not copy an endpoint from an old tutorial and assume it applies to your event.
Choose where FFmpeg will run
FFmpeg needs access to both sides of the transfer: it must retrieve the S3 object and send the live output to YouTube. The machine running it also needs to remain awake, online and running the process. That is the central choice between using your own computer and a persistent host.
| Execution location | Practical advantage | Main trade-off to plan for |
|---|---|---|
| Your computer | Easy to test and observe directly; no separate host to configure | Sleep, a home network interruption, a restart or closing the terminal can stop the process |
| Persistent cloud host | Can continue independently of your desk computer when configured to stay running | Requires host setup, monitoring and ongoing operating cost; outbound data transfer and network paths need consideration |
These are operational differences, not a measured performance ranking. The right choice depends on whether you can maintain a computer and connection continuously, or would rather manage a remote host. If you are assessing a persistent host, the 24/7 YouTube VPS guide covers the broader hosting decision. For a rupee-billed cloud computer approach, see setting up an always-on stream with a cloud PC.
Test with the host you expect to use for the real broadcast. A command that works on a desktop may fail on a remote machine because FFmpeg is missing, outbound access is restricted, the process exits when a session ends, or credentials were never transferred securely. Before scheduling a long run, verify that the host can reach the object and YouTube and that you know how to inspect and restart the process.
A hosted file-to-live workflow may also be attractive when the main operational burden is keeping a computer running overnight. StreamNeo addresses that specific burden by turning an uploaded video into a YouTube live stream that can run with your own computer switched off; it is YouTube-only, so it does not replace an FFmpeg setup when you need control over the S3-to-FFmpeg path itself.
Make the S3 object readable
S3 objects are private by default. FFmpeg cannot retrieve a private object merely because you know its bucket name or can open it in an AWS console. You must arrange an authorised GET request for the process that reads the file.
There are two practical access patterns for this workflow. A public object can be read by anyone who has access to its URL, but only use that approach when exposing the file publicly is intentional and the bucket or object configuration permits it. A private object can instead be accessed through a presigned URL, which grants temporary access without changing the bucket’s public-access setting.
| Input method | Confidentiality and setup | Expiry and recovery |
|---|---|---|
| Intentionally public object | Simple to pass to FFmpeg, but anyone able to obtain the accessible URL may be able to retrieve the object | No presigned-link expiry to handle, but public access remains a deliberate exposure |
| Private object with presigned URL | Keeps the object private while authorising a time-limited GET; requires creating and protecting the URL | The URL expires; a later request or reconnect may need a newly generated URL |
For the common private-bucket case, a presigned URL is generally the more appropriate way to authorise FFmpeg without making the object public. AWS explains that presigned URLs use the permissions of the principal who creates them and allow temporary access. Read the AWS guide to presigned URLs and its instructions for sharing an object with a presigned URL before setting up access.
Generate a URL that authorises a GET for the exact object FFmpeg must read. Use the complete HTTPS URL returned by AWS, unmodified. A URL copied without its query parameters, altered by shell quoting, or generated for another object will not authorise the intended request. A simple retrieval test from the eventual FFmpeg host can help separate access problems from output problems, but do not paste the URL into a public issue or shared terminal transcript while testing.
Use a presigned URL safely
Treat the entire presigned URL as a credential. It contains the authorisation needed to request the object while it remains valid, so it is not safe to publish, email widely, embed in a public script or leave in a screenshot. This remains true even if the bucket itself is private: possession of the URL can grant access for its authorised period.
The same principle applies to the YouTube stream key. The presigned URL authorises the input; the stream key authorises the output. Keep both out of source control, public documentation, support screenshots and logs that others can access. The command later in this guide uses environment-variable placeholders so that no real credential needs to appear in the command text.
A presigned URL is temporary, but its lifetime is not a useful substitute for careful handling. AWS evaluates expiry when a request is made. A transfer that began before expiry can finish, but a later request after expiry can fail. That distinction is important for a long-running broadcast: the initial read may succeed while a restart or reconnect later cannot open the object with the same URL.
Choose a validity period that accounts for the planned stream and likely recovery needs, within the limits applicable to how you create the URL. Do not assume that an FFmpeg process can reconnect indefinitely after expiry. If the URL expires and a new request is required, create a fresh URL and restart or reconfigure the input as appropriate. The exact procedure depends on how you supervise FFmpeg; test it before relying on it unattended.
If a URL is exposed, treat it as compromised rather than waiting to see whether anyone uses it. Stop using it and issue a new authorised URL, then review where it was copied. If a stream key is exposed, replace or reset it using YouTube’s controls. Avoid placing secrets directly in shell history; environment variables can reduce accidental disclosure, but they are not a universal secrecy mechanism and may still be visible to processes or administrators on the host.
Configure FFmpeg input and YouTube output
The following is a command shape to adapt, not a verified preset for every source or YouTube event:
ffmpeg -re -i "$S3_PRESIGNED_URL" \\
-c:v libx264 -pix_fmt yuv420p \\
-c:a aac \\
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
Set S3_PRESIGNED_URL to the full, unmodified HTTPS presigned URL. Set YOUTUBE_RTMPS_URL and YOUTUBE_STREAM_KEY from the current stream configuration in Live Control Room. Keep the RTMPS URL and key in the form YouTube provides for that stream; the command’s joined output form is illustrative, so check the exact address format for your current configuration. Never replace the placeholders with real values in an article, shared script or public support post.
The -re input option is useful for a stored video because it paces reading in real time. Without it, FFmpeg may read a file faster than its intended presentation rate, which is not the same as sending a paced live programme. The video and audio codec options shown are a starting shape only. You need to decide whether the source should be transcoded, what output resolution and frame rate suit it, and what video and audio bitrates and keyframe behaviour meet YouTube’s current recommendations.
Check YouTube’s current encoder settings and live-streaming guidance before choosing those values. The requirements and recommendations may change, and a source file’s properties matter. For example, a low-resolution devotional recording does not gain detail because it is encoded at a larger output size; conversely, a high-resolution source may need settings that the chosen host can sustain. Use FFmpeg’s output and error messages to verify what it is actually encoding rather than treating the sample options as proof of a good output.
RTMPS is the appropriate secure ingest protocol where it is available for the stream. Google’s Live Streams API documentation describes ingestion addresses, while the RTMPS ingestion guide covers the protocol. Use the endpoint YouTube presents for the event, not a remembered hostname or path from an unrelated example.
Before you make the broadcast public, confirm the feed appears in Live Control Room and that video and audio are behaving as expected. A successful FFmpeg process alone does not prove the public event is configured correctly. Check the event’s visibility and schedule separately, and do not treat file looping as a substitute for creating or starting the YouTube event.
If you need a repeating file, FFmpeg has stream-loop options, but looping simply repeats input; it does not schedule an event or guarantee a seamless transition at the loop boundary. Test the transition and audio continuity with the actual file. If you are comparing encoding approaches for a constrained machine, the discussion of an x264 preset for a low-power 24/7 stream is useful context, though FFmpeg command options and OBS settings are not interchangeable.
Monitor the stream and plan for access expiry
A 24/7 broadcast needs more than a command that starts. Watch FFmpeg’s process output, confirm that YouTube continues to receive the feed, and decide who or what will notice if either side stops. A process can exit on an input error, host restart or network interruption; a running process can also be unable to reconnect if the input URL has expired.
Separate the failure checks. First determine whether FFmpeg can still read from S3. Check whether the object remains available to the same authorised request and whether a fresh GET would be authorised. Then check whether the process is still writing to the RTMPS output and whether the event remains active in Live Control Room. These checks help avoid changing a working input credential when the actual issue is an output-side interruption.
Plan for expiry before the stream starts. If your expected broadcast or likely recovery window extends beyond the presigned URL’s validity, arrange a way to issue a fresh URL and restart or reconnect the input. A transfer already in progress may complete after expiry, but do not infer that a new request will be allowed. An overnight restart is precisely the kind of new request that can expose a URL-lifetime mistake.
For a local computer, disable sleep only if appropriate, keep the network connection dependable and ensure the process remains open. For a remote host, arrange process supervision and a way to inspect logs without exposing the full presigned URL or stream key. Restart behaviour should be tested, not assumed: automatic restart of FFmpeg cannot by itself renew an expired S3 credential.
The transfer also has a network path and data-flow consequence. The host downloads or reads the S3 object and sends the stream onward to YouTube, so consider connectivity to both services and where outbound transfer is incurred. The research and official guidance do not provide a universal cost or reliability comparison for host locations; assess the terms and network design of the host you choose rather than relying on a generic cost claim.
For a single-video workflow, distinguish continuous broadcasting from seamless programming. Repeating the same object may keep sending content, but it will not create new segments or assure a clean transition. If continuity matters, test a complete cycle, monitor the first restart, and document who can rotate credentials and recover the stream.
When you have confirmed the input is accessible, the endpoint and key belong to the intended YouTube event, and the chosen host can remain available, compare the practical operating options before committing.
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
How do I stream an S3 video to YouTube Live with FFmpeg?
Run FFmpeg somewhere that can retrieve the S3 object and reach YouTube’s ingest endpoint. For a private object, supply a presigned HTTPS GET URL; send the output to the RTMPS address and stream key for the event in Live Control Room. Confirm the feed there before making the broadcast public.
Can FFmpeg read an S3 presigned URL?
FFmpeg can use a URL as an input, and a presigned HTTPS URL can authorise access to a private S3 object. Pass the complete URL without modifying it, and protect it as a credential because anyone possessing it may be able to use its temporary access.
How do I use RTMPS with FFmpeg?
Use the RTMPS endpoint and stream key shown for the current or scheduled broadcast in YouTube Live Control Room. FFmpeg supports RTMPS; use the endpoint format YouTube supplies for that stream and verify the incoming feed in Live Control Room rather than copying an old sample endpoint.
What happens if the S3 presigned URL expires during a stream?
AWS evaluates expiry when a request is made, so a transfer already started can finish while a later request or reconnect can fail. Plan for the expected broadcast and recovery period, and be ready to generate a fresh URL if FFmpeg needs to request the object again.