# Error Resilient Coding Techniques for Video Delivery over Vehicular Networks
## 4 Channel Coding Protection
### FEC Protection  
RaptorQ codes provide AL-FEC protection to video streaming in order to improve video quality by recovering as many lost packets as possible. The cost of using FEC is an additional network bandwidth to carry FEC repair data, and also an increased latency to support packet recovery from a block of packets. Increasing the FEC bandwidth (given a fixed FEC latency) leads to an increase in data protection. Similarly, increasing the FEC latency (given fixed FEC bandwidth) also leads to an increase in data protection. Figure 7 shows the way in which the RaptorQ encoder protects data. First of all, the RaptorQ encoder receives a data stream (original source packets) during a specified protection period. A 4-byte FEC trailer is added to each original video packet thus forming an FEC-protected source packet stream. This trailer identifies the packet and the protection period to which it belongs. When an FEC-protected packet is generated, it is then immediately sent through the network. The packet payloads for all source packets within the protection period are gathered and represented as a set of continuous RaptorQ source symbols. When the protection period finishes, these source symbols are used to compute the repair symbols for that protection period by means of the FEC encoding process. The repair symbols are the same size as the source symbols and are carried in repair packet payloads. Each repair packet includes a 6-byte FEC header that prepends one or more FEC repair symbols. The repair FEC header identifies the associated protection period, the first symbol in the repair packet, and the number of source symbols in the protection period. Both the original source packets (with the FEC-trailer) and the associated repair packets are transmitted within the same protection period, and are used by a receiver application in the recovery process. Within each protection period, a receiver must receive \"enough\"  
source and repair symbols (from the FEC-protected source and repair packets) to be able to recover any dropped packets. For the protection of the encoded bit streams, we have used the Qualcomm (R) RaptorQ (TM) Evaluation Kit [22]. For each one of the encoded bit streams (bbd_25 sequence, using 9 encoding modes, with 6 different til/rm layouts), we have generated several protected versions by combining different values of the following parameters: protection level, protection period, and symbol size. The properties of the protected versions will determine the most suitable configurations for the protection of the video bit streams. Three different levels of protection have been tested: 10%, 20% and 30%; seven protection periods have been used: 133, 166, 200, 250, 333, 500 and 1000 milliseconds; and three symbol sizes have been evaluated: 192, 450 and 1350 bytes. In Table 4 the average overhead introduced by the three levels of protection, for the 1 til/rm and 10 til/rm layouts and all the protection periods, is shown. The smaller symbol size (192 bytes) obtains the lowest overhead values. This is due to the nature of the source data. As the source packets payloads have variable sizes and they range from small to big packets, a small symbol size optimizes the size of the repair packets. Instead, if we were protecting some other type of data with a constant size payload, then a symbol size matching the payload size would be the most efficient. Another observed feature is that the 1 til/rm layout generates less overhead than the 10 til/rm layout. The overhead values for the rest of the layouts have not been included in these tables for the sake of concision and clarity, but they show monotonically increasing behavior: the higher the number of tiles per frame, the higher the overhead introduced by FEC protection. For a fixed symbol size and a fixed til/rm layout, the overhead values for the different protection periods show monotonically decreasing behavior: the wider the temporal window, the lower the overhead percentage.