Encoding a broadcast video with HandBrake or ffmpeg

16 Jul 2026 · 6 min read

Can this account even broadcast?

None of the encoding below matters if the account itself isn't allowed to broadcast, and this is the step people skip because it has nothing to do with video. Steam requires the streaming account to be non-limited - at least $5 of historical spend on the platform - and to either hold the "Broadcast Live" permission or be enrolled in the Store Broadcast Beta. The account also has to own or otherwise have access to the game being broadcast, and it can't be Community Banned. Miss any one of those and a perfectly compliant H.264 High@4.1 feed still won't go live, and the failure looks identical to a bad encode from the outside - the stream just refuses to start, with nothing in the encoder log to blame. Rule this out before you spend an evening second-guessing your bitrate settings. It's a five-minute check against a multi-hour encoding rabbit hole, and it's cheap insurance to do it first rather than last.

Valve's spec, in full

Everything below comes from Valve's own documentation at partner.steamgames.com, not from guesswork. The video codec has to be H.264, Profile High, Level 4.1. Frame rate is either 30 or 60 FPS, aspect ratio is 16:9, and the keyframe interval has to be 2 seconds. Maximum bitrate is 7000 kbps CBR. Audio is AAC-LC, capped at 128 kbps. None of these are suggestions - Valve validates the stream against them when it connects, and a field outside spec is why a broadcast that looks fine in your encoder never goes live. We cover the same numbers with more context in video specs and encoding for Steam.

Connecting to Steam: the RTMP side

Encoding to spec gets you a compliant feed; you still have to send it somewhere, and this part trips people up less because it's simpler than the encode settings, not because it's undocumented. Steam's broadcast ingest is a standard RTMP endpoint: rtmp://ingest-rtmp.broadcast.steamcontent.com/app. You don't choose a region yourself - Steam picks the actual upload server for you based on the account's location, the way it also picks download servers for game installs. The stream key is generated at steamcommunity.com/broadcast/upload under "Create RTMP Token." When you create it, you select the game's base application ID, not a DLC or demo entry, since the broadcast attaches to the base app regardless of which edition you're promoting.

OBS is the software most people reach for to test this, but it isn't special to Steam - any RTMP-capable encoder connects the same way, whether that's OBS, vMix, a hardware unit, or ffmpeg pushing straight to the URL above with your stream key. In OBS terms, that's the "Custom" streaming service, with the ingest URL in the Server field and the key in the Stream Key field. The RTMP layer doesn't care what produced the bits, only that they match Valve's spec once they arrive.

One thing worth checking if the connection itself won't establish, separately from anything about the encode: RTMP runs over TCP port 1935 by default. On a home connection that's rarely an issue, but on an office network, a corporate VPN, or a locked-down cloud VM, outbound 1935 can be blocked by a firewall that has no problem with normal web traffic on 80 and 443. If the encoder can't reach the ingest URL at all - not a rejected stream, just no connection - that's the first thing to rule out before assuming it's a Steam-side problem.

The one setting that fails hard: keyframe interval

Most of the spec fields degrade gracefully if you're slightly off - a bitrate a little over the ceiling might just get capped by Steam's ingest. The keyframe interval does not work that way. Valve is explicit that if it isn't exactly 2 seconds, your stream will fail to start. No partial credit.

A keyframe interval of 2 seconds means a full frame is encoded every 2 seconds, with the frames in between referencing it. At 30 fps that's a GOP length of 60 frames; at 60 fps it's 120. Most encoders default to something else - often 4 or 5 seconds, tuned for file size rather than live compliance - so this is the setting people miss even when everything else is correct. Valve calls out vMix by name here: its default is Main Profile at Level 3.0, and that combination has to be changed before a vMix output will pass. Treat that as a warning that your own encoder's defaults are probably not Steam's defaults either, and check them explicitly rather than assuming.

Why constant bitrate, not variable

Valve's spec calls for CBR, not VBR, and the reason is specific to live streaming rather than video quality in general. Variable bitrate lets the encoder spend more bits on complex frames and fewer on simple ones, which is great for a file you'll watch once end to end. A live ingest server has to buffer against a roughly constant expected data rate; a stream that swings from 2000 kbps to 9000 kbps and back makes that buffer either starve or overflow, and either one shows up as stutter or a dropped connection. CBR trades a bit of quality on simple scenes for a data rate the ingest side can plan around, which is exactly what a 24/7 broadcast needs.

