QVidium QVENC Encoder v17 - Manual (Page 23)

User’s Manual v.17 QVidium
®
H.264 HD Video Codecs ™
Copyright 2011-2015 QVidium
®
Technologies, Inc. Page 23 of 73
normally found in other MPEG4 codecs. In addition to Constant Bit Rate mode of operation, the
QVENC and QVPRO encoder also features variable bit rate (VBR) transport, which strips out
unnecessary null packets from the video transport stream to minimize network loading.
The QVENC/
QVPRO supports QVidium’s patented ARQ error correction. ARQ is a robust
feedback-based error correction that can successfully recover nearly all packet loss, even in harsh
network environments. However because of support for CBR, the QVENC/QVPRO also
implements SMPTE-2022 (ProMPEG) Forward Error Correction (FEC). Because the ProMPEG
FEC specification does not support VBR streams, you must use CBR mode when using ProMPEG
FEC. However, as FEC cannot anticipate varying network conditions nor correct many common
forms of packet loss, for the most effective error correction, we suggest using ARQ wherever
possible. (SMPTE-2022 is available upon request from QVidium as an unsupported option. There
is no extra charge for a QVPRO or a QVENC having a permanent QOS (ARQ) license.)
In contrast 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, 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