多媒体技术原理及应用场景探索

多媒体的应用越来越广泛，主要的场景包括：点播、直播、实时音视频。深入了解其内在的技术原理，做到手中有粮心中不慌。

• 点播，用于离线视频的观看，是视频业务的主要场景，通常使用基于HTTP的.mp4、.m3u8或.mpd流媒体封装格式。
• 直播，主要使用.m3u8、.mpd或者.flv流媒体封装格式。
• 实时音视频，主要通过基于SRTP/SCTP的WebRTC协议进行推/拉流控制（小程序上暂不支持WebRTC，使用RTMP协议）

概览

多媒体技术应用，涉及的概念和技术比较多，大概将其划分为以下几个层面进行概述：

• 采集：包括视频、音频采集。视频采集主要通过摄像机进行连续成像，音频通过麦克风连续记录声波

• 编码：将采集到的成像模拟数据进行A/D转换并通过RGB编码，声波模拟数据进行A/D转换并通过PCM编码，这就是音视频的原始数据，体积会很大。字幕比较简单体积也很小，一般采用纯文本格式编码（如：WebVTT）。

• 压缩：无论是直播还是点播，媒体资源的编码是共通的，都是使用特定的算法或者格式将原始音频、视频、字幕数据进行压缩（如：MP3/ACC/Opus、H.264/H.265等）。

• 打包：点播或者直播观众端可以共用相同的流媒体协议（如：HLS、DASH等），将媒体打包成.ts、.mp4/m4a/m4v、.mp3/acc等文件片段进行传输，实现边加载边播并充分利用CDN进行分发；实时音视频对时延要求很高，一般都是采用SRTC或RTMP等实时传输协议进行媒体数据的传输。

• 封装：媒体资源（音频、视频、字幕）/片段需要进行合并/封装，常用的媒体封装格式包括.mp4、.m3u8、.mpd等；实时音视频使用实时传输协议，直接传输编码后的媒体数据。

• 转码：如果只是简单的点播或者直播，可以直接使用.mp4或者.m3u8媒体封装格式，具有良好的兼容性；简单的实时音视频也通过很少的代码实现推/拉流；但实际业务场景可能比较复杂，通常需要进行防盗链/加密或者精细化控制，这个时候就需要进行解密和转码，Web端可以通过Uint8Array对媒体数据进行转码，通过EME进行DRM解密，通过MSE对媒体数据进行重组，通过WebRTC进行推拉流控制。

• 播放：最终视频的播放通常都要通过video标签进行播放（原则上也可以通过canvas+audio，但是兼容性问题比较多，鲜有使用的），播放的过程是一个非常复杂的过程，大体是上述过程的逆序。视频会被解压缩并还原成RGB原始格式，逐帧显示到屏幕上，音频数据也会没解压并还原成PCM原始数据，然后通过D/A转换并驱动扬声器发声。

采集

音频采集

声音的本质是机械波，当声波通过介质（如：空气、固体、液体等）达到接收端（如：话筒、耳朵），引起响应的震动，就能被感知/听到。

声波有两个基本属性：频率和振幅。振幅对应声音的音量，频率对应声音的音调。

当声波传递到话筒时，话筒里的碳膜会随着声音一起振动，而碳膜下面是一个电极，碳膜振动时会触碰电极，接触时间的长短跟振动幅度有关（即：声音响度），这样就完成了声音信号到电压信号的转换。后面经过电路放大后，就得到了模拟音频信号（连续的电压或电流），留声机或是磁带记录的就是这种模拟信号。计算不能直接处理模拟信号，所以需要进行A/D转换，以一定的频率对模拟信号进行采样得到离散的波形振幅数值，然后再进行量化和存储，就得到了数字音频数据。

视频采集

视频的本质是一帧帧（张）连续的图片，按照一定的频率逐帧排列。视频采集的过程就是把通过镜头的光学图像投射到传感器上，然后光学图像被转换成电信号，然后通过A/D转换得到数字信号，数字信号交由DSP芯片加工处理得到最终的图片数字数据。如果是录屏的话，则直接读取显示缓冲区的RGB数据即可。

