Content for  TS 26.114  Word version:  18.8.0

This Annex gives the outline of possible example adaptation criteria that make use of adaptation signalling for video as described in clause 10.3. Several different adaptation implementations are possible and the example criteria shown in this clause are not to be seen as an adaptive scheme excluding other designs. Implementers are free to use these example criteria or to use any other adaptation algorithm as long as the requirements and recommendations specified in clause 10.3 are fulfilled. The description of the example criteria is split into two parts, one for the media sender side and one for the media receiver side.

The basic rate adaptation algorithm on the media sender side serves to combine the received RTCP TMMBR and RTCP Receiver Report or Sender Report in a way that makes adaptation possible in the presence of any or both of the aforementioned reports. One important aspect is that the TMMBR reports will serve as an upper limit on the permitted bitrate while RTCP Receiver or Sender Reports provide a means for temporary adjustments based on e.g. the packet loss rate in a given interval. Note that the actual bitrate limit will also depend on the bandwidth attribute in the SDP. Typically adjustments of the permitted bitrate due to TMMBR reports are less frequent than adjustments due to RTCP Receiver or Sender Reports The media sender may use the following conditions to adjust its video transmission rate:

1. Upon receiving a TMMBR message the media sender sets its maximum transmission rate to the requested rate.
2. If the requested rate in the TMMBR message is greater than the current video transmission rate the media sender (gradually) increases its transmission rate to the requested rate in the TMMBR message.
3. Examining the RTCP Receiver Report and Sender Report information to determine whether finer adaptations can be made to the video transmission rate. For example, the media sender may reduce its video transmission rate in response to an increase in the packet loss rate.
4. Reducing the video transmission rate if the media sender determines that the local radio uplink throughput is decreasing, e.g. detecting congestion in the uplink transmission buffers or examining other indicators of uplink quality.
5. Other conditions

The basic rate adaptation algorithm on the media receiver side may consist of both the well-established RFC 3550 RTCP RR and SR reporting (which is not described further) and the estimation and sending of TMMBR to the sender. Transmission of TMMBR reports is typically less frequent than RTCP Receiver Reports or Sender Reports. The media receiver may use the following conditions to send a TMMBR message requesting a reduction in video transmission rate

1. The video packets are arriving too close to or too late for their scheduled playout
2. The receiver detects an unacceptably high packet loss rate
3. The receiver detects that the received bitrate has been reduced
4. Other conditions

The MTSI media receiver may use the following conditions to send a TMMBR requesting an increase in video transmission rate

1. The video packets are arriving earlier than needed for their scheduled playout
2. Other conditions

Care must be taken when sending consecutive TMMBR messages to accommodate the media sender's reaction to previously sent TMMBR messages. When doing this, the media receiver should account for delays in the transmission of TMMBR messages due to RTCP bandwidth requirements.

As described in clause 10.3.4.2, the video encoder may not be able to immediately change the sending bitrate to the requested bitrate, especially if this also requires changing the frame rate and/or the video resolution. During this period, the generated bitrate is higher than the channel capacity which means that excessive bits (excess_bits) are generated and the corresponding RTP packets will be queuing up at the node where the congestion occurs. Figure C.8 gives a simplified schematic description of the encoder bitrate adaptation. The encoder bitrate is here shown with straight lines. In reality, the amount of data generated by the encoder will vary from frame to frame and the bitrate will then vary around the bitrate shown in this Figure. These bitrate variations are not considered in this description but needs to be considered in the real implementation. The encoder uses the bitrate of the previous channel capacity (prev_rate) as long as the sender is unaware of the reduced channel capacity. When the TMMBR message is received, the encoder starts reducing the bitrate towards the new channel capacity (new_rate). Since the bitrate indicated in the TMMBR message includes the IP/UDP/RTP overhead then this needs to be removed. The encoder bitrate is then reduced even further for a while to gain back the delay caused by the queue build-up.

The upper limit requirement (excess_bits_wc) for how many excessive bits that is allowed to be generated during the adaptation time is defined by the Worst-Case Adaptation Algorithm, which corresponds to the rectangle ABCD while the recommendation (0.5 * excess_bits_wc) is defined by the triangle ABC. The amount of excessive bits that are generated corresponds to the area of the triangle ABE. As can be seen in the Figure, the measurement window (measurement_window) is here longer than the worst case adaptation time (adapt_time_wc) which is used for defining the requirement limit and the recommendation limit for the excessive bits. In this example, the encoder bitrate is not reduced fast enough to fulfil the recommendation but the requirement is fulfilled. This shows that it is allowed to use an adaptation time that is longer than the time used for defining the requirement and recommendation, as long as the amount of excessive bits does not exceed the limit. After the encoder bitrate has been reduced to the new bitrate then the encoder needs to reduce the bitrate even further to form the beginning of the delay recovery period. The length of the delay recovery period depends on the amount of excessive bits that have been generated and how much lower the encoding bitrate is compared to the new channel capacity. In reality, the queue starts to build up even before the sender has received the TMMBR message, which is here shown by the rectangle ABFG. The sender can estimate the excessive bits generated during this period from the RTCP Receiver Reports and can then compensate for this by extending the delay recovery period.

When the channel is being under-utilized by the sender, it is likely that the delivery of video packets will occur before they actually need to be played out at the receiver. Therefore, the sender rate could be increased and introduce some additional delay without negatively affecting the system or the user experience. The excess bits (excess_bits) that can be introduced into the transmission path can be computed as follows in the case that the channel bandwidth is equal to the average receiving rate measured at the receiver, i.e., the worst case with no spare channel bandwidth available: where: and The corresponding worst case excess delay (excess_delay_wc) due to excess_bits equals: where: Therefore, if the receiver determines the amount of allowable excess delay (excess_delay_allowable) from the received video packets, it can calculate the amount of rate increase that would not congest the system as: Since the one-way delay from sender to receiver is generally unknown to the receiver, it cannot use this to calculate the allowable excess delay. Instead the receiver measures the amount of time between when a packet arrives and when it is scheduled to be played out to determine how much additional delay is acceptable. This metric is actually more accurate from a user-experience perspective since this directly determines whether the video information in received packets can actually be displayed to the user without degradation. The bitrate to request (requested_rate) in TMMBR is then: Before sending the TMMBR message with the requested rate, the receiver needs to verify that the requested rate does not exceed the bitrate that was negotiated in SDP offer/answer.

The delay recovery rate (delay_recovery_rate) and delay recovery period (delay_recovery_period) can be determined as follows. Let where: ƒU (0 < ƒU <1) is the rate undershoot factor and may depend on the magnitude of the channel rate drop (ΔR) is: For example, if ΔR is large, then ƒU may be proportionally large or if ΔR is small, then ƒU may be proportionally small, for example: Assuming that the bits during time period ΔT = time(E) - time(F) are queued up and are contributing to the delay, the delay recovery period ΔTu can be computed as follows: A minimum bit rate requirement for the encoder may exist that applies to delay_recovery_rate and, therefore, also to ƒU as follows: and therefore: with: If during the delay recovery period a TMMBR message is received that carries a new rate value (new_rate), and new_rate is significantly larger than new_rate, for example new_rate2 ≥1.2*new_rate, then the delay recovery period may be shortened. Conversely, if new_rate2 < new_rate then an extended delay recovery period can be computed.