Skip to content

Examples for SRT Bonding Using srt xtransmit

Maxim Sharabayko edited this page Mar 14, 2023 · 1 revision

This is a small starters-guide for using srt-xtransmit for bonded SRT connections.
Please see the srt-xtranmit documentation for more information. ​

Building srt-xtransmit

​ Requirements for building srt-xtransmitare listed here. ​ For Ubuntu 18 ​

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install tclsh pkg-config cmake libssl-dev build-essential

​ In following some quick steps using cmake in Linux: ​ SRT-Xtransmit is a separate application, outside of the SRT repository. Following command downloads srt-xtransmit to the folder xtransmit: ​

git clone https://github.com/maxsharabayko/srt-xtransmit.git xtransmit/

​ Change into the new directory and create a separate folder for you build: ​

cd xtransmit
mkdir _build_v1.5.0

​ Now init and update the submodules (including the SRT library): ​

git submodule init
git submodule update
cd submodule/srt/
git checkout v1.5.0
cd ../..

​ Instead of version v1.5.0 you can alternatively download the latest master by using git checkout without specifying version or you can also select a specific version e.g. git checkout v1.4.2 ​ Now it's time to build the program, but before we need to enable bonding by setting the ENABLE_BONDING=ON flag. In versions prior to v1.5.0 this build option was named ENABLE_EXPERIMENTAL_BONDING. Note: when using cmake this option is defined by -DENABLE_BONDING=ON

cd _build
cmake ../ -DENABLE_BONDING=ON

​ Time to build the application: ​

cmake --build ./
​
# or using 4 processors in parallel
cmake --build ./ --parallel 4

​ Once build, you will find your srt-xtransmit application in subfolder bin. ​

cd bin/
./srt-xtransmit --help-all

Using Bonding

​ Use CMake build option -DENABLE_BONDING=ON.
​ Enables the Connection Bonding feature.
​ Similar to SMPTE-2022-7 over managed networks, Connection Bonding adds seamless stream protection and hitless failover to the SRT protocol. This technology relies on more than one IP network path to prevent disruption to live video streams in the event of network congestion or outages, maintaining continuity of service.
​ This is accomplished using the socket groups introduced in SRT v1.5. The general concept of socket groups means having a group that contains multiple sockets, where one operation for sending one data signal is applied to the group. Single sockets inside the group will take over this operation and do what is necessary to deliver the signal to the receiver.
​ Two modes are supported: ​

  • Broadcast - In Broadcast mode, data is sent redundantly over all the member links in a group. If one of the links fails or experiences network jitter and/or packet loss, the missing data will be received over another link in the group. Redundant packets are simply discarded at the receiver side.
  • Main/Backup - In Main/Backup mode, only one (main) link at a time is used for data transmission while other (backup) connections are on standby to ensure the transmission will continue if the main link fails. The goal of Main/Backup mode is to identify a potential link break before it happens, thus providing a time window within which to switch to one of the backup links seamlessly. ​ With the Connection Bonding feature disabled, bonding API functions are present, but return an error. ​

Examples

​ The following examples are were made between 2 computers with 2 network interfaces in each of them. ​

PC1           ----           PC2
(192.168.4.1) ---- (192.168.4.2)
(192.168.3.1) ---- (192.168.3.2)

​ An endpoint for connection bonding could also use a single IP and 2 different ports instead of two different IP and ports. ​

broadcast mode example 1

​ The first example just uses srt-xtransmit to generate a stream containing dummy data. In this case a 10 Mbps stream for 60 seconds. Remember to start the receiver first. ​

receiver

./srt-xtransmit receive srt://:4200?latency=200 srt://:4201 -v

​ A listener is started on all available interfaces, including 192.168.3.2 and 192.168.4.2. ​

sender

./srt-xtransmit generate "srt://192.168.4.2:4200?latency=200&grouptype=broadcast" "srt://192.168.3.2:4201" --sendrate 10Mbps --duration 60s -v

​ The sender generates traffic and sends it to two enpoints: 192.168.3.2:4201 and 192.168.4.2:4200. Note the latency is only specified once and applies for members of the bonding group. ​

broadcast mode example 2

​ In this example srt-xtransmit uses an existing UDP MPEG-TS stream as source, coming in on PC1 on port 5000, flips it into a SRT stream using two network interfaces and broadcast mode and forwards it to PC2. On PC2 it is flipped back into a UDP MPEG-TS. ​

receiver 2

./srt-xtransmit route -i "srt://:4200?latency=200" "srt://:4201" -o "udp://239.1.2.3:5001" -v

​ A listener is started on all available interfaces, including 192.168.3.2 and 192.168.4.2. ​

sender 2

./srt-xtransmit route -i "udp://:5000" -o "srt://192.168.4.2:4200?latency=200&grouptype=broadcast" "srt://192.168.3.2:4201" -v

main/backup example 3

​ This connection is analog to example 1, but instead backup mode is used. (follow link for more detailed information on Main/Backup) ​ In this case we define one link as our mainlink by setting a higher weight factor with the SRT Option weight=51 and weight=50. That main link will carry the traffic until it is considered broken. If it becomes available again, SRT will try to use it as main link again. ​

sender 3

./srt-xtransmit generate "srt://192.168.4.2:4200?latency=200&grouptype=backup&weight=51" "srt://192.168.3.2:4201?weight=50" --sendrate 10Mbps --duration 60s -v

receiver 3

./srt-xtransmit receive srt://:4200?latency=200 srt://:4201 -v

main/backup example 4

​ This connection is analog to example 2, but instead backup mode is used. (follow link for more detailed information on Main/Backup) ​ In this case define one link as our mainlink by setting a higher weight factor with the SRT Option weight=51 and weight=50. That main link will carry the traffic until it is considered broken. If it becomes available again, SRT will try to use it as main link again. ​ Again an existing UDP MPEG-TS stream is used as source, coming in on PC1 on port 5000. It's fliped it into a SRT stream using two network interfaces and backup mode and forwarded to PC2. On PC2 it is flipped back into a UDP MPEG-TS. ​

receiver 4

./srt-xtransmit route -i "srt://:4200?latency=200" "srt://:4201" -o "udp://239.1.2.3:5001" -v

sender 4

./srt-xtransmit route -i "udp://:5000" -o "srt://192.168.4.2:4200?latency=200&grouptype=backup&weight=51" "srt://192.168.3.2:4201?weight=50" -v