Connection mode determines which side (encoder or decoder) initiates the connection.

For Server Mode (Listener) the encoder must be on an IP that is accessible to the decoder.

• Source/Listening Port - Default: 50000.  This is the port that the encoder will listen for incoming connections
• Connection limit - Default: 10.  Number of decoders that can connect to this encoder.

For Client Mode (Caller) the encoder must be able to reach the decoder or decode server 

• Host - the IPV4 address of the decoder or server used to receive the TRT stream
• Host Port - Default: 50000. The host port for the TRT stream to attempt to reach the Host IP

NOTE: Adaptive Bitrate and Adaptive Redundancy are disabled when Multicast Mode is enabled.

Multicast Mode is a communication method that allows TRT to be broadcast to multiple recipients simultaneously. It sends a single copy of the data, and the network switch replicates and delivers TRT packets to recipients connected to the same network. Unlike unicast or broadcast, multicast is more efficient as it targets only those who have requested the data. Multicast can be enabled when the encoder is set to Client Mode and must be configured with a valid multicast Host IP address. Additionally, decoders must also be set to Client mode and connected to the same multicast IP address and port.

NOTE: Adaptive Bitrate is disabled if Multicast Mode is enabled.

Adaptive Bitrate dynamically adjusts streaming bitrate according to network performance. When enabled, you can set Minimum and Maximum limits (default values are 1000 and 15000 kbps).  This action allows you to determine successful ranges of bitrates for your application.

NOTE: Adaptive Redundancy is disabled if Multicast Mode is enabled.

Adjusts redundancy based on network conditions.  

Redundancy is extra data sent and used for reliability purposes.  In UDP streaming, redundant data can help reform those packets when packets drop.

• Min Redundancy Limit - Default 0.3.  Sets the lower limit of redundancy from 0.0 to 1
• Max Redundancy Limit - Default 0.7 Sets the upper limit of redundancy from 0.0 to 1

Max Redundancy Limit: Set when Adaptive Redundancy is enabled, defining the upper threshold for redundancy adaptation.

TTL (Time to Live) is a crucial parameter, mostly applicable when using multicast networks, that dictates how far a broadcast packet can travel through a network before it's discarded. When a broadcast packet is sent out, it comes with a TTL value. If the TTL hits zero before the packet reaches its destination, it's typically dropped or stopped, which helps prevent potential network congestion or loops. TTL prevents broadcast packets from endlessly circulating within a network, thus avoiding unnecessary traffic and performance issues. By setting TTL limits, broadcast packets are controlled in how far they can spread, leading to more efficient network communication.

MTU (Maximum Transmission Unit) represents the maximum packet or frame size that can be transmitted via Ethernet. The larger the MTU of a connection, the more data can be passed in a single Ethernet packet.                                      

• Jitter Buffer: The Jitter Buffer is designed to compensate for variations in packet arrival time, which is crucial for maintaining a smooth and uninterrupted streaming experience.

  • A properly configured Jitter Buffer can absorb network-induced delays and jitter, making the data flow smoother.

  • Ideal settings depend on network stability; a more stable network might require a smaller buffer, while a variable network might benefit from a larger buffer.

• Max Jitter Buffer: This setting defines the maximum size of the Jitter Buffer.

  • The Max Jitter Buffer sets a limit on the buffer size, preventing it from becoming too large, which could cause problems such as higher latency.

  • Setting the maximum buffer size requires balancing between having enough buffer to smooth out the jitter and avoiding excessive delay in the stream.

  • This setting is important in live streaming scenarios where real-time interaction is crucial, as a very high buffer size might introduce noticeable delays.

The Retry Request Depth setting helps handle the recovery of lost packets in a stream. If packets are dropped and cannot be recovered by Forward Error Correction (FEC), this setting allows the receiver to ask the transmitter to send the missing packets again.

• When set to 0: No retry requests will be made for lost packets.

• When set to 1 - 10: Increased levels of retry requests, with 1 being the minimum and 10 the maximum number of times the receiver will request the missing packets.

• Impact on Stream: The higher the setting (up to 10), the more attempts will be made to recover lost packets, which can enhance the reliability of the stream.
• Latency Consideration: A higher retry depth may increase the overall latency of the stream, as it takes additional time for the receiver to request and the transmitter to resend packets.
• Balance of Reliability and Performance: Users need to balance the need for packet recovery with the desired stream performance. Lower settings are suited for scenarios where low latency is crucial, while higher settings are better for environments where packet loss is frequent, and data integrity is a priority.

• Max Burst Bitrate (kbps) - When set above 0, matches the packet transmission rate to this set bitrate.
  • Default: 0 (packets sent as quickly as possible).
• Max Burst Time (ms) - It is relevant when 'Max Burst Bitrate' is greater than 0, restricting the buffer duration.

  • Default: 16666 microseconds (16ms).

• Maximize FEC AV Packet Packing - If enabled, the probability of FEC recovery is improved at the expense of transmission delay. This is especially true for lower-bitrate streams.
• Max Delay for FEC AV Packet Packing - Only applicable when Maximize FEC AV Packet Packing is enabled.

  • Range: From 0.0 (disabled) to 1000.0 milliseconds.

  • Default: Set at 500 milliseconds.

NOTE: Send Audio Independently only applies when Maximize FEC AV Packet Packing is disabled.
Send Audio Independently allows for separate handling of audio data, independent of a video stream