编码

音频编码

最常见的A/D转换是通过脉冲编码调制PCM。要将连续的电压信号进行采样和量化，转换为PCM，量化指标主要包括以下几个维度：

• 采样频率：单位时间内采样的次数。通常采样频率越高，越接近真实的情况，声音就越好，同时数据量就越大。人耳能够感受到的音频范围在20~20KHz之间，普通的FM一般采用22KHz，CD采用44.1KHz，采样频率一般都不超过48KHz（DVD采用的采样频率）。
• 采样位数：每个采样点用多少比特表示。比特位越多，可表示的数值范围越大，量化后的波形越接近原始波形，音质就越好，同时数据量也会越大。移动通信一般采用8比特，CD采用16比特。
• 声道数量：如果每次采样记录一个波形数据称为单声道，两个波形数据称为双声道（立体声），播放的时候每个声道对应一个喇叭。声道用于模拟发声的位置，通常采用的都是立体声，在电影院等特定场景需要多声道，以便能够更真实地模拟实际场景。
• 采样时长：音频数据的大小（Byte）=采样频率（Hz）x采样时长（S）x（采样位数/8）x声道数量

下面我们看一下具体的采样案例：

其中红色的曲线是要采集的声音波形，蓝色的点是采样量化以后的PCM数据。横轴是时间，对应采样频率，采样频率越高，数据越秘籍，越越接近原始波形；纵轴是采样位数，上图是4位，能表示的数值范围是0-15，位数越多数据越精细化，越接近原始波形。

PCM数据的存储比较简单，没有头部信息，将全部采样数据按照一定的顺序（如：双声道采用LRLR）依序拼接，数据不经过任何压缩处理。

视频编码

采集得到的原始视频帧数据通常会被编码为RGB或者YUV格式。 RGB三个字母分别代表了红（Red）、绿（Green）、蓝（Blue），这三种颜色称为三原色，将它们以不同的比例相加，可以产生多种多样的颜色。 RGB图像中，每个像素点都有红、绿、蓝三个原色，其中每种原色都占用8bit，也就是一个字节，那么一个像素点也就占用24bit，也就是三个字节。一张1280x720大小的图片，就占用 1280x720x3/1024/1024=2.63MB存储空间。

YUV颜色编码采用的是明亮度、色度和浓度来指定像素的颜色。

YUV与RGB的相互转换如下：

以上转换的格式就是YUV 4:4:4采样，即完全采样。 转换为YUV是为了进行采样存储，YUV有很多种采样算法，我们以YUV 4:2:2为例来看一下是怎么实现体积压缩的。

假设图像像素为：[Y0 U0 V0]、[Y1 U1 V1]、[Y2 U2 V2]、[Y3 U3 V3]

YUV 4:4:4采样如下：

其中，Y分量用叉表示，UV分量用圆圈表示。 采样的码流为：Y0 U0 V0 Y1 U1 V1 Y2 U2 V2 Y3 U3 V3 最后映射出的像素点依旧为：[Y0 U0 V0]、[Y1 U1 V1]、[Y2 U2 V2]、[Y3 U3 V3] 可以看到这种采样方式的图像和RGB颜色模型的图像大小是一样，并没有达到节省带宽的目的。

然后我们再看一下YUV 4:2:2采样：

采样的码流为：Y0 U0 Y1 V1 Y2 U2 Y3 V3 其中，每采样过一个像素点，都会采样其Y分量，而U、V分量就会间隔一个采集一个。 最后映射出的像素点为 [Y0 U0 V1]、[Y1 U0 V1]、[Y2 U2 V3]、[Y3 U2 V3]

