For a 24/7 recorded lecture stream, use OBS settings that your computer can sustain, save a recoverable local recording, and match the actual YouTube output resolution and frame rate. There is no universal bitrate or configuration that guarantees an uninterrupted broadcast: test the whole file and monitor both OBS and YouTube while it runs.
Keep the local recording and the outgoing stream in view as separate jobs. The recording needs a container that can survive an abrupt stop and enough disk space for your retention period; the live output needs an encoder, bitrate and connection that stay stable for the chosen format.
Check YouTube's current encoder recommendations
Start with the current YouTube Live encoder settings, rather than a bitrate copied from a tutorial whose resolution or frame rate may not match yours. YouTube's recommendations are organised by output characteristics, so decide what you will send before choosing a bitrate. Read the YouTube Live encoder settings table directly and check it again when you change the stream format; guidance and supported options can change.
A practical order is to identify the lecture's intended output resolution and frame rate, choose the matching row in YouTube's table, then configure OBS's streaming output accordingly. A lecture made chiefly of static slides may look clear at a lower frame rate than a fast-moving demonstration, but that is a choice to test with your own source, not a platform rule. Higher frame rates can also increase encoding work and data use. OBS notes that 60 fps can be much more taxing than 30 fps in its overview guide.
Do not mix up recording quality with the live bitrate recommendation. OBS's local file can use a quality-based encoder setting that changes its file size over time, while the live stream generally needs a bitrate suitable for YouTube's ingest and the capacity of your upload connection. If you use different settings for recording and streaming, the computer may have to do more work than when one output reuses the other.
The OBS values later in this article describe documented recording baselines, not a promise that your computer will manage them for a full day. YouTube's current table is the primary reference for the outgoing stream's bitrate and format. Keep a note of the OBS version, encoder name and chosen output format so that a later update does not quietly change the options you rely on.
Choose the ingest protocol, codecs and recording format
For a YouTube broadcast from OBS, use the service's current recommended ingest protocol and the codecs it accepts, as shown in the current YouTube encoder documentation. Select the service in OBS's stream settings where possible, then confirm the server and stream key in YouTube Live Control Room. Avoid copying a server address or codec combination from an unrelated guide: account settings, OBS builds and YouTube's supported choices can vary.
Your local recording is a separate decision. OBS recommends MKV for recordings that might end without a graceful stop, because an interruption need not make the entire recording unusable. If your editing or upload tool expects MP4, stop the recording and use OBS's remux function to create an MP4 copy. Remuxing changes the container without re-encoding the audio and video, so it is not a way to improve a source that was encoded poorly.
| Choice | Useful when | Trade-off |
|---|---|---|
| MKV recording | You want a local file that is more recoverable after an abrupt shutdown | Some editing or upload tools may not accept it directly; remux after recording if needed |
| MP4 recording | Your workflow requires that container and shutdown risk is acceptable | An ungraceful stop can put the whole file at risk |
| Separate recording encoder | You need local recording quality or format independent of the live output | Additional encoding work can burden the computer |
| Same as stream | Simplicity matters and the live output also suits the local copy | The local file inherits stream settings and may not be ideal for editing |
OBS's Audio/Video Formats Guide discusses container compatibility, and its Standard Recording Output Guide covers choosing the recording path and output options. Check those guides alongside your own editor's accepted formats before committing to a long run.
Set real-time input pacing and match the source
When you use a prerecorded lecture as the source for an always-on stream, the media must be read and sent in real time. A file can be decoded faster than its playback duration; a streaming command therefore needs input pacing so it does not race through the file or send bursts that the ingest path cannot accept. In FFmpeg, -re is commonly used to read an input at its native rate. Put input options before the relevant input in the command and verify the behaviour with your installed FFmpeg build.
A minimal conceptual command structure is:
ffmpeg -re -i lecture.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 4500k -maxrate 4500k -bufsize 9000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -f flv "$YOUTUBE_INGEST_URL/$STREAM_KEY"
This is an example shape, not a universal command to paste in unchanged. In particular, the numbers shown in a shell example are illustrative and must not be treated as a recommendation for your resolution, frame rate or YouTube ingest. Set video bitrate, buffer and GOP to values derived from YouTube's current table for your chosen output and frame rate. Match GOP interval to two seconds using the actual frame rate: for example, the keyframe count is frame rate multiplied by two. A 30 fps stream therefore needs a different keyframe count from a 60 fps stream. Check your FFmpeg build's encoder help for accepted options, and do not assume every build exposes identical controls.
If the lecture is already at the output dimensions and frame rate, avoiding unnecessary scaling or frame-rate conversion can reduce work and avoid an avoidable quality change. If it is not, choose a deliberate output and test the conversion. Audio also needs attention: confirm that the input has the expected track, that speech is audible at a sensible level, and that long playback does not drift out of sync.
OBS and FFmpeg are different ways of preparing and sending a stream; you do not need to run both encoders for the same broadcast. For an OBS workflow, use its output controls and verify them in the current interface. For a file-based command, FFmpeg gives you explicit controls but makes you responsible for the command, process supervision and restart behaviour. If you are first setting up the loop itself, this guide to looping a recorded video in OBS covers the source workflow rather than replacing your encoder tests.
Use CBR and a two-second keyframe interval for the live output
For YouTube live ingest, configure a constant bitrate target and a keyframe interval of two seconds, following YouTube's current encoder recommendations. In FFmpeg, a typical CBR-style setup uses a target bitrate together with matching maximum rate and an appropriate buffer; exact syntax and encoder behaviour depend on the chosen encoder and build. In OBS, select the rate-control option and keyframe interval in the streaming output settings, then confirm the interface reports the values you intended.
CBR does not mean every frame contains the same amount of information. It aims to keep the output rate predictable for the ingest path, while the encoder varies how it allocates bits within that constraint. A static slide may need fewer bits to look clean than a screen recording with cursor movement, but the rate target still has to suit YouTube's table and your connection. If a scene becomes complex, the encoder may have less room to preserve detail at the same rate.
The two-second interval is about the live stream's keyframes, not a rule that every recording must use the same GOP in every circumstance. If you are encoding both a local file and a live output with distinct settings, verify each output independently. With FFmpeg, frame rate and GOP settings interact; a fixed keyframe count only represents two seconds when the output frame rate is known and stable. Variable frame rate inputs or frame-rate conversion deserve a test rather than an assumption.
Select bitrate for the actual resolution and frame rate
There is no single best bitrate for every lecture stream. Use the current YouTube table row for the resolution and frame rate you have selected, then check whether your upload connection can sustain that outgoing rate with room for other network traffic. Do not lower resolution or choose a bitrate solely because a forum post says it worked for someone else; the source, motion, encoder and connection all affect the result.
| Decision | What to compare | Practical consequence |
|---|---|---|
| Output resolution | Source detail, YouTube's current recommendations and encoder load | More pixels can retain small slide text but require more encoding and bandwidth |
| Frame rate | Whether the lecture has meaningful motion and the source frame rate | Higher frame rates can increase system load and data use; static slides may not benefit |
| Live bitrate | The matching YouTube recommendation and stable upload capacity | Too little can make detail suffer; too much can contribute to dropped frames if the route cannot keep up |
| Local recording quality | Desired edit quality, encoder capacity and file growth | Quality-based recording can vary in size, so estimate from a test rather than assuming a fixed file size |
A lecture containing small text is not automatically improved by increasing bitrate if the source was captured at low resolution or scaled badly. Check the actual stream preview on a separate device, including slides with dense text and any embedded video. If the text remains hard to read, assess source resolution and scaling as well as bitrate.
For a local OBS recording, quality-based settings such as NVENC CQP or x264 CRF are not the same thing as a live bitrate target. OBS's Advanced Recording Settings Guide lists NVENC CQP 16–23, keyframe interval 2, P5 and High Quality tuning as a baseline, and x264 CRF 16–23 with the veryfast preset. Lower CQP or CRF values generally mean higher quality and larger files. These are starting points from OBS's guide, not a certification for a particular PC or an instruction to set a live stream to those values.
Choose a hardware encoder when available and suitable if moving encoding work away from the CPU helps your particular machine. OBS explains that hardware encoding uses a specialised component and that quality varies with encoder generation. Software x264 may be preferable if the CPU is capable and its output suits your needs, but it adds CPU demand. Compare them on the machine that will actually run the stream, not on a different computer's benchmark.
Test the full file, settings and command before the long run
A short preview proves only that the stream can start. Before scheduling a continuous lecture, run the complete file from beginning to end with the same OBS profile, encoder, output format and destination settings you intend to use. Check the opening and ending, scene transitions, audio throughout, any repeated section or loop boundary, and the stream's behaviour after the file reaches its end. If you expect to replay the lecture, test the transition back to the start too.
The test should exercise the computer under normal conditions. Close applications you will not need, but do not create an unrealistically idle test if the computer must also run presentation software or other services during the real event. Watch OBS's status and logs, listen to the stream remotely, and compare the delivered picture with the source. A local preview can look fine while the connection to YouTube is dropping frames.
For a local recording, make a separate test file and play it back in the tools you plan to use. Confirm that the MKV opens after a normal stop, and practise remuxing it to MP4 if your editing or upload workflow needs MP4. Check that the recording path points to the intended drive, and estimate storage from observed file growth over a representative test multiplied by the planned recording and retention duration. Recheck free space before a long run; there is no defensible universal disk capacity without knowing quality, source, duration and retention.
OBS's recording presets guide gives an idea of how sharply file size can change: it describes the Lossless preset as around 7 GB per minute, specifically for that preset, and calls the resulting size very large. That figure is not a prediction for High Quality, CQP, CRF or your configuration. Avoid Lossless for a continuous recording unless you have calculated and verified that the storage and workflow can support it.
FFmpeg users should test the exact command and installed version, not merely a command copied from a page. Encoder names and option availability can differ across versions and builds. Use ffmpeg -version and the encoder's help output to establish what is installed; validate the command against the intended input, output codec and destination. Store the stream key outside the command history or shared scripts, and do not publish it in logs or screenshots.
OBS itself advises testing before going live. Updates can alter settings screens, encoder support or defaults, so record the working version and profile. If the test succeeds only after a particular change, document that change. A tested configuration is more useful than a long list of settings without evidence that your source and machine can sustain them.
Monitor stream health during the event
During the broadcast, check the OBS status bar and YouTube Live Control Room rather than assuming that an open window means the stream is healthy. OBS distinguishes rendering or encoding lag from network loss; the remedy depends on which counter or log message is changing. YouTube's preview can confirm that the ingest is receiving a signal, but also check the public playback when appropriate, since a stable ingest preview does not tell you whether every viewer's connection is healthy.
OBS's connection troubleshooting guide explains that dropped frames indicate an unstable connection to the remote server or an inability to sustain the configured bitrate. If dropped frames rise, first examine whether other devices or applications are consuming upload capacity and whether the connection to the selected ingest server is stable. Lowering bitrate may ease congestion, but it can reduce picture quality and does not repair the underlying network cause. Make any bitrate change using YouTube's current guidance for the resulting format.
If the problem is encoding lag rather than dropped frames, reduce the work the computer must do: test a lower frame rate or output resolution, simplify scaling or filters, or try a suitable hardware encoder. A lecture of still slides may tolerate a lower frame rate; a software demonstration with cursor movement may need more temporal detail. Change one variable at a time and check both picture quality and system load.
For a 24/7 schedule, decide who or what will notice a failed process and who can respond. OBS can show connection and encoding state, but a person who is away from the computer cannot act on a warning they never see. Use a remote check of the public stream and a separate way to receive alerts if unattended operation matters; do not rely on a single local preview. If you need the broadcast to continue while your own computer is off, StreamNeo removes the specific burden of keeping OBS running locally by taking an uploaded video and your YouTube stream key to run the broadcast in the cloud, with monitoring and automatic restarts if it drops.
Keep local recording failures distinct from network failures. A full drive or interrupted disk write can damage the local archive without necessarily ending YouTube's live output; a connection problem can interrupt the public stream while the local recording continues. Check both the recording file's growth and the broadcast status, and make sure the person responsible knows how to stop cleanly, preserve the file and restore the stream after a failure.
If the stream repeatedly buffers for viewers, investigate the ingest and playback path rather than changing random recording settings. The practical checks in this guide to repeated buffering on an always-on YouTube stream help distinguish a viewer playback symptom from a local encoder issue. If you need a simple remote check, use the steps in how to tell whether a 24/7 stream is still live.
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 are the best OBS recording settings for a lecture?
Start with MKV for a recoverable local recording and use a quality-based encoder setting that your hardware can sustain. OBS documents NVENC CQP 16–23 and x264 CRF 16–23 as recording baselines, but test the actual source and computer; these are not live bitrate recommendations.
What bitrate should I use for a 24/7 YouTube lecture stream?
Use the current YouTube encoder table for the output resolution and frame rate you have chosen, then confirm that your upload route can sustain it. A universal number would ignore the format, encoder, source and connection, so do not select one without those checks.
Should I record in MKV or MP4?
OBS recommends MKV when an abrupt stop could happen because the whole recording is less likely to be lost. If your editor or upload workflow needs MP4, remux the finished recording in OBS and verify the resulting file.
Can I guarantee OBS will stream without interruption?
No setting can guarantee that a computer, connection, storage device or platform will never fail. Test the full file and setup, keep an eye on local recording and live health separately, and plan how someone will respond if either fails.