【音视频第1天】常见的术语含义等

1. QoS和QoE的区别

Quality of Service（QoS）和Quality of Experience（QoE）是音视频通话中常用的两个概念。
**QoS是指网络提供服务的质量。**它是一种网络管理技术，用于确保网络中的数据传输符合预定的标准。QoS技术通过优先处理重要的数据包，降低网络拥塞，减少丢包和延迟，提高网络性能。
**QoE是指用户在使用某种服务时的主观感受。**它是评估用户对服务质量的一种方法，通常被用来描述用户感知的视觉、音频和交互体验。QoE不仅仅关注网络服务的技术指标，还包括用户对服务的期望、需求和满意度等因素。
两者之间的联系在于QoS是QoE的基础，只有网络提供良好的服务质量，才能让用户获得良好的体验。但是QoS并不能完全代表用户的体验，QoE更多地关注用户的主观感受。
衡量QoS的指标包括：带宽、丢包率、延迟、抖动等。衡量QoE的指标则比较复杂，包括视觉质量、音频质量、交互质量、响应时间等。
在音视频通话中，为了提高用户体验，需要同时优化QoS和QoE。可以通过技术手段来优化网络服务质量，比如增加带宽、降低丢包率、减少延迟等。同时，也可以通过提高视频和音频质量、改善用户界面等方式来提高用户体验。

2. 在webRTC中由浅入深讲一下什么是ARQ和Nack，相应的原理，以及解决的问题，优势劣势，还存在的问题

在WebRTC中，ARQ（Automatic Repeat Request）和Nack（Negative Acknowledge）也被用于数据传输过程中检测和纠正错误。
WebRTC中的ARQ和Nack工作原理与传统的ARQ和Nack相同：发送方发送数据包，接收方收到并检验数据包，若数据包出现错误，则向发送方发送Nack请求重传该数据包。发送方收到Nack后，会重新发送该数据包，直到接收方接收到正确的数据包为止。
ARQ和Nack解决的问题也是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。ARQ和Nack可以检测到这些错误，并通过重传数据包的方式进行纠正，保证数据的完整性和正确性。
WebRTC中ARQ和Nack的优势和劣势与传统的ARQ和Nack相同。优势是可以有效地纠正数据传输过程中的错误，保证数据的完整性和正确性。同时，ARQ和Nack还可以在网络拥塞的情况下，通过减少发送数据包的速率，降低网络负载，从而保证数据传输的稳定性。劣势是会增加数据传输的延迟和带宽占用。当数据包出现错误时，需要重新发送该数据包，这会增加数据传输的延迟和带宽占用。同时，在网络拥塞的情况下，ARQ和Nack会降低发送数据包的速率，从而降低数据传输的效率。
WebRTC中ARQ和Nack仍然存在一些问题。首先，当数据包的丢失率较高时，ARQ和Nack会增加数据传输的延迟和带宽占用。其次，ARQ和Nack无法避免数据包的重复发送，这会浪费网络资源。最后，ARQ和Nack只能检测到数据包的错误，无法纠正数据包的内容错误，比如数据包中的数据格式错误等。为了解决这些问题，WebRTC还使用了其他的技术，比如FEC（Forward Error Correction）和纠错编码等。

3. 在WebRTC中Nack是如何检测到数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等？

在WebRTC中，Nack（Negative Acknowledge）可以通过以下两种方式检测到数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等：

1. 通过RTP序列号检测数据包是否丢失
   WebRTC中每个RTP数据包都有一个唯一的序列号，接收方可以通过检查序列号来判断是否有数据包丢失。如果接收方发现某个序列号对应的数据包没有收到，就会向发送方发送Nack请求重传该数据包。这种方式可以有效地检测到数据包的丢失情况。
2. 通过计算数据包的校验和检测数据包内容是否损坏
   WebRTC中每个数据包都包含一个校验和，接收方可以通过计算校验和来检测数据包内容是否损坏。如果接收方发现校验和不匹配，就说明数据包内容出现了错误，就会向发送方发送Nack请求重传该数据包。这种方式可以有效地检测到数据包内容的错误情况。
   通过以上两种方式，Nack可以检测到数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。当检测到这些错误时，接收方会向发送方发送Nack请求重传该数据包，从而保证数据的完整性和正确性。

4. 在webRTC中由浅入深讲一下什么是FEC，相应的原理，以及解决的问题，优势劣势，还存在的问题

