QVidium QVSD - Manual (Page 12)

User‟s Manual v.3 QVidium
®
QVSD H.264 SD Video Codec™
Copyright 2011 QVidium
®
Technologies, Inc.Page 12 of 53
also features variable bit rate (VBR) transport, which strips out unnecessary null packets from the
video transport stream to minimize network loading.
The QVSD 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 QVSD also will be supporting 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, we
suggest using ARQ wherever possible.
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 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 QVSD H.264 SD
Video
Codec™ and how to enable ARQ error correction.
2.3.1 Configuring Video over IP Network Parameters
To configure the IP network parameters, within the Network Parameters section of the encoder
profile, select among RTSP, ARQ, RTP, 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. 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