# Error Resilient Coding Techniques for Video Delivery over Vehicular Networks
## 4 Channel Coding Protection
### Packet Recovery  
Now we will evaluate the behavior of the RaptorQ protection at different PLR values. The evaluations are formed by the following steps. Firstly, the video encoded bit streams are divided into network packets. In this step, tiles which do not fit into one network packet will be divided into several packets. After this, packets are sent to the RaptorQ encoding process, in order to protect them (adding the FEC trailer) and to generate the repair packets. Then, in the complete packet stream (protected packets and repair packets) some packets are discarded, using a simple probabilistic packet error model. In the next step, the surviving packets are sent to the RaptorQ recovery process, in order to recover as many missing packets as possible. After that, tiles are reconstructed by joining together all the packets which belong to the same tile. If one or more packets which belong to a tile are missing, the whole tile will not be decodable and so we will mark that tile as lost. At last, we obtain the TLR which is the rate of lost tiles versus the total number of original tiles.  
Now, we will present the results of our evaluations. Figure 8 shows the TLR (after FEC recovery) for different til/rm layouts with a protection level of 10% and 20% for both the AI and LPI4 modes at different packet loss rates (1%, 3%, 5%, 7%, 10% and 20%). Please note that the 20% packet loss curve is outside the bounds for this scale (or nearly out), so it is not completely sketched inside the graphic areas, but its values can be numerically inspected in the data tables.  
In the case of a protection level of 10%, (see Figure 8a,b) layouts of 4 til/rm and higher noticeably improve the recovery percentage over 1 til/rm and 2 til/rm layouts (in which the number of packets per tile penalizes the recovery process). A protection level of 10% can almost completely recover a protected bit stream for a packet loss percentage of 1%, and keeps the tile loss percentage really low for a packet loss percentage of 3%. Even at a packet loss of 5%, a protection level of 10% does a good job, especially for 8 and 10 til/rm layouts (where the final tile loss percentage is lower than 1% in both encoding modes). In Table 3, the AI encoding mode has an average value of 4.38 packets per tile (1 til/rm layout), and the LPI4 encoding mode has near the same value, however their TLR values (see Figure 8a,b) are not. Although the average packets per tile are similar, the I and P frame distribution in each encoding mode is very different. In the AI mode all the frames are I frames. This implies that all the encoded frames have a similar size and the packets-per-tile ratio is nearly constant for every frame. On the contrary, the LPI4 encoding mode inserts an I frame followed by three P frames. P frames are more efficient (and therefore they are smaller) than I frames, so the packets-per-tile ratio of a P frame is lower than that of an I frame. When the packets-per-tile ratio tends to 1 (high number of til/rm) these differences are narrow, but when the packets-per-tile ratio increases (low number of til/rm), the differences increase. This unbalance produces different results in the final tile loss percentage of both modes, and, in this situation, the LPI4 mode yields better recovery results than the AI mode.  
In the case of a protection level of 20% (see Figure 8c,d), PLR values of 5% and lower are practically wiped out. For the LPI4 encoding mode, this is also true with a 7% PLR and 4, 6, 8 and 10 til/rm layouts. The results in both figures show that the protection level parameter does not have to be confused with the \"recovery percentage\". A trade-off between bit stream overhead and packet recovery capabilities should be found depending on the application requirements and the network load conditions. The results show that between 4 and 6 tiles per frame with a 10% protection level configurations provide a reasonable good packet recovery performance with a moderated bit stream overhead.