在WebRTC中，FEC（Forward Error Correction）也被用于数据传输过程中检测和纠正错误，它通过在数据包中添加冗余信息来提高数据的可靠性。
FEC的原理是在发送方对数据包进行编码，添加一些冗余信息，然后将编码后的数据包发送给接收方。接收方在收到数据包后，可以通过解码冗余信息来纠正数据包中的错误。具体来说，FEC可以通过添加冗余数据包或者添加冗余编码符号来实现纠错。当发生数据包丢失或者数据包内容错误时，接收方可以利用冗余信息来恢复丢失的数据包或者修复错误的数据包。
FEC解决的问题是数据传输过程中的错误。在WebRTC中，数据传输过程中数据包可能会出现错误，比如数据包被丢失、数据包内容损坏等。FEC通过添加冗余信息来提高数据的可靠性，从而可以有效地检测和纠正这些错误，保证数据的完整性和正确性。
FEC的优势是可以提高数据传输的可靠性，尤其是在网络质量较差的情况下。相较于ARQ和Nack，FEC可以在接收方还未检测到数据包错误时，通过添加冗余信息提前纠正错误，从而减少数据传输的延迟和带宽占用。同时，FEC还可以在网络拥塞的情况下，通过减少发送冗余数据包的速率，降低网络负载，从而保证数据传输的稳定性。劣势是需要额外的带宽来传输冗余信息，从而增加了数据传输的带宽占用。
FEC还存在一些问题。首先，FEC的效果与冗余信息的添加方式和参数设置有关，需要根据网络状况进行调整，比较难以优化。其次，FEC无法避免数据包的重复发送，这会浪费网络资源。最后，FEC只能检测到数据包的错误，无法纠正数据包的内容错误，比如数据包中的数据格式错误等。为了解决这些问题，WebRTC还使用了其他的技术，比如ARQ和Nack以及纠错编码等。

5.FEC如何增加冗余信息，依据是什么，如何进行纠错，如何利用冗余信息来恢复丢失的数据包或者修复错误的数据包

FEC可以通过添加冗余数据包或者添加冗余编码符号来增加冗余信息。具体添加冗余信息的方法有两种：

1. 添加冗余数据包
   在发送方添加冗余数据包时，可以将原始数据包和冗余数据包一起发送给接收方。如果接收方收到原始数据包，则不需要使用冗余数据包。如果接收方丢失了原始数据包，则可以使用冗余数据包来恢复丢失的数据包。添加冗余数据包的方法可以通过FEC的Reed-Solomon编码实现。
2. 添加冗余编码符号
   在发送方添加冗余编码符号时，可以对原始数据包进行编码，生成一些冗余编码符号，然后将原始数据包和冗余编码符号一起发送给接收方。如果接收方收到所有原始数据包，则不需要使用冗余编码符号。如果接收方丢失了某个原始数据包，则可以通过解码冗余编码符号来恢复丢失的数据包。添加冗余编码符号的方法可以通过FEC的LDPC（Low-density Parity-check）编码实现。
   FEC添加冗余信息的依据是根据数据包的重要性和网络状态来确定。具体来说，FEC可以根据数据包的重要性和网络状况来动态调整添加冗余信息的方式和参数，以达到最优的纠错效果和带宽利用率。
   FEC利用冗余信息来恢复丢失的数据包或者修复错误的数据包的方法有两种：
3. 恢复丢失的数据包
   如果接收方丢失了某个数据包，则可以通过解码冗余信息来恢复丢失的数据包。具体来说，接收方可以使用已经收到的数据包和冗余信息来解码，从而恢复丢失的数据包。这种方式可以在不需要重传数据包的情况下恢复丢失的数据包，减少数据传输的延迟和带宽占用。
4. 修复错误的数据包
   如果接收方收到了错误的数据包，则可以通过解码冗余信息来修复错误的数据包。具体来说，接收方可以使用已经收到的数据包和冗余信息来解码，从而修复错误的数据包。这种方式可以在不需要重传数据包的情况下修复错误的数据包，减少数据传输的延迟和带宽占用。
   FEC的纠错方法是通过解码冗余信息来实现的。具体来说，接收方可以使用已经收到的数据包和冗余信息来解码，从而恢复丢失的数据包或者修复错误的数据包。解码的过程可以通过FEC的Reed-Solomon编码或者LDPC编码实现。

6. 详细说说FEC的Reed-Solomon编码和FEC的LDPC（Low-density Parity-check）编码

