For an SDR product demonstration on YouTube Live, start with H.264, constant bitrate, a two-second keyframe interval and AAC audio. Choose a resolution and frame rate that make the product easy to see and that your measured upload connection can sustain; no single OBS preset is best for every product, scene or network.
YouTube’s published H.264 examples recommend 8 Mbps for 720p30 and 14 Mbps for 1080p30, but those are ingest recommendations, not guarantees of picture quality or connection capacity. Test representative product footage, lighting, overlays and sound in YouTube’s preview before you commit to a continuous run.
Start with YouTube’s ingest recommendations
OBS sends an encoded feed to YouTube. For a standard SDR stream, a practical starting point is H.264 video over RTMPS, CBR rate control and a two-second keyframe interval. YouTube identifies RTMPS as the secure extension to RTMP for standard streaming, and its live encoder settings document the supported settings and bitrate recommendations. The precise options visible in OBS depend on your system and the encoder you select.
These settings describe the signal sent to YouTube, not the versions that each viewer will receive. YouTube transcodes live video into multiple output formats, so viewers may be offered playback quality options. OBS settings do not control those transcoding outputs. The useful target is a stable, supported ingest feed that presents the details your viewers need.
For ordinary SDR, use Rec. 709 colour and 8-bit output, and avoid selecting an HDR workflow unless you have checked the relevant camera, encoder and YouTube requirements. HDR has separate requirements; it is not simply a higher-quality toggle. YouTube lists other ingest codecs, including H.265 and AV1, but H.264 is the straightforward baseline for a conventional SDR setup. Check compatibility before switching codecs or changing stream-key settings.
The same distinction applies to latency. If viewers mainly watch a repeating demonstration and are not interacting with you live, normal latency is usually the sensible starting point. YouTube notes that lower latency can increase playback buffering and matters more when you need to respond to viewers in real time. Choose the viewing experience you need, rather than treating the lowest delay as an automatic improvement.
Choose resolution and frame rate your upload sustains
Start with what the viewer must read. A close-up of a product label, small menu text on a screen or a demonstration of a moving part may justify a sharper or smoother picture than a wide shot of an item turning slowly on a display stand. But a higher resolution or frame rate can require more upload capacity and encoding work. Decide from the content and a real test, not from the largest number OBS offers.
For a mostly static product display with occasional handling, 30 fps may be enough. If hands move quickly, a mechanism rotates or the camera pans regularly, test a higher frame rate and check whether that motion looks clearer to a viewer. YouTube supports frame rates up to 60 fps, but higher is not automatically better for a stationary scene. Match the resolution and frame rate you choose to the corresponding row in YouTube’s bitrate table.
Measure upload capacity where the encoder will run. Download speed does not tell you whether that connection can keep sending video. YouTube’s streaming tips recommend testing upload speed and keeping 20% upload-bandwidth headroom. Treat that as capacity to preserve, not spare bandwidth to fill: other users, cloud backups, point-of-sale devices or a backup stream may need the same connection.
If the connection is shared, its advertised speed is not necessarily what OBS can use while other devices are active. Test at a representative busy time, preferably with the normal shop, office or home network in use. A stream that looks stable during a quiet test may drop frames when someone uploads a large file or joins a video call. If your setup relies on a particular broadband service, the JioFiber livestream setup guide offers a useful connection-specific comparison, though the measurement for your own location still matters.
Set H.264, CBR and the keyframe interval
In OBS, select an H.264 encoder supported by the installed system and configure rate control as CBR, or constant bitrate. CBR aims to maintain the bitrate you set. That makes it easier to check whether the connection has enough sustained upload capacity, although real network conditions can still interrupt delivery. Set the keyframe interval to two seconds, YouTube’s recommendation; its guidance says not to exceed four seconds.
You may see several H.264 encoder choices in OBS. OBS explains that hardware encoding moves much of the work from the CPU to a specialised component in the GPU, while software encoding uses the CPU. Modern hardware encoders can reduce CPU load, but quality and performance vary by generation and by the scene being encoded. Use an encoder available on your machine and compare it under the real OBS scene load, not only with an empty scene.
A product demo scene can involve a camera, a screen capture, overlays and audio filters at once. Watch OBS’s performance statistics during a representative test, and make sure the computer is not struggling to render or encode the scene. If the CPU or GPU is already under pressure, reducing scene complexity or testing another available encoder may help. The NVENC explainer covers the trade-offs of one hardware-encoding option without making it the right choice for every system.
OBS also documents dynamic bitrate as a beta response to congestion. It can lower the bitrate during a network problem, but OBS cautions that this does not repair the underlying connection, and lower bitrate reduces picture quality. Consider it a possible mitigation to test, not a substitute for finding a weak Wi-Fi link, saturated router or unreliable upload path.
Set AAC audio for a spoken demonstration
For an RTMP or RTMPS feed, YouTube lists AAC or MP3 audio. AAC is a common, suitable choice for a spoken demonstration. YouTube specifies 128 Kbps for stereo audio at a 44.1 kHz sample rate. Set the audio output accordingly, then judge the result on ordinary speakers or headphones rather than assuming that a correct number makes the voice clear.
Listen for the details that matter in the demonstration: the presenter’s words, the sound of a product being handled, and any background music or room noise. Handling sounds can overwhelm speech when a microphone sits too close to packaging or a hard surface. Test the actual mic position and level with the camera and product in place. If you include music, make sure its level leaves speech intelligible and that you have permission to use it.
A loop that runs unattended needs an audio check even if it contains no presenter. Confirm that the file’s audio plays through the intended OBS source, does not vanish at a loop boundary and is not unintentionally muted in the stream mix. A silent or distorted feed can persist for hours without being obvious from a thumbnail. Ask someone to listen to the YouTube preview or a viewer-side playback before leaving the channel to run.
Use bitrate examples in context
YouTube’s H.264 table gives concrete reference points for common SDR formats. Use the row matching your chosen output, then test whether your network and scene sustain it. These are platform recommendations, not universal values or a guarantee of quality.
| OBS output | YouTube H.264 recommended video bitrate | Context |
|---|---|---|
| 720p30 | 8 Mbps | A possible starting point when the product remains legible at this size |
| 1080p30 | 14 Mbps | A possible starting point when finer detail or labels need more pixels |
| 720p60 | 8 Mbps | A higher frame rate may help show motion, but check whether it is useful in your scene |
| 1080p60 | 17 Mbps | More demanding; use only when the added detail and motion clarity justify it |
The table is not a menu of guaranteed outcomes. Your camera, focus, lighting, movement, encoding load and network all affect what arrives at YouTube. YouTube also lists minimum values for these combinations, but a minimum is not a recommended target for every scene. Consult the current encoder settings page for other resolutions, frame rates and codecs rather than extrapolating from two examples.
Compare viable configurations on more than their resolution label. Check whether a product name is readable, whether motion looks clear, whether the upload has headroom and whether OBS can encode the scene without sustained load problems. Also consider whether viewers need real-time interaction and what recovery measures your channel needs. A 720p30 picture that remains stable and readable can serve a product better than a higher setting that repeatedly loses frames.
If testing at the recommended bitrate shows dropped frames or a deteriorating stream-health message, reduce the target or investigate the network bottleneck before trying to increase quality. Recheck the available headroom after changing the target. You can also compare local and viewer-side output to distinguish an OBS preview issue from a problem in the delivered stream.
Test representative product footage and overlays
Build the test scene you actually intend to use, then include the difficult parts of the demonstration. YouTube’s guidance is direct: “Make sure that you test before you start your live stream. Tests should include audio and movement in the video similar to what you'll be doing in the stream.” For a product channel, that means more than checking a static logo card.
Test a wide product view, a close-up of labels or controls, hands entering the frame and any screen capture. Include the lighting you expect during a normal broadcast, including reflections on glossy packaging and any changes between bright and dim areas. Run the camera at its actual position and focus. A label that looks crisp when the camera is close may become unreadable after the scene is cropped or scaled to fit the layout.
Check overlays at the size they will appear in the stream. Prices, product names, disclaimers and call-outs should remain legible without covering the item being shown. If the overlay animates, watch it during movement and at the point where it appears or disappears. Test a loop boundary if you use prerecorded segments; a brief black frame, abrupt sound change or frozen last image may be easy to miss in a short setup check.
Open YouTube’s Live Control Room preview and check stream health and messages while the test is running. Confirm that the channel page or intended viewing destination shows the broadcast as expected. Do not judge only from the OBS preview: that shows the local scene before YouTube has received and processed it. A preflight can catch setup problems, but it cannot guarantee that a continuous stream will never be interrupted.
For a repeatable demonstration made from prerecorded footage, a church sermon loop built with OBS Media Source is a relevant example of arranging a loop. The content differs, but the practical checks around source playback, audio and transitions apply. For a live camera-led demo, use the same principle: test the full path viewers will see, not just the source file or scene editor.
Monitor ingest stability and plan recovery
A 24/7 broadcast is an operating arrangement, not a bitrate preset. During the test and live run, pay attention to OBS dropped frames, encoder load and YouTube stream-health messages. If frames are dropping because of network conditions, investigate the connection path; if rendering or encoding is overloaded, reduce workload or test a suitable encoder. OBS’s connection troubleshooting guide describes common causes and checks.
For a continuous channel, decide who notices a problem and what they do next. Consider application failure, an operating-system restart, power loss, an ISP outage and a YouTube ingest interruption. A bitrate or keyframe setting cannot restart an application after a crash, restore power or fix an outage. Monitoring, recovery procedures, power and network resilience, and tested failover are separate operational questions. If you use a backup encoder, YouTube recommends testing the failover rather than assuming it will work when needed.
If you need a person to respond to viewers, check the channel regularly and make sure the responsible operator can see alerts. If the content is a prerecorded loop and the priority is continuous transmission while your local computer is off, a cloud workflow may remove the need to keep OBS running on that computer. StreamNeo can take away the specific burden of leaving your own computer on to transmit an uploaded video, while still leaving you responsible for preparing the content and checking the YouTube channel. Choose a workflow around the kind of content and recovery oversight you need, not around a promise that any settings eliminate interruptions.
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 settings for YouTube Live?
For a standard SDR stream, use H.264, CBR, a two-second keyframe interval and AAC audio, then choose an output your upload can sustain. Test the full scene and check YouTube’s current encoder guidance, because the right resolution and bitrate depend on the product footage and connection.
What is the OBS bitrate for 1080p 30fps YouTube Live?
YouTube recommends 14 Mbps for H.264 at 1080p30. Treat that as an ingest reference rather than a promise that your connection will sustain it or that every camera scene will look the same; measure your upload and test the scene.
What is the best keyframe interval for YouTube streaming?
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Set it in OBS, then verify the stream health in the Live Control Room preview.
How do I keep a YouTube live stream running 24/7?
Use a tested ingest configuration, monitor the stream and make a recovery plan for application, power, network and ingest failures. Settings alone cannot ensure uninterrupted operation, so test monitoring and failover procedures before relying on an unattended run.