Skip to main content
All CollectionsTechnical Troubleshooting
Recommended viewing, encoding and internet settings
Recommended viewing, encoding and internet settings supports viewers on all systems, browsers and devices. To have the best viewing experience, follow our encoding settings.

Updated over a week ago


Attendees will be able to view and interact with the most internet connections. If network speed is a concern, here are some guidelines for the best user experience.

For 1:1 meeting in Virtual Stage or Networking:

  • For high-quality video: 600kbps (up/down)

  • For 720p HD video: 1.2Mbps (up/down)

For group video calling in Virtual Stage or Networking:

  • For high-quality video: 1.0 Mbps/600kbps (up/down)

  • For 720p HD video: 2.6Mbps/1.8Mbps (up/down)

For gallery view receiving:

  • 2.0Mbps (25 participants on stage)

We do require some browser and hardware set-ups for those that are Hosts and/or Presenters of a Virtual Stage that can be found here.


These settings only apply to streaming to via RTMP. If you are using the Virtual Stage this will not apply to you.

Stream Ingest: Codecs, RTMPS, and Port 443

Codecs: We support H.264 for video and AAC (LC) for audio.

Sequel supports the most common secure ingest protocol used in streaming software and hardware, RTMP and RTMPS (Real-Time Messaging Protocol over a TLS/SSL connection). Streaming and playback require TLS version 1.2 or later.


The stream’s resolution largely determines its bitrate and frame rate (frames-per-second, or FPS). These guidelines are our recommendations. Note the resolutions shown below are landscape orientation (horizontal x vertical), so reverse these for portrait orientation.

Acceptable Quality (SD) 480p (852x480)

Good Quality (HD) 720p (1280x720)

High Quality (Full HD) 1080p (1920x1080)


Up to 1500 Kbps

Up to 4500 Kbps

Up to 8500 Kbps



30 or 60

30 or 60

Keyframe interval

2 seconds

2 seconds

2 seconds

Bitrate, FPS, and resolution are interrelated. The best values can be complicated to determine. Start with our recommendations above and experiment if desired. The goal is clear and smooth video during streaming and good resolution within your available bandwidth. Increasing frame rate and/or resolution increases overall video quality, but this is limited by bandwidth.

Sequel supports framerates up to 60 FPS. The higher the framerate, the better the quality, again within the limits of your bandwidth.

Video Settings

We recommend the following settings. They are available to most H.264 video-encoding software or hardware APIs.

  • On the video encoder, set IDR/Keyframe to a 2-second interval (or 1 second, for even lower end-to-end latency).

  • H.264 level: Main

  • Scene change: Off (preferred)

  • Chroma subsample: YUV420P

  • CABAC: Preferred

Audio Settings

We support the following settings:

  • Codec: AAC (LC)

  • Bitrate: anything up to 320 Kbps

  • Sample rate: 44.1 Khz or 48 Khz (it is best to match your production audio flow)

  • Channels: Maximum 2 - Stereo (1: mono or 2: stereo audio channel support)

Use CBR, Not VBR

Always use CBR (Constant BitRate), not VBR (Variable BitRate), as the rate-control method for encoders. CBR is better suited for the fixed-bandwidth nature of networks, and it produces more predictable, stable video playback for client devices. With a consistent bitrate, it is easy for viewers to select a quality level that their connection can handle over time.

We strongly recommend you only use CBR. If you use VBR, your streams will be more subject to buffering and playback that is not smooth.

Use Progressive Signals

Use progressive signal flows; avoid any interlaced video in production flow and/or encoding. Progressive stream signals yield much better playback quality displaying a whole frame at a time, avoiding any motion artifacting (green/grey pixilation) that is produced when displaying an interlaced signal.


Network Requirements

A stable internet connection is a must for a quality stream. An unstable internet connection could result in stream stuttering and lagging for your viewers.

Use wired connections WiFi and LTE connections can be spotty or suffer from interference or latency due to bad QoS/packet-queue prioritization. Whenever possible, rely on a hardwired connection for streams.

When streaming via RTMP plan to allocate 50% more bandwidth than the minimum required. The overhead is added to compensate for the bitrate fluctuations in encoding of a video bitstream.

Use a dedicated Internet VLAN to encoding machines. Keeping the encoder on a separate network prevents potentially disruptive effects, including: pollution by traffic, bandwidth bottlenecks and adverse security factors.

Firewall settings

A well-configured, strong and fault-tolerant internet connection is a critical piece when attempting to broadcast content for an event. In order to view and send streams, we recommend that you create the following firewall rules on the internet connection you are using to broadcast:

Viewing a stream:

  • Outgoing UDP destination port 53 to your nameserver or any IP for domain name resolution (DNS).

  • Outgoing TCP destination port 80, 443 to any IP for web.

  • Outgoing TCP destination port 1935 to any IP for streaming (RTMP).

  • Outgoing TCP destination ports 8001-8004 to any IP for web based chat.

Sending a stream:

  • Outgoing UDP destination port 53, 1024-2048 to your nameserver or any IP for domain name resolution (DNS).

  • Outgoing TCP destination port 80, 443, 1935 to any IP for web.

  • Outgoing TCP destination port 1935 to any IP for streaming (RTMP).

Whitelist domain:

  • HTTPS Web socket access to wss://*, port 443

  • HTTPS Web socket access to wss://*, port 443

  • UDP access on port 10000. Media traffic preferentially uses UDP (DTLS-SRTP) on port 10000. If UDP connectivity is unavailable, it will use TCP (TURN+TLS) on port 443 as a fallback, with some unavoidable impact on call quality inherent to the use of TCP.

These settings are a great starting point but we always recommend testing with your setup before any event!

Did this answer your question?