Short answer: an encoder takes a video source — camera, mixer, computer — compresses it, and sends it to a streaming destination over a protocol like RTMP or SRT. Setting one up is four decisions: hardware or software, what bitrate your upload can sustain, which protocol your destination accepts, and what latency you're willing to trade for stability. Get the bitrate wrong and everything else fails downstream, so start there. A hardware encoder suits fixed installations that run unattended; software suits anything where you're switching sources or adding graphics.
One thing to be clear about up front: this covers encoding content you have the right to distribute. Capturing the output of a pay-TV decoder and re-encoding it for distribution is the setup that gets prosecuted — the 2019 Naples case that triggered Europe-wide IPTV raids began with exactly that, a room of Sky decoders feeding an encoder.
Hardware or software
| Hardware encoder | Software encoder | |
|---|---|---|
| Typical use | Fixed install, unattended | Multi-source, produced streams |
| Reliability | Very high, purpose-built | Depends on the host machine |
| Inputs | HDMI, SDI, sometimes analogue | Capture cards, webcams, screen |
| Switching, graphics | Limited or none | Full control |
| Cost | $150 to several thousand | Free (OBS) plus a capable PC |
| Startup | Powers on and streams | Someone has to run it |
The rule of thumb: if the stream is one camera pointed at one thing and nobody will be in the room, buy hardware. A church service, a lecture hall, a council chamber. If you're cutting between cameras, adding lower-thirds, or sharing a screen, use software — OBS Studio is free, mature, and does everything most people need.
Start with your upload speed
This is the step people skip, and it causes most failures.
Run an upload test — not download, upload — and take the sustained figure, not the peak. Then set your video bitrate to roughly half of it. If you upload at 10 Mbps, stream at 4–5 Mbps. The headroom absorbs the moments your connection dips, and it will dip.
Sensible starting points:
| Output | Video bitrate | Audio | Minimum sustained upload |
|---|---|---|---|
| 720p30 | 2.5–4 Mbps | 128 kbps | 8 Mbps |
| 1080p30 | 4–6 Mbps | 128–160 kbps | 12 Mbps |
| 1080p60 | 6–9 Mbps | 160 kbps | 18 Mbps |
| 4K30 | 13–20 Mbps | 160 kbps | 40 Mbps |
Higher isn't better. A 1080p stream at 9 Mbps on a connection that can't hold it looks worse to every viewer than the same stream at 4 Mbps, because it stalls. Encode for the connection you have on a bad day.
Use ethernet. Wi-Fi at the encoder end is the most common cause of intermittent stream failure, and it's the easiest thing to fix.
Choosing a protocol
RTMP is the near-universal default. Every platform accepts it, every encoder speaks it, it's well understood. It runs on H.264 with AAC audio and nothing newer, which is its main limitation. Use it unless you have a reason not to.
SRT is the better choice over unreliable networks. It recovers lost packets and tolerates jitter, which makes it the right pick for streaming over cellular, from a remote site, or across a long internet path. Your destination has to support it, and not all do.
RIST occupies similar ground to SRT, more common in broadcast contracting than in general streaming.
HLS or DASH are usually what comes out of your streaming platform to viewers, not what goes in from your encoder. You generally don't push HLS from an encoder unless your architecture specifically calls for it.
For most setups: RTMP to the platform, and let the platform package HLS for delivery. If your uplink is flaky and your destination accepts SRT, use SRT.
Encoder settings that matter
Keyframe interval: 2 seconds. Most platforms require this. It's the single setting most likely to cause a rejected or badly-segmented stream if you get it wrong.
Rate control: CBR for live. Constant bitrate is predictable, which matters more than efficiency here. Variable bitrate is for files, not live streams.
Codec: H.264, High profile. Universally supported. HEVC and AV1 are more efficient, but ingest support is inconsistent — check your destination before choosing either. AV1 in particular is expensive to encode in real time.
Preset: veryfast on CPU, or use hardware encoding (NVENC on NVIDIA, Quick Sync on Intel, AMF on AMD) if available. Hardware encoding frees the CPU and is more than good enough for live. Slower presets look marginally better and risk dropped frames, which is a bad trade live.
Audio: AAC, 128–160 kbps, 48 kHz stereo. Higher bitrates are rarely audible and consume headroom you'd rather give to video.
Resolution and frame rate: match your source. Scaling in the encoder costs quality and CPU. Shoot at what you intend to stream.
Connecting to your destination
Your platform gives you a server URL and a stream key. The key is a credential — anyone holding it can stream to your channel, so treat it accordingly and rotate it if it leaks.
In a hardware encoder these go into the streaming configuration page; in OBS, Settings then Stream. Then test before it matters: stream to an unlisted or private destination for ten minutes and watch the encoder's dropped-frame counter. Dropped frames climbing means your bitrate is too high for the connection, and the fix is to lower it.
Latency
An encoder contributes only part of total delay. Expect roughly 20–30 seconds end to end on a standard HLS platform, 5–15 with a low-latency mode enabled, and 2–5 seconds on a purpose-built low-latency service. Sub-second needs WebRTC, which is a different architecture.
Lower latency costs buffer, and buffer is what absorbs network trouble. If nobody is interacting with the stream live, take the higher latency and the stability that comes with it.
What not to bother with
Buying an expensive encoder before testing your upload. A $2,000 encoder on a 5 Mbps upload performs exactly as badly as a cheap one.
Maximising bitrate. The ceiling is your connection on its worst day, not your encoder's capability.
4K, for most purposes. It quadruples bandwidth for a difference most viewers on phones won't see. 1080p done reliably beats 4K that stalls.
Wi-Fi at the encoder. Repeating this because it causes more failures than any setting.
Chasing slower presets. The visual gain over veryfast is marginal and the dropped-frame risk isn't.
Quick answers
What bitrate should I stream at? About half your sustained upload. 4–6 Mbps covers most 1080p30.
RTMP or SRT? RTMP unless your network is unreliable and your destination supports SRT.
Why does my stream keep dropping? Usually bitrate too high for the connection, or Wi-Fi at the encoder. Check the dropped-frame counter.
Do I need a hardware encoder? Only for unattended fixed installs. OBS handles everything else.
What keyframe interval? Two seconds. Most platforms require it.
Why is my stream 30 seconds behind? Standard HLS delivery. Enable low-latency mode if your platform offers it — see our latency breakdown.
Sources: standard encoder and platform ingest documentation; protocol behaviour as described in published streaming-architecture references. Bitrate figures are widely used starting points, not platform-specific requirements — check your destination's own guidance.