For a 1080p25 YouTube Live stream, use progressive 1920×1080 video, H.264 with constant bitrate, a 50-frame keyframe interval, and AAC stereo audio as a practical starting point. YouTube’s published H.264 bitrate table has no 1080p25 row: its 14 Mbps recommendation for 1080p30 is a nearby working reference, not an official 25 fps figure.
The right target for your stream still depends on the source, encoder and sustained upload available at the actual location. Treat the settings below as a baseline to test, not as a promise of uninterrupted delivery; check YouTube’s live health feedback during a full rehearsal as well as during the event.
What YouTube’s bitrate table says about 1080p25
YouTube’s live encoder settings and bitrate guidance lists H.264 recommendations by resolution and frame rate. For 1080p at 30 fps, it gives a 5 Mbps minimum and a 14 Mbps recommended bitrate. It does not list a distinct 1080p25 row. That absence matters: it would be misleading to label 14 Mbps as YouTube’s official recommendation for 25 fps.
You can use 14 Mbps as a first test target because it is the nearest listed H.264 reference in the same resolution, but it is not a value derived specifically for 25 fps. The separate 1080p60 row gives different figures, which is another reason not to blend rows into a made-up frame-rate formula. Start with a defensible reference, then use the actual programme and connection to assess whether it is workable.
The minimum in the 1080p30 row is not a suggested target for every kind of picture. A static devotional image and a fast-moving camera scene place different demands on video compression, while the connection must carry the encoded stream continuously. YouTube’s table is guidance for live ingest, not a promise about your ISP’s available upload or a guarantee that an encoder will keep up.
Do not use a YouTube upload bitrate recommendation as a substitute: uploading a finished file and sending a live feed are different workflows. If you want to understand the broader choices when picture quality or delivery is not behaving as expected, see this guide to live streaming quality settings and fixes.
Choose H.264, CBR and a 50-frame GOP
This example uses H.264 because it is a widely documented workflow supported by YouTube Live. YouTube also lists HEVC and AV1 as supported live video codecs, but the encoder must actually support the codec and the receiving workflow must accept it. For an FFmpeg setup, verify that your local build includes the encoder you plan to use; the name libx264 in a command is not proof that every installed build has it.
Use constant bitrate control (CBR) for this starting point. YouTube’s live encoder guidance calls for CBR. In the sample command, -b:v, -minrate and -maxrate set the same target as a practical way to express a constrained constant rate with x264. Rate control is an encoder behaviour, not a guarantee that every frame looks equally detailed: complex motion can still be harder to compress than a still image.
Set the keyframe interval to two seconds. At 25 frames per second, that means a GOP of 50 frames: -g 50. YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. The accompanying -keyint_min 50 and -sc_threshold 0 keep the example from shortening the interval through scene-change keyframes. If you change the output frame rate, recalculate the GOP in frames so the time interval remains appropriate.
The sample’s -bufsize 28M is an encoder buffer example, not a YouTube-prescribed value. Buffer size and rate-control behaviour can affect how the encoder manages short-term complexity; do not confuse a buffer setting with the amount of upload capacity required at every moment. If your stream health reports sustained delivery trouble, a sensible response is to test a lower target or a lower output resolution rather than assuming a particular buffer will fix the connection.
Set progressive 1920×1080 video at 25 fps
The intended output is 1920 pixels wide by 1080 pixels high, progressive, at 25 frames per second. Progressive frames avoid the interlaced-field format; the output frame rate should match the programme you mean to deliver. The example filter first scales within the 1920×1080 canvas, then pads any unused space, applies 25 fps and outputs yuv420p, a common pixel format for this H.264 workflow.
The scale-and-pad filter preserves the source’s aspect ratio rather than stretching it to fill the screen. A portrait or unusual-ratio source may therefore have bars, but its geometry is not distorted. If your source is already 16:9 at the intended dimensions and frame rate, the conversion may be unnecessary. Removing avoidable scaling or frame-rate conversion can reduce work for the encoder, but inspect the output rather than assuming the source is correct.
Be particularly careful with frame-rate conversion. A 25 fps source can be passed at 25 fps without a frame-rate change; a source at another rate may require dropping, duplicating or blending frames depending on the filter and workflow. The simple fps=25 filter in the example gives an output rate, but does not make every source look natural at that rate. Watch representative motion, including camera pans, scrolling text or moving artwork, in a test stream.
For a file replayed as a live feed, -re reads the input at its intended rate rather than sending it as quickly as the computer can process it. For a real camera or capture input already arriving in real time, do not blindly add file-replay pacing; follow the input’s real-time behaviour. Readers preparing a looped programme may also find the practical steps in setting up FFmpeg to loop videos on YouTube Live in India.
Configure AAC stereo, square pixels and Rec. 709
The command selects AAC audio at 128 kbps, 44.1 kHz and two channels. YouTube’s advanced live settings specify AAC or MP3 as supported audio codecs and give 128 kbps at 44.1 kHz for stereo. The -ac 2 setting requests two-channel output; listen to the received stream, because a silent or misrouted input will not be repaired by choosing a codec. If sound is central to the programme, check channel routing and levels in rehearsal. For a focused troubleshooting path, see how to fix no sound over RTMP.
YouTube’s advanced recommendations also describe square pixels, progressive scan, two B-frames, one reference frame, CABAC, Rec. 709 SDR and 8-bit SDR. Square pixels mean a pixel aspect ratio of 1:1, rather than a display stretched by non-square samples. The example uses a conventional 8-bit 4:2:0 pixel format, but it does not explicitly tag every colour characteristic. The source, filter chain and encoder metadata should be checked if colour appearance matters, especially when footage was recorded in HDR or another colour space.
Rec. 709 is the intended SDR colour space for this baseline. A filter such as format=yuv420p selects a pixel format; it is not by itself a complete colour-management workflow. If you are converting HDR footage or material with different transfer characteristics, verify the conversion separately and inspect it on YouTube. Do not add colour tags mechanically without knowing the source, since a tag describes interpretation and does not transform the pixels.
The advanced encoder recommendations are useful checks when your chosen FFmpeg encoder exposes the corresponding controls. Exact option names and availability depend on encoder and local build, so inspect ffmpeg -h encoder=libx264 or the documentation for the encoder you actually use. The example stays intentionally compact rather than pretending that one command configures every build identically.
Use RTMPS where supported
YouTube recommends RTMPS for live ingest. RTMPS is the secure form of the ingest connection; choose the server URL provided by your own YouTube Live Control Room rather than copying a URL from an old tutorial. The Control Room supplies the stream URL and stream key for the broadcast. The exact endpoint can depend on the account and workflow, so let the current control room be authoritative.
Keep the stream key private. It is a credential that lets a sender publish to the associated stream. Do not paste a real key into a public support forum, screenshot, shared document or command history that other people can read. In the command below, the placeholder URL is deliberately not a usable endpoint: replace it with the RTMPS server URL and key shown in the Control Room, following YouTube’s expected URL format.
RTMPS support depends on the FFmpeg build and protocol setup. The FFmpeg protocol documentation describes available protocols, but a build’s compiled features can vary. If the command reports that the protocol or TLS support is unavailable, check the local build and use a build with the needed support rather than quietly assuming that an rtmps:// URL will work everywhere.
Build and verify an FFmpeg command
Here is an illustrative template for an existing media file. It has not been tested against your file, encoder build, computer or account, so treat it as a starting point for a rehearsal rather than a known-good preset.
ffmpeg -re -i INPUT \\
-vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,fps=25,format=yuv420p" \\
-c:v libx264 -preset veryfast \\
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M \\
-g 50 -keyint_min 50 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'rtmps://<ingest-host>/<stream-key>'
Replace INPUT with your media path and the placeholder with the RTMPS URL and key from Live Control Room. The 14 Mbps target is the 1080p30 H.264 recommended value used as a nearby working reference because there is no separate 1080p25 row. The 28 Mbps buffer is only an example parameter. Do not paste the sample literally and expect it to match your input, key, or local FFmpeg build.
Before running it, confirm the installed FFmpeg lists libx264 and RTMPS support. The FFmpeg command documentation covers command syntax and options, but an option’s availability can depend on how the local binary was built. Check the input’s resolution, frame rate, audio stream and aspect ratio; then decide whether the scale and frame-rate filters are needed. A file with no audio track may need a deliberate audio strategy instead of an assumed AAC stream.
During the test, check that the encoder processes at least as fast as real time. If it falls behind, the CPU or selected preset may be too demanding for the computer. A faster preset can reduce encoding work at the cost of compression efficiency; lowering resolution or target bitrate can also reduce work or transmission demand, but each changes the delivered picture. Make one change at a time and evaluate the received stream, not just the command’s lack of errors.
For a 24/7 channel, a command that works once is not the same as a process that recovers after a dropped connection or a computer restart. Decide how you will notice a failure and who can respond; test the recovery path during setup. If your task is specifically handling restarts, this FFmpeg automatic-restart guide addresses that separate operating concern. StreamNeo can remove the need to keep your own computer running for a file-based 24/7 broadcast by taking an uploaded video and stream key and running the YouTube broadcast from the cloud, but you still need to prepare the right file and channel details.
Test upload headroom and stream health from India
There is no special India-only bitrate or FFmpeg flag in the platform guidance reviewed for this setup. Nor should one national upload figure be treated as a reliable description of every ISP, city, building or time of day. Test from the exact connection and location you will use for the event, because local route and sustained uplink matter more than a result measured elsewhere.
YouTube recommends an upload speed test and a full pre-event test. Run the intended programme long enough to expose ordinary variation, using motion and audio similar to the real event. A still title card is not a useful substitute for a moving visual loop, and a silent test will not reveal an audio-routing mistake. Check the stream’s health messages in Live Control Room and note whether delivery problems persist rather than reacting to one brief warning without context.
Leave headroom between measured sustained upload capacity and the video-plus-audio payload. Network speed tests are measurements at a point in time; a live encoder needs the connection to carry the stream continuously. Other devices uploading backups, camera feeds or files can consume the same uplink. If health feedback shows sustained problems, first reduce competing traffic, then test a lower bitrate or resolution and watch again. Do not assume that a faster advertised plan guarantees a stable stream at the event site.
A wired connection may make a setup easier to reason about if Wi-Fi is variable, but it does not create more capacity from the ISP or guarantee delivery. Likewise, a mobile hotspot can behave differently from a test done at another time or location. The useful evidence is a rehearsal over the actual route, with the actual encoder and representative content.
During the event, watch both the encoder and YouTube’s stream-health indicators. An encoder can remain running while the outgoing stream is delayed, disconnected or missing sound. YouTube describes latency as the delay between capture and playback; its guidance notes that choosing lower latency can increase buffering for viewers. Select latency with the audience and programme in mind, then test playback from a viewer’s connection as well as the Control Room preview.
Keep a short record of the configuration that passed rehearsal: output dimensions and frame rate, bitrate, connection used, source file, and any warnings seen. If the event moves to another venue or ISP, repeat the test there. This is more useful than assuming a setting that worked in one place will behave identically throughout India.
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 14 Mbps YouTube’s official bitrate recommendation for 1080p25?
No. The published H.264 table gives 14 Mbps as the recommended value for 1080p30 and does not provide a separate 1080p25 row. It can serve as a nearby working reference for a test, but do not describe it as an official 25 fps recommendation.
Why use a 50-frame GOP at 25 fps?
Fifty frames at 25 frames per second span two seconds. That matches YouTube’s recommended two-second keyframe frequency; the platform also says not to exceed four seconds. Recalculate the frame count if you change the output rate.
Should I add -re for a camera input?
The example uses -re because it is intended for a file being replayed at its normal pace. A live capture input already arrives in real time, so do not add file-replay pacing blindly. Follow the capture input’s behaviour and confirm in rehearsal that encoding keeps up.
What should I change if the stream health is poor?
Test from the actual event connection and inspect whether the problem is sustained; then reduce competing network use and trial a lower bitrate or resolution. Check encoder speed and audio/video output at the same time, since a connection is not the only possible cause. No setting can guarantee a stable stream across every computer and Indian network.