Skip to main content

Broadcast Guidelines

Vindral Live supports multiple incoming transport protocols. However, RTMPS is the most widely used and supported - and therefore, the one we often recommend.

Most software and hardware encoders have a wide range of configuration options, but there are a couple of things that we generally recommend:

General recommendations​

  • If your device supports it, use hardware acceleration - a performance drop on an origin encoder will lead to unwanted buffering for all connected clients.
  • Verify that the host machine can run in a stable environment without other applications stealing CPU/IO power.
  • Use constant bitrate as rate control - leads to a more stable experience for clients.
  • Disable or limit buffers to achieve the lowest possible latency.
  • Use a buffer only if needed for higher stability on unstable ingress connections.
  • Keyframe Interval (GOP size) - should be around 1-2 seconds for fast connection time and channel switching.
  • Profile - H.264 baseline for best possible compatibility and lowest latency.
  • Tune for low-latency/live (no b-frames, high performance/stability).
  • Your maximum upload bandwidth may be a limiting factor for deciding on encoder bitrate. Using more than half of the available bandwidth is not recommended as it may be exceeded because of the encoder and network jitter.
  • While we recommend using RTMPS, some hardware encoders and software applications do not yet support RTMPS. RTMP is supported in Vindral using the same ingest URLs.

Resolution, frame rate and bitrate​

Vindral Live supports a wide range of resolutions and bitrates. We recommend using CBR (Constant Bitrate) for the best performance, especially for live streaming. The bitrate you choose will depend on the resolution and framerate of your video, as well as the codec you are using.

If you are uncertain about which resolution and bitrate to use, we recommend starting with 1080p30 at 4 Mbps. This is a good balance between quality and bandwidth usage for most live streaming scenarios. If the player will be part of a user interface and not expected to be full screen or used on large screens, you can use a lower resolution and bitrate, such as 720p30 at 2 Mbps. Some customers even go as low as 360p30 at 0.5 Mbps for low-bandwidth or second-screen scenarios.

The following table provides some common resolutions and bitrate examples for 30 fps video. The bitrates are approximate and can vary based on the codec used, the content being streamed, and other factors.

ResolutionBitrate H.264 (Mbps)Bitrate AV1 (Mbps)
2160p30128
1440p3084
1080p3043
720p3021.5
540p3010.5
360p300.50.3
240p300.30.2
144p300.150.1

The table above serves as a helpful reference point, but actual bitrate requirements should be fine-tuned based on your specific content type, use case, and network conditions.

📺 Frame Rate​

The most common frame rates for live streaming are 25 fps and 30 fps. However, some content may benefit from higher frame rates, such as 50 fps or 60 fps. The choice of frame rate can significantly impact the perceived quality of the stream. Some webinars and auction even use lower frame rates, such as 15 fps or 10 fps, to save bandwidth or make the content more crisp.

If you are uncertain about which frame rate to use, we recommend starting with 30 fps.

caution

Make sure your camera and encoder are set to the same frame rate, as mismatched frame rates can lead to choppy or stuttery video.

note

While higher frame rates can enhance motion smoothness and improve the viewing experience, they also increase the computational load on both the encoder (server side) and decoder (client side). This added complexity often translates to higher infrastructure costs and may impact device compatibility or battery life on lower-end clients.

In most streaming scenarios, increasing the frame rate from 30fps to 60fps (or 25fps to 50fps in PAL regions) does not require doubling the bitrate. Thanks to efficient temporal compression in modern codecs, a 10–30% increase is typically sufficient to maintain comparable or even better perceived quality, especially for content with smooth or predictable motion.

📦 Codec Efficiency​

The AV1 codec offers significantly better compression efficiency compared to H.264. For instance:

  • 1080p30 streams with AV1 may achieve good quality at just 1–3 Mbps, whereas H.264 might require 2–6 Mbps for similar results.
  • At lower resolutions, AV1 performs even better. A 720p AV1 stream can often deliver acceptable quality at 500 kbps or less—something H.264 struggles to match at the same bitrate.

This makes AV1 especially valuable for delivering low-latency or adaptive streams in bandwidth-constrained environments.

🔊 Audio Considerations​

For audio:

  • AAC is commonly used with streaming, typically at 96 kbps, though bitrates can range from 64 to 160 kbps depending on quality goals.
  • Opus, a more modern and flexible codec, can maintain high perceptual quality at lower bitrates—often between 48–64 kbps—making it ideal for live streaming setups.
Content typeBitrate AAC (kbps)Bitrate Opus (kbps)
Voice9664
Mixed12896

The table above serves as a helpful reference point, but actual bitrate requirements should be fine-tuned based on your specific content type, use case, and network conditions.

note

Vindral Live supports audio only streams, for doing internet radio or similar. In those cases, make sure to only send the audio stream to Vindral Live, and not the video stream. This will save you bandwidth and make sure that the audio stream is not delayed or otherwise effected by the video stream.

RTMP(s) or SRT​

RTMP(s) and SRT are both widely used protocols for streaming video over the internet, but they have some key differences:

  • RTMP: This is a traditional protocol and is widely supported across many streaming platforms and devices. It is easy to use and does not incur any additional latency. However, it is important to note that RTMP only supports a limited set of video- and audio codecs1, and does not support multiple audio or video tracks.

  • SRT: Secure Reliable Transport (SRT) is a newer protocol designed to overcome some of the limitations of RTMP. It offers high performance over unreliable networks, but can incur additional latency due to use of buffers. Unlike RTMP, SRT supports multiple audio and video tracks and is not limited to specific codecs.

In general, if your streaming setup does not need multiple audio or video tracks and is compatible with H.264 for video and AAC for audio, RTMP(s) is a straightforward and reliable choice. However, if you require more flexibility in terms of codecs, or if you are streaming over long distances or unstable networks, SRT might be the better option.

Software encoders​

Many software applications are easy to use and have full support for RTMPS and other protocols. Our customers commonly use these:

Hardware encoders​

Most hardware encoders have RTMP(s) support and should work out of the box. Some of the more commonly used are:

Custom encoder setups​

Let us know if you have more advanced encoder requirements, such as:

  • local monitoring dashboard with graphs and alerts
  • error handling and automatic restarts
  • robust 24/7 streaming
  • multiple sources (MPEG-TS, SDI, RTMP) that should be combined into a single stream
  • multiple outputs
  • custom hardware
  • dense transcoding, hardware offload using GPUs, iGPUs, or ASICs
  • API control

We have solutions for advanced on-prem setups that have been in use for years with rock-solid performance.

Footnotes​

  1. Being an old protocol, RTMP has not traditionally supported modern video codecs, but with the addition of the Enhanced RTMP specification, AV1 is now supported and available to use when ingesting to Vindral. ↩