QVidium QVAVQ Series v3 - Manual (Page 10)

User’s Manual v.2 QVidium
® QVARQ QoS Proxy Server™
10 of 17 - Copyright 2004-2013 QVidium
®
Technologies, Inc.
3.3 ARQ Packet Transport & Error Correction
The QVidium QVARQ QoS Multimedia Proxy Server ™ features some of the most powerful and
advanced error correction capabilities found in any video over IP product. The QVidium QVARQ
QoS Multimedia Proxy Server
™ implements QVidium’s patented ARQ error correction and clock
synchronization (US Patents #7,551,647 and #7,522,528) for the more robust video transmission
with the lowest delay
. QVidium’s ARQ (Automatic Retransmission Request) is a dynamically
adjusting feedback error correction mechanism designed specifically to enable the highest quality
video transport over wireless networks and the Internet. ARQ senses packet loss at the receiver
and requests replacement packets from the server. ARQ can provide nearly flawless reproduction
of a video stream even through extremely lossy or congested networks.
In contras
t with FEC, QVidium’s ARQ is a feedback mechanism that detects packet loss at the
receiver and requests the retransmission of only those lost packets from a video source. A user-
configurable buffer at the receiver (decoder) delays the video stream just long enough to allow the
system to replace any missing packets and re-insert them in their proper order without disturbing
play out of the video stream. Because ARQ senses actual packet loss, rather than attempt to
predict packet loss, it can precisely and completely restore all lost packets without disturbing timing
of the video play out. In contrast to FEC, ARQ can successfully recover lost packets regardless of
the magnitude or pattern of the packet losses, provided that the network connection has enough
capacity to send both the original video stream and the replacement packets.
ARQ shares similarities with robust packet transport protocols, such as TCP/IP in that both use
feedback to create robust network packet transport. However TCP/IP uses a sliding window that
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 and makes it unacceptable for live, low-latency
video transport.
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.
This section explains how to configure the video transport capabilities of the QVidium QVARQ QoS
Multimedia Proxy Server
™ and how to enable ARQ error correction.
3.3.1 ARQ Operation
Automatic Retransmission Request (ARQ) tries to recover any packets lost during transport to the
decoder by adding a small amount of delay at the decoder during which time the decoder would
have time to detect and request any missing packets. The size of this delay should also include
adequate time for the missing packet to be received and inserted into the play out queue so that
the video stream can continue to flow smoothly and unimpeded to the MPEG decoder.
To enable ARQ, you must first select ARQ transport from the Profile dialog. ARQ transport
must also be enabled at this receive proxy. With ARQ selected and the encoder started, the
encoder will begin to save outgoing packets for later retransmission, when necessary. You must
also be certain to configure any firewalls to allow the ARQ retransmission request packets through.
The default port for these upstream ARQ request packets is UDP port 7020, although you can
configure this to any other valid, non-conflicting UDP port. However, if you choose to change the