【音视频第3天】实时音视频会议场景下 QoS 策略

Magic_o

已于 2023-04-11 10:17:01 修改

阅读量801

点赞数

分类专栏：音视频文章标签：音视频实时音视频网络

于 2023-03-29 19:33:40 首次发布

原文链接：http://www.52im.net/thread-2840-1-1.html

版权

音视频专栏收录该内容

20 篇文章 11 订阅

订阅专栏

参考
网络 QoS 的平衡之道——音视频弱网对抗策略介绍
实时音视频会议场景下 QoS 策略
参考：
技术分享| 视频传输Simulcast与Svc ：https://juejin.cn/post/7130466929575198727
http://www.52im.net/thread-1746-1-1.html
http://www.52im.net/thread-3079-1-1.html

抗丢包

丢包的影响：视频帧往往是拆成一个个分组包进行传输，当网络发生丢包时，接收端无法成功组帧，不仅仅影响这一帧的数据解码，从这一帧开始的整个 GOP 都将无法解码显示，用户看到的画面将出现卡顿，直到完整的 I 帧到达接收端才能恢复画面。

FEC/RED

FEC 策略，其作用效果是实时观测丢包率的变化，做丢包率的预估，实时产生冗余数据来对抗可能出现的丢包。
优点：基本不需要牺牲时延，可以做快速的丢包恢复。
缺点：依赖于丢包预测的准确度，过高的冗余会造成带宽流量的浪费，甚至挤压正常的信源的传输，导致一个不健康的信道传输状态。

在发送端的时候额外发一些数据，接收端在检测到有丢包的时候，就把这些冗余的数据进行丢包恢复。延时低，但是会额外占用带宽，如果带宽有限，那会挤压视频的原始码率。影响FEC的丢包恢复能力的因素：冗余数据数量、分组大小。
这是一种== 用码率流量来交换抗丢包能力==的技术。
应该重点关注，如何设计冗余策略和分组大小
冗余算法，关注冗余算法的两个层面

冗余度在算法层面是否支持动态调整。还原的成功率跟我们冗余算法的冗余度大小有关，因为网络丢包是复杂多变的，固定冗余度的算法要么会带来带宽的浪费要么恢复效果不理想。
计算复杂度能否满足服务器性能要求。分发的高效，一旦 FEC 的算法复杂度过高，在高并发高 I/O 吞吐的情况下，势必会降低服务器并发性能，甚至会引入额外的端到端的 delay。

丢包率

平均 RTT 内的丢包率：指在一个固定时间内（通常为一秒钟），根据网络延迟和传输情况计算出平均往返时间（RTT），然后统计在这个时间段内发送的数据包中由于网络因素丢失的数据包所占的比例。这个丢包率考虑了网络传输的稳定性和延迟情况。

去抖动的丢包率：指为了解决网络抖动带来的影响，采取一些措施来确保数据不被丢失。通常会使用抖动缓冲区技术，该技术会将接收到的数据暂时存储在缓冲区中，并在一段时间后再进行处理，以确保数据的完整性。去抖动的丢包率则是指在这个过程中由于缓冲区溢出等原因导致的数据包丢失的比例。

跟 NACK 请求相关的丢包率：指在网络传输中经常采用的 NACK 回传技术。在这个机制中，接收方会在发现缺失数据包后向发送方发送 NACK 请求以请求重新发送数据包。因此，当发送方在接收到 NACK 请求后重新发送数据包时，如果这个过程中存在由于网络原因导致的数据包丢失，则会导致丢包率的增加。

重传超时时间相关的丢包率：指在网络传输中，由于不同节点之间的延迟和网络拥塞等原因，可能会造成数据包的发送失败，因此会设置一个重传超时时间。如果在这个时间段内没有收到对方的 ACK 确认包，则会重新发送数据包。这个丢包率是由于重传超时时间设置得过长或过短导致的

