流媒体基础-基本概念「码率、帧率、分辨率、封装格式、编码格式、传输协议、防盗链」

1流媒体基础

流媒体又叫流式媒体，是把连续的影像和声音信息经过压缩（编码）处理后放在网站服务器上，经过网络传输到终端用户上，播放器通过解压设备对这些数据进行解压（解码）后，节目就会像发送前那样显示出来。

1、完整的视频流程

视频的播放涉及到声音的采集，编码压缩，封装的格式，什么协议传输，到用户侧的时候选择的播放器和播放形式，一个完整的视频过程是端到端的

2、分辨率（不同分辨率的差异）

说视频之前，先要说说图像。图像，大家都知道，是由很多“带有颜色的点”组成的。这个点，就是“像素点”像素是图像显示的基本单位。我们通常说一幅图片的大小，例如是1920×1080，就是长度为1920个像素点，宽度为1080个像素点。乘积是2,073,600，也就是说，这个图片是两百万像素的。1920×1080，这个也被称为这幅图片的分辨率

3、帧率（I、B、P）

帧率简单地说，帧数就是在1秒钟时间里传输的图片的数量，单位为fps。
由于人类眼睛的特殊生理结构，如果所看画面之帧率高于16的时候，就会认为是连贯的，此现象称之为视觉停留。
帧数越高画面越流畅，但相应的，文件就越大，需要耗费更多带宽、显卡和内存资源。
视频压缩中，每帧代表一幅静止的图像。而在实际压缩时，会采取各种算法减少数据的容量，其中IPB就是最常见的。

