User Manual v.2
QVidium
®
QVENC4K™ UHD/HEVC Video Encoder
Copyright 2023 QVidium
®
Technologies, Inc.
Page 25 of 43
sending copies of the output to multiple destinations. For sending more than 4 output copies of a
stream, either use an IP Transport that allows multicasting (and UDP, RTP, or RIST Simple Profile)
or send the stream to a server or PC running the QVidium QVARQ-TxRep QoS Proxy server (see
The encoder internally encapsulates the video and audio signals as UDP packets in all cases,
regardless of the type of packet transport you select. Specifying UDP eliminates the RTP header
and encapsulates the encoder
’s multiplexed MPEG-2 transport stream directly as the payload of
the UDP packet. All the other transport selections (except SRT, RTMP and HLS) add an RTP
header to the UDP packet stream. In the case of RTMP and HLS, the QVENC4K converts the
stream to TCP protocol. SRT uses a proprietary protocol called UDT that was originally designed
for reliable file transfer.
The RTP header adds a timestamp and packet sequence number to the UDP packet and then
adds the 188-byte MPEG-2 Transport Stream sections into the IP packet payload. A typical
Ethernet/IP packet contains 7 of these MPEG Transport Stream sections. RTP protocol is a
commonly used and widely interoperable protocol for sending video. The IP encapsulation adheres
to the IETF/RFC3550 standard for video over IP that specifies that the packet payload must
comprise an integral number of whole 188-byte MPEG-2 transport stream sections within an RTP
header.
2.3.2 Error Correction - ARQ: Automatic Retransmission Request
To enable
A
utomatic
R
etransmission Re
q
uest (ARQ), you must first select ARQ transport from the
Profile
dialog. ARQ transport must also be enabled at the decoder. With ARQ selected and the
encoder started, the encoder will begin to save outgoing packets for later retransmission, when
necessary. Normally, the ARQ port should be set to the same value as the outgoing UDP port for
the video stream, with a default value of 10000. This will allow the upstream ARQ retransmission-
request packets to travel back through most encoder-side firewalls without requiring any special
configuration at the encoder-side firewall. If you use a different ARQ port than video UDP port,
then you must also be certain to configure any encoder-side firewalls to allow the upstream ARQ
retransmission request packets through to the encoder. You may change the value of the ARQ
port, but the ARQ and UDP port settings must match on both the encoder and decoder.
At the receiver, the ARQ error correction mechanism first buffers incoming packets in a
synchronized network de-jitter buffer that maintains a constant, configurable delay for incoming
packets. The de-jitter buffer processes RTP sequence numbers and reorders packets as
necessary to restore proper packet sequence and to buffer against erratic network delays. Its goal
is to output a smooth, consistent flow of packets with increasing sequence numbers. This output
feeds the ARQ error correction mechanism.
The ARQ unit at the receiver watches for gaps in RTP sequence number from the de-jitter buffer
output, and immediately sends out retransmission requests when necessary. Incoming
retransmitted ARQ packets bypass the de-jitter queue and find their correct place in the ARQ
buffer, so that by the time packet are output by the ARQ buffer, the ARQ error correction
mechanism should no longer contain any missing packets.
When the encoder and decoder are both started, the decoder automatically measures the round-
trip delay and packet jitter to the encoder and automatically configures ARQ for optimal operation
according to a few basic user-specified parameters, as described in Section 2.3.2.
Note:
For testing ARQ error correction, select ARQ transport at both the encoder and decoder and
use the default ARQ parameters at the decoder (receiver).