在对丢包率进行采样观测和预估时，需要根据关心的阈值（即重要性和影响程度），将数据按照不同的区间进行分类，并针对每个区间进行标本采样。这样可以更有效地观测和预估不同区间中的丢包率，从而更好地掌握网络传输的稳定性和延迟情况。

例如，如果一个网络应用的关键数据包丢失率超过了1%，则需要对这个关键数据包的丢失率进行更频繁的观测和预估，以便及早发现和解决问题。而对于其他非关键数据包的丢失率，则可以采用更宽松的阈值和较少的观测次数进行采样，以节省成本和提高效率。因此，根据不同的关心程度和阈值，需要对丢包率进行不同的细分观测和预估，以达到更好的效果。

重传

丢包重传策略，解决的是当前丢包已经发生，需要做短暂的时延牺牲（即做丢包重传的时候会造成 Jitter），来对抗丢包。

优点：即不会实时的占用信道带宽，
缺点：引入的时延Delay，一些不当的 NACK 请求策略的设计甚至会造成流量尖刺。流量尖刺（Traffic Spike）是网络流量的突然增加，在很短的时间内产生了大量的流量。

接收端检测到丢包反馈给发送端丢包信息，进行相应数据重传。每隔1个RTT对同一个包发起重传请求，直到接收到包。如果双向丢包，可以每隔1/2个RTT对同一个包发起重传请求，防止重传请求包也丢了，发送端对同一个 seq 的包响应间隔按照 RTT 间隔控制，防止重传码率过多浪费。
RTT是往返时延，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
好处：码率利用率高
缺点：会引起额外的丢包恢复抖动从而增大延时
RTT越大重传恢复效果越差
重传的码率不能浪费，也就是重传的时间间隔要控制一下，减少重传的次数，要看一下会不会容忍乱序

PLC

PLC（Packet Loss Concealment，丢包隐藏）技术被广泛应用于抗丢包。PLC技术的核心思想是通过在丢失的数据包前后插入同音量、相似频谱、持续时间较短的音频包，让音视频可以平滑过渡，从而减少用户的体验负担。
mediasoup中使用的webrtc-audio-processing(webrtc-apm)音频处理库，就提供了PLC(丢包隐藏)功能。

webrtc-apm的PLC模块采用的是基于同音域平均的算法，当检测到音频丢失的时候，从已有的音频数据中找到与丢失的音频数据最接近的音频帧，然后将其用于填补丢失的数据，使得音频传输可以平滑进行，避免因丢包导致的明显信号中断和声音断续。

该PLC技术可以实现对较小数量的丢包进行较有效的修复，从而提高音频的稳定性和质量。在与其他损失恢复技术，如前向纠错等相结合的情况下，可以进一步增强mediasoup在各种网络环境下的稳定性和效率。

抖动

引起抖动的原因：发送数据抖动，网络传输抖动，接收丢包恢复抖动。
Jitter Buffer缓冲区负责消除抖动，提供稳定的解码帧率，会带来延迟。

Jitter Buffer

因为视频是按帧解码播放，所以 Jitter Buffer 的延时计算也是是按视频帧为最小计算单元，而不是按视频包，输入 Jitter Buffer 的参数是每一帧视频数据的抖动。造成帧抖动的因素有很多，有采集抖动、编码抖动，发送抖动，网络抖动，丢包修复引入的抖动等，总之，在解码之前的任何环节引入的数据抖动会汇总到 Jitter Buffer 模块处理抖动消除。
发挥重传的抗丢包能力需要有 Jitter Buffer 的拉伸策略。
== 延时交换抗丢包能力 ==。
最低的缓冲延时代价消除数据抖动，提供流畅的播放帧率

Neteq

Neteq 的全称为 “Network Adaptive Audio Playout”，也就是网络自适应音频播放技术。

Neteq (网络等待队列)是WebRTC中的一个用于抗抖动的重要技术，它采用了延迟抖动缓冲区和时钟校准等技术来解决网络抖动带来的问题。Neteq通过以下几个方面实现抗抖动：

