# Video over DSL with LDGM Codes for Interactive Applications
## 1 Introduction  
Compressed video has recently received a boost from around a 50% reduction in bandwidth requirements arising from the High Efficiency Video Coding (HEVC) codec standard [1]. Unfortunately, either owing to a desire to reduce codec complexity or owing to a preference for commercial high-definition video-on-demand applications, low-latency video streaming is no longer strongly supported in the codec. As a result, applications such as telemedicine and video conferencing have a limited range of built-in error-resilience tools available [2]. Further, the Dynamic Adaptive Streaming over HTTP (DASH), which is supported by HEVC, owing to the underlying Transmission Control Protocol (TCP) used by DASH introduces packet re-sending delay whenever a packet is lost to errors or congestion. Video streaming has an important role in telemedicine [3] both in longer-term monitoring and in emergency responses, where the need for low-latency communication is probably strongest. For home medical advice it would be helpful if face-to-face consultation with a remote clinician were possible. This assumes that HEVC encoding delays can be addressed, as they are currently many times above real-time [4]. For interactive video streaming with an associated speech channel, delay is harmful to synchronization at both ends of the communication link. Digital Subscriber Line (DSL) is the dominant broadband access network for residential users with 364.1 million links in 2012 [5]. However, impulse noise is a potent source of DSL transmission errors, resulting in fixed-lengtherror bursts, causing multiple packet losses, the number of which depends on the transmission rate. Sources of error bursts vary from street lights though faulty set-top boxes and even from flashing Christmas tree lights [6]. As a way of responding to packet error bursts, end-to-end Automatic Repeat ReQuest (ARQ) packets introduce latency, particularly if used from end-to-end, leaving Forward Error Correction (FEC) as the main way of reducing errors in the absence of effective error resilience tools. This paper considers an application-layer (AL) FEC solution to the problem of video packet loss on DSLs. If packets are lost, owing to video-coding dependencies video streams may be disrupted for up to 500 ms, the duration of a typical Group of Pictures (GoP) [7]. Consequently, PHYsical-layer FEC protection in the case of video is often supplemented by AL-FEC [8], which has been introduced into the main wireless standards. Typical examples discussed in Section 2 of FEC codes [9] employed in packetized video streams are: eXclusive OR (XOR)-based codes, simple or interleaved; Low-Density Parity-Check (LDPC) codes; and Reed-Solomon (RS) codes. However, FEC or channel codes due to their computational complexity may also introduce latency. Coding latency can be composed of: the need to accumulate sufficient data to successfully repair packets, a problem that may arise with the rateless codes [10], including Raptor codes [8], leading to large input buffers; and the delay arising from the computational complexity of the coding and decoding operations, a problem with Reed-Solomon (RS) codes [11] as the block size increases. When rateless codes are employed adaptively, another source of latency may arise, owing to a need to request the sender to stop sending additional repair packets. Though there are now open-source versions of Raptor code, Raptor10 and RaptorQ [12], for research purposes, care should be taken not to infringe any of the patents associated with Raptor coding. Thus, to computational complexity, in some cases, one can add legal complexity. One aim of our research in this paper was to find an effective method of channel coding which was not constrained by legal restrictions. Therefore, legally-constrained methods of channel coding, however efficient they may be in repairing erasures are, in this paper, not directly included in the performance comparison.