For FFmpeg YouTube Live at 60 fps, use a two-second keyframe interval as your starting point: that is 120 frames at a constant 60 fps. YouTube recommends two seconds and says not to exceed four seconds; it also calls for a closed GOP for optimal transcoding.
That setting is about the video you output, not a reason to turn every 30 fps source into 60 fps. Match output to the source unless your production has a deliberate frame-rate conversion, then verify the encoder’s actual output and YouTube’s received stream.
Check the source frame rate before choosing a GOP
Start with the file or live production you are sending, not with a number copied from someone else’s command. A clip described as “60 fps” may have a constant 60 frames per second, variable timestamps, or a different cadence after editing. The GOP calculation depends on the output cadence: two seconds at 60 fps is 120 frames, while two seconds at 30 fps is 60 frames.
Inspect the source with a media probe such as FFprobe or your editing application’s clip properties. In FFprobe, r_frame_rate and avg_frame_rate can help identify the reported and average rates, but do not treat either field alone as proof that every frame is evenly spaced. If a file has variable frame rate, inspect its timestamps or use a tool that reports frame timing before deciding how you will encode it.
A source’s frame rate and the output frame rate are separate values. An editor or FFmpeg filter can repeat, drop, or blend frames to create another output cadence. If you have a 30 fps devotional loop, study visual, or local-news segment, sending it as 60 fps does not create new captured motion. It may simply duplicate frames and add encoding work. YouTube’s support for input up to 60 fps is a supported ceiling, not a demand to upscale.
This distinction matters when you compare a guide using -g 60 with one using -g 120. Neither number is universal: each represents a frame count, and its duration changes with the output rate. First establish whether your outgoing stream is 30 or 60 fps; then translate YouTube’s time recommendation into frames.
Inspect the encoder output settings
In an FFmpeg command, -g sets the maximum GOP size for libx264. A GOP is the group of pictures between keyframes. For a constant 60 fps output, -g 120 expresses a maximum interval of two seconds. At constant 30 fps, the corresponding two-second maximum is -g 60.
A practical libx264 starting point for known constant 60 fps output is:
ffmpeg -i INPUT -c:v libx264 -g 120 -keyint_min 120 -sc_threshold 0 ... OUTPUT
The omitted parts matter: input handling, output frame rate, pixel format, rate control, audio, transport URL and stream key all need to suit your setup. This is an illustration of GOP-related options, not a complete command to paste into a production stream. The FFmpeg codec documentation describes g as the maximum GOP size and documents the libx264 keyint_min and sc_threshold options.
Setting -keyint_min 120 alongside -g 120 can help keep a regular interval, while -sc_threshold 0 suppresses scene-cut keyframe insertion that could disturb a fixed cadence. These are controls for the libx264 wrapper; they do not establish that another encoder, hardware path, or locally built FFmpeg behaves identically. Confirm which video encoder your command actually selects, and consult its option documentation rather than assuming x264 flags apply to it.
YouTube specifically says a closed GOP is needed for optimal transcoding. A keyframe interval alone does not prove that your GOP is closed. Check how the chosen encoder exposes closed-GOP behaviour and verify the resulting stream if your workflow provides a way to inspect it. Do not assume a flag from a different encoder has the same meaning.
You can also express a time-based schedule with FFmpeg’s -force_key_frames, for example -force_key_frames 'expr:gte(t,n_forced*2)'. This requests forced keyframes on a two-second timestamp cadence. FFmpeg documents that forced times are rounded to output timestamps and that it uses the first frame at or after the computed time. It is an alternative control, not proof on its own of a fixed GOP or closed-GOP structure; see the FFmpeg command-line documentation and inspect what is emitted.
Set output to 30 fps when appropriate
If your source is 30 fps and your programme is not intentionally converting it, configure a 30 fps output. That keeps the cadence aligned and avoids spending bitrate on duplicated frames merely to label the stream 60 fps. For libx264, the two-second GOP starting point is then 60 frames, not 120. Confirm that the output frame-rate option or filter in your actual command is set as intended; a GOP value cannot set the frame rate by itself.
For example, the basic relationship is:
| Constant output cadence | Frames per second | Frames in two seconds | Frames in four seconds |
|---|---|---|---|
| 30 fps | 30 | 60 | 120 |
| 60 fps | 60 | 120 | 240 |
The four-second column is a conversion of YouTube’s stated ceiling, not the recommended target. Aim for two seconds. If your production intentionally converts 30 fps material to 60 fps, calculate using the output rate and test the motion: the encoder may create repeated or interpolated frames, depending on your conversion method.
The practical trade-off is that a higher output frame rate can represent faster motion more smoothly when the source and production support it, but it also affects encoding load and bitrate needs. A static artwork radio loop or a talking-head feed may have little to gain from 60 fps. A sports or gameplay source captured at 60 fps may benefit from keeping that cadence. Choose based on the material and the encoding capacity available, not a belief that YouTube requires 60 fps.
If you are diagnosing stutter rather than configuring a clean output, compare the rate, resolution, bitrate and encoder load together. The checks in our guide to dropped frames despite good internet cover encoder-side causes that can resemble a keyframe problem.
Understand YouTube’s supported frame rates and ingest guidance
YouTube’s live encoder guidance lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS ingestion, supports up to 60 fps, and recommends RTMPS. It recommends progressive scan and two B-frames among advanced settings. These choices sit alongside keyframe interval; one setting does not substitute for another. Check YouTube’s current live encoder settings before configuring a new stream, because platform guidance can change.
The page’s keyframe guidance is precise: two seconds is recommended and four seconds should not be exceeded. The conversion to frames assumes the output rate is constant. At 60 fps, two seconds corresponds to 120 frames and four seconds to 240; at 30 fps, those values are 60 and 120. A stream with variable rate, frame drops, resampling or timestamp irregularities may not maintain that simple relationship in every moment.
Bitrate and codec should be chosen for the resolution and frame rate, separately from the GOP. As listed on YouTube’s site in September 2026, its recommended H.264 bitrates include 17 Mbps for 1080p60, 34 Mbps for 1440p60 and 50 Mbps for 2160p60. Those are examples from the platform’s guidance, not universal guarantees of quality or a reason to force a lower-rate source to 60 fps. Use the current table for the actual resolution and codec you send.
Constant bitrate is part of YouTube’s ingest recommendations. If you change resolution, frame rate or codec, revisit the corresponding bitrate guidance rather than assuming the old rate remains appropriate. An under-provisioned output can produce visible degradation even when the keyframe interval is correct; an unnecessarily large bitrate can exceed the upload capacity or encoder budget you actually have.
Check for intentional frame-rate conversion
Frame-rate conversion can be deliberate. You might combine footage captured at different rates, apply a delivery standard across a programme, or use a filter to produce a constant-rate output from variable-rate input. In those cases, document the conversion in the command or editing preset and calculate GOP duration from the resulting output cadence, not the original clip’s label.
For variable-frame-rate input, avoid reasoning as if every source frame arrives at equal intervals. FFmpeg may resample frames, and your selected output options determine the timestamps YouTube receives. Look for an explicit output frame-rate setting or an fps filter in the filter chain, then confirm where it sits relative to scaling and other filters. A duplicated or dropped frame is not necessarily a keyframe error; it may be the intended result of conversion or a symptom of processing load.
With a mixed-rate playlist, inspect representative sections, not just the first file. A 60 fps intro followed by 30 fps material can make a conversion pipeline behave differently from a single-rate clip. If you are building a repeating playlist, the process described in our FFmpeg playlist scripting guide is relevant to keeping the inputs organised, but you still need to define and check your encoding cadence.
For a prerecorded loop, compare the encoded output around cuts and scene changes. With scene-cut detection enabled, the encoder may insert additional keyframes; that may be acceptable if you care more about scene changes than a perfectly regular cadence. If you need a predictable two-second pattern for ingest, disabling scene-cut insertion can help, but verify the chosen encoder’s behaviour and do not trade away other quality or compatibility needs without testing.
Test and confirm the stream YouTube receives
A command that looks right is not evidence that the stream arriving at YouTube is right. Test with a representative section containing motion, scene cuts, audio and any planned transition between clips. Check local encoder logs for warnings, inspect output metadata or packet timing when you can, and confirm the actual rate and keyframe pattern rather than reading the intended options back from the command.
Then check YouTube Live Control Room’s stream health and preview. YouTube’s live streaming error messages guidance notes that ingestion errors can lead to an incorrectly reported GOP size. If the status display looks inconsistent with your encoder’s output, investigate the ingest path and the actual stream before changing several settings at once. Make one controlled change, repeat the test, and note what changed.
Watch for symptoms that point elsewhere. A correct GOP does not solve dropped frames caused by an overloaded encoder, unstable connection or an unsuitable bitrate. Conversely, a smooth local preview does not confirm that YouTube has received the intended frame rate or keyframe structure. Verify both ends when the problem appears only after ingest.
For a long-running broadcast, a test should include enough duration to reveal repeated transitions and not just a short opening. If your channel loops a prerecorded file, check the loop boundary, because a discontinuity can coincide with a scene change and make it harder to distinguish an encoder issue from the content itself. The practical workflow in our guide to confirming the resolution received from FFmpeg can help separate configured output from the stream YouTube reports.
When a stream is produced manually on a computer, the process needs attention for the full broadcast: the machine must remain on, the encoding process must continue, and a dropped process needs recovery. If the recurring problem is keeping a prepared video running through the night rather than selecting an FFmpeg flag, StreamNeo removes the need to leave your own computer running by taking an uploaded video and carrying it as a YouTube live stream, with monitoring and restart if it drops.
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
What should my FFmpeg keyframe interval be for YouTube Live at 60 fps?
Use two seconds as the target, which is 120 frames when the output is constant 60 fps. For libx264, -g 120 is a sensible maximum-GOP starting point; check closed-GOP behaviour and verify the encoder’s actual output.
Is the GOP size 120 or 60 for 60 fps streaming?
At 60 fps, 120 frames spans two seconds; 60 frames spans one second. For a two-second target at constant 30 fps, use a 60-frame calculation instead. The frame count follows output rate, not the source’s name or the number used by another guide.
Should I force a 30 fps source to 60 fps?
Not unless your production intentionally converts frame rates. YouTube supports up to 60 fps, but that does not mean a 30 fps source should be forced to 60; matching the source avoids adding duplicated frames without a production reason.
Does -g 120 guarantee a closed GOP?
No. It sets a maximum GOP size in the libx264 wrapper, while YouTube calls for a closed GOP for optimal transcoding. Check the selected encoder’s controls and inspect the resulting stream; do not infer GOP structure from -g alone.