延迟缓冲区：Neteq在接收端设置一个缓冲区，将需要播放的音频数据预先存储一段时间，一旦播放延迟到达一定程度就播放这些缓存数据，使音频内容更加连贯。

时钟校准：Neteq会定期将音视频数据同步到本地时钟，校准本地的系统时钟。通过这种方式能够保证播放音频数据的时候不会出现时间上的偏差，同时有效防止音视频播放的抖动现象。

基于声音模型的处理：Neteq通过对声学原理的应用规避网络状况、耳机类型等影响音频数据的因素，对音频数据进行优化。这种处理方式能够避免一些不必要的干扰，提高音频传递质量。

综上所述，Neteq技术为WebRTC实时音视频通信提供了很好的抗抖动能力，能够有效提高音视频通信的质量和用户体验。

两者的区别

Neteq和jitter buffer都是用于解决网络抖动问题的技术，它们的主要区别如下：

1.工作原理
Jitter buffer会对收到的音视频数据进行一定时间的缓冲和排序，以减少数据丢失和抖动产生的影响，然后将有序的数据传递给后面的模块进行处理；

Neteq在jitter buffer的基础上，增加了更为灵活的丢失恢复机制，通过声音模型方案等多种技术，尽可能地恢复音视频数据的准确性和连贯性，从而提高音视频的质量和体验。

2.适用场景
Jitter buffer通常用于对音视频的网络传输进行缓存和排序，比如在网络环境不稳定，通信双方的带宽、时延等存在不确定因素时，就需要使用jitter buffer技术；

Neteq不仅包含了jitter buffer的基本功能，同时融合了自适应PLC技术等更为先进的音频处理技术，能够有效解决音视频实时通信中出现的抖动和丢包问题。

3.性能和使用领域

Jitter buffer的主要缺点是使用较为简单，可适用于多种音视频应用领域，但是对于一些网络质量较差、延迟较高的环境，效果可能会下降明显；

Neteq作为一种比较先进的音频处理技术，具有更灵活、更高效、更稳定的特点，适用于高清晰度音视频的实时传输、在线教育、远程医疗、在线游戏等多个领域。

综上所述，Jitter buffer和Neteq都是对抗抖动的技术，但是在实际应用中，Neteq可以提供更加灵活、智能的解决方案，可以为网络实时音视频通信提供更好的服务及体验。

mediasoup内的jitter buffer 和 Neteq 技术

mediasoup 内置了 jitter buffer 和 Neteq 技术，用于解决音视频传输过程中的网络抖动和丢包等问题。具体地，mediasoup 通过内置的 RTP 接收器和音视频插件，支持自适应 jitter buffer，可以根据实时的网络抖动情况，自动调整 jitter buffer 的大小和缓冲时间，来确保接收到的音视频数据的连续和正确性。

同时，mediasoup 也实现了 Neteq 技术，支持延迟缓存和排队，使用声学模型处理音频数据，智能恢复由于网络抖动和数据丢失导致的音频损失，以确保音频的质量和连贯性。

除此之外，mediasoup 还支持音频处理库 webrtc-audio-processing，该库提供了多种用于实时音频处理的技术，包括自适应 PLM（Packet Loss Concealment），动态范围压缩、时域放大、回声消除等等，这些技术与 jitter buffer 和 Neteq 相结合，可以提高 mediasoup 在音视频通信中的稳定性和效率。

综上所述，mediasoup 在音视频通信中广泛运用 jitter buffer 和 Neteq 技术，以及先进的音频处理技术，可以帮助 mediasoup 在不稳定和高延迟的网络环境中实现高效、稳定和质量较高的音视频传输。

其他

强制I帧

“强制I帧”可以指定需要发送关键帧（I帧），I帧是视频编码中关键的一种帧类型，每隔一段时间或者发生剧烈变化时需要发送一个I帧，以确保视频质量。

