User`s manual

User’s Manual v.13 QVidium
®
H.264 HD Video Codecs™
Copyright 2011-2013 QVidium
®
Technologies, Inc. Page 22 of 67
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, 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.
This section explains how to configure the video transport capabilities of the QVPRO H.264 HD
Video Codec™ and how to enable ARQ error correction.
3.5.1 Configuring Video over IP Network Parameters
To configure the IP network parameters, within the Network Parameters section of the encoder
profile, select among ARQ, RTP, ProMPEG FEC, or UDP packet transport. Also, specify the
destination IP address and UDP port number. The destination IP address may be a multicast or a
unicast IP address.
Note: For ARQ IP transport, you may specify up to 4 comma-separated destination IP addresses
for sending copies of the output to multiple destinations. For more than 4 output copies of a
stream, either use a multicast address (and UDP or RTP transport) or contact QVidium for a
QVARQ-TxRep QoS Proxy server.
The encoder 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 add an RTP header to the UDP packet stream. The
RTP header adds a timestamp and packet sequence number before inserting the MPEG-2
transport stream packets into the RTP/UDP/IP packet payload.
All of these transport types insert an integral number of 188-byte MPEG-2 transport stream
packets into the packet payload as specified by the TS packets per IP packet parameter. The IP
encapsulation adheres to the IETF/RFC 2733 standard for video over IP that specifies that the
packet payload must comprise an integral number of whole MPEG-2 transport stream packets
within an RTP header, so all transport types, aside from UDP-only, are compatible with the
ProMPEG Forum’s standard and the IETF/RFC 2733 standard.
3.5.2 Error Correction - ARQ: Automatic Retransmission Request
To enable Automatic Retransmission Request (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.