（这里还是糊里糊涂等）
FEC的Reed-Solomon编码是一种基于多项式的纠错码，可以通过添加冗余数据包来增加冗余信息。具体来说，编码器将原始数据包看作多项式的系数，并将多项式扩展为一个更高次数的多项式，然后计算该多项式在一个有限域上的值，得到冗余数据包。接收方可以使用已经收到的数据包和冗余数据包来解码，从而恢复丢失的数据包。Reed-Solomon编码具有良好的纠错能力和高效的编解码算法，可以广泛应用于视频、音频等实时数据传输领域。
FEC的LDPC编码（Low-density Parity-check）是一种基于矩阵的纠错码，可以通过添加冗余编码符号来增加冗余信息。具体来说，编码器将原始数据包看作矩阵的一行或一列，并将矩阵扩展为一个更大的矩阵，然后计算该矩阵的校验和，得到冗余编码符号。接收方可以使用已经收到的数据包和冗余编码符号来解码，从而恢复丢失的数据包。LDPC编码具有良好的纠错能力和较低的编解码复杂度，可以广泛应用于数据传输领域。
Reed-Solomon编码和LDPC编码都是一种前向纠错（Forward Error Correction，FEC）技术，可以在不需要进行反馈的情况下对数据包进行纠错。它们的区别在于，Reed-Solomon编码适用于数据包丢失较多的情况，而LDPC编码适用于数据包错误较多的情况。此外，Reed-Solomon编码需要添加冗余数据包，而LDPC编码需要添加冗余编码符号。
总之，FEC的Reed-Solomon编码和FEC的LDPC编码都是常见的纠错码技术，可以在不需要进行反馈的情况下对数据包进行纠错，提高数据传输的可靠性。选择哪种编码方式，需要根据具体的传输场景和要求来决定。
Nack是需要反馈的。

7.WebRTC 利用 UlpFEC 进行数据保护，冗余系数由链路上的丢包率决定。这里面UlpFEC是什么？冗余系数有什么作用，链路上的丢包率怎么求

UlpFEC是WebRTC中使用的一种前向纠错技术，它是一种基于ULP（UDP-based Data Transfer Protocol）协议的前向纠错技术。它可以在传输数据时添加一些冗余数据，以便在接收方收到部分数据丢失的情况下，通过冗余数据进行修复。
UlpFEC的冗余系数是指添加的冗余数据包的数量，它的大小决定了FEC的纠错能力。通常，冗余系数越高，纠错能力越强，但是传输延迟也会相应增加。
链路上的丢包率是指数据在传输过程中由于网络原因丢失的比例。在WebRTC中，通过监测链路上的丢包率来动态调整FEC的冗余系数。如果链路上的丢包率很低，那么可以选择较低的冗余系数，以减少传输延迟。如果链路上的丢包率较高，那么需要选择较高的冗余系数，以提高数据传输的可靠性。链路上的丢包率可以通过计算发送方与接收方之间的数据包丢失比例来求得。

8. 在webRTC中由浅入深讲一下什么是Jitter Buffer，相应的原理，以及解决的问题，优势劣势，还存在的问题

Jitter Buffer是WebRTC中用于抵消网络延迟和抖动的技术。在WebRTC中，由于网络的不稳定性，接收方可能会在接收数据时遇到网络延迟和抖动，导致数据包的到达时间不稳定。为了解决这个问题，WebRTC使用Jitter Buffer来缓存一定数量的数据包，以平滑延迟和抖动对数据的影响。
Jitter Buffer的原理是，将接收到的数据包存储在缓冲区中，并根据数据包的时间戳进行排序。如果某个数据包到达的时间比预期时间早，则将其立即交付给应用程序。否则，将其存储在缓冲区中，等到与其时间戳相同的后续数据包到达后，再将其交付给应用程序。这样可以抵消网络延迟和抖动对数据的影响，保证数据在接收方的播放中保持平滑。
Jitter Buffer的优势在于可以有效地减少网络延迟和抖动对数据的影响，提高数据的播放质量。它可以根据不同的网络条件动态调整缓冲区的大小，以适应不同的网络环境。缺点在于，Jitter Buffer会增加数据的延迟，可能会影响实时性。同时，由于网络环境的复杂性，Jitter Buffer可能会面临一些问题，如缓冲区溢出、数据包丢失等。
总之，Jitter Buffer是WebRTC中解决网络延迟和抖动的重要技术之一，它可以通过缓存数据包来抵消网络延迟和抖动对数据的影响，提高数据的播放质量。但是，需要注意Jitter Buffer可能会增加数据的延迟，同时可能会面临一些问题，需要在实践中进行优化和解决。

9. 如果某个数据包到达的时间比预期时间早，则将其立即交付给应用程序。否则，将其存储在缓冲区中，等到与其时间戳相同的后续数据包到达后，再将其交付给应用程序。这样可以抵消网络延迟和抖动对数据的影响，保证数据在接收方的播放中保持平滑。为啥？