• I帧表示关键帧，可以理解为这一帧画面的完整保留;解码时只需要本帧数据就可以完成(因为包含完整画面)
• P帧——前向预测编码帧:表示的是这一帧跟之前的一个关键帧(或P帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。(也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据)
• B帧——双向预测内插编码帧，是双向差别帧，也就是B帧记录的是本帧与前后帧的差别(具体比较复杂，有4种情况)，换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。 网络上的电影很多都采用了B帧，B帧压缩率高，但是解码时CPU会比较累。
  
  在视频编码中，有一个概念叫做GOP，就是帧分组，两个关键帧之间有多少个编码帧（P帧和B帧），两个关键帧之间帧的多少直接影响到对图像的解码和编码。
  如果两个关键帧之间的帧比较多，那么从P帧和B帧的定义我们知道，解码程序就需要缓冲更多的中间解码帧，内存消耗就会比较多，而且GOP越长，那么B帧的帧数会越来越多，这直接影响到图像失真率，所以，不是GOP越长就会越好。
  那么，如果GOP越短，B帧就会越小，这种情况下图像的失真率就会越小，但是同时压缩率也会越小，对应的比特率就会越大，在网络上传输需要的带宽就会越多，所以，GOP不是越长越好，也不是越短越好，需要找一个合适位置，这个时候就是关键帧发挥作用的关键了。
  I帧与I帧之间的间隔便为GOP。那GOP的大小影响了什么呢，其实就是时延、带宽，清晰度等问题，还有拖拉，关于时延优化的可以参考已经写的另一篇博客，这里不再过多赘述。
  

3.1视频压缩说明

• 帧内压缩:也称为空间压缩(Spatial compression)。当 压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间 的冗余信息，这实际上与静态图像压缩类似。帧内一般采 用有损压缩算法，由于帧内压缩是编码一个完整的图像， 所以可以独立的解码、显示。帧内压缩一般达不到很高的 压缩，跟编码jpeg差不多。帧内压缩是生成I帧的算法。
  
• 帧间压缩:相邻几帧的数据有很大的相关性，或者说前后 两帧信息变化很小的特点。也即连续的视频其相邻帧之间 具有冗余信 息,根据这一特性，压缩相邻帧之间的冗余量就 可以进一步提高压缩量，减小压缩比。帧间压缩也称为时 间压缩(Temporal compression)，它通过比较时间轴上 不同帧之间的数据进行压缩。帧间压缩一般是无损的。帧 差值(Frame differencing)算法是一种典型的时间压缩 法，它通过比较本帧与相邻帧之间的差异，仅记录本帧与 其相邻帧的差值，这样可以大大减少数据量。 帧间压缩是生成B帧和P帧的算法。
  

4、编码解码及码率（不同码率的差异）

一个完整的视频处理过程如下图所示：

以一个分辨率为19201280，帧率为例，来一起做个简单估算：
假设一个像素大小24bit，那么一张图片大小为：1920128024=49766400bit=6220800Byte≈6.22MB
那么一秒钟文件大小为6.2230=186.6MB 每分钟为186.6*60≈11GB，一部电影假如100分钟，那么文件大小为1TB。

视频清晰度和比特率的关系，可以看到分辨率不变的情况喜爱，比特率越高也就是码率越高，视频越清晰，那思考下同样的码率下视频分辨率越高，视频越清晰吗？
同时如下也附了带宽、并发，比特率的计算，涉及比特率的计算比较复杂，一般主要遇到的问题是码率或者并发的计算。

4.1视频信号的说明

摄像机把图像中的每个像素转换成RGB三个独立的信号，由于RGB不利用压缩，所以先转换为YUV格式处理 (YPbPr或YCbCr):YUV格式比RGB节省带宽，符合人眼特性，并且兼容黑白信号 (Y亮度信号，U、V 两个
色差信号)，应用更广泛;视频会议系统中处理的都是YUV信号而不是RGB信号。

• 直接输出YUV的信号量较大，通常在视频编码前经过采样丢掉部分色彩信号，一般有4:2:2、4:1:1等多种方式;
• 如图原来4个像素12个信号，经过4:2:2采样后就变为8个信号了，节省了1/3的数据，对色彩的影响人眼基本不可察觉。
  

5、编码协议

编码简单地说，就是压缩。各种五花八门的视频编码方式，都是为了让视频变得体积更小，有利于存储和传输。
编码又分为视频编码和音频编码，下面详细来说下音视频编码的情况。

5.1、视频

视频编码经历了一个很长的发展史，目前视频的编码流派分为国际的，国内的，谷歌微软系的，不同的编码协议各有一定的差异和优劣势，主要也是基于应用场景，成本，成熟度来考量选型。：

5.1.1、H264

H.264是MPEG-4标准的第十部分，目前国内使用比较多的视频压缩格式， 与其他编码格式相比，同等画面质量，文件体积最小。电脑及部分便携式视频设备都可播放。常见于高清视频中，压缩率高，图像清晰。H.264最大的优势是高性能，因此目前网络资源中的高清视频格式(即MKV、AVI、 MPG，TS)多采用H.264编码的视频流。

• 序列
  在H264中图像以序列为单位进行组织，一个序列是一段图像编码后的数据流，以I帧开 始，到下一个I帧结束。
  一个序列的第一个图像叫做 IDR 图像(立即刷新图像)，IDR 图像都是 I 帧图像。 H.264 引入 IDR 图像是为了解码的重同步，当解码器解码到 IDR 图像时，立即将参考 帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始一个新的序 列。这样，如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR图像 之后的图像永远不会使用IDR之前的图像的数据来解码。 一个序列就是一段内容差异不太大的图像编码后生成的一串数据流。当运动变化比较 少时，一个序列可以很长，因为运动变化少就代表图像画面的内容变动很小，所以就 可以编一个I帧，然后一直P帧、B帧了。当运动变化多时，可能一个序列就比较短了， 比如就包含一个I帧和3、4个P帧。
  H264与H263及MPEG2/4的对比如下，对比其具有更好的视频质量和网络适应性，I帧的引入提高了容错率。
  
  优缺点
  H264（也称为 AVC，高级视频编码）是目前最广泛使用的视频编码格式，它支持多种分辨率、帧率、码率等参数，可以实现高质量、低延迟、低复杂度的视频压缩。它采用了帧内预测、帧间预测、变换、量化、熵编码等技术，可以有效地消除时间和空间上的数据冗余。它还支持多种配置文件和级别，以适应不同的应用场景和设备。H264 的优点是成熟、稳定、高效、灵活，缺点是需要付费专利费用，并且难以满足超高清（4K/8K）视频的需求。

5.1.2、H265

• H.265是新的编码协议，是H.264的升级版。H.265相比H.264最主要的改变是采用了块的四叉树划分结构，也极大了优化了算法，H.265比H.264占用的存储 空间理论上要少50%。H.265在各方面都碾压了H.264。 H265优点:降低存储空间。比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说，H.264中每个宏块(macroblock/MB)大小都是固定的16x16像素，而H.265的编码单位可以选择从最小的8x8到最大的64x64。那么，在相同的图像质量下，相比H.264，通过H.265编码的视频大 小将减少大约39-44%。
  优缺点：
• H265（也称为 HEVC，高效视频编码）是 H264 的后续版本，它在 H264 的基础上进行了改进和优化，可以实现更高的压缩比和更好的视频质量。它采用了更大的宏块（最大 64x64），更多的预测模式（33 个方向），更高的色深（最高 12 位），更灵活的并行处理等技术，可以有效地降低比特率和带宽消耗，提高画面清晰度和细节。它还支持 HDR（高动态范围）和 360 度全景视频等新特性。H265 的优点是适应超高清视频，提升视频质量，缺点是需要付费专利费用，并且编解码复杂度较高，需要更强的计算能力 。

H265有没有 I、B、P帧的概念：

H265 也有 I、B、P 帧的概念，它们分别代表帧内编码帧、双向预测内插编码帧和前向预测编码帧。H265 中的 I 帧是一个完整的画面，不需要参考其他帧而生成；P 帧是参考前面的 I 帧或 P 帧而生成的，只包含与参考帧的差异部分；B 帧是参考前后的 I 帧或 P 帧而生成的，也只包含与参考帧的差异部分。H265 中的 I、B、P 帧都是由宏块（macroblock）组成的，每个宏块可以选择不同的编码模式和预测方式。
H265 相比 H264，在 I、B、P 帧的编码上有一些改进和优化，例如：

• H265 引入了新的帧类型，如 CRA（Clean Random Access）、BLA（Broken Link Access）等，用于提高随机访问和错误恢复的能力。
• H265 支持更多种类和大小的宏块，如 CTU（Coding Tree Unit）、CU（Coding Unit）、PU（Prediction Unit）、TU（Transform Unit）等，可以更灵活地适应不同场景和纹理的图像。
• H265 使用更复杂的运动估计和补偿算法，如 AMP（Asymmetric Motion Partitioning）、MERGE（Merge Mode）、TMVP（Temporal Motion Vector Prediction）等，可以提高运动补偿的精度和效率。
• H265 使用更高级的帧内预测技术，如 SAO（Sample Adaptive Offset）、ALF（Adaptive Loop Filter）、DBF（Deblocking Filter）等，可以减少帧内编码的失真和块效应。
  看到这里会产生一个新的问题，宏块是什么，因为按大概的逻辑梳理是H265有更大的宏块和更多种类的宏块，那就需要明白宏块与编解码的联系，才能更好的理解H265与H264的差异：
• 宏块与编码复杂度的关联性是一个比较复杂的问题，不同的编码标准和算法可能有不同的影响因素和评估方法。一般来说，宏块的大小、形状、划分方式、预测模式等都会影响编码复杂度，也就是编码所需的时间和资源。以下是一些可能的关系：
• 宏块的大小越小，编码复杂度越高，因为需要更多的宏块头信息和运动矢量来描述图像细节。但是，宏块的大小也不能太大，否则会导致预测误差和失真增加，需要更多的残差数据来补偿。
• 宏块的形状越灵活，编码复杂度越高，因为需要更多的参数来指示宏块的划分方式。但是，宏块的形状也不能太固定，否则会导致预测不准确和边缘失真，需要更多的滤波器来消除块效应。
• 宏块的划分方式越复杂，编码复杂度越高，因为需要更多的逻辑和算法来确定最优的划分方案。但是，宏块的划分方式也不能太简单，否则会导致预测不适应和效率降低，需要更多的比特率来保证质量。
• 宏块的预测模式越多样，编码复杂度越高，因为需要更多的搜索和选择来找到最佳的预测参考。但是，宏块的预测模式也不能太单一，否则会导致预测不精确和冗余增加，需要更多的误差补偿来修正。
• 总之，宏块与编码复杂度之间存在一种平衡和折中的关系，需要根据不同的场景和需求来调整和优化。
• 问题来了既然H.265这么好，为何至今无法普及？
  由于压缩率大幅提升，对服务器及播放器都有更苛刻的要求。当前较多终端还无法支持，要把全部H.264转为H.265对服务器的代价也非常高。专利费问题。企业在实际的使用中还是要考虑成本。

5.1.3、H266

• H266（也称为 VVC，万能视频编码）是 H265 的后续版本，它在 H265 的基础上进行了进一步的改进和创新，可以实现更低的比特率和更好的视频质量。它采用了自适应变换选择、自适应运动矢量分辨率、自适应环路滤波器等技术，可以有效地减少编码噪声和失真，提高编码效率和灵活性。它还支持多视点视频、屏幕内容编码、超分辨率重建等新特性。H266 的优点是适应未来视频技术的发展，提供更高的压缩性能，缺点是目前尚未广泛应用，并且编解码复杂度极高，需要极强的计算能力 。
• 新标准的公 告中指出，由于改进了压缩技术，H.266将减少约50%的数据需求。使用之前的HEVC编解码器，传输一段90分钟的超高清(UHD)视频需要大约10GB的数据， 而H.266只需5GB就可以做到这一点。(主要用于4K/8k)
  H.266的优势主要有以下几点：
• H.266采用了更灵活和精细的宏块划分方式，可以根据图像内容的复杂度和纹理特征，动态地调整宏块的大小、形状和预测模式。
• H.266引入了更多的帧间预测模式，包括仿射运动补偿、双向光流预测、多参考图像预测等，可以更准确地描述图像中的运动信息，减少预测误差和残差数据。
• H.266增加了更多的帧内预测方向，从H.265的67个增加到H.266的130个，可以更好地适应图像中的边缘和角落等细节部分。
• H.266优化了熵编码方式，从H.265的上下文自适应二进制算术编码（CABAC）改进为上下文自适应二进制编码（CABAC），可以更高效地压缩残差数据和边信息。
• H.266支持更多的视频特性，如超高清分辨率、高动态范围、宽色域、高帧率、逐行扫描等，可以满足不同场景和需求的视频质量要求。
  H.266的劣势主要有以下几点：
• H.266的编解码复杂度比H.265高出约50%，需要更多的计算资源和时间来处理视频数据。
• H.266的兼容性和普及性还不高，目前还没有成熟的硬件支持和商用产品，需要等待芯片厂商、设备厂商、内容提供商等各方面的配合和推广。
• H.266的专利费用问题还没有明确和统一的解决方案，可能会遇到与H.265类似的专利许可混乱和危机，影响行业发展和用户利益 。

H.266和H.265都是用于4K、8K超高清视频的编解码标准，但是它们在使用场景上有一些差异，主要体现在以下几个方面：

• H.266相比H.265有更高的压缩效率和质量，可以在相同的码率下，将视频文件大小减少一半，或者在相同的文件大小下，提升视频的清晰度和细节。这意味着H.266更适合于需要节省存储空间和网络带宽的场景，如云端存储、在线传输、移动设备等。
• H.266相比H.265有更高的编解码复杂度和计算资源需求，需要更多的时间和功耗来处理视频数据。这意味着H.266更适合于有强大硬件支持和优化的场景，如专业摄像机、电视机、服务器等。
• H.266相比H.265有更多的视频特性和编码工具，可以支持更多的视频类型和应用场景，如超高清分辨率、高动态范围、宽色域、高帧率、逐行扫描、屏幕内容、360度全景视频等。这意味着H.266更适合于需要提供高质量和多样化的视频体验的场景，如电影制作、游戏直播、虚拟现实等。

总之，H.266和H.265都是用于4K、8K超高清视频的编解码标准，但是H.266在压缩效率和质量上有明显优势，而H.265在编解码复杂度和兼容性上有一定优势。不同的使用场景可以根据自身的需求和条件，选择合适的编解码标准。

5.1.4、VP8（客户端缺乏硬件解码器，支持度不高）

VP8 是由 Google 开发并开源的一种视频编码格式，它与 H264 有类似的技术特点和性能表现，但没有专利费用的限制。它采用了帧内预测、帧间预测、变换、量化、熵编码等技术，可以实现高质量、低延迟、低复杂度的视频压缩。它还支持多种配置文件和级别，以适应不同的应用场景和设备。VP8 的优点是开源、免费、兼容性强，缺点是与 H264 相比没有明显的优势，并且难以满足超高清视频的需求 。

• VP8在浏览器上的支持比较广泛，因为它是WebRTC协议的一部分，可以用于实时视频通信。目前，支持WebRTC协议的现代浏览器，如Google Chrome、Microsoft Edge、Mozilla Firefox等，都可以播放VP8编码的视频。
• VP8在客户端的支持则比较有限，因为它没有像H.264那样有广泛的硬件解码器和兼容性。一些Android设备和应用可以支持VP8编码和解码，但不是所有的设备和应用都支持。另外，一些游戏引擎和框架也可以支持VP8编码的视频流，如虚幻引擎。

总的来说，VP8在浏览器上的支持比客户端上的支持更多，但也不是所有的浏览器和客户端都支持VP8。
VP8和H.264都是用于网络视频的编解码标准，但是它们在使用场景上有一些差异和优劣势，主要体现在以下几个方面：

• VP8相比H.264有更低的专利费用和授权问题，因为VP8是由Google开源和免费的，而H.264涉及到很多专利技术，需要向MPEG LA支付专利许可费用。这意味着VP8更适合于需要节省成本和避免法律风险的场景，如开源软件、网络视频分发等。
• H.264相比VP8有更高的压缩效率和质量，因为H.264有更多的编码工具和特性，如8x8变换、B帧、自适应环路滤波等。这意味着H.264更适合于需要提供高清晰度和细节的场景，如电影制作、游戏直播、高清视频通话等。
• H.264相比VP8有更广泛的硬件支持和兼容性，因为H.264已经被市场检验和广泛使用，有很多不同厂商开发的编码器、解码器实现和硬件解码器。这意味着H.264更适合于需要在不同的设备和平台上播放视频的场景，如移动设备、电视机、浏览器等。

总之，VP8和H.264都是用于网络视频的编解码标准，但是VP8在专利费用和授权问题上有明显优势，而H.264在压缩效率和质量、硬件支持和兼容性上有一定优势。不同的使用场景可以根据自身的需求和条件，选择合适的编解码标准。

5.1.5、VP9（客户端缺乏硬件解码器，支持度不高）

VP9 是 VP8 的后续版本，它在 VP8 的基础上进行了改进和优化，可以实现更高的压缩比和更好的视频质量。它采用了更大的宏块（最大 64x64），更多的预测模式（10 个方向），更高的色深（最高 12 位），更灵活的并行处理等技术，可以有效地降低比特率和带宽消耗，提高画面清晰度和细节。它还支持 HDR 和 360 度全景视频等新特性。VP9 的优点是开源、免费、适应超高清视频，提升视频质量，缺点是编解码复杂度较高，需要较强的计算能力，并且与 H265 相比没有明显的优势 。

• VP9是一种由Google开发的开源视频编码标准，是VP8的后续版本，主要用于压缩YouTube上的超高清内容1。VP9的优点是免费、无专利费用、压缩效率高，可以节省流量和空间。VP9的缺点是编码时间长、复杂度高、硬件支持和兼容性差，需要更多的处理资源。
  VP9在浏览器上的支持比较好，因为它是WebRTC协议的一部分，可以用于实时视频通信。目前，支持WebRTC协议的现代浏览器，如Google Chrome、Microsoft Edge、Mozilla Firefox等，都可以播放VP9编码的视频。VP9也可以直接在浏览器中工作，不需要额外的插件或播放器。
  VP9在客户端上的支持则比较有限，因为它没有像H.264那样有广泛的硬件解码器和兼容性。一些Android设备和应用可以支持VP9编码和解码，但不是所有的设备和应用都支持。另外，一些游戏引擎和框架也可以支持VP9编码的视频流，如虚幻引擎。
• H.265在浏览器上的支持比较差，因为它不是WebRTC协议的一部分，需要额外的插件或播放器才能播放。目前，只有Safari浏览器可以原生支持H.265编码的视频。其他浏览器需要使用第三方解决方案，如JavaScript解码器或Flash播放器。

总的来说，VP9和H.265都是高效的视频编码标准，但是VP9在浏览器上的支持更好，而H.265在客户端上的支持更好。

5.1.6、AV1

AV1 是由 AOMedia（开放媒体联盟）开发并开源的一种视频编码格式，它是目前最先进的视频编码格式之一，它集成了 H265、VP9、Daala 等多种编码技术，可以实现更低的比特率和更好的视频质量。它采用了自适应变换选择、自适应运动矢量分辨率、自适应环路滤波器等技术，可以有效地减少编码噪声和失真，提高编码效率和灵活性。它还支持多视点视频、屏幕内容编码、超分辨率重建等新特性。AV1 的优点是开源、免费、适应未来视频技术的发展，提供最高的压缩性能，缺点是目前尚未广泛应用，并且编解码复杂度极高，需要极强的计算能力 。
AV1是VP9的后续版本，也是H.265的竞争者。因此在客户端或者浏览器的支持情况与VP9是类似的。

5.1.7 、AVS

AVS是一系列由数字音视频编解码技术标准工作组制定的音视频编解码技术标准，包括系统、视频、音频、数字版权管理等四个主要技术标准和符合性测试支撑标准。AVS的目的是为了解决国内外专利费用高昂和授权复杂的问题，提供一种开放、自主、高效的视频编码方案。
AVS2.0是AVS的第二代标准，主要针对4K超高清视频，相比于第一代标准，AVS2.0有以下特点：

• 支持更大的编码区块，最大可达128×128像素，以及更灵活的划分模式，如四叉树、六叉树等。
• 支持更多的帧内预测模式，如平面模式、DC模式、角度模式等，以及更精细的预测单位，如4×4、8×8等。
• 支持更多的帧间预测工具，如双向预测、运动矢量精度、运动矢量合并等。
• 支持更多的变换工具，如二维整数变换、非对称变换、自适应变换等。
• 支持更多的熵编码工具，如自适应算术编码、上下文建模等。

AVS2.0目前已经被广泛应用于国内的电视广播领域，如中央电视台的4K超高清频道和“百城千屏”公共大屏项目等。据测试，AVS2.0相比于H.265/HEVC和VP9，有着相当或略优的编码效率和质量，在相同质量下可以节省约30%的码率 。同时，AVS2.0也有着较低的专利费用和较好的兼容性。

AVS3是AVS的第三代标准，主要面向5G和8K视频，于2018年3月启动制定工作，并于2021年7月正式成为DVB标准体系中下一代视频编码标准之一。AVS3相比于AVS2.0有以下特点：

• 支持更高的分辨率和帧率，最高可达8192×4320像素和120帧/秒。
• 支持更多的色彩空间和色深，如BT.2020、BT.2100等。
• 支持更多的编码工具和特性，如神经网络预测、自适应量化、自适应滤波等。
• 支持更多的场景和应用，如全景视频、VR/AR/MR、云游戏等。
  AVS3目前已经在部分移动端设备和应用中实现了规模化商用，如中国移动咪咕视频客户端在2022年世界杯期间支持了基于AVS3标准的4K直播。据测试，AVS3相比于H.266/VVC有着略优或相当的编码效率和质量，在相同质量下可以节省约20%的码率。

总之，AVS是一种国产自主的音视频编码标准，经过多年的发展和完善，已经形成了从高清到超高清到移动端的全覆盖体系，并在国内外取得了一定的市场份额和影响力。AVS的优势是免专利费、编码效率高、质量好、兼容性强，适用于各种场景和应用。AVS的劣势是编码时间长、复杂度高、硬件支持和国际化程度不足，需要更多的优化和推广。

5.2、音频

5.2.1、OPUS

Opus是一种完全开源，免费的，通用性高的音频编解码器，遵从IETF RFC 6716标准，整合了Skype的SILK编解码和Xiph.Org的CELT编解码的技术。Opus在网络上有着无与伦比的交互式语音和音乐传播功能，但也可以用来存储，在流媒体上使用。Opus支持从6 kbit/s的窄带单声道语音到510 kbit/s的宽带立体声音乐的各种比特率，支持从8 kHz（窄带）到48 kHz（全频）的各种音频带宽，支持从2.5 ms到60 ms的各种帧长，支持单声道和立体声两种通道数。Opus还提供了多种控制参数，如复杂度、丢包弹性、前向纠错、恒定/可变比特率、不连续传输等，以适应不同的场景和需求。
Opus的应用场景非常广泛，主要包括以下几类：

• 实时通信：Opus是WebRTC中默认的音频编码格式，适用于IP语音、视频会议、游戏内聊天等低延迟、高质量的语音传输场景。Opus可以根据网络状况和语音内容动态调整比特率和帧长，提供丢包弹性和前向纠错功能，保证语音的清晰度和连贯性。
• 流媒体：Opus可以用于流媒体平台，如Spotify、YouTube等，提供高效率、高质量的音乐传输和存储。Opus可以支持从窄带到全频的各种音频带宽，以及从单声道到立体声的各种通道数，满足不同用户的偏好和设备的能力。
• 录音存储：Opus可以用于录音应用，如语音备忘录、口语评测等，提供低比特率、高压缩比的音频存储。Opus可以使用OGG格式进行封装，方便在各种播放器上进行解码和播放。

5.2.2、ACC

ACC是基于MPEG-2的音频编码技术，目的是取代MP3格式，是一种高压缩比的音频压缩算法。AAC压缩比通常为18:1，远胜mp3。由于采用多声道（48个音轨，15个低频（LFE）音轨，5.1多声道支持）、使用低复杂性的描述方式、多种语言的兼容能力及更高的解码效率，比几乎所有的传统编码方式在同规格情况下更胜一筹。一般来说，AAC可以在对比MP3文件缩小30%的前提下提供更好的音质。

• Opus是一个完全开源，免费的音频编解码器，没有任何专利或限制，遵从IETF RFC 6716标准，整合了Skype的SILK编解码和Xiph.Org的CELT编解码的技术。AAC（Advanced Audio Coding，高级音频编码）是杜比实验室为音乐社区提供的技术，是有损声音压缩编码的格式，版税方式为一次性收费。出现于1997年，基于MPEG-2的音频编码技术。
• AAC也支持多种比特率、带宽、帧长和通道数，但通常比Opus要高一些。例如，AAC支持最高96 kHz的采样率。
• Opus在低比特率下具有更好的音质和压缩效率，尤其适合语音传输和通信场景。Opus可以根据网络状况和语音内容动态调整比特率和帧长，提供丢包弹性和前向纠错功能，保证语音的清晰度和连贯性。AAC在中高比特率下具有更好的音质和压缩效率，尤其适合音乐传输和存储场景。AAC可以保留更多的高频信息，提供更接近原始音频的还原度。

5.2.3、MP3

MP3被设计用来大幅度地降低音频数据量，将音乐以1:10 甚至 1:12 的压缩率，压缩成容量较小的文件。bitrates对MP3来说是可变的，原则是bitrate越高声音文件中包含的原始声音信息越多，这样回放时声音品质也越高。就bitrates来说MP3可以分为2种:
1）MP3-CBR(Constant BitRate)在MP3编码的早期，整个文件使用一个固定的位元率。
2）MP3_VBR(Variable Bit Rate)可以让MP3文件的每一段甚至每一帧都可以有单独的bitrate，这样在保证音质的前提下最大程度的限制了文件的大小。这个方法类似于声音控制的磁带录音机不记录静止部分节省磁带消耗。

6、音视频封装格式

首先理解下什么是封装，举个例子：

那新问题来了为什么要封装，不封装行不行：
对于任何一部视频来说，只有图像，没有声音，肯定是不行的。所以，视频编码后，加上音频编码，要一起进行封装。
视频轨相当于饭，而音频轨相当于菜，封装格式就是一个饭盒，用来盛放饭菜的容器。
也可以这么理解封装处在传输前，或者下载后，播放前

6.1、音视频封装格式

封装格式是指将音频和视频的编码数据和同步信息打包到一个文件中，形成一个统一的格式，便于存储和传输。封装的目的是为了方便音视频的管理、播放和编辑，以及提供一些额外的信息和功能，如字幕、章节、元数据等。封装格式不影响音视频的质量，只影响文件的大小和可操作性。封装格式可以根据需要进行转换，但转换过程可能会损失一些元数据或附加信息。
音频和视频封装是指将音频和视频的编码数据和同步信息打包到一个文件中，形成一个统一的格式，便于存储和传输。音频和视频的编码数据是指将原始的音频和视频信号经过压缩算法处理后得到的数据，用于减少数据量和提高质量。同步信息是指音频和视频之间的时间关系，用于保证音视频的同步播放。

常见的音视频封装格式有AVI、RMVB、MKV、ASF、WMV、MP4、3GP、FLV等，不同的封装格式有不同的结构、功能和应用场景。一般来说，封装格式不影响音视频的质量，只影响文件的大小和可操作性。封装格式可以根据需要进行转换，但转换过程可能会损失一些元数据或附加信息。

以下是一些常见的音视频封装格式的介绍：

• AVI（Audio Video Interleave）：是一种最早的封装格式，由微软公司开发，支持多种音视频编码格式，结构简单，但功能有限，不支持字幕、章节等信息，也不支持流媒体传输。
• RMVB（RealMedia Variable Bitrate）：是一种基于RM（RealMedia）格式的变码率封装格式，由RealNetworks公司开发，专门用于压缩电影和电视剧等长视频，具有较高的压缩率和质量，但兼容性较差，需要专用的播放器或解码器。
• MKV（Matroska Video）：是一种开源的封装格式，支持多种音视频编码格式，以及字幕、章节、元数据等信息，具有较强的功能和扩展性，但也较为复杂，需要较高的处理能力。
• ASF（Advanced Systems Format）：是一种由微软公司开发的封装格式，专门用于流媒体传输和播放，支持多种音视频编码格式，以及元数据、脚本命令等信息，具有较好的网络适应性和交互性。
• WMV（Windows Media Video）：是一种基于ASF格式的封装格式，由微软公司开发，专门用于压缩和存储视频数据，使用微软自己的视频编码技术，具有较高的压缩率和质量，但兼容性较差。
• MP4（MPEG-4 Part 14）：是一种基于MPEG-4标准的封装格式，支持多种音视频编码格式，以及字幕、章节、元数据等信息，具有较好的兼容性和功能性，是目前最流行的封装格式之一。
• 3GP（3GPP file format）：是一种基于MPEG-4标准的封装格式，专门用于移动设备上的音视频传输和播放，使用较低的比特率和分辨率，具有较小的文件大小和较低的质量。
• FLV（Flash Video）：是一种由Adobe公司推出的封装格式，专门用于网络上的实时音视频传输和播放，使用Adobe自己的音视频编码技术或其他常见的编码技术，具有较高的压缩率和效率，但需要Flash插件或播放器支持。

6.2、封装格式与传输协议的区别

封装格式和传输协议是两个不同的概念，但有一定的联系和区别。

• 封装格式是指将音频和视频的编码数据和同步信息打包到一个文件中，形成一个统一的格式，便于存储和传输。封装格式只是为多媒体编码提供了一个“外壳”，也就是将所有的处理好的视频、音频或字幕都包装到一个文件容器内呈现给观众，这个包装的过程就叫封装。常见的封装格式有AVI、RMVB、MKV、ASF、WMV、MP4、3GP、FLV等。

• 传输协议是指在网络上进行音视频传输和播放时使用的一种规则或标准，用于保证音视频数据的有效性、完整性和实时性。传输协议在传输视音频数据的同时，也会传输一些信令数据，用于控制播放、调节网络状态等。常见的传输协议有HTTP、RTMP、RTSP、HLS等。

封装格式和传输协议的区别有以下几点：

• 封装格式是针对文件的，传输协议是针对流的。封装格式是将音视频数据保存为一个文件，可以在本地播放或下载；传输协议是将音视频数据以流的形式发送或接收，可以在线播放或直播。
• 封装格式是静态的，传输协议是动态的。封装格式是在音视频数据编码完成后进行的操作，不会改变音视频数据本身；传输协议是在音视频数据传输过程中进行的操作，可能会根据网络状况或用户需求改变音视频数据的质量或速度。
• 封装格式和编码格式是多对多的关系，传输协议和编码格式是多对一或一对一的关系。封装格式只是一个容器，可以容纳多种编码格式的音视频数据；传输协议则需要与特定的编码格式匹配，才能有效地传输和播放音视频数据。

封装格式和传输协议的联系有以下几点：

• 封装格式和传输协议都需要携带音视频数据和元数据。音视频数据是指经过压缩算法处理后得到的数据，用于减少数据量和提高质量；元数据是指关于音视频数据的一些信息，如时长、分辨率、帧率等。

• 封装格式和传输协议都可以根据需要进行转换。封装格式可以通过工具或程序将一个文件转换为另一个文件，例如将AVI转换为MP4；传输协议可以通过服务器或网关将一个流转换为另一个流，例如将RTMP转换为HLS。

• 封装格式和传输协议都要考虑兼容性和功能性。不同的封装格式和传输协议有不同的结构、功能和应用场景，需要根据目标平台、设备、网络等因素选择合适的封装格式和传输协议。
  
  常见的封装格式及说明：
  
  2019年初针对top视频厂商封装编码格式等做的调研结果如下：
  （1）短视频客户视频封装格式还是以mp4为主（96%），少部分使用hls（腾讯和网易）、flv（网易）和TS（搜狐新闻）
  （2）长视频封装格式以hls为主（75%），其次是mp4（25%），少部分有使用到dash（华为视频）、m4s（B站）、flv（B站）和f4v（爱奇艺PC端）（8%）

• MP4格式：
  

• FLV格式
  FLV是一种流媒体格式，由Adobe公司推出，用于在互联网上传输和播放音视频数据。FLV的封装格式是由一个文件头和一个文件体组成，文件体由一系列的Tag和Tag Size对组成。每个Tag包含一个Tag Header和一个Tag Data，用于存储音频、视频或脚本数据。
  
  
  FLV格式有以下优劣势：
  优势：

• 文件体积小，便于传输和共享。

• 适合网络发展的需求，可以提供快速加载和低CPU占用率的视频体验。

• 资源丰富多样，可以找到各种类型的视频内容。
  劣势：

• 视频质量不高，可能出现画面模糊或失真的情况。

• 不被所有播放器支持，需要安装特定的软件或插件才能观看。

• 不利于视频编辑，需要转换成其他格式才能进行剪辑或添加特效。

• HLS：
  m3u8，是HLS的索引文件,基本上可以认为就是.m3u格式文件，m3u8文件使用UTF-8字符编码。
  
  HLS有以下优点：

• 可以适应不同的网络状况和设备能力，通过提供不同码率和分辨率的流，让客户端自动选择最合适的流。

• 可以方便地利用HTTP协议和CDN网络进行分发和加速，提高传输效率和用户体验。

• 可以支持加密和认证机制，保护版权和隐私。
  HLS有以下缺点：

• 由于每个.ts文件都需要单独请求，会增加网络开销和延迟。

• 由于MPEG-TS格式不支持B帧，会降低视频质量和压缩效率。

• 由于HLS是苹果公司的专利技术，需要支付版权费用。

7、协议分析

封装是静态，传输格式传输的是流式数据。
流媒体传输协议是指在网络上传输音频和视频数据的一种规范，它定义了数据的格式、封装、传输和解析等方面的细节。流媒体编码协议可以分为以下几类：

• 基于 TCP 的协议，如 RTMP、RTMPS、RTMPT、HTTP-FLV 等，这类协议的特点是稳定、可靠、兼容性强，但是延迟较高，适合用于直播和点播场景。
• 基于 UDP 的协议，如 RTP、RTCP、RSVP 等，这类协议的特点是实时性高、效率高，但是容易丢包、抖动，适合用于视频会议和视频电话场景。
• 基于 HTTP 的协议，如 HLS、MMS 等，这类协议的特点是利用 HTTP 的分发能力，支持 CDN 和缓存，但是延迟较高，适合用于互联网直播和点播场景。
• 基于 WebSocket 的协议，如 WebSocket-FLV 等，这类协议的特点是利用 WebSocket 的双向通信能力，支持 HTML5 和浏览器播放，但是数据量较大，适合用于互联网直播和点播场景。
• 基于 WebRTC 的协议，如 WebRTC 等，这类协议的特点是利用 WebRTC 的实时音视频通信能力，支持 HTML5 和浏览器播放，实现低延迟、高质量的音视频互动，适合用于视频社交、在线教育、视频会议等场景。

具体来说：

• RTMP（Real Time Messaging Protocol）是由 Adobe 公司基于 Flash Player 播放器对应的音视频 flv 封装格式提出的一种基于 TCP 的数据传输协议。它可以实现音频、视频和数据的实时传输，并支持多种消息类型和命令。它常被应用于流媒体直播和点播等场景。
• RTMPS（Real Time Messaging Protocol Secure）是在 RTMP 协议的基础上加入了 SSL/TLS 加密层的一种安全版本。它可以保护音频、视频和数据的传输不被窃听或篡改。
• RTMPT（Real Time Messaging Protocol Tunneled）是一种将 RTMP 协议封装在 HTTP 请求中的一种变种。它可以穿透防火墙和代理服务器，提高 RTMP 协议的可达性。
• HTTP-FLV（Hypertext Transfer Protocol Flash Video）是一种将音视频数据封装成 FLV 格式，然后通过 HTTP 协议传输给客户端的一种方式。它可以利用 HTTP 的分发能力和兼容性，并支持 HTML5 和浏览器播放。
• RTP（Real-time Transport Protocol）是一种针对多媒体数据流的一种传输协议，建立在 UDP 协议之上。它定义了互联网上传递音频和视频的标准数据包格式，并提供时间戳、序号等信息来实现同步和重组。
• RTCP（Real-time Transport Control Protocol）是一种为 RTP 媒体流提供信道外控制的一种协议。它定期在流多媒体会话参与者之间传输控制数据，提供服务质量反馈、统计信息、同步信息等功能。
• RSVP（Resource Reservation Protocol）是一种使用 RSVP 预留一部分网络资源（即带宽）的一种协议，能在一定程度上为流媒体的传输提供 QoS（Quality of Service），保证流媒体的质量和稳定性。
• RTSP（Real Time Streaming Protocol）是一种用于控制流媒体服务器的一种应用层协议。它可以实现对流媒体的播放、暂停、快进、倒退等操作，类似于 VCR 的功能。它通常与 RTP 和 RTCP 协同工作，实现流媒体的传输和控制。
• HLS（HTTP Live Streaming）是一种由苹果公司实现的基于 HTTP 的流媒体传输协议，可实现流媒体的直播和点播。它将音视频数据切分成小片段（TS 格式），并通过一个索引文件（M3U8 格式）来描述这些片段的信息。客户端可以根据索引文件来下载和播放这些片段，实现流媒体的播放。
• MMS（Microsoft Media Server）是一种由微软公司开发的用于访问并流式接收 Windows Media 服务器中 ASF 文件的一种协议。它可以利用 TCP 或 UDP 来传输数据，并支持多种消息类型和命令。
• WebSocket-FLV（WebSocket Flash Video）是一种基于 WebSocket 传输 FLV 的一种方式。它可以利用 WebSocket 的双向通信能力，支持 HTML5 和浏览器播放，并实现低延迟、高效率的音视频传输。
• WebRTC（Web Real-Time Communication）是一种支持网页浏览器进行实时语音对话或视频对话的 API。它可以利用 WebRTC 的实时音视频通信能力，支持 HTML5 和浏览器播放，并实现低延迟、高质量的音视频互动。

视频传输协议的选择与延迟、应用场景等有关系
如下是视频延迟的分类说明：

视频传输协议与延迟的关系如下图：

7.1、RTMP

• RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议。Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的 私有协议。工作在 TCP 之上的明文协议，默认使用端口 1935。协议中的基本数据单元成为消息(Message)，传输的过程中消息会被拆 分为更小的消息块(Chunk)单元。最后将分割后的消息块通过 TCP 协议传输，接收端再反解接收的消息块恢复成流媒体数据。
• RTMP 主要有以下几个优点:RTMP 是专为流媒体开发的协议，对底层的优化比其它协议更加优秀，同时它 Adobe Flash 支持好，基本 上所有的编码器(摄像头之类)都支持 RTMP 输出。现在 PC 市场巨大，PC 主要是 Windows，Windows 的浏览器基本上都支持 Flash。另外RTMP适合长时间播放，曾经有过测试，连续 100 万秒，即 10 天多连续播放没有出现问题。最后 RTMP 的延迟相对较低， 一般延时在 3-5s 之间，一般的视频会议，互动式直播，完全是够用的。
• 当然 RTMP 并没有尽善尽美，它也有不足的地方。一方面是它是基于 TCP 传输，非公共端口，可能会被防火墙阻拦;另一方面，也是比较 坑的一方面是 RTMP 为 Adobe 私有协议，很多设备无法播放，特别是在 iOS 端，需要使用第三方解码器才能播放。RTMP支持动态调整块长度，以适应不同的带宽和延迟。

RTMP协议是一个互联网五层体系结构中应用层的协议。RTMP 协议中基本的数据单元称为消息(Message)。当RTMP协议在 互联网中传输数据的时候，消息会被拆分成更小的单元，称为 块(Chunk)。如下是RTMP从建联到传输到停止的过程展示：

RTMP是一种有状态协议，需要为每一个播放视 频流的客户端维护状态，RTMP对设备的性能损 耗大，占用CPU、内存等。
RTMP有以下优点：

• 可以实现低延迟的实时音视频流的传输和播放。
• 可以支持多种格式的音视频编码，如H.264、AAC、MP3等。
• 可以支持加密和认证机制，保护版权和隐私。
  RTMP有以下缺点：
• 由于基于TCP协议，会受到TCP拥塞控制和重传机制的影响，导致传输抖动和丢帧。
• 由于使用私有的协议格式，需要专门的客户端或插件才能播放，不利于跨平台和兼容性.
• 由于使用可靠的字节流，会增加网络开销和资源消耗.

7.2、HLS

• HLS是一种流媒体协议，全称为HTTP Live Streaming，是由苹果公司提出的一种基于HTTP的多媒体传输协议，用于实现实时或点播的音视频流的分发和播放。
• HLS的工作原理是将整个流切割成一个个小的基于HTTP的文件来下载，每次只下载一些。这些文件通常是MPEG-TS格式的，后缀为.ts，每个文件包含一段时间的音视频数据，通常为10秒左右（因为一般播放要求客户端接收到3片TS文件才能起播）。HLS还提供了一个配套的媒体列表文件，后缀为.m3u8，用于记录所有的.ts文件的地址和相关信息，以供客户端按顺序请求和播放。
  

组成M3U8说明：

• 一般有两级，第一级包含这不同分辨率的第二级 索引，目的是为了做分辨率的自适应先下载一级 Index file，它里面记录了二级索引文件( Alternate-A、Alternate-B、Alternate-C)的 地址，然后客户端再去下载二级索引文件，二级 索引文件中又记录了TS文件的下载地址，这样客 户端就可以按顺序下载TS视频文件并连续播放。
  

TS文件说明：

• 直播：
  VOD模式:只需要下载一次一级index文件和二级index文件就可以得到所有ts文 件的下载地址，除非客户端进行比特率切换，否则无需再下载任何index文件， 只需顺序下载ts文件并播放就可以了。 Live模式:略有不同，因为播放的同时，新ts文件也在被生成中，所以客户端实 际上是下载一次二级index文件，然后下载ts文件，再下载二级index文件(这个 时候这个二级index文件已经被重写，记录了新生成的ts文件的下载地址),再下载新ts文件，如此反复进行播放。
• 点播：
  
  1、#EXT-X-PLAYLIST-TYPE:VOD的意思是当前 的视频流并不是一个直播流，而是点播流。
  2、#EXT-X-TARGETDURATION指定当前视频 流中的切片文件的最大时长。
  3、#EXTINF表示每个ts切片视频文件的时长。
  4、#EXT-X-ENDLIST这个表示视频结束，有这个标志同时也说明当前的流是一个非直播流。

HLS有以下优点：

• 可以适应不同的网络状况和设备能力，通过提供不同码率和分辨率的流，让客户端自动选择最合适的流。
• 可以方便地利用HTTP协议和CDN网络进行分发和加速，提高传输效率和用户体验。
• 可以支持加密和认证机制，保护版权和隐私1234。

HLS有以下缺点：

• 由于每个.ts文件都需要单独请求，会增加网络开销和延迟。
• 由于MPEG-TS格式不支持B帧，会降低视频质量和压缩效率.
• 由于HLS是苹果公司的专利技术，需要支付版权费用.

7.3、FLV

FLV是一种流媒体格式，全称为Flash Video，是由Adobe公司提出的一种视频封装格式，用于存储和传输音视频数据。
FLV的工作原理是将音视频数据分成一个个消息（Message），每个消息包含消息头和消息体。消息头中包含了消息类型、长度、时间戳等信息，用来标识和控制消息的传输。消息体中包含了实际的音视频数据或元数据的内容。
HTTP-FLV则是将RTMP封装在HTTP协议之上，一个无限大的http流的文件。
HTTP协议中有个content-length字段，服务器回复http请求的时候如果有这个字段，客户端就接收这个长度的数据然后就认为数据传输完成了。如果服务器回复http请求中没有这个字段，客户端就一直接收数据，直到服务器跟容户端的socket连接断开。HTTP-FLV直播就是利用第二个原理，服务器回复容户端请求的时候不加content-length字段，在回复了http内容之后，紧接着发送flv数据，客户端就一直接收数据了。（延迟为1-3s）
首屏更快（首屏比RTMP快的原因是，RTMP与服务端的交互会更久）
FLV有以下优点：

• 可以实现低延迟的实时音视频流的传输和播放。
• 可以支持多种格式的音视频编码，如H.264、AAC、MP3等。
• 可以与RTMP协议或HTTP协议结合，实现流媒体的分发和播放.
  FLV有以下缺点：
• 由于使用私有的格式，需要专门的客户端或插件才能播放，不利于跨平台和兼容性
• 由于不支持自适应码率，不能根据网络状况和设备能力动态调整视频质量.
• 由于不支持分片传输，不能实现快速拖动和随机访问

7.4、DASH

DASH是一种流媒体协议，全称为Dynamic Adaptive Streaming over HTTP，是一种基于HTTP的自适应比特率流技术，使高质量流媒体可以通过传统的HTTP网络服务器以互联网传递。

• DASH的工作原理是将音视频流分割成小块，通过HTTP协议进行传输，客户端得到之后进行播放。DASH支持MPEG-2 TS、MP4等多种媒体格式，有良好的扩展性。
• 与HLS 类似，DASH 将传输内容切片为小文件，每个小文件对应的内容允许存在不同码率，这些不 同码率的文件通过关键帧对齐可以做到根据网络状况无缝切换，从而减少卡顿和缓冲。DASH 同样 使用类似m3u8 的切片描述文件，叫做Media Presentation Description(MPD)，是一个XML 文件。DASH 服务器(HTTP)提供内容切片文件以及MPD 索引文件，客户端请求MPD 文件然后 根据带宽情况/用户需求请求相应的分片。
• 内容生产服务器:负责制作媒体内容，并将制作好的内容发分发至流媒体服务器;
• 流媒体服务器:管理Dash 媒体内容，并响应客户端的HTTP 媒体服务请求;
• (1)MPD:用于描述客户端向服务器获取媒体分片进行解封装、解码与流媒体服务所需的详细信 息。MPD 采用HTTP XML 格式组织数据。
• (2)媒体分片:与媒体格式相对应的有效编码内容和元数据，由客户端通过HTTP Get指令获取。
• Dash 客户端:以标准的HTTP 协议与服务器进行交互，获取和解析MPD(MediaPresentation Description:媒体表示描述)文件，构建与管理媒体文件的下载请求、解码与输出媒体内容，同 时也负责响应事件，实现与流媒体服务相关的应用。
  
  

1. 每个presentation划分为一系列时间连续且不重叠的媒体时段(period)。
2. 每个时段包含同一段多媒体内容的一个或多个自适应集合(Adaptation Set)，其中包含视觉上同一段内容的 多个多媒体资源，例如不同视角的视频或不同音轨的音频等;同时，每个时段都有一个参数用以标识该音/视频切片 的起始时间和持续时间。
3. 每个自适应集合包含一个或多个媒体文件描述(representation)，这是同一时段媒体内容的最小集合。每个 representation定义了一个视频质量描述文件，其中包含了多个参数，包括带宽、编码、分辨率等。
4. 每个representation包括一个或多个切片(segment)及它们的URL，其中每个切片可以按时间顺序划分为数个 彼此连续且不重叠的子切片(sub-segment)。
5. 每个切片或子切片就是实际的音/视频的切片文件，可以通过URL，用HTTP GET请求直接下载。 除此之外，MPEG-DASH协议中还定义了某些可选的结构，如与集合平行的子集(Subset)、与切片平行的Sub- Representation等。
   为了描述以上架构，MPEG-DASH定义了专门的描述文件，称为MPD(Media Presentation

音视频分离说明：

DASH有以下优点：

• 可以适应不同的网络状况和设备能力，通过提供不同码率和分辨率的流，让客户端自动选择最合适的流。
• 可以方便地利用HTTP协议和CDN网络进行分发和加速，提高传输效率和用户体验。
• 可以支持加密和认证机制，保护版权和隐私.
  可以与其他流媒体协议如HLS、HDS、MSS等实现互操作性
  DASH有以下缺点：
• 由于每个片段都需要单独请求，会增加网络开销和延迟
• 由于使用XML格式的MPD文件，会增加解析复杂度和内存消耗
• 由于没有统一的播放器标准，会导致不同平台和浏览器的兼容性问题.

HLS与DASH的区别：
DASH和HLS都是基于HTTP的自适应比特率流技术，都是将音视频流分割成小块，通过HTTP协议进行传输，客户端得到之后进行播放。但是它们也有一些区别，主要有以下几个方面：

• 码率切换：DASH可以在每个片段之间无缝切换不同的码率，而HLS需要等待当前片段播放完毕才能切换码率，这可能导致HLS的切换延迟较高。
• 码率选择：DASH可以根据客户端的反馈信息动态调整码率，而HLS只能根据客户端的下载速度选择码率，这可能导致HLS的码率选择不够准确。
• 片段长度：DASH的片段长度通常在2-10秒之间，优化长度为2-4秒，而HLS的默认片段长度为6秒，可以调整。片段长度的不同会影响到缓冲时间、延迟和切换效果。
• 编码格式：DASH允许使用任何编码标准，如H.264、H.265、VP9等，而HLS则要求使用H.264或H.265。编码格式的不同会影响到视频质量和压缩效率。
• 设备支持：HLS是唯一受Apple设备支持的格式，iPhone、MacBook和其他Apple产品无法播放通过DASH传递的视频。而DASH在Android上已经可原生使用，各品牌电视机也已支持。
• 标准化：DASH是一个国际标准，由MPEG和ISO共同制定，而HLS是一个私有标准，由苹果公司提出。标准化的不同会影响到协议的普及和更新。

7.5、webRTC

WebRTC协议是一种用于在网页上实现实时音视频通信的技术，它由一组标准、协议和JavaScript API组成，使得浏览器之间可以直接建立点对点的连接，无需借助中间服务器或插件。WebRTC协议的特点有以下几个：

• 开源：WebRTC协议是由Google主导的，基于开源项目libjingle和libsrtp开发的，遵循W3C和IETF的标准，任何人都可以免费使用和贡献代码。
• 跨平台：WebRTC协议可以在不同的操作系统、浏览器和设备上运行，只要支持相应的API和协议，就可以实现实时通信的功能。
• 安全：WebRTC协议使用DTLS（Datagram Transport Layer Security）和SRTP（Secure Real-time Transport Protocol）来保护数据的传输，防止中间人攻击和数据泄露。
• 高效：WebRTC协议使用UDP（User Datagram Protocol）作为传输层协议，提高了数据的实时性和效率，同时使用RTP（Real-time Transport Protocol）和RTCP（Real-time Control Protocol）来封装和控制媒体流，支持多种编解码格式和自适应码率等功能。
  
• 灵活：WebRTC协议不仅可以传输音视频流，还可以传输任意类型的数据，例如文本、文件、图片等，通过DataChannel API可以实现双向的数据通道。

WebRTC协议的优势是：

• 降低了实时通信的门槛：WebRTC协议使得开发者无需安装任何插件或软件，就可以在网页上实现实时通信的功能，简化了开发流程和用户体验。
• 提高了实时通信的性能：WebRTC协议利用点对点的连接方式，减少了中间服务器的负担和延迟，提高了通信的质量和稳定性。
• 拓展了实时通信的场景：WebRTC协议可以支持多种类型的数据传输，例如视频会议、在线教育、远程医疗、游戏互动、物联网控制等，为用户提供了更多的可能性和创新空间。

WebRTC协议的劣势是：

• 缺乏统一的标准：WebRTC协议虽然遵循W3C和IETF的标准，但是不同的浏览器对于API和协议的支持程度不同，可能导致兼容性问题和功能差异。
• 存在安全风险：WebRTC协议虽然使用了加密技术来保护数据的传输，但是仍然存在一些安全风险，例如用户隐私泄露、网络攻击、恶意代码注入等，需要开发者和用户注意防范。
• 受限于网络环境：WebRTC协议虽然使用了UDP作为传输层协议，提高了数据的实时性和效率，但是也受限于网络环境的影响，例如带宽、延迟、丢包、防火墙等，可能导致通信质量下降或中断。

7.6、SRT

SRT(Secure Reliable Transport)是一种基于UDP协议的开源互联网传输协议，其保留了UDP的核心思想和机制，解决了 复杂的传输时序问题，可以极大减少传输延迟。同时，SRT拥有AQR和FEC纠错技术，可以出色的抵抗网络抖动，确保传输的稳 定性。此外，SRT可支持H.264和HEVC等编码格式，并支持AES-128/256位加密，可提供质量大码率视频的安全传输。

• 具备出色的抗抖动能力：携带精准的时间戳，支持 ARQ和FEC两种丢包恢复机 制，能很好的对抗有损网络 中的丢包和抖动。
• 更低的延迟：基于UDP协议进行传输，2次 握手即可完成建联，可配置 的延时使其能拥有更低的延时。
• 更适合超高清直播：超清直播其码率大，音频格 式要求高的特性，对于传输 要求更加高。

SRT协议在弱网传输环境下的对比：

7.7、CMAF

CMAF是一种通用媒体应用格式，是由苹果和微软邀请MPEG开发的一种基于HTTP的自适应比特率流技术，旨在解决不同流媒体协议之间的兼容性和效率问题。
通过将段分割成块，流服务器可以使段中的块已经可用，而整个块尚未完成。这改变了情况，因为玩家可以提前下载各个块，并且可以更快地填充缓冲区。这样可以大大减少端到端的等待时间

CMAF的特点有：

• 它使用MP4作为容器格式，可以支持H.264、HEVC和其他编码标准，以及WebVTT和IMSC-1字幕。
• 它可以与HLS和DASH等演示格式配合使用，只需要一组MP4文件和四个不同的manifest文件，可以减少编码、存储和传输的成本和复杂度。
• 它可以支持CENC加密方式，实现多DRM的保护，如FairPlay、Widevine和PlayReady等。
• 它可以实现低延迟的传输，通过将segment切分成更小的chunk进行编码、传输和播放，降低了编码器、服务器和播放器之间的缓冲时间。
• 它可以支持多音轨、多视频轨、多字幕轨的选择和切换，提高了用户体验
  CMAF的挑战有：
• 它需要设备和浏览器支持MP4容器格式和CENC加密方式，一些旧设备或浏览器可能无法播放CMAF格式的视频.
• 它需要与HLS或DASH等演示格式配合使用，这可能增加了manifest文件的解析和管理的复杂度.
• 它需要与CDN网络协同工作，实现chunked传输和缓存的优化.

CMAF和DASH的区别主要有以下几个方面：

• CMAF是一种容器格式，而DASH是一种演示格式。CMAF定义了如何封装和加密音视频数据，而DASH定义了如何描述和传输这些数据。
• CMAF可以与DASH配合使用，也可以与HLS配合使用。CMAF可以作为DASH或HLS的segment格式，只需要不同的manifest文件来描述CMAF文件的位置和属性。
• CMAF可以实现低延迟的传输，而DASH则需要额外的标准或扩展。CMAF支持将segment切分成更小的chunk，可以在segment完全生成之前进行传输和播放，降低了延迟。而DASH则需要遵循LL-DASH或其他低延迟方案来实现类似的功能。
• CMAF可以支持多DRM的保护，而DASH则需要额外的协商或协议。CMAF支持CENC加密方式，可以使用不同的DRM系统来解密同一份CMAF文件，如FairPlay、Widevine和PlayReady等。而DASH则需要使用Content Protection Information Exchange (CPIX)或其他协议来交换DRM信息.

8、延迟分析

8.1、延迟说明

延迟都来自哪些环节产生呢，通过下面的图片可以看到：

8.2、延迟追赶

因为存在延迟的积累，在流媒体直播的场景下就需要去做追赶，那通过哪些方面来做追帧呢：
追帧关键技术:
背景:直播过程中会出现延迟逐渐变大的情况
原因: buffer queue 变大，拉流端播放的内容和推流端相差时延增加。
解决办法:
Ø 控制max_buffer_size，
Ø 使用倍速播放，快速消耗BufferQueue
Ø 使用丢包(丢帧)策略。策略说明:
•有音频流和视频流，或者只有音频流情况下，当audio q达到一定的durati on，就丢掉前面一部分数据包，因为默认是AV_SYNC_AUDIO_MASTE R，视频会追上来。
•只有视频流情况，当video q达到一定的duration，就丢掉前面一部分数据包。
对齐技术关键点:
l 直播视频流时逐帧打入时间戳t1。业务系统推送内容时携带时间戳t2，
并在播放终端进行比对，当视频流帧所携带的时间戳t1与题目中t2相匹配时弹出内容。
l SEI字段
l 推流器/推流边缘

9、安全性说明

流媒体传输的安全性是指保护流媒体数据在网络中的传输过程不被窃听、篡改、伪造或重放，以及保护流媒体内容的版权和隐私。为了保障流媒体传输的安全性，有以下一些手段或技术：

• 加密：加密是对流媒体数据进行编码，使得只有拥有密钥的用户才能解码还原出原始数据，防止未授权的用户获取或修改数据。加密可以分为对称加密和非对称加密，对称加密使用相同的密钥进行加密和解密，非对称加密使用一对公钥和私钥进行加密和解密。加密可以应用在不同的层次，例如传输层、应用层或者数据本身。例如，HLS协议可以使用AES-128算法对每个视频分片进行加密，并在m3u8文件中指定获取密钥的URL；RTMP协议可以使用RTMPE变种来对FLV分块进行加密；RTP协议可以使用SRTP变种来对音视频数据进行加密 。
• 鉴权：鉴权是对流媒体用户进行身份验证，确定用户是否有权限访问或操作流媒体数据。鉴权可以通过用户名、密码、令牌、证书等方式实现，也可以结合数字签名或消息摘要等技术来增强安全性。鉴权可以应用在不同的环节，例如获取流媒体地址、获取流媒体内容、获取流媒体密钥等。例如，HLS协议可以使用HTTPS协议来提供给客户端获取密钥的鉴权服务³；RTSP协议可以使用HTTP基本认证或摘要认证来验证客户端的身份 。
• 数字水印：数字水印是在流媒体数据中嵌入一些不易察觉的信息，用于标识流媒体的来源、归属、版权等。数字水印可以分为可见水印和不可见水印，可见水印是在视频画面上添加一些图标或文字，不可见水印是在视频数据中添加一些隐蔽的信号或编码。数字水印可以用于追踪流媒体的传播路径，防止流媒体的非法复制或转发¹ 。例如，电影院可以在放映的电影中添加数字水印，以便识别盗录者的位置；直播平台可以在直播视频中添加数字水印，以便识别盗播者的身份。

9.1DRM加密

DRM系统是指数字版权管理系统（Digital Rights Management System），是一种用于保护数字内容的版权和使用权限的技术和方案。DRM系统的工作原理如下：

• DRM系统主要包括三个模块：内容服务器、权限证书服务器和客户端。
• 内容服务器负责对数字内容进行加密、打包和分发，通常使用对称加密或非对称加密算法，如AES或RSA。
• 权限证书服务器负责生成和分发数字许可证，用于描述数字内容的使用权利、使用条件和解密密钥等信息，通常使用权利描述语言（Rights Expression Language）如XrML或ODRL。
• 客户端负责执行DRM功能，如获取数字许可证、验证用户身份、解密数字内容、强制执行使用控制等。
• DRM系统还可以使用其他技术来增强安全性和可追溯性，如数字证书、数字对象唯一标识符（DOI）、数字水印等。

DRM系统的工作流程如下：

• 用户登录内容服务器，浏览并选择自己感兴趣的内容；
• 用户向权限证书服务器申请购买自己选择的数字内容；
• 权限证书服务器根据用户的购买要求生成相应的数字许可证并发送给用户；
• 用户下载相应的加密数字内容；
• 客户端解密数字许可证和数字内容，确保用户按照授权使用。

DRM与加密的差异点分析：

• 加密是一种技术，是指将明文数据转换为密文数据，使得只有拥有密钥的用户才能还原出原始数据。加密可以用于保护数据的机密性、完整性和不可否认性。
• DRM系统是一种方案，是指利用加密和其他技术来保护数字内容的版权和使用权限，使得只有获得授权的用户才能按照规定的条件使用数字内容。DRM系统可以用于保护数字内容的价值、可控性和可追溯性。

因此，DRM系统和加密的区别在于：

• 目的不同：加密是为了保护数据本身，DRM系统是为了保护数据的使用；
• 范围不同：加密是一种单一的技术，DRM系统是一种综合的方案；
• 对象不同：加密可以应用于任何类型的数据，DRM系统主要应用于数字内容。

9.2 防盗链技术说明

常见的防盗链有refer、UA、时间戳，中心认证等，在流媒体场景中运用最多的是时间戳防盗链，简单说明下其原理：
时间戳防盗链是一种防止其他网站或用户非法使用或复制数字内容的技术，它通过在访问URL中添加过期时间和签名信息，来限制URL的有效期和合法性¹²。时间戳防盗链的工作原理如下：

• 内容提供商和CDN服务商需要事先约定一个密钥（key），用于生成和验证签名。
• 当用户请求某个数字内容时，内容提供商根据约定的算法，使用key、过期时间（T）和文件路径（path）等信息，生成一个签名（SIGN），并将T和SIGN作为查询参数附加在URL后面。
• 用户使用带有时间戳和签名的URL访问数字内容，CDN服务商根据同样的算法，使用key、T和path等信息，重新计算一个签名，并与URL中的SIGN进行比较。
• 如果签名相同且T没有超过当前时间，说明URL是合法的，CDN服务商就返回数字内容给用户；如果签名不同或T已经过期，说明URL是非法的或失效的，CDN服务商就拒绝访问并返回错误信息。
  
  时间戳防盗链的优点是：
• 安全性高：由于签名是使用密钥和加密算法生成的，很难被伪造或篡改¹²。
• 时效性强：由于URL有过期时间，可以防止URL被长期保存或传播¹²。
• 灵活性好：由于过期时间和签名可以根据不同的内容、用户和场景进行动态生成和调整，可以实现不同级别的访问控制。

10、长短视频关注点

流媒体对用户侧来说，其对长短视频的关注点可能有以下几个方面：

• 内容质量和多样性：用户观看视频的主要目的是为了娱乐休闲、学习技能、了解资讯等，因此他们希望视频内容能够有趣、有用、有价值，同时也能满足他们不同的兴趣爱好和需求。
• 播放体验和互动性：用户观看视频的过程中，也希望能够有流畅、清晰、稳定的播放效果，以及方便、快捷、个性化的操作功能²。此外，用户也喜欢在视频平台上进行评论、点赞、分享、弹幕等互动行为，增加自己的参与感和社交感。
• 消费意愿和信任度：用户观看视频的同时，也可能会受到视频内容中的商品或服务的吸引，产生购买或咨询的意愿。这时，用户会关注视频平台是否能够提供真实、可靠、优惠的消费信息和渠道，以及是否能够保障自己的消费权益。

根据不同的视频时长，用户对长短视频的关注点也可能有所不同：

• 对于短视频（一般指15秒至3分钟以内的视频），用户更加关注其内容创意和吸引力，以及播放速度和便捷性。短视频通常以碎片化、轻量化、移动化为特点，适合用户在任何时间、任何场景进行快速浏览和消费。因此，短视频需要在有限的时间内展现出鲜明的主题、风格和价值，吸引用户的注意力和兴趣。同时，短视频也需要能够快速加载和播放，减少用户的等待时间和流量消耗。
• 对于长视频（一般指超过10分钟以上的视频），用户更加关注其内容质量和深度，以及播放体验和稳定性。长视频通常以完整化、专业化、沉浸化为特点，适合用户在有充裕时间和专注力的情况下进行深入观看和学习。因此，长视频需要在较长的时间内展现出丰富的内容、细致的制作和专业的知识。同时，长视频也需要能够提供清晰、流畅、稳定的播放效果，避免用户在观看过程中出现卡顿、模糊、断开等问题。
• 总结需求如下：