User Manual v.1
QVidium
®
QVDEC4K™ UHD/HEVC Video Decoder
Copyright 2023 QVidium
®
Technologies, Inc.
Page 19 of 34
limits the number of packets that a source can have in transit and requires a positive
acknowledgement for each window of packets.
This limits TCP’s throughput, especially over links
with long latencies. Furthermore, under heavy loss conditions, TCP/IP scales back the data
transmission rates and provides no concise deadlines or constraints on packet delivery times. For
real-time video, this limits the usefulness of TCP/IP, making it unacceptable for low-latency uses.
In contrast with TCP/IP, QVidium designed its patented ARQ error correction specifically for live,
interactive, real-time video and audio signals to automatically recover nearly all lost packets with
minimal latency and over nearly any link loss conditions. It adds a small configurable amount of
delay to the network transport in exchange for significantly improving the robustness and reliability
of video transport.
2.3.1 Configuring Video over IP Network Parameters
To configure the IP network parameters, within the Network Parameters section of the decoder
profile, first select an IP Transport mode. Depending upon the IP Transport more that you select,
tables of additional optional parameters relevant to that IP Transport will then appear. For more
protocols, you will also be required to specify the destination IP address and UDP port number.
The destination IP address is usually a unicast IP address, but for UDP and RIST Simple Profile, it
can also be a multicast address.
For QVidium ARQ, you may specify up to 4 comma-separated destination IP addresses for
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 decoder 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 decoder
’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 QVDEC4K 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
decoder started, the decoder 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 decoder-side firewalls without requiring any special
configuration at the decoder-side firewall. If you use a different ARQ port than video UDP port,
then you must also be certain to configure any decoder-side firewalls to allow the upstream ARQ
retransmission request packets through to the decoder. You may change the value of the ARQ
port, but the ARQ and UDP port settings must match on both the decoder and decoder.