|
9 ^7 A8 ^( q& }+ S$ C 自从VoLTE推广后，除了打高清语音掉话外，还可以进行高清视频通话（个人认为比微信的视频通话清晰很多也更稳定），所以，就需要机制进行丢包处理。
5 k/ R/ n; `5 n* l7 f L/ L MTSI（Multimedia Telephony Service for IMS）客户端可以使用以下机制从数据包丢失中恢复： AVPF（audio video profile feedback）通用NACK和图像丢失指示（PLI：Picture Loss Indication）反馈信息 RTP（Real-time Transport Protocol）重传 前向纠错（FEC：Forward Error Correction）这些机制根据信道条件提供不同的性能权衡：端到端时延、带宽、速率和数据包丢失情况。 " S" K2 k' i0 Q( k6 q
MTSI客户端使用AVPF NACK消息来指示未接收到的视频RTP包。传输视频的MTSI客户端可以使用此信息以及AVPF图片丢失指示（PLI），以便尽早采取适当的操作，以便为发送NACK或PLI消息的MTSI客户端从错误中恢复视频。从错误动作中恢复被定义为发送良好帧的恢复图片、发送导致良好帧的逐渐解码器刷新（GDR：Gradual Decoder Refresh）或重新传输丢失的包。 6 Q4 A6 k) Z- a. V* G, B. |) H
接收方行为
/ E" _7 B" z( |# ~# U7 t: Y9 W3 n 当已协商NACK和PLI而不支持会话重传时，终端接收媒体中的MTSI客户端执行如下动作：
4 M2 @, n! h0 m: k- m+ [ 1. 在解码好帧后检测到第一个错误时，应立即将NACK消息排队等待RTCP（RTP Control Protocol）调度。 ' Y, A4 c- t& ?
2. 如果恢复图片未到达，则应在RWT（Response Wait Time）持续时间后重复排队NACK消息以进行RTCP调度。
' J' K, B) i: n. U* n* m4 d 3. 如果恢复图片没有在两个RWT持续时间内到达，则应将PLI消息排队等待RTCP调度，然后应停止发送与该PLI相同数据相关的NACK消息。
$ M6 C, q/ h- q, J. v9 e, o 4. 如果最初请求的恢复图片未到达，则应在RWT持续时间后重复排队PLI消息以进行RTCP调度。
( f/ m( f }8 {8 X 如果支持FEC，则NACK消息应该在FEC恢复后发出不可恢复的丢失包信号，而不是在恢复前发出检测到的丢失包信号。在为丢失的数据包发出NACK消息之前，接收器应该等待“repair-window”时间。 % M+ ?. h, f. ~; F9 ~
当支持重传时，NACK消息对应于要重传的丢失分组数据的请求，而不是指示错误位置以便在不重传的情况下恢复。接收方应根据需要将NACK消息排队以进行RTCP调度。在请求重传之前，应考虑丢失数据包的重要性以及请求数据包及时到达的可能性。
/ n I! S$ g" P 发送方行为
5 ^9 n& V6 b/ v. I' ^" o 当已协商NACK和PLI而不支持会话重传时，终端发送媒体中的MTSI客户端执行如下操作：
) F7 B5 e* S; N- c$ l3 b 1. 如果消息指示的丢失与500 ms内的参考图片中的错误相对应，则在接收到NACK消息时应发送恢复图片或逐渐解码器刷新（GDR）。如果在接收NACK消息之前发送了与NACK消息相对应的恢复图片，持续时间小于RWT，发送方不必响应此特定的NACK消息。 / h4 j2 N. [0 q9 Q2 c t/ j
2. 应在收到PLI消息后500 ms内发送即时解码器刷新（IDR：Instantaneous Decoder Refresh）或GDR图片。 0 N) K" J( l4 D- ]7 L; T
3. 在同一消息类型的RWT持续时间内，不应对传入的NACK或PLI消息作出响应，表明接收到由丢失开始触发的初始反馈消息时发生了相同的丢失。
" d" h8 v9 v* f2 T IDR图片是帧内图片，其中可以解码在IDR图片之后的图片而不参考（帧间预测）在IDR图片之前解码的图片。GDR通过在N个图片上分布图片内数据来执行图片内刷新。在从GDR开始的N个图片的末尾，所有宏块区域被帧内编码以生成良好帧。与IDR情况类似，如果使用帧内图片或GDR作为恢复机制，则帧内图片或GDR图片之后的图片不应引用在这些图片之前解码的图片。 ! i' m* ]: F* ~% o2 S/ z
当支持重传时，发送方应该重传它认为有利于及时恢复的数据包。只应重新传输源数据包。发送方应在其缓冲区中保留原始RTP数据包以供重新传输的最短时间，即“rtx_time”值应为RTT，发送方应保留原始RTP数据包的最长时间应为400 ms。
3 y7 \/ A4 U4 j7 u! ]0 ]+ o( O& E 当支持FEC时，跨越源和相应的修复包（即“repair-window”）的时间量不应小于用于生成修复包的位掩码所需的最小持续时间。跨越源和相应修复数据包的最长时间不应超过300毫秒。 4 i6 D! g/ s. e. Q. x7 D6 k
丢失数据恢复机制建议
6 `: {: ^1 g7 F) a* R FEC应用于在高时延情况下提供对中等分组数据丢失率的鲁棒性。FEC特别能够处理随机丢失和短突发丢失，并且在具有高分组数据丢失率或高时延（RTT）的环境中是有益的。当由于吞吐量不足（通过无线接入或由于网络拥塞）而导致分组数据丢失时，FEC的使用可能不合适，因为它引入了一些比特率开销。为了补偿比特率开销，FEC应采用有效的速率自适应机制，根据信道条件降低源比特率，而不增加RTP总比特率。当错误案例不能通过FEC恢复时，需要其他机制与FEC相结合。 由于重传可以有效地处理FEC失败的情况，因此对于低RTT和较高丢包率的情况，应该结合FEC进行重传。一般的基于NACK的恢复与FEC结合应用于高RTT、相对较高的丢包情况，因为一般的基于NACK的恢复不会引入额外的时延。选择性重传应该在低时延（RTT）和低失败（丢失）率条件下使用。重传需要确保重传的数据包及时到达，以满足端到端系统的时延要求。较高的数据包丢失率可能会导致重新传输的数据包丢失，从而导致较大的端到端时延。
J6 @# X9 R7 b' j' A 一般的基于NACK和PLI的纠错机制应该与FEC或选择性重传结合使用，或者在低丢包率和高RTT条件下使用。一般NACK消息可用于指示要重传的分组，以及通知发送方特定RTP分组的丢失，以便发送方采取必要的措施从错误中恢复。
; h6 i7 F l+ V/ r. `) S8 z5 t- O 实例 6 o& }4 W, r) Z9 U/ k4 R4 }
高效的视频错误恢复需要发送方和接收方的错误跟踪功能。为了检测错误的发生以及从错误中恢复，在接收机侧需要错误检测和跟踪。在发送方，有必要生成一个恢复图片来处理所报告的数据包丢失。基本上，接收者应该能够检测错误并及时向发送者报告。作为回报，发送方通过发送恢复图片或执行渐进解码器刷新（GDR）来响应。 / Q; ^% }& d$ O# z7 A
下面的图1使用NACK消息说明了视频错误恢复的示例。
C4 K# M! I9 I6 r* }6 m+ O 图1： 使用NACK反馈消息恢复视频错误在此示例中，按照以下步骤执行误差校正： 8 y( P" e+ R3 H ?& L7 x) R) G- {
1）发送方对参考图片（蓝色）进行编码并传输。属于此图片的一个或多个数据包丢失。
2 ~* @1 L% C! T) b7 ~( J0 s 2）在去抖动之后，接收器在接收到属于蓝色图片后面的图片的包或蓝色图片的最后一个包（如果接收到）时检测属于蓝色图片的丢失包。 8 @( \& O* t$ p) B8 x* `% c7 \
3）当解码器尝试解码蓝色图片之后的图片并且注意到它所引用的参考图片（即蓝色图片）丢失或者已经部分接收时，并且作为响应标记错误。
* I( O: ` ~5 y2 B 4）在从解码器看到错误报告时，接收器发出NACK消息。从第一次检测到丢失分组到发出反馈消息所经过的持续时间被表示为接收器反应时间。 - N* @" ~3 P" u' p. n
5）发送方接收NACK消息，将该信息提供给编码器，编码器通过将下一个图片编码为帧内或帧间图片来响应。或者，编码器可以在接下来的N帧上生成GDR。在图片间的情况下，编码器参考其假设可以在接收器侧正确解码的参考图片（红色）。从接收反馈消息到发送恢复图片所经过的持续时间被表示为发送者反应时间。
+ r/ @! E; b" k$ ? 6）发送方将恢复图片或GDR发送给接收方。 1 D* ?% \6 x& j9 ]3 G3 l; a- Q
7）接收机的解码器继续解码传入的图片，寻找恢复图片的到达或来自GDR的完全刷新。在等待恢复图片或完全刷新的到来时，接收器可以选择不呈现任何传入的损坏图片。
! ~7 {; W; j, c# Q) M 如果恢复图片没有在响应等待时间（RWT）内到达，那么接收器应该发出另一个NACK消息来请求错误恢复并等待恢复。如果恢复仍然没有在另一个RWT中发生，则它开始发出PLI消息以请求IDR或GDR恢复。下图2对此进行了说明。
0 Z! o# H, v6 S( v 图2：使用PLI反馈信息恢复视频错误当具有用于错误间恢复的公共参考帧的可能性降低时，PLI请求变得必要。在此示例中，按照以下步骤执行误差校正：
4 p7 \. p5 H9 w, c 1）接收器在等待两个RWT持续时间之后发出PLI消息，以使NACK消息请求的恢复图片从错误开始到达。
0 u. w2 u0 Z- q$ b @$ O 2）发送方收到PLI消息后，将下一张图片编码为IDR图片或启动GDR。
: [+ Z% y) O( Z" R! ^" \! s 3）接收器接收IDR图片或GDR图片，从而进行完全刷新。
- e! D- v% E! W3 X/ u 在上述示例中，发送方在RWT间隔内接收到第二个PLI。在这种情况下，发送方忽略第二个PLI，因为接收方无法在该时间帧内检测到第一个发送的IDR/GDR的到达。同样的原理也适用于NACK消息。这也适用于发送方在RWT持续时间内接收到PLI/NACK消息之前发送了可以用作恢复图片（不是由PLI/NACK消息触发的）的图片的情况。在这种情况下，发送方不必对收到的PLI/NACK消息作出响应，如下面的图3所示。
) {* X0 Q" t% [- I9 V1 Y* a 图3：发送方不必响应传入NACK/PLI消息的示例这种情况将适用于发送方周期性地执行某种形式的周期内刷新或周期间恢复（周期性地从长期参考（LTR）图片预测）的方案。 4 @4 S$ C% T! n( B7 C; B
另一个例子：RTP重传
, m" ?# r! N# O' G RTP重传提供由NACK反馈报告的丢失包的重传。接收器检测到丢失的数据包并请求重新传输丢失的数据包。发送方在接收到NACK消息时决定通过将所报告的丢失分组重新传输给接收方来采取纠正措施。如果重新传输的数据包及时到达渲染，则可以实现及时恢复。
9 a* Q2 v a% G( D2 F 使用NACK消息从错误中恢复的示例如下图4所示。
+ N6 P9 R$ `+ h, B1 h" w( G; E 2 E: m7 a# b) C
在此示例中，按照以下步骤执行误差校正： : f( o1 q2 f0 e2 t8 Z7 u7 i, V
1）发送方对参考图片（蓝色）进行编码并传输。发送方在其缓冲区中存储与此帧对应的RTP包。属于此图片的一个或多个数据包丢失。 5 [) P$ S0 I/ y+ y5 g* h% d
2）在去抖动之后，接收器在接收到属于蓝色图片后面的图片的包或蓝色图片的最后一个包（如果接收到）时检测属于蓝色图片的丢失包。 3 x/ e1 b' m, h
3）接收器发出NACK消息并暂停解码，同时缓存传入的数据包。 : ~- V9 y) I" g% ~6 P
4）发送方收到NACK消息，检查请求的数据包在其缓存中是否可用。如果是，它将重新传输请求的数据包。 8 A4 u' h) v0 B4 r5 l
5）接收器监视进入的包以确定请求的包的到达以恢复解码。
g. h/ A R# O 6）如果数据包及时到达，渲染不会中断。 - C5 c" s7 [! c1 ^1 x( s
, j% T, A& v# D% ~
, n6 s/ i# N @7 ~) Z
\; `6 b; h Y2 R" L8 K) ~! n- c! S# E X. b0 k% }$ B
| 
