Inside an Encoder Setup: How We Choose Bitrate, Resolution and Frame Rate

Starting with the venue, not the encoder

When I run the encoder module, nobody opens the software in the first twenty minutes. We begin with a sheet of paper and three questions: what connection does the venue have, which platform receives the stream, and what equipment is already agreed for the show. Learners often expect a list of ideal numbers. There is none, because the right settings come from those three answers, and they change from one room to the next.

I ask each learner to note the upload speed measured at the venue, the number of devices sharing that line, and whether a wired port is available near the switcher. Only then do we look at the encoder. This habit saves more trouble than any single setting, because it stops people copying a configuration from a previous event that had a different connection and a different destination.

• Venue upload speed and who else shares the line
• Wired port or wireless only
• Destination platform and its ingest guidance
• Agreed cameras, switcher and laptop or hardware encoder

Setting bitrate with headroom

Bitrate is the first value we set, and we set it conservatively. A common beginner habit is to read the measured upload speed and use nearly all of it. In practice a line that tests at one figure rarely holds it for an hour of live use, so we leave a generous margin and treat the remainder as protection against dips.

In class we compare two short test streams on the same connection: one pushed close to the limit and one with clear headroom. Learners watch the playback side and see the first version stutter while the second stays steady. The picture from the lower bitrate is slightly softer, and most audiences accept that far more readily than a stream that freezes. We also check the platform's published ingest range so the number sits inside what the destination expects.

Matching resolution and frame rate to the content

Resolution and frame rate are chosen after bitrate, because they share the same budget. A panel of seated speakers has little movement, so a modest frame rate and a clean 720p or 1080p image can look better than a higher setting starved of bits. A show with moving cameras, demonstrations or on-screen motion needs more data for the same sharpness.

I have learners run the same scene at two combinations and compare them side by side. The point is not to find a winner for all cases but to see the trade: more pixels or smoother motion, never both for free. We also make sure every camera and the switcher output use the same frame rate, since mixed rates are a quiet source of judder that people blame on the encoder.

• Static panels: favour clean resolution
• Moving subjects: protect frame rate
• Keep every source on one agreed frame rate

Changing one setting at a time

The discipline I push hardest is changing a single value, then testing again. When a stream misbehaves, the temptation is to adjust bitrate, keyframe interval and resolution together and hope. That leaves nobody knowing which change helped. In the session each learner keeps a short log: setting changed, reason, and what the test showed.

This log becomes part of the pre-stream paperwork. If the same venue is used again, the notes give a starting point rather than a guess. It also helps when a colleague takes over the encoder on the day, because the reasoning is written down and not carried in one person's memory. Learners tell me the log feels slow at first and then becomes the part they would least want to lose.

Confirming the result before the audience arrives

Once the numbers are set, we run a test stream to the real destination and watch it from a separate device on a different network, as a viewer would. We check that the picture is stable for a full stretch of time, that audio stays in step with video, and that the encoder shows no dropped frames or rising buffer.

We also decide on a fallback before it is needed. That might be a lower bitrate preset saved in the encoder, ready to load in seconds if the line weakens. Learners practise switching to it during a live test so the action is familiar. None of this promises a flawless broadcast, since the venue connection and platform remain outside anyone's control, but it means problems are met with a plan.

• Watch from a second device on another network
• Check for dropped frames and audio sync
• Save a lower-bitrate preset as a fallback

What learners take away

By the end of the encoder module, learners can read a venue's connection, choose a sensible starting configuration, and explain why each value was picked. They leave with a log template and a fallback preset habit rather than a table of magic figures.

This module sits between camera connections and connection testing in the programme, and it assumes you are comfortable with basic streaming terms. Realistic outcomes are practical: fewer surprises, quicker diagnosis, and a setup you can describe to a colleague or client without guessing.