在WebRTC中，强制I帧意味着在开始请求或终止请求前，强制生成一个I帧。这通常用于解决视频会议中质量差的问题，例如视频画面出现模糊或者卡顿现象。发送I帧可以强制使接收方的解码器重置，并从下一个I帧开始解码，从而解决这些问题。

要在WebRTC中强制I帧，可以使用RTCRtpSender接口的getParameters方法获取发送器参数，然后将forceSendOnlyPicture属性设置为true以强制生成I帧。

长参考帧

长期参考帧技术即选择参考帧技术，是一种网络模块和编码器共同配合完成的技术。在 RTC 场景下一般的编码参考策略是向前一帧参考，因为参考的距离越近压缩效果越好，出于实时的考虑编码只有 I 帧和 P 帧，没有 B 帧。而长期参考帧是一种可跨帧的参考帧选择策略，这种策略打破了传统的向前一帧的参考的规则，可以更加灵活地选择参考帧。

长期参考帧策略的目的是在有丢包的场景下，接收端不需要等待丢包恢复也能继续显示画面，其最大的好处是低延时，不需要等待重传恢复，但是带来了压缩率的牺牲，在相同码率下表现为图像质量的牺牲，但是这种牺牲和收益的交换在某些场景下是值得的。此外，常态的长期参考帧技术在抵抗突发丢包能力上有很大提升，当网络突然出现丢包， FEC 和重传的立即恢复效果一般是比较差的，尤其是有基础 RTT 的网络。而长期参考帧可以饶过丢失的帧，利用丢失帧之后任何一个恢复的帧进行解码显示，从而提升突发丢包时的流畅性。

根据长期参考帧的特点和目的，实现长期参考帧技术应用需要有接收端侧反馈信息，编码器根据接收端反馈的帧信息选择参考帧编码，在有丢包的场景下，接收端通过短时的帧率牺牲将很快恢复画面。由于存在接收反馈，高 RTT 时反馈延时较大将会导致参考距离变大，而参考距离超出了编码器的编码缓冲限制将会导致编码找不到参考帧，所以长期参考帧比较适合低 RTT 场景。在多人会议场景中，下行人数太多也会制约长期参考帧的参考帧选择。
在这里插入图片描述

综合来看，长期参考帧适合 1V1 的通信场景，适合低 RTT 伴随丢包或者拥塞的弱网场景，这样的场景下长期参考帧比传统的向前一帧参考有更好的实时性和流畅性，同时结合重传和 FEC 的抗丢包贡献，其抗弱网能力将大大提升。

ANA

VQC

网络拥塞控制

突发丢包，突发抖动，不及时预测拥塞降低发送量，接收端会卡顿。。。
拥塞控制

大小流

大小流是指上行同时传输两条不同分辨率的流.
媒体服务器可以根据下行实际的带宽情况转发相应质量的流，如果带宽足够转发高质量的大流，带宽不足转发低质量的小流。

SVC

SVC（Scalable Video Coding）是一种视频编码标准，它可以根据不同的带宽和设备能力，将视频流编码成多种分辨率和比特率下的版本。在SVC中，视频流是分割成多层编码，每一层视频码率、分辨率和质量不同，每层都可以独立地解码。这使得视频流在网络带宽受限或设备处理能力较低的情况下，用户也可以获得较高的视频质量。SVC适用于要求适应不同网络状态或设备能力的实时视频流。

Simulcast

Simulcast直译过来是多播的意思，其实就是一个客户端发送多条不同码率大小的流，为了达到这样的效果，客户端会对同一帧画面进行不同分辨率的编码来达到降低码率的目的。
视频发送端同时向服务端SFU发送多个不同分辨率的视频流（1080p、720p或360p）。SFU接收到这三个码流后，根据终端性能选择其中一个码流转发给终端。
但是Simulcast也有一定的缺陷,虽然Simulcast可以解决下行带宽不足时降码率的需求，但是在应用的过程中存在比较致命的缺陷：
A.上行带宽的增加，我们在上行时会多发送多条流，导致大量的带宽浪费。而为了应对几个下行网络较差的用户而牺牲上行用户的带宽资源，这样的做法有待商榷；
B.下行可供的流选择性很少，及时使用3条流同时传输的方式，在移动网络这样复杂多变的网络条件下，上下调整的幅度将会是巨大的，会造成不好的用户体验，相比SVC适用性较差