采样的码流映射为像素点，还是要满足每个像素点有Y、U、V三个分量。 但是可以看到，第一和第二像素点公用了U0、V1分量，第三和第四个像素点公用了U2、V3分量，这样就节省了图像空间。 一张1280x720 大小的图片，在YUV 4:2:2采样时的大小为：（1280x720x8+1280x720x0.5x8x2/8/1024/1024=1.76 MB，相比于RGB节省了三分之一的存储空间。

注意：YUV不完全采样本身是有损的，之所以能够这么做，主要有两个原因：其一，人眼对明亮度敏感但对色度/浓度不敏感；其二，相邻像素点之间的色相/浓度往往是比较接近的，直接复用对最终的图片质量影响很小。

压缩

不管是原始音频编码PCM还是视频编码RGB/YUV，存储的是原始编码数据，没有经过任何压缩处理，体积很大，不利于存储或者传输。 而音频及视频都是有其独特的数据特征的，使用通用的zip或者rar也能压缩一定的体积，但是效果不尽人意，所有出现了大量的专门针对音频或者视频的压缩算法。

音频压缩

我们以CD音质为例，采样深度为16位，采样频率为44.1kHz，声道数为2，那么：

• 比特率=采样率x采样深度x通道数=44100x16*2=1378.123kbps
• 3分钟音频大小=3x60x1378.125/8/1024=30.28MB

我们日常听歌使用的.mp3一首歌大概也就3-5MB，这就是压缩的作用了。 压缩分位两类：无损压缩和有损压缩。无损压缩通过优化数据的排列或组合实现，优点是可以根据规则完整地复原数据，缺点就是压缩率有限。有损压缩是通过去除一些非必要或者冗余的数据达到减少数据的目的，优点是压缩率比较高，缺点就是有部分信息丢失。

常用的无损音频压缩格式包括：

• FLAC, Free Lossless Audio Codec：免费开源的无损音频编码，能减少50-70%的体积，跟压缩选项有关。源码在这里

• ALAC, Apple Lossless Audio Codec：苹果无损音频编码，已于2011年10月26日以Apache License协议开源，能减少40-60%的体积。源码在这里。

有损音频压缩格式包括：

• MP3, MPEG-1 Audio Layer III or MPEG-2 Audio Layer III：是最常见的音频编码格式，兼容性最好，其压效果可以通过调整比特率实现数据大小与音质之间的平衡（PS：与MP3相关的专利已于2017年4月16日全数过期）。即使MP3是一种很优秀的压缩格式，但由于设计的限制（比特率最大320kbs，采样频率最高48kHz，频谱小于15kHz等），目前已经在逐步被一些新的编码格式（如：ACC、Opus）取代，比如hls中就不再推荐使用mp3编码音频。
• ACC：被设计作为MP3的继任者，在相同比特率下，通常会比MP3有更好的声音质量。支持48个高至96kHz的全宽带声道，16个120Hz的低频声道，不多于16个耦合通道及数据流。目前已经成为很多平台（YouTube、iPhone等）的默认选项，并得到越来越多平台的支持。
• Opus：是一个开放格式，比MP3、ACC等常见格式有更低的延迟和更高的压缩率，而且使用上没有任何专利或限制，但目前支持度比较有限，Mac/iOS上只有.caf容器支持。编码标准文档在这里。

音频编码格式非常多，每一种都涉及大量的细节，在此不展开讨论，更多音频压缩格式参考Audio file format。

视频压缩

视频采集得到的原始数字数据会被简单地编码为RGB或者YUV，体积很大。以1280x720尺寸视频为例，假设视频帧率为30，那么一秒钟的视频采用RGB编码的大小为：30x2.63MB=4734MB=78.90MB，即使使用有损的YUV 4:2:0编码，也会有39.45MB，在线观看这样的视频至少需要315.6Mb的带宽，这对于绝大多数用户来说简直是天文数字，这还只是普通高清视频，2K或者4K就更夸张了。

实际应用中，需要将数据进一步压缩，以便存储、传输和使用。 视频压缩算法很多，如：H.264、H.265、VP8、VP9等，更多的编码格式参考Video coding format。

