Contribution Encoder Buyer's Checklist: Hardware vs Software, SDI vs NDI, SRT vs WebRTC

Tim Tselikovski -

A contribution encoder moves live video from one place to another: venue to control room, camera to cloud, studio to master control, or field team to production staff.

Bad encoder choices show up fast. The picture breaks. Audio drifts. Firewalls block the connection. Operators cannot see useful errors. Backup paths take too long.

Choose the encoder around the workflow, not the spec sheet.

Start with inputs

List every source the encoder must accept.

Common inputs:

  • SDI
  • HDMI
  • NDI
  • IP camera streams
  • File playback
  • Screen capture
  • Audio interfaces
  • Test pattern and tone

SDI still matters for cameras, switchers, replay, and venue gear. NDI matters for software production and local IP workflows. HDMI may work for simple setups, but it can cause headaches with connectors, cable runs, and format handling.

Ask whether the encoder handles embedded audio, multi-channel audio, timecode, captions, and format changes. A product that works only in the clean demo can fail in a mixed venue.

Hardware vs software

Hardware encoders give teams a dedicated appliance. Operators can rack them, label them, power-cycle them, and standardize them across kits.

Choose hardware when:

  • You need a fixed field kit
  • Nontechnical operators run the show
  • You want repeatable setup
  • You need rugged deployment
  • You want fewer OS and driver variables

Software encoders give teams flexibility. They can run on workstations, cloud instances, or production PCs. They can combine capture, graphics, monitoring, recording, routing, and streaming.

Choose software when:

  • You need custom workflows
  • You need SDI and NDI in the same app
  • You need overlays, switching, or recording
  • You want to update features quickly
  • You build a product, not only an event kit

Many teams use both. Hardware handles field contribution. Software handles cloud processing, monitoring, and special cases.

SRT vs WebRTC vs RTMP

SRT:
Use it for high-quality contribution over public internet, cellular, or satellite. Set the latency buffer based on the network. Use encryption. Monitor packet recovery.

WebRTC:
Use it for browser preview, remote guests, talent return, and interactive workflows. Plan SFU and TURN capacity if more than a few users join.

RTMP:
Use it when a destination still requires it. Do not build a new low-latency contribution strategy around RTMP unless compatibility forces the choice.

If a vendor claims one protocol handles everything, ask for the failure cases.

Latency targets by job

Match delay to the production need.

Camera contribution to remote switcher:
150 to 800 ms often works, depending on sport, directing style, and network quality.

Talent return:
Under 500 ms feels better for interaction. Audio stability matters more than bragging rights.

Producer monitoring:
500 ms to 2 seconds can work if the producer makes content decisions rather than frame-accurate cuts.

Public streaming:
HLS or DASH latency may run several seconds. That can work for viewers but not for production control.

Monitoring questions

A good encoder tells operators what happens.

Ask vendors:

  • Can I see input format and frame rate?
  • Can I see encoded bitrate in real time?
  • Can I see packet loss and retransmissions?
  • Can I see audio levels?
  • Can I log connection drops?
  • Can I export metrics?
  • Can I trigger alerts?
  • Can I see CPU, GPU, and thermal status?

If the encoder only shows a green icon, keep looking.

Failover questions

Every contribution plan needs a failure plan.

Ask:

  • Can the encoder send two streams at once?
  • Can it send a low-bitrate backup?
  • Can it switch networks automatically?
  • Can it bond cellular links?
  • Can it record locally?
  • Can it reconnect without operator action?
  • Can it keep settings after power loss?
  • Can operators switch destinations fast?

Local recording matters. If the live path fails, the local file can save highlights, sponsor deliverables, and post-show edits.

Security questions

Contribution feeds often carry unreleased content, talent audio, ads, sponsor graphics, and internal conversations.

Ask:

  • Does the encoder support encrypted SRT?
  • How does it store passphrases?
  • Can users have separate roles?
  • Can access expire after an event?
  • Can admins audit connections?
  • Does the vendor patch security issues quickly?

Security belongs in the purchase checklist, not the postmortem.

Total cost

Look past the sticker price.

Include:

  • Capture hardware
  • Support contract
  • Cloud egress
  • TURN relay costs
  • Cellular plans
  • Shipping and spares
  • Operator training
  • Monitoring tools
  • Engineering time
  • Replacement cycle

A cheap box can cost more if it creates custom fixes for every event.

Where Medialooks fits

Medialooks Video Transport gives production teams a software-based way to move SDI and NDI sources over IP with low latency, using SRT and NAT traversal to reduce setup pain.

Medialooks Video SDK fits vendors and internal teams building their own contribution, monitoring, playout, or routing products.

Buy the encoder that matches the workflow. Then test it on the worst network you expect to use.