Skip to main content

Broadcast Guidelines

Vindral 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 - h264 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.

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. 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. ↩