RTMPS in FFmpeg means sending your live output to the RTMPS endpoint YouTube gives you for that stream, with its matching stream key. You enable it by using the stream-specific URL and key, choosing encoder settings that suit your video and connection, and checking that YouTube receives the feed.
The command below is a starting template, not a promise that every input, FFmpeg build or channel configuration will work unchanged. Test it with the actual stream settings in YouTube Live Control Room before relying on it for an event or overnight broadcast.
What RTMPS changes
RTMPS is RTMP carried over SSL/TLS. The encryption protects the connection between your encoder and the ingest service; it does not change the content of your video or make a feed more reliable by itself. YouTube recommends RTMPS for encrypted ingest in its encoder settings guidance, and FFmpeg documents RTMPS as one of the RTMP protocol variants in its protocol reference.
For FFmpeg, the practical change is the destination protocol and endpoint. You still need to provide a media input, encode or pass through compatible audio and video, and send the result in a format accepted by the destination. The example here uses FLV output, a common FFmpeg pattern for RTMP-family destinations. RTMPS does not choose your codec, resolution, frame rate or bitrate for you.
The key detail is that YouTube supplies the endpoint for a particular stream in Live Control Room. An address copied from a tutorial, a different channel or an earlier setup may not be the right address for the stream you are configuring now. The relevant comparison between RTMP, SRT and HLS is useful for understanding protocols, but for this job follow the RTMPS endpoint that YouTube shows for the actual stream.
Find the RTMPS URL in Live Control Room
Open YouTube Studio and go to Live Control Room. Select or create the live stream you intend to use, then open its stream settings. In the Stream URL field, use the lock icon to reveal the RTMPS URL, as described in YouTube’s stream setup instructions. Copy that URL from the same stream whose key you will use.
Do not substitute a sample hostname or endpoint from this article into your command. The placeholder below is deliberately not an example URL. The endpoint YouTube shows is authoritative for this stream, and its exact value can differ. If Live Control Room offers separate URL and key fields, keep them separate in your notes and use the format the encoder expects; for a direct FFmpeg command, you must determine the correct URL/key formatting for that endpoint from the information YouTube provides.
Treat copying as a configuration step rather than a typing exercise. Pasting avoids mistakes in long endpoint strings, and checking both the beginning and end of the copied value can catch an accidental truncation. Do not paste the actual URL or key into a public support post, screenshot, shared script repository or article draft. A stream key functions like a credential for sending to your channel.
If you are configuring a managed channel, make sure you are working in the correct channel account and stream. Channel access and live eligibility are separate from FFmpeg’s protocol support; if Studio does not let you start a stream, consult the current account status and YouTube’s live streaming eligibility information.
Copy the matching stream key
Copy the stream key shown for the same stream in Live Control Room. A frequent setup error is pairing a correct-looking RTMPS URL with a key from another stream or channel. Since the endpoint and key are stream-specific inputs, use them as a pair and avoid reusing an old command unless you have verified both values against the current stream settings.
The FFmpeg template later places the destination in quotes, but that is only a reminder to handle the destination as one shell argument. It does not imply that every YouTube account displays the key as part of a single URL string. If YouTube presents a separate key field, follow its current instructions and verify how that URL and key are meant to be entered for the encoder you are using. For direct command-line use, confirm the precise formatting for the endpoint shown in Studio rather than guessing where to append the key.
Keep the key out of command histories and logs where you can. A command typed directly into a terminal may be retained in shell history or visible to other users of that machine. Consider using a restricted local script or another private method suited to your operating system, and ensure that any diagnostic output you share has the credential removed. If a key is exposed, YouTube says an authorised channel owner or manager can reset it; consult the current YouTube stream setup page for the control available to your account.
This separation is useful when a producer hands a stream over to a technician: send the non-secret settings and instructions openly, then transfer the key through an appropriate private channel. Also be careful when using examples from a recorded-video FFmpeg workflow: a command structure may be reusable, but its destination credentials are not.
Build the FFmpeg output command
The following is an illustrative template for a file sent at real-time speed. Replace INPUT with the actual media file path and replace the quoted destination placeholder with the endpoint and key formatting confirmed for your stream. Neither placeholder is a working YouTube address or credential.
ffmpeg -re -i INPUT \\
-c:v libx264 -preset veryfast \\
-b:v 6000k -maxrate 6000k -bufsize 12000k -g 60 \\
-c:a aac -b:a 128k \\
-f flv 'RTMPS_DESTINATION_FOR_THIS_STREAM'
-re asks FFmpeg to read a file at approximately its natural playback rate rather than sending it as quickly as the machine can process it. This matters for a recorded programme intended to appear as a live feed. Without real-time pacing, a fast source could be pushed as a burst instead of as a continuous programme. The option is intended for file inputs; when using a live capture device or another real-time source, consider that source’s own timing and FFmpeg’s guidance rather than adding options mechanically.
-i INPUT names the input. If the filename contains spaces, quote the path in the shell. The video options in this example select the H.264 encoder, a preset, bitrate controls and a keyframe interval; the audio options select AAC and a bitrate. The -f flv option explicitly selects the output muxer used in this example. FFmpeg’s documentation on RTMP-family protocols describes the protocol side, but the combination still depends on your installed FFmpeg build and input streams.
Use the command as a pattern, not as a universal incantation. For example, a file with no audio track may need a deliberate audio strategy, and a source whose dimensions or frame rate differ from your intended output may need explicit scaling or frame-rate handling. If you are building a long-running loop rather than transmitting one file, the playlist behaviour and transitions need separate testing; the advice for avoiding gaps in an FFmpeg playlist covers a different but related operational problem.
Before you run the command, inspect your FFmpeg build for the encoder you intend to use and test that it can read the file. A command can fail before contacting YouTube if the input path is wrong, the build lacks the requested codec, or the shell interprets special characters in the path or destination. Keep the real key private while checking errors.
Choose compatible encoder settings
RTMPS is a transport choice, not a quality preset. Your codec and bitrate should match the target resolution and frame rate, the capabilities of the installed encoder, and the upload capacity available to the sending machine. YouTube’s current recommendations list H.264, H.265/HEVC and AV1 options, frame rates up to 60 fps, CBR bitrate encoding, and a two-second keyframe interval (not over four seconds). Check the current YouTube encoder settings before deciding on a profile.
The figures below are examples from YouTube’s recommendations checked in 2026, not guarantees of a particular picture quality. They illustrate why the bitrate in the command should not be copied unchanged when you change codec or output size.
| Output example | Codec | YouTube recommended video bitrate |
|---|---|---|
| 720p at 30 fps | H.264 | 8 Mbps |
| 720p at 30 fps | AV1 or H.265/HEVC | 6 Mbps |
| 1080p at 30 fps | H.264 | 14 Mbps |
| 1080p at 30 fps | AV1 or H.265/HEVC | 10 Mbps |
The template’s 6000k video bitrate is merely an illustrative starting value, and it does not match every row in that table. Choose the row and codec that correspond to your actual output, then configure the encoder’s average rate, maximum rate and buffer in a way consistent with YouTube’s current guidance and the encoder you use. In particular, do not infer that a 6 Mbps setting is sufficient for every 1080p H.264 feed because it appeared in a command example.
The -g 60 value also depends on frame rate. A keyframe interval is measured in frames, so at a different output frame rate this value may not produce the recommended two-second interval. Set the GOP/keyframe interval to reflect the actual frame rate, and confirm the output configuration in FFmpeg logs or with a local test if you are not sure. Use a constant bitrate mode when the encoder exposes that control, as YouTube recommends CBR for encoder ingest.
For stereo audio, YouTube lists 44.1 kHz and 128 kbps as recommended; for 5.1 it lists 48 kHz and 384 kbps. Its documentation says 5.1 audio over RTMP/RTMPS is supported only with AAC. The template’s -b:a 128k does not set the sample rate, channel layout or a 5.1 mix, so do not assume those properties are correct simply because FFmpeg accepts the command. For SDR video, YouTube recommends Rec. 709; check the source and output colour characteristics if preserving colour matters.
Codec availability is a practical trade-off. A newer codec may offer an appropriate bitrate option in YouTube’s table, but only use it if your FFmpeg build and hardware can encode it reliably and YouTube accepts the configuration for your stream. H.264 is a straightforward choice for the illustrative command, not a claim that it is best for every machine or channel.
Start the file at real-time speed
Once the input, encoder settings, destination and key formatting are checked, start with a short private or otherwise suitable test stream rather than a scheduled programme you cannot interrupt. Use a representative section of the file: motion, scene changes, fades, text overlays and audio all place different demands on encoding and make it easier to see problems than a still frame or silence.
In FFmpeg’s output, look for evidence that it opens the input, configures the output streams and continues to report progress instead of exiting with an error. A connection being opened is not the same as YouTube accepting a valid playable stream. Keep the terminal available during the test, but do not copy credential-bearing output into a public issue. If you need to share logs, redact the endpoint’s secret portion and any key.
A desktop computer running the command must remain on and connected for the duration of that broadcast. For a 24/7 channel, a local machine also leaves you responsible for power, network interruptions, operating system updates and recovery after a process stops. If those are the specific pains you are trying to remove, StreamNeo lets you upload the file once and run the YouTube broadcast without keeping your own computer on, with monitoring and automatic restart if the stream drops.
If the goal is one event or a short test, running FFmpeg locally may be the simpler fit because you control the command and the machine. For a recurring channel, assess who will notice and repair a failure in the middle of the night, and whether the local connection can sustain the chosen output. Planning a continuous recorded language lesson stream also involves deciding how the content repeats and what viewers see between segments, beyond choosing an ingest protocol.
Verify ingestion and stream health
After FFmpeg starts, return to Live Control Room and check the preview and status indicators for the stream. Allow time for the feed to be processed, then confirm that picture and sound are present and that the displayed stream health is not reporting a problem. The preview is an important check, but it does not prove that a later overnight run will be uninterrupted, so monitor a longer representative test before depending on it.
Check the actual output rather than only the source file. Confirm that the video is the intended resolution and frame rate, that motion is not stuttering, and that speech or music is audible at a sensible level. Look for unexpected black frames, missing audio, stretched aspect ratio, clipped peaks or text cropped by scaling. If the source and target settings differ, adjust the filter or encoder configuration deliberately and test again.
Network capacity needs headroom. YouTube’s current streaming tips recommend leaving 20% upload headroom. Count the stream’s bitrate and any backup feed against the available upload capacity, rather than treating a speed test’s headline upload figure as wholly available to FFmpeg. A connection shared with other people or devices can vary, so test under realistic household or workplace use. See YouTube’s streaming tips for current guidance.
If the connection fails, verify the endpoint and matching key first, then confirm that the network permits the connection and that your FFmpeg build supports RTMPS. A timeout may point to an incorrect endpoint or unavailable protocol support. If FFmpeg reports an SSL problem, YouTube’s troubleshooting guidance suggests explicitly specifying port 443 if the error persists; use the server and port in accordance with YouTube’s instructions for the actual endpoint.
Do not make disabling certificate verification your routine fix for a TLS error. FFmpeg’s TLS documentation covers peer verification and certificate authority configuration. First validate that you copied the RTMPS endpoint correctly, check system time and trusted certificate configuration, and ask whether a network filter is interrupting TLS. If you change certificate settings, understand the security effect rather than applying an insecure workaround just to make a test connect.
A good preflight has both a technical and an operational part. Technically, you verify the output and the YouTube preview. Operationally, you confirm who can restart the command, how the key is stored, and what happens if the computer or connection is unavailable. A clean test now is evidence about this particular setup, not a guarantee of uninterrupted future transmission.
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 enabling RTMPS require a different FFmpeg installation?
Not necessarily. FFmpeg documents RTMPS as an RTMP-family protocol, but the capabilities of an installed build can vary. Check the build and test the actual command; if it lacks RTMPS support, use a suitable build rather than assuming a protocol option will be available.
Can I use the same RTMPS URL and key for every YouTube stream?
Do not assume so. Copy the RTMPS URL and key shown for the particular stream you are setting up, and verify that they belong together. If you think a key has been exposed, use YouTube’s current controls to reset it.
Why does FFmpeg connect but Live Control Room show no usable preview?
A connection alone does not establish that the feed has valid media. Check that FFmpeg is sending the expected audio and video streams, that the destination and key are correct, and that the encoder settings are supported. Use the preview and stream health information in Live Control Room to guide the next check.
Is the command suitable for a 24/7 channel without changes?
No. It illustrates real-time output from a file but does not account for your file format, chosen resolution and frame rate, keyframe interval, audio layout, loop behaviour, network capacity or recovery plan. Adapt and test those parts with your actual stream before relying on it for continuous broadcasting.