jitteBuffer的设计是为了解决网络中的抖动问题，即网络延迟的不稳定性。当某个数据包到达的时间比预期时间早，说明网络延迟较低，此时将其立即交付给应用程序可以使应用程序更快地处理数据，提高交互效率。同时，将数据包立即交付给应用程序也可以避免jitteBuffer内缓存的数据过多，从而减少延迟和数据包丢失的可能性。因此，jitteBuffer将早到的数据包立即交付给应用程序是为了最大化网络资源的利用和提高用户体验。

jitteBufferr如果某个数据包到达的时间比预期时间晚,则将其存储在缓冲区中等与其时间戳相同的后续数据包到达后再将其交付到应用程序是为什么

当某个数据包到达的时间比预期时间晚，说明网络延迟较高，此时将其立即交付给应用程序可能会导致应用程序无法及时处理数据，从而影响交互效率。而将其存储在缓冲区中等待后续数据包到达后再交付给应用程序，可以等待网络延迟恢复正常后再进行处理，避免了数据包交付的不稳定性和数据包丢失的可能性，同时也可以提高应用程序的处理效率。另外，根据jitteBuffer的设计，其还可以通过对缓冲区内数据包的排序和调整，来降低网络延迟的不稳定性，从而提高数据的交付效率和用户体验。因此，将数据包存储在缓冲区中等待后续数据包到达后再交付给应用程序，是jitteBuffer设计的重要特点之一，旨在提高网络资源的利用和用户体验。

如果某个数据包到达的时间比预期时间早，立即交付给应用程序可以确保数据包能够按照正确的顺序展示或者播放。因为如果数据包太早交付，它的前面的数据包肯定已经全部接收并处理完毕了，可以肯定这个数据包是正确的，可以直接提供给应用程序使用。

如果数据包到达时间晚于预期到达时间，那么就需要把它存储在缓冲区里，等待与它时间戳相同的数据包到达。这是因为，网络中存在一些不可预知的延迟和抖动，可能导致数据包在传输过程中无法及时到达，如果直接交付给应用程序，可能会影响应用程序的显示和播放效果，引起延迟和卡顿等问题。

因此，按照时间戳排序并缓存数据包，可以抵消网络延迟和抖动对数据的影响，保证数据在接收方的播放中保持平滑。这种方法可以最大化提高数据的传输效率和质量。

10. Jitter Buffer抖动缓冲如何平衡接收延时和卡顿，原理是什么？

Jitter Buffer抖动缓冲在平衡接收延迟和卡顿方面起着重要的作用。它的基本原理是，在网络通信中，数据传输需要时间和资源，可能会出现误差和间隔，从而导致数据包接收的不连续性和抖动现象。抖动是指接收到的数据包之间的时间间隔不稳定，可能会引起卡顿和影响网络通信质量。

Jitter Buffer抖动缓冲的作用是在一定程度上平衡数据包接收的延迟和抖动，保证数据包在正确的时间到达接收方，从而提高通信质量和用户体验。它的工作原理是将接收到的数据包放入缓存中，并按照时间顺序进行排序和处理。当收到数据包之间的时间间隔较短时，Jitter Buffer会延迟一段时间再将数据包输出，从而调整数据包之间的时间间隔，防止数据包之间的抖动现象，减少网络通信中丢包的发生和减少卡顿现象的出现。

需要注意的是，Jitter Buffer的缓冲区大小和调整策略需要根据网络通信的特点和质量进行调整，以使其发挥最佳效果。如果缓冲区大小太小或调整策略不当，可能会导致数据包丢失或实时性差，从而降低通信质量和用户体验。

11. WebRTC如何进行拥塞控制，用到的算法和原理是什么，介绍一下GCC

WebRTC是一种基于网页浏览器的实时通信技术，它支持实时音视频传输和数据传输。在实时通信中，拥塞控制是一个非常重要的技术。拥塞控制能够保证网络带宽不被过度占用，从而保证通信质量。WebRTC通过使用一些算法和原理来进行拥塞控制。

WebRTC使用了**实时传输控制协议（Real-Time Transport Control Protocol，简称RTCP）**来进行拥塞控制。RTCP是一种传输控制协议，它是基于用户数据报协议（User Datagram Protocol，简称UDP）的。RTCP可以让WebRTC应用程序了解网络的拥塞情况，并且根据拥塞情况动态地调整应用程序的传输速率。RTCP通过向发送方编码反馈信息来实现这一点。RTCP反馈信息包括传输速率、丢包率、网络延迟等指标。

WebRTC还使用了一种称为Generic Congestion Control（GCC）的拥塞控制算法。GCC算法采用了TCP拥塞控制算法的一些特征，但是对于多媒体通信做了一些优化。GCC算法是一种基于丢包率的拥塞控制算法，它能够在不减少传输速率的情况下避免过度拥塞。GCC算法使用了一个双阈值的机制来控制拥塞窗口，当网络拥塞程度高时，它会缓慢地减少传输速率，以避免进一步加剧拥塞。

