This Annex describes operation principles and provides examples to video packet loss handling scheme described in clause 9.3. Several different video packet loss handling behaviours are possible at both sender and receiver ends for responding and reporting, respectively. Example criteria shown in this section are not to be seen as a scheme that excludes other designs. Implementers are free to use any packet loss algorithm as long as the requirements and recommendations specified in clause 9.3 are fulfilled.

Efficient video error recovery requires error tracking capabilities at both the sender and the receiver side. Error detection and tracking is necessary on the receiver side for detecting the occurrence of the error as well as detecting the recovery from the error. On the sender side it is necessary for producing a recovery picture that would address the reported packet loss. Basically a receiver should be able to detect errors and report them to the sender in timely fashion. In return sender responds by sending recovery pictures or performing gradual decoder refresh (GDR). An example of video error recovery is illustrated in Figure P.1 below using a NACK message.

In this example, the error correction is performed in the following steps:

1. Sender encodes a reference picture (blue) and transmits it. One or more of the packets belonging to this picture are lost.
2. Receiver detects lost packets belonging to the blue picture upon receiving packets belonging to the picture following the blue picture or the last packet (if received) of the blue picture, after de-jittering.
3. When the decoder tries to decode the picture following the blue picture and notices that a reference picture that it is referring to (i.e. the blue picture) is missing or has been partially received, and in response flags an error.
4. Upon seeing the error report from the decoder, the receiver issues a NACK message. The duration of time that elapses from the first detection of missing packets to the issuance of the feedback message is denoted as the receiver reaction time.
5. Sender receives the NACK message, feeds this information to the encoder, which responds by encoding the next picture either as an intra or inter picture. Alternatively the encoder can generate GDR over next N frames. In the inter-picture case, the encoder refers to a reference picture (red) that it assumes can be correctly decoded at the receiver side. The duration of time that elapses from receipt of the feedback message and sending of the recovery picture is denoted as the sender reaction time.
6. Sender sends the recovery picture or the GDR to the receiver.
7. Receiver's decoder continues to decode incoming pictures looking for the arrival of the recovery picture or full refresh from GDR. The receiver may opt not to render any incoming corrupted pictures while waiting for the arrival of the recovery picture or full refresh.

If the recovery picture does not arrive in response wait time duration (RWT) then the receiver should issue another NACK message to request error recovery and wait for recovery. If the recovery still does not occur within another RWT, then it starts issuing PLI messages to request IDR or GDR recovery. This is illustrated in Figure P.2 below.

PLI request becomes necessary when the likelihood of having a common reference frame for inter error recovery is diminished. In this example, the error correction is performed in the following steps:

1. Receiver issues a PLI message after waiting for two RWT duration for a recovery picture requested by NACK messages to arrive from the onset of the error.
2. Sender upon reception of the PLI message, encodes the next picture as IDR picture or starts a GDR.
3. Receiver receives the IDR picture or the GDR pictures resulting in full refresh.

In the above example, a second PLI is received by the sender within RWT interval. In this case, the sender ignores the second PLI since the receiver cannot detect the arrival of the first sent IDR/GDR within this time frame. The same principle applies to NACK messages as well. This would also apply to cases where the sender has sent a picture that could serve as a recovery picture (not triggered by a PLI/NACK message) prior to the reception of a PLI/NACK message within RWT duration. In this case the sender does not have to respond to the received PLI/NACK message as illustrated in Figure P.3 below.

This case would apply to schemes where the sender periodically performs some form of periodic intra refresh or inter recovery (periodically predict from long term reference (LTR) pictures) as long as the period is conforms to the timing restrictions defined in clause 9.3.