下面我们通过目前使用最广泛的H.264算法介绍一下视频压缩的过程。

• 帧内压缩：处理空间冗余，采用预测编码。将一张图片分成16x18、8x8或4x4的块，因为一张图片的一个相邻区域通常不会有太大的变化，所以可以预测这个块内的值都是同一个值R0，然后再计算块内其他每个点真实值与预测值的差，仅记录有差值的点即可，这样就减少了数据的大小，解码的时候通过预测值及差值就可以完整地恢复原来的数据，所以这个过程是无损的。
• 帧间压缩：处理时间冗余，视频前后帧之间通常绝大部分是相同，只有少部分运动的对象位置会有变化，所以可以通过记录差值而不是全部信息来减少体积。H.264编码中，将视频帧分成了如下几种类型：
  • I帧：关键帧，是一个张完整的画面，可以独立解码，供其他帧参考
  • P帧：前向预测帧，无法独立解码，需要参看前面的I帧或者P帧才能还原画面
  • B帧：双向预测帧，无法独立解码，需要参考前面的I/P帧和后面的I/P帧才能还原画面
  • IDR帧：也是关键帧，可以独立解码，与I帧的区别是，IDR帧强制后续的帧不再参考IDR帧之前的帧，前面的缓冲将被清空，重新开始一个序列，用于避免数据异常后持续影响后续的帧。
• DCT变换：数据预处理，利用DCT变换具有很强的“能量集中”特性，经过DCT变换后，数据能量聚集在矩阵的左上方（低频信号），低能量的数据（高频信号）聚集在右下角，这个转换过程本身并没有减少数据。
• 量化处理：对DCT转换以后的数据进行量化处理，是一个有损过程，会将不太影响图片质量的高频信号（右下角）变为0，从而减少体积。
• CABAC压缩：处理统计冗余，基于统计分布的重新编码压缩，属于无损压缩。

打包

媒体资源通常体积会比较大，有些甚至是动态新增的（比如直播流），所以会有一系列的流媒体协议（如：hls、dash等）用于预定媒体资源的分段传输方式，以便能够边下边播，并能够利用CDN进行分发。常用的打包方式有：ts, MPEG-2 Transport Stream和fmp4, fragmented MPEG-4。不管是ts还是fmp4都可以将音频和视频数据一起进行打包，音频和字幕也是可以单独进行传输而不用跟视频资源一起打包的。

封装

音频、视频从采集到编码到压缩，都是分开处理的，字幕更是一个独立的存在。在需要传输并呈现给用户的时候，我们需要将相关的音频、视频、字幕进行的封装，这样才能达到同步的效果。把这种存放音频、视频、字幕的容器叫做封装格式，就是我们常见的一些视频文件格式，如：.mp4、.m3u8、.mpd、.flv等。

转码

常用的标准视频封装格式（如：.mp4、.m3u8等），浏览器默认的video播放器就可以直接播放，整个的解封/解码/转码/同步/渲染全部由浏览器原生支持。如果是自定义的视频流（自定义加密）或者需要做浏览器兼容，则需要进行数据的解码/转码/同步等流程控制，其目的就是要把流媒体数据重新组装成播放器能够正常播放的数据格式。

Web提供了一系列的标准接口，可以用于操作视频流数据，通过Uint8Array对媒体数据进行解码或重组，通过EME进行DRM解密，通过MSE对重组的媒体数据关联到播放器。

常见的两种播放器（hls.js和flv.js）就是利用这些标准接口实现对hls和flv视频流到mp4的转码，并使用默认video播放器进行播放的，两者的工作原理类似，我们看一下hls.js的技术架构即可一探究竟。

播放

上面提到，标准的视频封装格式，浏览器默认的video标签就可以直接播放了，在移动端.mp4、.m3u8都有良好的兼容性，PC端chrome浏览器不支持.m3u8，需要通过MSE协议进行扩展支持，有非常成熟的播放第三方库（如：hls.js、video.js等），.flv在移动端和PC端没有原生支持，逐步被淘汰，不过由于历史原因，也还有大量的应用，目前基本不再使用flash技术，也都是通过MSE协议进行扩展支持，也有比较成熟的第三方库（如：flv.js）可以很好地支持。

