For a mostly static Hindi music visual, start with 1080p30 SDR, H.264 at 10 Mb/s, a two-second keyframe interval, and AAC stereo at 128 kb/s and 44.1 kHz. YouTube publishes broader bitrate ranges, so treat 10 Mb/s as a practical starting point rather than the only acceptable setting.
The command below loops an image and an audio file and sends the result to YouTube over RTMPS. Test it with your own files and connection before relying on it for a long broadcast: a correctly formed command cannot guarantee a stable stream.
Recommended FFmpeg starting point for a Hindi music loop
This example assumes a single still image and one audio file that can repeat. It creates a 1920×1080, progressive video stream at 30 frames per second and encodes the picture and sound as H.264 and AAC. Replace the endpoint and key placeholders with the values shown in YouTube Live Control Room.
ffmpeg \\
-re -loop 1 -framerate 30 -i artwork.jpg \\
-stream_loop -1 -i music.mp3 \\
-map 0:v:0 -map 1:a:0 \\
-vf "scale=1920:1080,format=yuv420p" \\
-c:v libx264 -preset veryfast -tune stillimage \\
-r 30 -g 60 -keyint_min 60 \\
-b:v 10M -maxrate 10M -bufsize 20M \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
This is an illustrative starting point, not a command tested against your files or FFmpeg build. The libx264 encoder must be present in your installed build; input formats, audio channel layout and image dimensions can all affect whether the command runs as written. FFmpeg documents its input, encoding and pacing options in its documentation.
The -loop 1 option keeps the image input available, while -stream_loop -1 repeats the audio file. -re paces file-based input at real-time speed rather than sending it as fast as the computer can read it. Do not assume a finite still-image input will keep the whole job alive indefinitely unless it is explicitly looped. If you use a video visual or a playlist instead, adapt the inputs deliberately; the FFmpeg playlist approach for looping videos covers a different source arrangement.
Before you schedule the channel, run the exact command with representative media. Check that the image framing is right, that the audio plays continuously across the loop boundary, and that the stream remains active in the Live Control Room preview. For music, separately confirm that you have the necessary permission to stream and archive the chosen recordings. Technical settings do not establish music-use rights.
Set 1080p30 H.264 and CBR
The example uses H.264 through FFmpeg's libx264 encoder. It sets the picture to 1920×1080 and 30 frames per second, uses yuv420p pixel format for a broadly practical SDR output, and fixes the video rate at 10 Mb/s with -b:v and -maxrate. Setting both to the same value is part of this example's constant-bitrate approach; -bufsize 20M configures the rate-control buffer.
YouTube recommends constant bitrate encoding. Its live encoder settings guidance lists H.264 at 1080p30 with a 5 Mb/s minimum and 14 Mb/s recommended, and identifies 10 Mb/s as its recommended value in that range. That means 10 Mb/s is a defensible starting point, not a universal requirement or the sole YouTube-recommended setting. A lower rate may be necessary when the connection cannot sustain it; image detail and motion may then be less clear.
A mostly static devotional artwork or album cover does not gain much from encoding frames at twice the rate simply because the source is 1080p. Thirty frames per second reduces the bitrate demand compared with a 60 fps stream and is a sensible baseline for a still image, slow visualiser or gentle transitions. If your artwork has substantial motion, test whether the extra frames improve what viewers actually see before increasing the demand on both encoder and upload connection.
The table below separates the YouTube H.264 recommendations from the proposed starting point. These are incoming encoder settings, not a promise of how a viewer's device will receive the stream: YouTube transcodes live video for playback on different devices.
| Choice | 1080p30 H.264 | 1080p60 H.264 |
|---|---|---|
| YouTube-published minimum | 5 Mb/s | 6 Mb/s |
| YouTube-published recommended range | 5–14 Mb/s | 6–17 Mb/s |
| YouTube recommended value within range | 10 Mb/s | 12 Mb/s |
| Practical emphasis | Static or slow visuals; lower frame-rate demand | Motion that benefits from smoother movement; higher rate and capacity demand |
The ranges and recommended values above come from YouTube's published encoder guidance. If you are changing quality to suit a constrained connection, use a test stream and inspect the result rather than assuming that resolution alone determines picture quality. If a particular FFmpeg encoder or preset is unavailable, check your build; the hardware encoding setup guide may help explain the separate trade-offs involved in encoding on a VPS.
Configure two-second keyframes
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. At 30 frames per second, two seconds corresponds to 60 frames, which is why the example sets -g 60 and -keyint_min 60. The group-of-pictures interval controls how far apart keyframes are in the encoded video; it is not the same thing as the overall frame rate.
Keep the interval tied to the frame rate if you change it. At 60 fps, 120 frames span two seconds, so a 60-frame GOP would instead span one second. A shorter interval is not automatically better: follow YouTube's guidance and make the interval explicit so the encoder is not left to choose an unsuitable default. For terms such as GOP and bitrate, the blog's plain-language live streaming glossary is useful if you are reading encoder options for the first time.
A keyframe setting cannot correct an unstable upload or a poor source file. It does, however, give the receiving platform a predictable cadence for important frames. After changing GOP or frame rate, make another short test and check stream health rather than carrying forward assumptions from a previous configuration.
Set AAC stereo audio
The audio options in the command encode AAC stereo at 128 kb/s and 44.1 kHz. Those values match YouTube's recommended stereo audio bitrate and sample rate in its live encoder guidance. -ac 2 requests two output channels; it does not make a mono source genuinely stereo, nor can it restore detail absent from a compressed source.
Listen to the beginning and end of a repeated track. A file can play correctly on its first pass but expose a gap, abrupt cut or level change at the loop boundary. Check at a sensible listening level, and make sure the image and music remain in sync if you add visual changes. For a channel built around recurring ambience or music, the guide to preventing audio gaps in looping sleep sounds discusses the source-side problem that bitrate settings cannot solve.
Your actual file may have a different sample rate or channel layout. FFmpeg can convert input to the output settings, but conversion is not a substitute for listening to the result. If the music source is already compressed, raising the output bitrate will not recreate information that is not present in the original.
Use RTMPS and protect the stream key
YouTube recommends RTMPS for sending a live stream. The example uses FLV as the output container and an RTMPS URL, with the ingest address and key represented by placeholders. In Live Control Room, select or create the stream and copy the corresponding URL and stream key into your encoder configuration; consult YouTube's streaming setup guidance if you need to find them.
Treat the key like a password. Do not publish it in a screenshot, paste it into a public forum, include it in a script you share, or leave it visible in a recording of your desktop. If you believe it has been exposed, replace it in the appropriate YouTube controls and update the encoder before broadcasting. Check that the endpoint and key are copied as intended, because an incorrect destination can prevent the stream from reaching the expected live event.
RTMPS is the recommended transport in this setup, not a guarantee against interruptions. A correct protocol and key address the route into YouTube; they do not fix a connection drop, an encoder process that exits, or a source file that ends unexpectedly. If your priority is keeping a channel running after you close a desktop streaming application, see how to keep a 24/7 stream live after closing OBS for the broader operational question.
Check upload capacity and stream health
The connection must carry more than the video bitrate alone. Audio, transport and protocol overhead also consume capacity, and available upload can vary while other devices use the same connection. YouTube advises testing upload speed and choosing a stream quality the connection can sustain. Do not treat a single speed-test result as proof that a long broadcast will remain stable.
For this 10 Mb/s video starting point, aim for comfortable headroom above the video rate plus audio and overhead. There is no one margin in the supplied guidance that fits every household, venue or network. Run tests from the place and network you will actually stream from, ideally under normal competing traffic, then begin with a rate the connection can sustain rather than the highest number it briefly reports. If the stream reports problems, reduce the bitrate or step down resolution or frame rate and test again.
Before the intended broadcast, send a representative test stream. Watch the Live Control Room preview for framing, continuous picture and audio, and inspect the stream health messages. YouTube's help page says to test before starting, and its live streaming tips advise monitoring audio and video quality. Check again during the broadcast; an initial successful preview does not rule out a later network or source problem.
Keep the test representative: use the actual image, audio, FFmpeg build, output settings and connection. Confirm that loop behaviour matches your schedule and that the media does not stop when a finite input reaches its end. Record the settings that worked, but retest after meaningful changes to the file, encoder, connection or destination. This is more useful than relying on an overnight run performed under different conditions.
For a continuous channel, also decide what should happen if the encoder exits or loses its connection. The command itself describes encoding and sending; it is not a complete operational plan for detecting and recovering from every failure. Keep an eye on the live event, and make sure someone can respond to a problem when the broadcast matters.
When 1080p60 may be appropriate
Choose 60 fps when the visual contains motion that benefits from smoother movement, such as fast animation, scrolling text or a rapidly moving visualiser, and when your encoder and upload connection can sustain the higher demand. It is not necessary merely because the content is music, nor is it a requirement for a static Hindi devotional image. With a still artwork loop, 30 fps is usually the more practical first test.
YouTube's H.264 table lists 6 Mb/s minimum and 17 Mb/s recommended for 1080p60, with 12 Mb/s as its recommended value in the table. The higher published recommended endpoint reflects a different frame-rate option; it does not mean that every 60 fps stream must use 17 Mb/s, or that every 30 fps stream must use 10 Mb/s. Pick settings within the published guidance that your connection can sustain and that suit the actual motion in the picture.
If you change this example to 60 fps, set -r 60 and use a 120-frame GOP to retain the two-second keyframe interval. Then test the resulting stream and monitor health. If upload capacity or encoding performance is marginal, return to 30 fps before sacrificing reliability for motion that viewers may not notice in a mostly static image.
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
Is 10 Mb/s the only YouTube-recommended bitrate for 1080p30?
No. YouTube's H.264 guidance gives a 5–14 Mb/s recommended range for 1080p30 and lists 10 Mb/s as its recommended value within that range. Treat the example's 10 Mb/s as a starting point, then consider connection capacity and the visual result in a test.
Should a static Hindi music image use 60 fps?
Usually not as a starting point. Thirty frames per second is a sensible baseline for a still or slowly changing visual, while 60 fps is worth testing when meaningful motion benefits from smoother movement and the encoder and connection can support it.
Can I expect this command to run all night without interruption?
No command or bitrate setting can guarantee stream stability. Test the exact files and connection, watch Live Control Room health, and plan how you will notice and respond if the process or network fails.
Does this FFmpeg setup confirm that I can stream the music?
No. Encoding settings say nothing about your permission to broadcast or archive a recording. Confirm the relevant music rights independently before you use the track in a live stream.