总之，WebRTC通过使用RTCP和GCC算法来进行拥塞控制，以确保通信质量。这些技术可以根据网络状况自适应地调整传输速率和流量控制。

WebRTC使用的拥塞控制机制基于一个名为Google Congestion Control的算法，也被称为BWE（Bandwidth Estimation）。

该算法的原理是，监测数据包的传输延迟和网络丢包率，并根据这些数据调整发送方的传输速率。

具体来说，该算法分为以下主要步骤：

准确地测量网络传输的延迟和丢包率，采用了两个技术：发送端使用预测模型评估网络和接收端引入了测试反馈。

基于漏桶算法，根据接收端的反馈决定发送速率。具体来说，该算法利用漏桶模型在发送端将传输速率限制在预测的上限（核心思想是避免过多的数据流入网络）。

动态调整传输速率，从而在保证数据完整性和最小传输延迟的前提下，充分利用网络带宽，提高传输效率。

具有抗干扰和自适应性，能够优化多个用户之间的网络状态和传输质量，以达到尽可能高的带宽利用率。

综合来看，WebRTC使用的拥塞控制算法和策略，能够智能地监测和调整传输速率，从而使网络和应用程序能够在高质量和低延迟的环境下运行，实现卓越的视频和语音传输效果。
Google Congestion Control（GCC）是WebRTC使用的拥塞控制算法之一，又称为BWE（Bandwidth Estimation），其主要功能是通过控制发送方的数据发送速率，优化网络带宽利用，从而保证网络稳定性，提供卓越的语音和视频传输质量。

GCC算法采用了一系列数学计算方法，来实现网络质量的实时检测和快速响应。其中主要包括以下几个方面：

延迟估计阶段：
在该阶段，GCC采用平滑移动窗口方法，估算网络路径的往返时延RTT（Round Trip Time）。具体来说，发送方传送一小包（COMBO）到接收端，并记录发送和接收时间戳，计算出RTT，并计算移动平均的往返时延MRTT。接收端在回复确认消息时也填充时间戳和序号，以供数据率的估算。

带宽估计阶段：
在该阶段，GCC通过估计网络可用带宽，控制数据发送速率。估算带宽主要基于算法TCPS (TCP-friendly single-bitrate rate control)。其中， 经过简单数学计算，MRTT（时间平滑处理）与PLR（丢包频率）可以得到队列长度（Qloss），从而估算带宽BWE（Bandwidth Estimation）。

$Qloss=\frac{MRTT}{RTTvar}AP/8-SDL. $

$BWE=Min(BWE,Qloss/(MRTT/1000s)).$

其中，MRTT为平均往返时延，$RTTvar$为平均往返时延方差，$A$为TCP窗口大小（当接收窗口均等时，$A=1.22$)，$P$为传输丢失率，$SDL$表示数据包大小的偏移量。该公式中的控制参数主要有$A$和$SDL$，对于传输丢包率较小的稳定网络，可以适当调大$A$，以提高实际带宽利用率。

发送速率控制阶段：
在该阶段，GCC会根据带宽估计结果，以及发送方发送的数据是否得到确认，动态控制数据发送速率。具体来说，如果带宽估计值小于当前的发送速率，则发送速率逐步降低；如果带宽估计值大于当前发送速率，就要逐渐增加发送速率，直到最大限制值。

动态调控：
如果当前的数据包发送速率未被确认，则发送包速率会逐渐下降，直至发生突发丢包，以响应通信链路拥塞情况。此时，发送速率将快速降低，直至数据包的接收得到确认。在网络进入平稳状态之后，发送速率逐步提高，直到达到实际可用带宽的最大值。

综上所述，GCC算法通过对网络路径时延、丢包频率、带宽估计

GCC算法（Generic Congestion Control）是WebRTC中用于拥塞控制的一种算法。GCC算法受到TCP拥塞控制算法的启发，但是针对多媒体通信做了一些优化，能够更好地适应实时音视频通信的需求。

GCC算法的核心是基于网络丢包率进行拥塞窗口控制。假设t时刻发送端发送了W个数据包，而在一定时间周期内，这些数据包中有L个被网络丢失（在最新的WebRTC文档中，L可以是丢包数或丢包率）。GCC算法在每次t+1周期开始前，会根据L和阈值计算新的拥塞窗口，以此来控制发送端的传输速率。

算法具体步骤：

通过RTCP（Real-time Transport Control Protocol）获取网络丢包率L。

根据以下计算公式求得下一个周期内的拥塞窗口大小：