说完了常规的标准封装格式，我们来说一点非常规的情况，毕竟业务是多种多样，需求是千变万化的。非常规的需求主要体现在两个方面：防爬和个性内容注入，涉及到内容修改的场景都需要定制化的播放流程。个性化的内容注入包括提示信息或者广告内容等，应用场景也还比较有限，广告内容一般是阻断式的，防止用户跳过。下面重点说一下防爬机制。

防爬

优质的视频资源生产都是有刚性成本的，大量的优质资源往往是公司的核心资产，甚至是核心堡垒。 所以，对视频资源的防爬是视频服务平台应该重点防范的事项。防爬归根到底也就两个手段：加密和频控。 加密是为了防止竞争对手低成本获取资源，频控是预防资源被大规模盗取。

频控可以很简单，比如限制特定IP/用户的访问频次，或者通过给资源链接加验签防止盗链。当然也可以很复杂，可以根据用户的访问指纹/时间/频率等指标，建立用户行为模型，智能识别机器人抓取行为，频控虽然是防爬取最有效的方案，但其本身跟多媒体技术关联不大，不展开讨论，下面重点聊一下加密。

加密答题上可以分为两类：标准加密和自定义加密。

下面我们以hls协议为例介绍加密过程，hls格式将多媒体数据封装成一个纯文本的.m3u8索引文件（参考M3u File Format），索引文件会列出媒体资源的分段数据的打包流媒体资源（如.ts），这个.ts文件就是可以整体进行对称加密的。在生产hls资源的时候，可以指定加密算法及秘钥key，在生成的索引.m3u8索引文件中会有一个#EXT-X-KEY标签，用于制定解密算法及获取秘钥key的接口地址，播放器加载完索引文件后就回去请求接口获取解密密钥key，后续所有的.ts媒体资源下载完以后就可以通过制定的解密算法及密钥key完成数据的解密还原。这些过程都是hls协议本身就支持的，所以整个播放过程不需要特殊的处理。 当前如果是通过MSE扩展协议进行播放的话需要自行处理，hls.js播放器默认也是支持的。

我们看一下通过.mp4视频文件生成加密.m3u8的例子

  # 0. 安装ffmpeg
  # brew install ffmpeg

  # 1. 准备秘钥文件（encrypt.key）
  # 内容是任意字符串

  # 2. 准备关键信息文件（key_info.key）
  # 格式如下：
  # 第一行：请求URL，用于客户端获取密钥文件（）
  # 第二行：密钥文件文件路径（./encrypt.key）
  # 第三行：加密偏移向量IV（可选，默认0x00000000000000000000000000000000）

  # 3. mp4文件转码并加密
  # -hls_key_info_file 制定关键信息文件路径
  # -f 转换后的格式
  # -hls_time 每个ts片段的时长
  ffmpeg -i mp4.mp4 -hls_key_info_file ./key_info.key -hls_time 10 -f hls mp4.m3u8

  # 4. 会生成一个`.m3u8`文件及n个`.ts`文件
  # `.m3u8`文件的格式如下：
  #EXTM3U
  #EXT-X-VERSION:3
  #EXT-X-TARGETDURATION:17
  #EXT-X-MEDIA-SEQUENCE:0
  #EXT-X-KEY:METHOD=AES-128,URI="http://127.0.0.1:3000/key",IV=0x00000000000000000000000000000000
  #EXTINF:16.666667,
  mp40.ts
  #EXTINF:8.333333,
  mp41.ts
  #EXTINF:5.033333,
  mp42.ts
  #EXT-X-ENDLIST

  # 5. 客户端播放
  # 首先，会拉取`.m3u8`文件并解析出URI
  # 然后，请求请求URI获取密钥
  # 最后，会拉取.ts文件并用获取到的秘钥进行解密并播放