三者区别

在视频通信中，为了适应不同的网络环境和终端设备，我们通常需要对视频进行编码和压缩，以便在传输过程中占用更少的带宽和资源。这时就会出现不同的编码和传输方式，包括大小流、SVC和simulcast等。

首先，大小流是一种编码方式，它将原始视频按照不同的分辨率和码率分别编码成多个版本，然后根据网络状况和设备能力选择合适的版本进行传输。这样可以提高视频的适应性和质量，但会增加编码和传输的复杂度和延迟，同时也需要更多的存储空间。

其次，SVC（Scalable Video Coding）是一种编解码标准，它允许将视频序列分成多个层次，每个层次可以单独进行编码和传输，也可以根据需要进行组合和解码，从而实现不同的码率和分辨率。这样可以有效地适应不同的网络环境和设备能力，同时也可以提高视频的重传、冗余和故障恢复能力。

最后，simulcast是一种传输方式，它将原始视频同时复制成多个版本，然后分别通过不同的网络路径进行传输。这样可以提高视频的可靠性和稳定性，同时也可以减少传输延迟和丢包率。但相较于大小流和SVC，simulcast需要更多的带宽和传输资源，并且在处理和合成多个版本时也会增加一定的计算和存储成本。

大小流和simulcast的区别

大小流是一种编码方式，将同一份视频分别编码成多个不同分辨率和码率的版本，以适应不同的设备和网络环境，这些版本会在传输时选择其中之一进行传输，提供更好的视频质量和适应性。大小流是通过对原始视频进行不同的编码来生成多个版本的视频流，每个版本都已经是在源端生成的独立的视频流，对于每个设备在播放时都有不同的流选择。

Simulcast是一种传输方式，它将同一份源视频复制成多份，在多个网络传输，从而增强传输的稳定性和可靠性，但它不提供不同版本之间的视频质量调节。而Simulcast是通过将一份源视频复制成多份视频流进行传输，每份流都是从同一件源视频中复制而得。在Simulcast传输过程中，同一份视频会被复制成多份视频流进行传输，这些流之间存在细微差异，但相互之间是独立的，可以被分别传输或合并在一起传输。

因此，Simulcast适用于需要提高视频的可靠性和稳定性的应用场景，例如在视频会议和实时直播中应用。而大小流的应用场景更多的是在带宽资源受限的情况下，提供更多的视频流选择，以达到更好的视频质量和适应性。

为了更好理解，可以将Simulcast直接理解为视频流的“重复复制”，而大小流则是“编码生成不同的流”。两者的区别在于：Simulcast是将源视频完整复制 n 多份，而大小流是基于源视频生成不同码率、分辨率的多个视频流，增强适应性，两者存在的主要需求和实现都是不同的。

Simulcast 是将源视频进行不同分辨率和比特率的编码，同时在不同的网络带宽和设备屏幕分辨率下选择合适的流进行传输，也就是说每个流都是一个完整的视频。

而大小流则是通过将源视频分割成多个小的视频块，这些小块可能会因为分辨率、码率、帧率等参数的不同而有所不同。较低分辨率、较低码率、较低帧率等参数的小视频块被称为小流（low bitstream），而较高参数的小视频块被称为大流（high bitstream）。在传输的过程中只传输必要的视频块，来适应不同的设备分辨率和带宽需求。换句话说，大小流不是所有流都是完整的视频，仅仅传输每个视频块的内容。

这两种技术都可以提高视频流的可用性，但是大小流更为灵活，能够更好地应对复杂的网络状况，而 Simulcast 在实现上有些复杂，但可以提高视频流的稳定性和同步性。

大小流和SVC的区别

