For a prerecorded YouTube Live stream, set the outgoing encoder’s keyframe interval to 2 seconds; do not exceed 4 seconds. If the control is expressed in frames, multiply your outgoing frame rate by two: that is 60 frames at 30 fps or 120 at 60 fps.
The key detail is the stream YouTube receives, not simply the GOP already present in your source file. Whether playback passes that GOP through or re-encodes it depends on the software and output path, so check the active encoder settings and test the actual stream.
Decide whether you need to re-encode
Start by identifying how the prerecorded file reaches YouTube. A file may be read by a live encoder that decodes and re-encodes it, or a compatible workflow may pass through some or all of its encoded media. Those paths do not necessarily produce the same outgoing keyframe cadence. YouTube’s live encoder guidance applies to the incoming live stream; it does not tell you what every playback application does with a file’s existing GOP.
If you use OBS, another desktop encoder, or a custom FFmpeg command to play a video into a live output, look at that output’s encoder settings. A source file with two-second GOPs is not proof that the live output has them: re-encoding can create a new GOP, and the output setting then matters. Conversely, if a workflow genuinely passes through the video, an encoder setting that is not being used cannot change the source cadence.
Do not assume “streaming a file” means either guaranteed passthrough or guaranteed re-encoding. Check the documentation for the specific playback method, and inspect the actual outgoing stream or YouTube’s stream-health feedback. When the software does not clearly expose its behaviour, a short private or unlisted test is more useful than inference from the source file alone.
The same distinction matters when diagnosing a warning. If YouTube reports a long GOP, first check whether the active output encoder is the one you configured and whether it is re-encoding. A diagnostic can also be affected by ingestion problems, so treat a detected GOP value as evidence to investigate rather than an infallible reading in isolation.
Start with libx264 veryfast when speed matters
For a software libx264 workflow where getting an encode done promptly is the priority, begin a representative test with the veryfast preset and a CRF target you consider acceptable. This is a starting point, not a universal best setting. The preset trades encoding work against compression efficiency: a faster preset generally uses less computation, while a slower preset may encode more efficiently for a given quality target.
That distinction is practical for a long devotional, lofi, ambience, or product-video programme. If you have a limited preparation window and the output looks and sounds suitable, veryfast may be a sensible compromise. If file size matters for upload or storage, or the picture shows avoidable compression artefacts, compare a slower preset using the same source and CRF. A slower preset may take longer, and the exact time and resulting file size depend on the material and the machine; do not assume a fixed outcome.
The preset governs the x264 encode, not YouTube’s recommended keyframe interval. Keep those decisions separate: configure the outgoing live encoder for the required two-second cadence, and choose the offline encoding preset according to your time, quality, and file-size priorities. After changing presets or using an already-encoded file, verify what is actually sent to YouTube.
If your playlist consists of compatible files and a reliable workflow can avoid unnecessary re-encoding, that may be preferable to spending time making new encodes. But compatibility has to be established, not guessed. A faster offline preset does not fix incompatible codecs, containers, frame rates, or audio settings in the live path.
Set and test a CRF target
CRF is an x264 quality-control setting for variable-bitrate encoding. Rather than asking the encoder to hold one fixed bitrate throughout the file, you choose a quality target and the bitrate can vary with scene complexity. A still devotional image and a busy camera pan do not demand the same amount of data, which is why one average bitrate is not a reliable promise about every section’s visual quality or final file size.
Choose a CRF value that gives you an acceptable sample, then keep it fixed while comparing presets. The value is a target for the encoding process, not a guarantee that every source will look identical or produce the same bitrate. Fine text, gradients, dark scenes, fast movement, and repeated overlays can reveal problems that a static frame will not.
For a fair comparison, encode the same short source section at the same resolution and frame rate, using the same CRF while changing only the preset. Watch the output at its intended viewing size, including on a phone if that is how much of your audience will watch. Listen to the audio as well: video encoding changes should not be allowed to conceal a separate audio issue.
When a CRF result looks too soft or shows blocking, try adjusting the quality target and test again. If the picture is already acceptable but the file is larger than your upload or storage plan allows, compare a slower preset before compromising quality; it may improve compression efficiency, although there is no guarantee for a particular clip. Keep notes on the source, preset, CRF, and observed result so the next file does not require starting from memory.
CRF is for the file encode, not a substitute for the outgoing live stream’s bitrate configuration. YouTube’s live encoder settings provide codec, resolution, and frame-rate guidance for the live contribution. Use the applicable profile rather than treating an offline CRF result as a live bitrate recommendation.
Compare veryfast, fast, and medium
There is no preset that is right for every playlist. Compare the options against the constraint that matters in your case: preparation time, acceptable visual quality, upload size, or storage. Keep the source segment and CRF constant, and compare the resulting files rather than relying on the preset name as a quality rating.
| Preset | A useful reason to test it | Trade-off to check |
|---|---|---|
veryfast |
You need a quick software encode and want a practical baseline. | Check fine detail and motion at the chosen CRF; file size may not suit your limits. |
fast |
You can spend more encode time than veryfast and want to test compression efficiency. |
Confirm the result is worth the extra preparation time for your material. |
medium |
Quality or file size matters more than finishing the encode quickly. | The additional encode work may not be worthwhile for a simple, low-motion source. |
This table describes what to compare, not a ranked result. A static background with a small animated element may behave differently from a concert recording or jewellery close-up. If the audience sees a recurring loop, sample both a quiet section and the busiest part; a single still frame cannot show how movement holds up.
For an always-on channel, preparation time includes more than the encode itself. You may have to check the whole playlist, verify audio transitions, upload the result, and test the live route. A preset that is tolerable for one short file may be inconvenient when you need to prepare many. On the other hand, if each file is reused often, taking longer to produce a smaller or cleaner master can be worthwhile.
If the encode is not the bottleneck, do not slow down the workflow just because a preset sounds more thorough. If the image has visible artefacts or the file is difficult to move, test a slower preset on a sample before committing the entire playlist. This keeps the decision evidence-based without committing hours to a setting that makes no practical difference on your source.
Inspect a representative sample
A representative sample should include the material most likely to expose a problem: motion, fine detail, dark or smooth areas, title cards, and an audio transition if the programme has one. For a bhajan loop, that might mean a section with a moving visualizer and a static prayer card. For a local-news loop, include a presenter shot, scrolling text, and a transition between items.
Inspect three things separately. First, view the video for blocking, softness, banding, and detail loss. Second, listen for clipped, missing, or abruptly changing audio. Third, confirm the outgoing live settings: frame rate, resolution, keyframe interval, and the appropriate bitrate for the selected codec and profile. A good-looking file does not prove that the live output uses the right GOP cadence.
For GOP verification, check the encoder’s outgoing setting and run a test stream that uses the same playback and output path planned for the real channel. Monitor YouTube’s stream health in Live Control Room. Google’s Live Streaming API diagnostics document GOP-related configuration issues, including a GOP that is too long and mismatched keyframe frequencies for primary and backup streams. If you send both feeds, configure their keyframe cadence to match.
YouTube normally detects the incoming frame rate and resolution in Live Control Room, while manual choices are available in the relevant custom-key settings. Verify the actual selected output rather than assuming the file’s properties automatically determine them. If YouTube reports an ingestion problem at the same time as an unexpected GOP reading, resolve the transport or configuration issue and test again before deciding the source encode is at fault.
A short test cannot prove every hour of a 24/7 run will behave identically, but it can catch a bad preset, wrong frame-based GOP value, or a mismatched backup stream before you schedule a longer broadcast. For further checks after the test, see how to check whether a 24/7 stream is still live. Keep the test close to the actual workflow: same source type, encoder, protocol, and output profile.
Use the concat demuxer when files are compatible
If your programme is built from several files, concatenating compatible media without re-encoding can save time and avoid an unnecessary quality-generation step. FFmpeg’s concat demuxer reads a list of files as though they were one continuous input, but the files need compatible stream parameters. Differences in codec, dimensions, frame rate, sample rate, channel layout, or time bases can prevent a clean result or create problems at boundaries.
The demuxer does not make unlike files compatible by itself. Check the files’ streams before relying on a joined output, then inspect transitions and duration. Even when the joined file is valid, it still does not prove the live encoder will pass through its GOP unchanged. The playback/output stage may re-encode it, and that outgoing encoder’s cadence remains the setting YouTube receives.
If files are not compatible, you may need to standardise them by re-encoding. For that path, use your chosen libx264 preset and CRF test, then check the assembled result. If you are building a recurring programme rather than one continuous file, a prerecorded-video YouTube Live setup guide can help you think through the wider playlist workflow. For an FFmpeg playlist with changing order, see how to shuffle videos in an FFmpeg YouTube Live playlist.
There is also a protocol distinction. The general two-second recommendation is for YouTube Live encoder guidance; HLS ingestion has additional packaging requirements. YouTube’s HLS ingestion guide calls for closed GOPs and specifies media and segment-duration requirements. Segment duration and GOP interval are related but separate controls. Do not carry HLS container or segment rules into an RTMP/RTMPS workflow, or assume that setting a two-second GOP alone satisfies HLS requirements.
A practical setup sequence
- Identify whether your workflow re-encodes the prerecorded file or sends compatible encoded media through. Confirm which encoder/output is active.
- Set that outgoing YouTube Live encoder’s keyframe interval to 2 seconds. Where it accepts frames, use the outgoing frame rate multiplied by two: 60 at 30 fps, or 120 at 60 fps. Do not exceed 4 seconds.
- If creating a new libx264 file and speed is your priority, test
veryfastat a CRF you find acceptable. Comparefastormediumwhen picture quality or file size warrants spending more encode time. - Inspect representative video and audio, then test the actual live path and review stream health. If using primary and backup feeds, ensure their keyframe frequencies match.
OBS’s advanced recording settings guide shows that OBS exposes a keyframe interval setting and lists a value of 2 in its baseline recording settings. That guide concerns recording presets; it is useful for locating the concept, but it is not a replacement for checking the streaming encoder’s output tab or YouTube’s feedback. For a separate look at keeping a multi-video broadcast running, the guide to avoiding freezes between playlist videos addresses a different failure point than GOP cadence.
Choose your path based on what the source and destination require. If your files are already compatible and the playback route preserves the media, avoid encoding them again without a reason. If you must encode, use a short sample to decide whether a faster preset meets your needs. In either case, configure and verify the outgoing stream independently.
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 GOP length should I use for YouTube Live?
Use a two-second keyframe interval for the outgoing live stream, and do not exceed four seconds. YouTube’s guidance concerns the feed it receives, so verify the active encoder or pass-through path rather than relying only on the source file.
How many frames is a two-second GOP?
Multiply the output frame rate by two. That gives 60 frames at 30 fps and 120 frames at 60 fps; these are conversions of the two-second interval, not separate platform recommendations.
Does a prerecorded file keep its original keyframe interval when streamed?
Not necessarily. The application may re-encode the source or may pass through compatible media, and behaviour depends on the workflow. Test the actual outgoing stream and check YouTube’s stream health.
Should I always use libx264 veryfast?
No. It is a reasonable starting point when speed is the priority, but it is not best for every source or constraint. Compare presets at the same CRF on representative footage, and choose based on the quality, preparation time, and file size you can accept.