这种标准加密的流程，可以解决流媒体资源片段被重用的问题，结合秘钥接口进行频控，可以较好地保护媒体资源被低成本爬取。 但这种方案逆向成本并不大，核心还是要依赖频控，防止被大规模爬取，加密本身也仅限于一定程度防止对.ts资源的盗链。

上面说的标准加密基本上可以说只能放君子，难以防小人，如果有心爬取，只需要对加密原理了解一下就可以实施，成本很低。 所以，实际的业务中用的更多的是自定义加密，刚才提到的资源地址做验签其实也算是自定义加密范畴，但比较简单不再赘述，我们来说一下媒体内容的加密。视频内容加密包括两种：所以文件加密和视频内容加密。原理都一样，都是对内容进行对称加密，核心在于如何确保秘钥的安全，不同点在于成本，对索引文件加密对性能影响很小，对媒体流数据加密解密有一定的性能开销，也需要处理更底层的数据，对播放器技术要求更高。

在纯H5的场景，密钥的安全性保障比较困难，常用的手段无非就是对核心代码进行混淆、转换、干扰、方调试等处理，加大逆向的成本，参考JavaScript Obfuscator Tool，国内一些大厂也有一定程度的引用，比如B站就使用了sojson这样的工具对加密的过程进行混淆。

在Native环境其实也面临类似的困境，默认的.apk或.ipa逆向成本并不比.js高多少，所以行业中就催生了应用加固的行当。各大平台厂商都提供了应用加固的服务，如：百度应用加固、腾讯应用加固、阿里应用加固等等，技术原理参考APP加固技术近几年的变化。上加固处理，可以极大地提高逆向成本。这就是为什么在hybrid场景，一般会依赖Native完成加解密操作的原因，相对比较安全。

以上都属于应用级别的安全机制，原则上都是能够被逆向的，没有绝对的安全。关于数字内容安全，还有更高安全级别的标准方案，参考数字版权管理，在国外很多知名厂商都有应用，如：亚马逊、AT&T、Apple Inc.、Netfix、Google、BBC、微软等，国内云厂商也有一定的支持，参考腾讯云「DRM视频加密技术-数字版权管理解决方案」，阿里云「DRM加密」。DRM的原理是将安全秘钥的协商和解密过程由应用转移到了更底层（浏览器/操作系统），甚至直接由专门的硬件设备进行支持，安全性相对更高，但仍然存在安全缺陷，参考Chrome CDM框架重大缺陷，DRM视频轻易复制、Google's Widevine L3 DRM cracked by a security researcher。

综上，不管用什么机制或策略，没有绝对的安全，都只是相对安全。在特定业务场景下，需要结合资源的重要程度选择适当的安全机制，以达到一个合理的性价比。国内主流的做法还是基于水印 + 自定义的加密 + 频控组合方式做自我保护，这也算是性价比比较高的方式了。

应用

点播和直播在技术和协议栈上目前基本是一致的，可以互通，实时音视频的差异比较大，除了最基本的音视频编码相同以外，整个传输控制流程都完全不一样。

点播和直播目前常用的媒体流协议包括：MP4、HLS、DASH、RTMP，这几种技术的对比如下：

方案	优势	劣势
HLS	支持度高；HTTP协议；自适应网络	专利保护（PC Chrome不支持）；
DASH	开源协议；HTTP协议；网络自适应	兼容性不好（依赖MSE）；
FMP4	兼容性好；HTTP协议；	不能自适应网络；
RTMP	低延迟；	不能自适应网络；不能利用CDN；使用TCP协议；逐步被放弃；

目前HLS应该是主流的选择，因为其在移动端有良好的兼容性，PC端也有成熟的兼容方案（如：video.js），还有一个原因是hls也便于进行加密处理。

实时音视频目前基本都是通过WebRTC实现，这是一套完整的解决方案，与普通的视频服务关联不大，下面重点聊一下。 WebRTC核心的亮点是低延时，这对于实时音视频是最核心的诉求，影响实时音视频体验的延迟因素比较多，我们重点关注网络相关的传输延迟，主要包括：接通延迟、通话延迟。

