OBS stream settings for cross-border live selling

Cross-border streaming differs from domestic streaming in exactly one way at the encoder level: the same machine is also running a translation pipeline. Everything else — keyframes, bitrate, rate control — has values that platform documentation states outright, so there is nothing to guess at.

The short answer

Setting	Value	Source
Encoder	Hardware first (NVENC / AMD / QuickSync / VideoToolbox)	Keeps CPU free for recognition and synthesis
Rate control	CBR	Twitch tells all broadcasters to use CBR
Bitrate	Start at 75% of stable upload	OBS stream connection troubleshooting
Keyframe interval	2 seconds	YouTube: recommended 2s, do not exceed 4s
Sample rate	One value end to end	Avoids resampling and long-session drift

The rest of this article explains each choice and where cross-border streaming needs different handling.

Why the keyframe interval has to be typed in

Leaving it at 0 (auto) is the single most common misconfiguration. Platforms slice your stream into segments for delivery, and each segment has to start on a keyframe to be playable on its own. A long keyframe interval misaligns those boundaries, and viewers feel it as a hitch every time the player changes quality.

The published guidance is consistent:

• YouTube lists “Recommended 2 seconds, Do not exceed 4 seconds” in its encoder settings page;
• Twitch uses 2 seconds in every spec it publishes, from 720p30 through 1080p60;
• TikTok is the exception. Its help documentation does not publish an RTMP ingest spec at all — it only explains that LIVE Studio picks parameters automatically based on your hardware and network.

That last point deserves its own sentence: when you push to TikTok from OBS, there is no official encoder spec to cite. Every TikTok settings table circulating online is third-party experience rather than a published requirement. The defensible fallback is the intersection of what YouTube and Twitch document — CBR, 2-second keyframes, H.264 — which holds for any HLS-based delivery.

Bitrate: measure your upload first, read the platform ceiling second

The OBS troubleshooting guide states the starting point plainly: set the bitrate to 75% of your stable upload speed. That 25% is not waste. It absorbs retransmits, bursts, and whatever else on the network decides to talk at the same time.

“Stable upload” means measured during your actual broadcast window, not the number on your contract and not the best single speed test you ever ran. If your cross-border route goes through a proxy or a leased line, it moves around more than a domestic connection does, which makes measuring it more important rather than less.

Why CBR rather than VBR. Twitch documents the mechanism: with VBR, bitrate falls sharply during static scenes and then spikes when motion returns, and many viewer connections cannot absorb that jump — it shows up as buffering and dropped frames. Twitch also notes that VBR causes problems crossing ISPs, which it calls broadcast starvation. Video rides on TCP, and sudden bursts are what TCP handles worst.

The cross-border-specific part: give the CPU back

This is the one recommendation that has no domestic equivalent.

In ordinary streaming, x264 versus hardware encoding is a quality-against-CPU trade. Cross-border streaming adds a second claimant: speech recognition and speech synthesis want that CPU too. On slower x264 presets the encoder consumes a large share of CPU time, and when the translation pipeline gets squeezed the symptom is not a stuttering picture — it is recognition results arriving late and translated audio falling further and further behind. That reads like a slow translation service, and it usually is not.

A hardware encoder moves the work onto dedicated silicon on the GPU. TikTok gives the same reasoning in its own LIVE Studio documentation: hardware encoders are recommended because they use the GPU to reduce CPU load.

The quality gap is smaller than people assume. Twitch’s published comparison: NVENC from Turing onwards (RTX 20-series and GTX 1660/Ti) typically beats x264 fast and lands around x264 medium, while older Pascal and Kepler encoders sit near veryfast / faster. For the kind of content a selling stream shows, that difference matters far less than the translation latency you buy back.

Audio is the part that actually matters here

A slightly soft picture is survivable. Broken translated audio ends the broadcast.

One sample rate everywhere, and the specific value matters less than the consistency. Pick a rate in Settings → Audio and make the microphone and both ends of the virtual audio cable match it in the operating system. Otherwise OBS resamples, which costs a little CPU and can drift audibly over a long session. The virtual cable is the one people forget — it appears as its own playback and recording device with its own rate setting.

Worth correcting a widely repeated claim while we are here: “streaming requires 48 kHz” is not a universal platform requirement. YouTube’s recommended advanced settings list 44.1 kHz for stereo, with 48 kHz reserved for 5.1 surround, and Twitch simply documents “Sampling frequency: any (AAC)”. Aligning the chain is the real task; copying a number is not.

Do not scale audio bitrate the way you scale video bitrate. Twitch publishes a 160 kbps AAC maximum and recommends 96 kbps for widest compatibility; YouTube recommends 128 kbps for stereo. Synthesised speech has a cleaner spectrum than a live room, so there is very little to gain above that range.

Check the channel layout. If translated audio arrives on only one channel of the virtual cable, OBS shows a single lit meter and your viewers hear the translation in one ear. The OBS audio mixer guide points at Downmix to Mono in the advanced audio section for exactly this. It is an easy failure to miss when you are monitoring on one earbud.

When it stutters, read the right counter

OBS separates three kinds of frame loss, and the causes do not overlap:

Counter	Meaning	What to change
Dropped Frames (Network)	The network cannot carry it	Lower bitrate, go wired, enable dynamic bitrate
Frames missed due to rendering lag	The GPU cannot composite in time	Fewer sources, smaller canvas, disable preview
Skipped frames due to encoding lag	The encoder cannot keep up	Faster preset, or move to hardware encoding

Watch the third one especially. When encoding lag and translated-audio delay get worse together, it is almost certainly CPU contention rather than a translation problem — and switching to a hardware encoder usually fixes both symptoms at once.

If all three counters read zero and viewers still complain, the problem is not on your side of the connection. OBS files that case separately as stream buffering: the causes live on viewer devices and networks, and your available moves are to lower the bitrate and stay inside the platform’s recommended range.

The other network switches worth knowing

All of these sit under Settings → Advanced → Network, and the OBS connection troubleshooting guide describes each one:

• Enable network optimizations and Enable TCP pacing (Windows only): some users report fewer drops and disconnects, and they add detail to the log for diagnosis;
• Bind to IP should stay on Default unless you deliberately need one specific adapter;
• IP Family can be set to IPv4 Only as a test — OBS advises returning to the default IPv4 and IPv6 if it makes no difference;
• Dynamically change bitrate to manage congestion (Beta) lowers bitrate instead of dropping frames, with the documented caveat that it treats the symptom and costs picture quality.

Cross-border routes are longer than domestic ones, so these are worth a pass here even though they are rarely needed at home. The order still matters: measure upload, lower bitrate, and only then start flipping switches.

Verify it yourself

Ten minutes before going live:

1. Measure upload speed during your actual broadcast window, take a low result rather than the best one, and multiply by 0.75;
2. Configure the five settings from the table and open the Stats dock;
3. Start the translation pipeline and talk normally for five minutes while recording locally;
4. Watch whether any counter climbs, encoding lag in particular;
5. Play the local recording back and confirm the translated audio is present in both channels and free of clipping.

Step 3 has to include the translation pipeline. Idling OBS on its own will never surface the real bottleneck, because that pipeline is the largest variable on the machine.