The following hardware is suggested to run VT Publisher, VT Receiver, VT Server and VT Guest:
OS Microsoft Windows 10, Windows 11, or Windows Server 2016-2019
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
Video Transport is compatible with hardware by Blackmagic Design, AJA, Magewell and Bluefish444.
Bandwidth
Our technology currently supports up to 50 Mbps.
Quality
Minimum
Recommended
1080i/720p
10 Mbps
20 Mbps
1080p
15 Mbps
30 Mbps
4K
20 Mbps
40 Mbps
If the adaptive bit rate features are enabled, video quality may dynamically decrease if bandwidth is not available.
Allocating hardware
The hardware you'll need to properly use Video Transport depends on 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.
Make sure that you pay close attention to the specifications of the send machines since this is a common reason for streaming issues.
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 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 the "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 whether 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 are some test results (still work in progress) for the most common configurations.
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 endpoints 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 endpoints 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.
TURN bandwidth = peerBitrate * peerCount + 5 Mbit for service messages.
For OS, we recommend running Ubuntu, a Debian-based Linux build (but other versions of Linux will also work).