System requirements for VT apps

The following hardware is suggested to run VT Publisher, VT Receiver and VT Guest:

• Windows 8.1, 10 or Windows Server 2012, 2016

• Intel i7-4770 CPU or better

• 16 GB of RAM

• .NET Framework v. 4.6.1 or newer

GPU suggestions for VT Publisher

Unlike VT Receiver (receives feeds and decodes them) and VT Guest (receives one feed and encodes one feed), VT Publisher is capable of encoding and sending multiple feeds. Hence, it needs more encoding power.

We recommend Nvidia hardware for optimal performance, for example:

• NVIDIA GeForce GTX 1070 – for up to 2 channels of Full HD 60p video with a bitrate of 30 MB/s

• NVIDIA Quadro M2000 – for up to 4 channels of Full HD 60p video with bitrate 10 MB/s

• NVIDIA Quadro P4000 – for up to 8 channels of Full HD 60p video with a bitrate of 10 MB/s

• NVIDIA GeForce GTX 1060 – for 1 channel of UHD 25p video with a bitrate of 40 MB/s

Here's Nvidia's comparison guide that will help you choose the right model.

I/O hardware

Video Transport is compatible with hardware by Blackmagic Design, AJA, Magewell and Bluefish444.

Bandwidth

Our technology currently supports up to 50 Mbps.

If the adaptive bit rate features is enabled, video quality may dynamically decrease if bandwidth is not available.

Allocating hardware

The hardware you'll need to properly use Video Transport depends what will be the function of each machine in your scenario. It's best to allocate separate machines for sending and receiving functions:

1. Sending (or publishing) machines will be running VT Publisher and need to have sufficient encoding power.

2. Receiving machines will be running VT Receiver – these can be lighter machines since their job will be only to decode the incoming streams.

The following codecs are used in Video Transport:

1. H.265 – used with the "SRT-HEVC" streaming mode (requires an Nvidia GPU card);

2. H.264 – used with "WebRTC-AVC" and "SRT-AVC" streaming modes;

3. VP9 – used with WebRTC when used by the web applications.

We recommend using GPU encoders and decoders because the CPU can't provide the same quality of the video and often does not have sufficient power. There are two possible limitations to keep in mind when selecting the right Nvidia GPU product:

1. The primary limitation of GPU encoding is the count of the simultaneous encoding processes. Most GPU cards have a limitation on 3 encoding processes. We recommend using the Quadro (starting with P2000), Grid, or Tesla series in scenarios when you want to send more than three streams from one machine.

2. Another limitation is codec support – for example, the Quadro M2000 does not support H.265. In this case, if "SRT-HEVC" mode is selected in VT, it will automatically switch to GPU-powered H.264 encoding.

Here's the Nvidia guide that shows how many encoding processes each Nvidia model supports: find the "Max # of concurrent sessions" and check wether it supports both H.264 and H.265, or just H.264. For example, you will find out that all GeForce GTX models support up to 3 simultaneous encoding processes, but not all models support H.265:

Alternatively, you may find out that the Quadro P1000 model does support H.265 (can be used with the "SRT-HEVC" setting), but is still limited to 3 concurrent encoding sessions – while some other models do not restrict the number of sessions:

GPU hardware suggestions

Here's some test results (still work in progress) for the most common configurations.

AWS deployment

The most suitable AWS EC2 instance for VT deployment is G4 series: https://aws.amazon.com/ec2/instance-types/g4/​

VT does not utilize multiple GPU resources in the current version, so Single GPU VMs are preferable. Starting from g4dn.xlarge all the way up to g4dn.16xlarge depending on the anticipated load.

On-prem deployment

If you are deploying Video Transport on your own infrastructure, you will also need to run instances of the signaling and TURN servers. These can be run on your own servers or in a cloud (such as AWS EC2).

The signaling server establishes a handshake between the end points and allows them to establish a direct connection. This server does not need much performance. An HTTP server + a "light" backend i7 should be enough.

The TURN server acts as a proxy (re-streamer) in case the end points can't establish a direct connection (due to firewall settings or network configuration). The load on the TURN server depends on the number of streams it will be re-sending.

The TURN server requires sufficient CPU and RAM for operation. For example, an i9 CPU with 32 GB RAM can handle up to 100 connections via TURN. Also, it is very important that the TURN server has enough network bandwidth.

For OS, we recommend running Ubuntu, a Debian-based Linux build (but other versions of Linux will also work).