SVC（Scalable Video Coding）是一种视频编码技术，它将视频分成多个层次，每个层次的视频码流都相互独立，可以被解码成独立的视频流进行传输。而大小流则是一种适应性视频编码技术，它能够根据终端设备的不同分辨率和带宽情况，动态调整视频流的分辨率和比特率。

两者的区别在于视频层次的不同。SVC 把视频分成多个层次的视频流，每个层次的视频流都独立，可以根据需求进行解码和传输；而大小流则是根据分辨率和带宽的不同需求，将同一个视频分成多个不同分辨率和比特率的流。另外，SVC 技术还可以根据客户端设备能力与网络状况进行动态调整，而大小流则不具备此功能。

因此，SVC 在实际应用中，利用编码层次的思想，进行不同层次的值得编码和传输，能够实现更加丰富的视频传输应用，例如视频会议、远程医疗、监控等场景；而大小流则适用于需要根据终端设备和带宽环境优化视频传输的场景，例如在线视频服务、直播等。

指标

用 QoE 表示用户在接收端的主观体验，而 QoS 是指通过一些量化指标衡量网络的传输质量并提供优质网络的服务。

分段QoS

为此针对于这种多人会议场景，需要制定上下行独立的 QoS 传输方案，去保障上下行的传输质量。

服务器端具体实践

上行

服务器端作为接收端，丢包重传请求（ NACK）、前向纠错（ FEC）、关键帧请求（ PLI/FIR）、接受信息反馈（ FeedBack）
建立网络状态的观测器，其主要监控当前网络的丢包率、抖动、时延、拥塞状态。ARQ 手段先行， FEC 手段做兜底。
具体的意思是我们会根据预设的最大端到端 Delay（这个 Delay 跟用户设置模式有关，可以动态调节），再根据观测器观测出来的相关网络指标去计算 ARQ 的成功率，剩下的失败率由 FEC 做兜底。

下行

服务器掌握了具体的控制权

设计出下行接收端可弹性接收流组合的方案。
准确的探测出用户真实的下行带宽。
制定合理的带宽分配方案。
进行流量的平滑发送以及拥塞控制
看不太懂啦，放过自己！！！！！！

音视频常用的定义

1.视频帧

帧，是视频的一个基本概念，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。

2.帧率

帧率，即单位时间内帧的数量，单位为：帧/秒或fps（frames per second）。如动画书中，一秒内包含多少张图片，图片越多，画面越顺滑，过渡越自然。

帧率的一般以下几个典型值：

1）24/25 fps：1秒 24/25 帧，一般的电影帧率；
2）30/60 fps：1秒 30/60 帧，游戏的帧率，30帧可以接受，60帧会感觉更加流畅逼真。

85 fps以上人眼基本无法察觉出来了，所以更高的帧率在视频里没有太大意义。

3.色彩空间

这里我们只讲常用到的两种色彩空间。

1）RGB：RGB的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B三种基础色，可以混合出所有的颜色；
2）YUV：这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。

早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV两种色度，形成现在的YUV，也叫YCbCr。

1）Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量；
2）U：蓝色通道与亮度的差值；
3）V：红色通道与亮度的差值。

采用YUV有什么优势呢？
人眼对亮度敏感，对色度不敏感，因此减少部分UV的数据量，人眼却无法感知出来，这样可以通过压缩UV的分辨率，在不影响观感的前提下，减小视频的体积。

4.音频是什么？

4.1基本知识

音频数据的承载方式最常用的是脉冲编码调制，即 PCM。

在自然界中，声音是连续不断的，是一种模拟信号，那怎样才能把声音保存下来呢？那就是把声音数字化，即转换为数字信号。

我们知道声音是一种波，有自己的振幅和频率，那么要保存声音，就要保存声音在各个时间点上的振幅。

而数字信号并不能连续保存所有时间点的振幅，事实上，并不需要保存连续的信号，就可以还原到人耳可接受的声音。

根据奈奎斯特采样定理：为了不失真地恢复模拟信号，采样频率应该不小于模拟信号频谱中最高频率的2倍。