7000 kbps is Valve's documented ceiling, not a target. Running right up against it leaves no margin if your source material spikes briefly above your set rate, which is normal encoder behavior even in CBR mode. A safer target is to encode a couple hundred kbps below the ceiling - 6000 kbps is a reasonable choice, and it's what we default to for the same reason.

What Steam does with your feed after ingest

It's worth knowing what happens to the feed once it's accepted, mostly so you don't over-build for a problem Steam already solves. Once a broadcast passes roughly 10 concurrent viewers, Steam automatically enables transcoding and generates lower-resolution renditions - 720p, 480p, and 360p - alongside your original 1080p feed. That happens entirely server-side; you never upload more than one stream and never configure a resolution ladder yourself. The single CBR feed described above is the only encode you're responsible for. If you're used to platforms where you push multiple bitrate variants yourself, you can drop that habit here - one clean 1080p feed at the spec above is the whole job, and it also means the quality of that one feed matters more, not less, since it's the master everything else gets derived from below the transcode threshold.

Encoding in HandBrake

HandBrake will get you compliant output, but the fields that matter for Steam sit outside its default presets. Set the container to MP4 and the video codec to H.264 (x264). Under Framerate, choose your target - 30 or 60 - and set it to Constant, not Variable. For rate control, use Average Bitrate and set it to 6000 kbps rather than a quality-based (CRF) mode, since CRF produces variable bitrate by design.

The profile, level, and keyframe interval live in the Advanced tab's x264 options string. Set Profile to High and Level to 4.1 in their own dropdowns, then add keyint=60:min-keyint=60 to the options string for 30 fps, or keyint=120:min-keyint=120 for 60 fps - that's your 2-second interval expressed in frames. On the audio tab, encode to AAC at 128 kbps.

The same thing in ffmpeg

If you'd rather script it, every field above maps to a flag. This encodes to the spec at 30 fps with a 6000 kbps target and a 2-second GOP:

The pairing worth explaining is -b:v, -maxrate, and -bufsize set to the same or related values - that's what makes libx264 actually hold to CBR instead of drifting toward its default VBR-like behavior. -g 60 is the GOP length for 30 fps (use 120 at 60 fps), and -sc_threshold 0 stops the encoder from inserting an extra keyframe at scene cuts, which would otherwise break the fixed 2-second interval Valve requires.

Checking your output before you push it live

Rather than trusting that your encoder did what you asked, it's worth reading the file back before you route it at Steam's ingest. ffprobe, which ships alongside ffmpeg, will print the actual profile, level, and frame rate it finds in the output rather than the ones you requested:

That prints back exactly what got baked into the file - if the profile reads "Main" instead of "High," or the level shows as 3.1 instead of 4.1, you'll know before Steam tells you the hard way. The GOP length is a little more work to confirm directly, but a rough check is to count video packets over the first few seconds; at 30 fps with a 2-second interval you should see a keyframe roughly every 60th frame. It's a small step, but it turns "the stream got rejected, now what" into "the level is wrong, fix that one field" - a much shorter debugging loop.

Latency: what to actually expect

Valve doesn't publish an official latency figure for store broadcasts, so treat anything you read on this - including here - as a reported figure, not a spec. With that caveat: users commonly report latency of around 30 seconds on store broadcasts, against roughly 15 seconds on Twitch. Valve's own patch notes have claimed sub-1-second latency, but specifically for 1-on-1 friend broadcasts, not the store page feed, and some users report that improvement never showed up on store broadcasts at all. Take the ~30-second figure as a rough, community-reported number rather than something Valve stands behind in writing.

For a looping pre-recorded video, none of this matters in practice. Latency only becomes a problem when someone on the other end needs to interact with what's happening live - reading chat, reacting in real time, timing a countdown. A 24/7 loop of a trailer or gameplay reel has nothing live to desync, so a 30-second delay is invisible to someone just watching your store page. It's a real constraint only if you're trying to run something interactive through the same connection; see running a looping pre-recorded broadcast for what does and doesn't work well as a loop.

Or skip the encoder entirely

All of the above exists because Steam's ingest is unforgiving about the encode, not because the numbers are hard to find. With Loopcast you upload whatever file you have and we transcode it to 1920x1080 at 30 fps, a 2-second keyframe interval, 6000 kbps CBR, and AAC-LC audio at 128 kbps and 44.1 kHz automatically - the same spec covered above, applied without you touching a codec setting or an RTMP URL. Once you've got a stream key from Steam, see getting your Steam stream key to connect it, and if a stream ever refuses to start, broadcast troubleshooting covers the most common causes, encode and eligibility both.