$$W_{new}=\{\begin{array}{llcc}{W}_{old}+\alpha & \text{if L < tlow}\max \left(L,tlow\right)\cdot W_{old}& \text{if tlow}\le L\le thigh\frac{W_{old}}{2}& \text{if L > thigh}\end{array}$$

其中，$W_{old}$是上一个周期内的拥塞窗口，$W_{new}$是新的拥塞窗口，$\alpha$是每个周期增加的拥塞窗口的最大值，$L$是网络丢包率，$tlow$和$thigh$是两个阈值，根据网络丢包率的不同取值，选择相应的计算方式：

如果L小于$tlow$，则拥塞窗口每次增加$\alpha$。
如果$tlow\le L\le thigh$，则拥塞窗口根据网络丢包率动态地调整。
如果L大于$thigh$，则拥塞窗口减半。
同时，$\alpha$的值也会根据网络拥塞情况实时调整。如果丢包率很高，发送端会根据拥塞窗口大小降低自己的传输速率。

根据新的拥塞窗口大小调整发送速率。
总的来说，GCC算法是一种基于网络丢包率的自适应拥塞控制算法，能够动态地调整传输速率和拥塞窗口大小，最大程度地避免网络拥塞。

12. 使用RTP进行多媒体内容的传输时，有以下几种常用的反馈机制

当使用RTP进行多媒体内容的传输时，有以下几种常用的反馈机制：

NACK（否定确认）：NACK用于通知发送者有丢失的数据包，当接收方检测到有数据包丢失时，会发送NACK数据包给发送方, 以便发送方能够重新发送丢失的数据包给接收方。

PLI（图像丢失指示）：PLI用于视频流传输，通知发送者有图像丢失。当接收方检测到图像未到达或因出现错误而被丢弃时，会发送PLI数据报文给发送方。发送方接受到该信息后，可以选择将下一个图像作为内部编码帧传输，这可以取代完整图像中的整个数据块，而不仅仅是更改，从而修复丢失并保持视频流的质量。

REMB（接收端预估的最大比特率）：REMB用于帮助发送方确定传输数据的合适比特率的反馈机制。接收方将包含接收端估计的最大比特率的信息发送给发送方。这种反馈使发送方能够调整编码速率，以防止网络拥塞或超载接收方。

接收方报告：接收方报告（RR）是RTP中用于提供反馈信息，以帮助发送方维护传输质量的机制。接收方报告向发送方汇报有关已接收、丢失和丢弃的数据包数，以及接收每个数据包所需的延迟量等性能统计信息。发送者可以利用这些反馈信息进行实时分析，以优化流媒体传输的性能，包括调整编码比特率、传输速率和其他参数。

13. 讲一下NACK, PLI, REMB,Receiver Report是干嘛用的

NACK，代表“Negative Acknowledgement”，所以当一个数据包到达时，接收端如果发现这个包有错误，它会发送一个NACK给发送端，告诉它需要重新发送有效数据包。因此，NACK是用于识别和纠正传输错误的机制。

PLI，代表“Picture Loss Indication”，是在实时视频通信中使用的信号，通常会在视频帧未正确接收时由接收方发出，告诉发送方它需要发送一个全新的视频帧，以便接收方能够正常显示视频内容。

REMB，代表“Receiver Estimated Maximum Bitrate”，用于在多媒体流中调整带宽。它告诉发送方正在接收端网络中估计的最大带宽，发送方可以根据这个信息动态调整其发送的数据流量以匹配接收端的带宽。

Receiver Report（接收端报告）是接收端向发送端发送的一个用于记录关于数据包传输的一些信息的报告。通常包括接收了多少个数据包，发送的时间戳信息，丢失的数据包数量等等。发送方可以根据这些信息来动态优化自己的发送方式，以更好的适应接收端。

14. NACK, PLI, REMB,Receiver Report和RTCP有啥关系

NACK, PLI, REMB,Receiver Report实际上是RTCP协议中的一些机制或报告。RTCP指实时传输控制协议，它是协议栈中用于控制传输质量的协议之一，在实时音视频传输中扮演着重要的角色。

RTCP主要用于在实时音视频通信中发送控制命令和反馈信息。 NACK是用于纠正传输错误的反馈机制之一，PLI是用于指示需要重新发送视频帧的反馈机制之一，REMB是用于告知发送端当前接收端处理传输的能力的反馈机制之一，而Receiver Report是接收终端向发送终端发送的包含一些统计信息的报告信息之一。

因此，这些机制和报告都是RTCP协议的一部分，它们旨在提高实时音视频通信的效率和质量。

15.RTCP还有什么关键内容

除了NACK、PLI、REMB和Receiver Report，RTCP还包括其他一些关键内容，如：

Sender Report（发送端报告）：发送端周期性向接收端发送包含有关其发送速率、时间戳等信息的报告。

BYE消息：用于通知对方该流的结束。

Source Description（源描述）：提供关于媒体源的信息，如名称、位置、媒体类型等。

SDES（Session Description）：提供关于本次通信相关方的信息，如会话名称、媒体类型、会话地址等。

Feedback Messages（反馈消息）：用于在通信中向对端提供拥塞和质量控制反馈，如ACK、NACK、PLI、REMB等反馈消息。

Reception Quality Feedback（接收质量反馈）：提供有关接收端接收质量的反馈信息，如丢包率、抖动等等。

这些信息用于建立、维护和优化音视频传输会话。通过收集和分析这些反馈信息，可以做出相应的调整，并确保在使用实时音视频通信时获得更好的用户体验。

16 往返时间RTT

Round Trip Time （往返时间）- 一种衡量网络延迟的指标，表示发送数据包从一个设备到达目标设备，再返回源设备所需的时间。RTT指的是“Round-Trip Time”，是指从发送数据到接收数据再返回的时间延迟。具体而言，它是指客户端向服务器发送一个请求数据包，服务器接收到后，处理完请求后再返回响应给客户端，这整个过程所需要消耗的时间。

往返时间RTT是测量客户端和服务器之间网络通信延迟的重要指标，它可以用来评估网络连接的质量和响应速度。RTT时间越短，网络传输速度越快，用户体验也会更好。

例如，一个测量结果为100毫秒的RTT意味着从客户端发送请求到收到响应并返回的时间为100毫秒。RTT的值可以受到许多因素的影响，如数据传输速度、网络拥塞、网络负载等。

17 I帧、P帧和B帧

I帧、P帧和B帧都是视频编码中的重要帧类型，各有其含义和作用。

I帧：I帧代表“关键帧”（keyframe），也称为“帧间无压缩帧”，是视频流中的独立帧。I帧可以使视频解码器从该帧开始渲染图像，而不需要依赖其他帧。因此，I帧是视频中的基础点，它以完全未压缩的方式提供视频内容，并为音视频的同步提供了时间戳。

P帧：P帧代表“预测帧”（predictive frame），也称为“前向预测帧”。P帧编码时，只编码先前的一个I帧或P帧与当前帧之间发生变化的部分。P帧不是原始的独立帧，它通过对之前的参考帧进行预测来编码当前帧，所以P帧的时间戳是相对于之前的I帧或P帧来计算的。

B帧：B帧代表“双向预测帧”（bidirectional predictive frame），它可以通过前后的P帧（或I帧）进行预测编码。B帧是使用最多的编码类型，因为它可以最大程度地压缩视频数据，减少了传输视频需要的带宽。B帧的时间戳是相对之前的P帧或I帧和之后的P帧来计算的。
丢失I帧会导致视频解码器无法正确解码帧序列，整个视频可能无法正常播放。丢失P帧会导致视频质量受到影响，可能会产生图像失真和同步问题。丢失B帧则可能会导致视频质量下降和压缩效率降低，可能会导致视频卡顿或不流畅。因此，在视频编码和传输过程中，要避免丢失I帧、P帧和B帧，以保障视频的正常播放。

18.介绍一下Simulcast 和 SVC，两者干嘛用的原理，区别联系以及优缺点

Simulcast和SVC是视频传输中采用的两种不同的技术，它们都能够通过不同方式提高视频传输的质量和效率。

Simulcast是指一种将不同的码率和分辨率的视频同步传输的技术。该技术的实现是将同一段视频同时编码成不同的分辨率和码率的多个版本，在传输过程中根据网络带宽情况选择最合适的版本进行传输。采用Simulcast技术可以在不同的网络条件下提供最佳的视频质量和效果。但是Simulcast技术需要更多的带宽和更高的编码复杂度，因此成本更高。

SVC（Scalable Video Coding）是一种具有可扩展性的视频编码技术。它是一种递归分层的编码方式，将视频分成多个层次，每个层次都包含着前一个层次的所有内容，并添加了更多的详细信息。在传输过程中，可根据网络带宽和设备能力的不同，选择传输多层中的一部分。这使得SVC技术能够为不同的设备和网络条件下提供最佳的视频质量和效率，很适合视频会议和移动设备等场景。但SVC技术需要更高的编码复杂度和更多的计算资源来实现，因此实现成本更高。

虽然Simulcast和SVC在实现方式上不同，但它们都能够提高视频质量和效率。Simulcast相对SVC来说更简单，在网络条件稳定的情况下效果很好。SVC则具有更好的适应能力，能够根据网络条件和设备能力的变化来选择最佳的传输方式。选择使用哪种技术主要取决于具体的使用场景和需求。

19.深入浅出介绍一下SVC（Scalable Video Coding）

SVC（Scalable Video Coding）是一种视频编码标准，旨在实现视频数据的可伸缩性。这个标准最初由几家公司和组织共同开发，其中包括欧洲电信标准化组织（ETSI）和国际电信联盟（ITU）。

SVC使用了一种多分辨率编码的方法，即将视频分成多层，并在每一层中编码不同的细节级别。这使得视频能够在不同的带宽和传输质量条件下进行传输。例如，在网络带宽较低的地区，只需要发送低分辨率的视频层，而在带宽更高的地区，可以发送更高分辨率的视频层，从而提高视频质量。

SVC还支持视频数据的多个版本，这些版本可以在码率和质量之间进行权衡。这是通过在每个层中使用不同的量化参数来实现的。

值得注意的是，与其他视频编码标准相比，SVC的性能损失非常小，同时具有更好的错误恢复和网络拓扑灵活性。
Simulcast和SVC都是视频传输技术，但它们之间存在一些区别。

Simulcast是一种传输视频的方法，即将同一信号的不同版本通过不同的路径同时传输给多个接收方设备，每个版本都是不同的分辨率和比特率。这意味着对于每个接收方设备来说，都会使用最佳的视频版本，从而提高了视频的观看体验。 Simulcast通常在需要同时发送给多个接受者的场景下使用，如视频会议、实时直播等。

SVC（Scalable Video Coding）是一种视频编码标准，旨在提供视频的可扩展性。它可以将视频划分为一组分层，每个分层由不同的编码参数编码，以提供不同的解码质量。这使SVC能够适应不同的网络宽带和媒体设备约束下的多种视频传输应用场景，比如视频会议、网络视频直播等。

因此，Simulcast和SVC都是为了提高视频传输效果而产生的技术，Simulcast主要解决多接收者的场景，而SVC主要解决多种网络和接收设备场景下的视频传输问题。

20. SVC 的时域分层会影响帧率，容易出现卡顿，为什么

SVC (Scalable Video Coding) 的时域分层会将视频数据分成不同的层，使得每个层分别用不同的编码参数进行编码，以便于在不同的网络带宽和接收设备限制下进行传输和解码。

然而，这种分层设计往往会使得视频帧在不同的层之间出现重叠和重复，从而大大增加了视频解码的复杂度，加大了解码的时间延迟。另外，由于时域分层的缘故，有些帧的时间间隔可能比较短，而有些则可能比较长，这可能导致视频帧率的不一致性，从而影响到视频的流畅播放，并很容易导致卡顿现象。

因此，SVC的时域分层需要针对不同的网络和设备，合理设置帧率和编码参数，以保证视频传输的质量稳定，并减少卡顿现象的出现。如果帧率不一致，音视频同步出现问题，需要进行适当的音视频同步控制，以保持良好的观感效果。

21. 什么是帧率

帧率（Frame Rate）是指视频显示设备在单位时间内所显示的静态图像（帧）数目。一般来说，帧率用每秒显示的帧数 (fps，Frames Per Second) 来表示。常见的视频帧率有24fps，30fps和60fps等。

帧率是衡量视频质量和流畅度的重要因素之一。帧率越高，视频的运动细节展示得就越流畅，但同时需要的处理能力、带宽和存储空间也就越大。而低帧率则会导致视频的运动不连续，出现跳帧、卡顿等现象，影响用户的观感体验。

在视频制作和后期制作中，帧率可以根据不同的需要选择不同的数值进行设置，比如电影通常以 24fps 的帧率进行制作，而视频游戏则需要更高的帧率来提高游戏体验。在视频处理和转码时，也需要注意合理设置帧率，以保证视频传输的流畅性和质量。

22. 什么是码率

码率（bitrate）是指数字视频或音频信号的传输速度，通常以每秒传输的位数（unit/s）或者每秒传输的比特（bit/s）来衡量。更高的码率通常可以提供更高质量的音视频内容。

帧率（frame rate）是指视频播放中每秒钟呈现的画面数，通常以每秒钟的帧数（frames per second，FPS）来表示。更高的帧率可以使视频播放更加流畅自然，但是也需要更高的计算资源支持。

帧率就是视频每秒刷新的次数，如果帧率高，看起来就很流畅；码率就是视频每秒传输的数据量，如果码率高，画面和声音的质量就更好，并且可能需要更高配置的设备播放。换言之，帧率主要影响视频播放的流畅度，码率主要影响视频播放的清晰度和保真度。