根据以上分析，PCM的采集步骤分为以下步骤：
模拟信号 -> 采样 -> 量化 -> 编码 -> 数字信号

4.2采样率和采样位数

采样率，即采样的频率。

上面提到，采样率要大于原声波频率的2倍，人耳能听到的最高频率为20kHz，所以为了满足人耳的听觉要求，采样率至少为40kHz，通常为44.1kHz，更高的通常为48kHz。

采样位数，涉及到上面提到的振幅量化。波形振幅在模拟信号上也是连续的样本值，而在数字信号中，信号一般是不连续的，所以模拟信号量化以后，只能取一个近似的整数值，为了记录这些振幅值，采样器会采用一个固定的位数来记录这些振幅值，通常有8位、16位、32位。

零基础入门：实时音视频技术基础知识全面盘点_xx.jpg

位数越多，记录的值越准确，还原度越高。

4.3编码

最后就是编码了。由于数字信号是由0，1组成的，因此，需要将幅度值转换为一系列0和1进行存储，也就是编码，最后得到的数据就是数字信号：一串0和1组成的数据。
在这里插入图片描述
4.4声道数

声道数，是指支持能不同发声（注意是不同声音）的音响的个数。

单声道：1个声道
双声道：2个声道
立体声道：默认为2个声道
立体声道（4声道）：4个声道

4.5码率

码率，是指一个数据流中每秒钟能通过的信息量，单位bps（bit per second）。
码率 = 采样率 x 采样位数 x 声道数

5.为什么要编码

这里的编码和上面音频中提到的编码不是同个概念，而是指压缩编码。

我们知道，在计算机的世界中，一切都是0和1组成的，音频和视频数据也不例外。由于音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0和1的重复数据，因此可以通过一定的算法来压缩这些0和1的数据。

特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。

因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。

那么，未经编码的原始音视频，数据量至底有多大？

以一个分辨率1920×1280，帧率30的视频为例：
共：1920×1280=2,073,600（Pixels 像素），每个像素点是24bit（前面算过的哦）；
也就是：每幅图片2073600×24=49766400 bit，8 bit（位）=1 byte（字节）；
所以：49766400bit=6220800byte≈6.22MB。

这是一幅1920×1280图片的原始大小，再乘以帧率30。

也就是说：每秒视频的大小是186.6MB，每分钟大约是11GB，一部90分钟的电影，约是1000GB。。。

（以上举例引用自：《即时通讯音视频开发（十九）：零基础，史上最通俗视频编码技术入门》）

6.视频编码

视频编码格式有很多，比如H26x系列和MPEG系列的编码，这些编码格式都是为了适应时代发展而出现的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）国际电传视讯联盟主导

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的组织）主导。

当然，他们也有联合制定的编码标准，那就是现在主流的编码格式H264，当然还有下一代更先进的压缩编码标准H265。

7.音频编码

原始的PCM音频数据也是非常大的数据量，因此也需要对其进行压缩编码。

和视频编码一样，音频也有许多的编码格式，如：WAV、MP3、WMA、APE、FLAC等等，音乐发烧友应该对这些格式非常熟悉，特别是后两种无损压缩格式。

但是，我们今天的主角不是他们，而是另外一个叫AAC的压缩格式。本节以AAC格式为例，直观的了解音频压缩格式。

AAC是新一代的音频有损压缩技术，一种高压缩比的音频压缩算法。在MP4视频中的音频数据，大多数时候都是采用AAC压缩格式。

AAC格式主要分为两种：ADIF、ADTS。

1）ADIF：Audio Data Interchange Format。音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。这种格式常用在磁盘文件中。

2）ADTS：Audio Data Transport Stream。音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。
ADTS可以在任意帧解码，它每一帧都有头信息。ADIF只有一个统一的头，所以必须得到所有的数据后解码。且这两种的header的格式也是不同的，目前一般编码后的都是ADTS格式的音频流。