• 接通延迟：被叫方接受通话后，多久能收到多方的音视频，这个延迟用户体验感官比较明显，如果延迟高就会出现接通后长时间没有反应
• 通话延迟：体现为在通话过程中画面或者声音不连贯，这是影响体验最重要的方面，大多数优化也是也是针对通话延迟的

我们看一下各种实时传输协议的延迟情况：

延迟	RTMP/TCP	RTMP/QUIC	WebRTC
接通延迟	+通知延迟（1RTT） +握手延迟（3RTT） +发送延迟（0.5RTT） +转发延迟（0.5RTT） +控制协议延迟（2+RTT） +TCP慢启动	+通知延迟（1RTT） +握手延迟（3RTT） +发送延迟（0.5RTT） +转发延迟（0.5RTT）	+通知延迟（1RTT） +发送延迟（0.5RTT）
通话延迟	+发送延迟（0.5RTT） +转发延迟（0.5RTT） +TCP对首阻塞	+发送延迟（0.5RTT） +转发延迟（0.5RTT）	+发送延迟（0.5RTT）

理想情况下（P2P通信），WebRTC协议在通话过程中只有0.5RTT的时延。在实际应用中大多需要通过服务端进行中转（并不主要因为P2P连通问题，主要是需要进行视频存档或者进行转码），会有1RTT的时延。

WebRTC的通信连接/通信过程依赖一个ICE框架完成，整体架构如下：

• STUN Server: 负责IP发现及NAT类型检测及NAT穿透，检测过程如下：

NAT穿透不是任何情况都能成功的，根据之前业务中的实际统计情况，成功率大概在89%左右，各NAT类型原则上能否穿透的关系如下：

• TURN Server: 负责在无法完成P2P连接的情况下中继媒体数据，实际业务场景还会涉及到录制、转码、合成等一些列的业务需求，所以通常会是一个比较重的服务。

• Gateway Server: 属于信令服务，负责建立通信双方信息（如：Candidate、SDP等）交换，话双方的通信，房间的创建、状态维护及销毁等过程的协调和管理。

除了以上几部分，实际业务中通常还有单独的业务服务（Service Server），用于通讯各方的通信通知（确定谁跟谁通信）。

PS：SRUN Server和TURN Server是标准化的服务，有成熟的公共服务可以选用，参考STUN+TURN servers list，公共的服务一般只用于demo，为了稳定及数据隐私，通常业务需要自行实现，有开源代码可用，参考Free open source implementation of TURN and STUN Server。

WebRTC接通/断开的时序大致如下：

PS: 关于WebRTC部分，如果想了解更多细节，建议参看《WebRTC音视频实时互动技术：原理、实践与源码分析》

参考

• Video coding format
• Analog-to-digital converter
• Digital-to-analog converter
• Pulse-code modulation
• WebVTT
• MP3
• ACC
• FLAC
• ALAC
• Opus_(audio_format)
• Advanced Video Coding
• High Efficiency Video Coding
• HTTP Live Streaming 2nd Edition draft-pantos-hls-rfc8216bis-09
• Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats
• Information technology — Coding of audio-visual objects — Part 14: MP4 file format
• Information technology — Generic coding of moving pictures and associated audio information — Part 1: Systems
• HLS vs DASH vs MP4 vs MPEG-TS Linear vs RTMP for Streaming
• Packaging HTTP Live Streaming with fragmented MP4 (fMP4 HLS)
• RTP: A Transport Protocol for Real-Time Applications
• WebRTC
• Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
• Encrypted Media Extensions
• Digital rights management
• APP加固技术近几年的变化
• Chrome CDM框架重大缺陷，DRM视频轻易复制
• 计算机如何“看懂”图片？达摩院提出新的研究方法
• 《WebRTC音视频实时互动技术：原理、实践与源码分析》