MPEG是动态图像专家组（Moving Picture Experts Group）的简称，它可以指：

1. 一个成立于1988年的，研究视频和音频编码标准的组织
2. 一系列音视频编码标准，包括MPEG-1、MPEG-2、MPEG-3、MPEG-4、MPEG-7以及正在制定中的MPEG-21

MPEG发布的第一个视频和音频有损压缩标准，它采用了块方式的运动补偿、离散余弦变换（DCT）、量化等技术，并为1.2Mbps传输速率进行了优化。其主要是为光盘类介质制定，随后被作为VCD（352×240，1.15mbps比特率）的核心技术。

MPEG-1标准由五个部分组成，其中第二部分、第三部分规定了视频、音频编码标准。

MPEG-1音频编码标准分为三代，逐代提升了压缩比。其中最著名的第三代协议被称为MPEG-1 Layer 3，简称MP3。

一个MPEG-1视频序列，包含多个图像群组（Group Of Pictures，GOP），每个GOP包含多个帧，每个帧包含多个slice。GOP由两个I帧之间的帧构成。

帧是MPEG-1的一个重要基本元素，一个帧就是一个完整的显示图像。帧的种类有四种：

1. I帧（Intra Frame）即帧内帧，也叫关键帧。这类帧能够被独立的解码，可以看做是基线Profile的JPEG图像
2. P帧（Predicted Frame）即预测帧，也叫向前预测帧（ Forward-predicted Frames）。P帧利用视频中的时域冗余（ Temporal Redundancy）来提高压缩比。P帧仅仅存储相对于它前面的那一帧的图像的差异（基于运动补偿和运动估计算法）部分
3. B帧（Bidirectional Frame）即双向预测帧，也叫向后预测帧（Backwards-predicted Frames）。B帧类似于P帧，但是它同时可以基于前一帧、后一帧进行预测。由于B帧可能依赖于“未来”的帧来解码，它会引入额外的编解码延迟
4. D帧（Direct Frame）即指示帧。仅仅由DC转换系数编码而成，因此其质量较低。D帧不会被I/P/B帧引用，仅仅在快速预览时有用。D帧实际应用的很少，后续标准也没有包含它

通常用来为广播信号提供视频和音频编码，包括卫星电视、有线电视等。MPEG-2经过少量修改后，成为DVD产品的核心技术。

MPEG-2的视频部分，提供了对隔行扫描（广泛应用在广播电视领域，在CRT类显示器上，比相同帧率的逐行扫描更加不会引起视觉闪烁）视频显示模式的支持。

高级音频编码（Advanced Audio Coding，AAC）在MPEG-4发布前，作为MPEG-2的附加内容发布。

MPEG-2定义了两种复合信息流：传送流（TS）和节目流（PS：Program Stream）。TS流与PS流的区别在于TS流的包结构是固定长度的，而PS流的包结构是可变长度的。 PS包与TS包在结构上的这种差异，导致了它们对传输误码具有不同的抵抗能力，因而应用的环境也有所不同。TS码流由于采用了固定长度的包结构，当传输误码破坏了某一个TS包的同步信息时，接收机可在固定的位置检测它后面包中的同步信息，从而恢复同步，避免了信息丢失。而PS包由于长度是变化的，一旦某一PS包的同步信息丢失，接收机无法确定下一包的同步位置，就会造成失步，导致严重的信息丢失。因此，在信道环境较为恶劣，传输误码较高时，一般采用TS码流；而在信道环境较好，传输误码较低时，一般采用PS码流。由于TS码流具有较强的抵抗传输误码的能力，因此目前在传输媒体中进行传输的MPEG-2码流基本上都采用了TS码流。

本来的目标是为HDTV提供20-40Mbps视频压缩技术。在标准制定的过程中，委员会很快发现MPEG-2技术足以获取类似的效果，因此将其合并到MPEG-2，成为MPEG-2的延伸。

主要用途在于网上流、光盘、语音发送，以及电视广播。 MPEG-4吸收了MPEG-1、MPEG-2以及其它相关标准的很多特性。

MPEG-4仍然在进化之中，其关键组成部分是：

1. 第二部分：定义了一个编码器标准，DivX、Xvid都是该标准的实现
2. 第十部分：即MPEG-4 AVC（高级视频编码， Advanced Video Coding），也称H.264。开源编码器x264、Quick Time7以及蓝光都遵循此标准

目前H.264已经成为高精度视频录制、压缩和发布的最常用格式之一。它不是单个标准，而是由多个配置（Profile）构成的标准家族。每个编码器至少需要支持一种H.264配置。

H.264能够在低带宽情况下提供优质视频，同等视频质量下，它仅仅需要MPEG-2/H.263/MPEG-4 Part2的一半甚至更少的带宽。

视频编码是压缩、解压缩数字视频信号的处理过程。数字视频是真实世界中视觉影像的基于空间、时间的采样。

通常情况下，在某一特定时刻对整个场景采样，形成帧（Frame），或者，对场景进行隔行采样，所谓场（Field）。采样总是按照一定的时间间隔进行，例如每1/25秒一次采样，这样连续的采样就形成了动态的视频信号，每秒钟采样的次数叫做帧率（Frame Rate）。为了表示彩色的场景，通常需要三个分量（Component）或者一系列的采样。

程序需要度量场景还原的精度，这样才能评估自身的性能。评估逻辑比较困难，原因是场景的质量很大程度上要考虑人的视觉心理特征，不同的人的视觉心理特征是不同的。

真实世界中的视觉场景，通常由多个物体构成。这些物体有各自的形状、深度（景深）、纹理、照度。自然视觉场景的颜色、亮度呈现出平滑变化的特征。

对自然视觉场景进行数字化处理时，程序需要关注两个维度：

1. 空间特征：单个场景内部纹理的变化特征、物体的数量和形状、颜色
2. 时间特征：物体移动、明度变化、镜头/视点的切换

自然视觉场景在空间、时间上都是连续的。要以数字化的方式呈现这种场景，需要：

1. 空间采样：通常在场景的图像平面上设立矩形网格（Grid），采集离散的点（分辨率，帧大小），这些点分布在Grid的交叉处
2. 时间采样：按照一定的间隔对帧或者帧的分量进行采样（帧率）。对于低质量的视频通信来说了，采样率通常在10-20FPS之间，这种级别的FPS下急速移动的物体不容易平滑显示；25-30FPS是典型的电视电影采样率；高达50-60FPS的时间采样下移动物体会非常平滑，代价是过高的数据率（Data Rate）

时空采样的示意图如下：

每个时空采样点 —— 叫做图像元素（Picture Element）或者像素（Pixel）——采用1-N个数字来表示。这些数字包含了亮度（Brightness）/照度（Luminance）、颜色信息。注意，从视频采集设备（如CCD）直接获得的采样阵列是模拟视频电信号。经过处理后才能变成像素表示的数字信号。

这两个概念是对同一事物的不同表述。

照度是一个客观性的概念，即以特定角度射向指定区域的光照强度。单位是坎德拉（Candela）/平方厘米（cd/cm2）。通过调整，不同显示器可以达到相同的光照强度。

亮度则是一个主观性的和光照相关的概念。显示器可以调整亮度，但是不好度量，只能自己感觉。

视频信号采样可以由：

1. 一系列连续的完整的帧构成，所谓逐行采样（Progressive Sampling） 
2. 一系列交错的场构成，所谓隔行采样（Interlaced Sampling）

隔行采样时，通常在每个时间采样间隔中，两个场（分别由奇数行、偶数行构成）都进行采样。奇数行构成的场叫做Top Field，偶数行构成的场叫做Bottom Field。

隔行采样的优势是，提供两倍的帧率。根据人类的视觉停留的特点，可以避免产生画面抖动。

相关文章：图像处理知识集锦

大部分数字视频程序依赖于显示彩色图像，因此，需要一种机制来捕获、呈现颜色信息。单色图像仅仅需要一个数字来表示像素点的亮度/明度。彩色图像则需要至少三个数字来表示一个像素。

所谓色彩空间，就是用来描述亮度/照度（Brightness, Luminance or Luma）、颜色信息的方法。

这种色彩空间中，一个采样点利用三个数字表示，分别代表红色、绿色、蓝色的相对比例。由于RGB是三原色，因而它们的组合可以形成任何颜色。RGB的各分量取值越大，则亮度越高。

RGB色彩空间中，颜色信息、亮度信息是融合在一起的。然而，人类视觉系统（HVS）的特点是，对于亮度比颜色更加敏感。为了节省空间，可以把亮度信息分离出来，然后以较低的分辨率存储颜色信息，较高的分辨率存储亮度信息。

YCrCb（也叫YUV）就是一种分离亮度的色彩空间。其中Y是明度分量，Y根据根据RGB的权重计算出来：

Y = kr R + kgG + kbB        k*是颜色分量的权重因子

颜色信息则可以利用色差（Chrominance/Chroma）分量表示，每个色差分量即RGB与Y的差值：

Cr = R − Y
Cb = B − Y
Cg = G − Y

由于Cr+Cb+Cg求和是常量，因此，实际上仅仅需要记录两个色差信息就足够了。在YCrCb空间中，仅仅明度、红色差、蓝色差信号被传输。

YCrCb可以使用较低分辨率来描述Cr、Cb，由于HVS的特点，这样做图像质量不会受到太大影响。

视频编码的目的是实现视频压缩，这样视频信号更加容易存储和传输。没有压缩过的原始视频需要很高的比特率，对于标清视频来说，大概256pbps。

压缩总是要和解压缩配对使用，因此视频编码器通常包含压缩、解压缩两套算法。

某些类型的数据包含统计冗余（Statistical Redundancy），可以被无损的压缩/解压缩。不幸的是，要实现无损的图像、视频压缩，则压缩比会很低，因而在这些领域常常使用有损压缩。

视频的有损压缩原则是基于主观冗余（Subjective Redundancy），即在不太影响观察者的主观感受的前提下，信息可以被删除。大部分视频编码器同时关注空间、时间上的冗余：

1. 在时域上，相邻的场景总是有很大的相似性，特别是在高帧率的情况下
2. 在空域上，类似于静态图片的压缩算法

H.264和其它流行视频压缩算法——例如MPEG-2、MPEG-4、H.263——共享了一系列通用的特性。例如预测、基于块的运动补偿（Motion Compensation）。

编码器的一般工作流程如下图所示：

编码器使用一个模型（Model）来表示视频源，一个搞笑的编码算法允许解码器尽可能保真的还原视频流。理想情况下，编码后的视频应该占据尽可能少的比特，同时尽可能的保真，当然这两个目标通常是冲突的。

编码器主要包括三个功能单元：预测模型、空闲模型、熵（Entropy，信息论中的熵是信息量的度量，熵越高包含的信息量越大）编码器：

1. 预测模型的输入时原始视频序列。预测模型利用邻近的视频帧/图像采样之间的相似性，来降低信息冗余。典型的做法是构造当前帧/视频数据块的预测（Prediction）。对于H.264来说，预测可以是：
   1. 帧内预测（Intra Prediction）：通过根据当前帧内的邻近的图像采样进行空间推断（Spatial Extrapolation），构造出预测
   2. 帧间预测（Inter Prediction）或者叫运动补偿预测（Motion Compensated Prediction）：通过补偿不同帧之间的差异构造出预测
2. 预测模型的输出是帧残余（Residual Frame）—— 从当前帧中减去预测，附加上说明帧间/帧内预测如何进行的模型参数
3. 残余帧输入到空间模型，后者利用残余帧中的采样之间的相似性，降低空间冗余。H.264的做法是对残余帧进行转换并对结果进行量化。转换后的残余帧变为量化转换系数（Quantized Transform Coefficients）表示——量化移除了采样中不重要的数据以实现对残余帧的进一步压缩
4. 预测模型的参数：帧内预测模式、帧间预测模式、运动向量（Motion Vectors），以及空间模型的参数，一起被熵编码器进一步压缩，移除统计学冗余数据。例如，反复出现的向量、系数被替换为简短的二进制代码。熵编码器产生容易传输的比特流或者文件
5. 压缩完成后的视频序列，包括编码后的预测参数、编码后的残余系数，外加头信息

预测模型处理的对象是当前帧/场中的一系列图像采样，其目标是减少数据冗余，其手段是构建一个预测，并将其中当前数据中减去。预测可能从先前已经编码好的帧中推导，此所谓时域预测；预测也可能从当前帧/场中已经编码好的图像采样中推导，此所谓空域预测。

预测模型的输出是一系列残余/差异样本。预测处理越精确，则残余样板中包含的Energy（信息量）越少。

被预测的帧的产生依赖于参考帧（Reference Frames），参考帧可以是过去或者未来的帧。帧预测的精度通常可以通过运动补偿——补偿当前帧和参考帧中由于物体移动产生的差异——的方式提高。

最简单的时域预测，是使用前一个帧（预测器，Predictor）来预测当前帧，从当前帧中减去预测帧，直接得到帧残余：

这种预测方法的缺点是，残余的信息量很大。这些残余很大程度上都是因为物体运动导致的，因而更好的时域预测算法能够通过自动补偿，减少不必要的信息量。

帧之间的差异，主要原因包括：物体运动、未覆盖（Uncovered）的区域、光照变化。

物体运动的类型包括：

1. 死板的平移，例如汽车运动
2. 变形运动，例如人说话时脸部的运动
3. 镜头运动，例如平移、倾斜、缩放、旋转

未覆盖区域的类型包括：

1. 由于物体移动而显露出来的背景区域

除了未覆盖区域、光照变化之外的其他帧间差异，都属于帧间像素移动。估算每个像素在帧间的移动轨迹（Trajectory）是可能的，像素移动轨迹构成的场被称为光流（Optical Flow）：

上图是前面前帧、后帧之间的光流的示意图。

如果得到了精确的光流场，那么就可以构造当前帧的绝大部分像素的精确预测，只需要将参考帧中的每一个像素沿着它的光流向量（Optical Flow Vector）移动即可。然而，精确的光流场需要大量的计算资源才能获得。

实践中经常使用的一种运动补偿方是，针对块（当前帧中一个矩形区域）进行运动补偿，这种方法避免了逐像素光流计算的资源消耗。基于块的运动补偿的流程如下（针对当前帧中每一个MxN大小的采样块）：

1. 搜索过去或者未来的参考帧中的一个相似的MxN采样块。具体的做法可能是，将当前帧的MxN块和搜索区域中所有可能的MxN块进行比较，从中选取最匹配的块。一个流行的判断“匹配”的准则是，将两个块进行相减得到残余，残余的Energy越低匹配度越高。寻找最佳匹配的过程被称为移动估算（Motion Estimation）
2. 最佳匹配的块被作为当前MxN块的预测器（Predictor），预测器和当前块求差后，形成一个MxN的残余块 —— 运动补偿（Motion Compensation）
3. 编码后的残余块，外加预测器和当前块之间的位置偏移（运动向量，Motion Vector），被一起发送

解码器利用运动向量重新定位预测器区域，解码残余块，将预测器 + 残余块即可还原当前块。

基于块的运动补偿之所以流行，有如下几个原因：

1. 计算资源的消耗相对较小，而且算法比较直观
2. 帧本身都是矩形的，和块运动补偿很适配
3. 基于块的图像转换算法（例如离散余弦变换，Discrete Cosine Transform，DCT）和块运动补偿很适配
4. 对于很多视频序列来说，块运动补偿能提供高效的时域模型（Temporal Model）

但是这种运动补偿也有缺陷：

1. 真实物体很少具有能匹配矩形区域的边界
2. 物体的帧间移动距离，常常不是整数个像素
3. 很多类型的对象运动很难通过基于块的方式补偿 —— 例如变形、旋转，以及类似云或者烟雾那样复杂的运动

尽管如此，当前所有视频编码标准均将基于块的运动补偿作为时域预测模型的基础。

宏块（Macroblock）是帧中16x16大小的区域，它是包括MPEG-1、MPEG-2、MPEG-4 Visual、H.261、H.262、H,264在内的很多视频编码标准的运动补偿预测的基本单元。

在常见的YUV 4:2:0图像编码格式中，一个宏块由：

1. 256个照度采样构成，这些采样组成4个8x8的采样块
2. 64个红色色差采样构成，这些采样组成1个8x8的采样块
3. 64个蓝色色差采样构成，这些采样组成1个8x8的采样块

即一共6个采样块，示意图如下：

宏块的运动估计，主要是寻找参考帧中和当前宏块匹配的16x16采样区域。参考帧是先前就编码好的一个帧，在时间维上，参考帧可以在过去或者未来。参考帧中以当前宏块为中心的区域被搜索，寻找最佳匹配。

最佳匹配的照度、色差采样，被从当前宏块中减去，这样就产生了一个残余宏块。残余宏块与标示了最佳匹配区域和当前宏块的相对位移的移动向量一起编码并传输。

在上述基本的运动估计、运动补偿的基础上，有很多变体的算法：

1. 如果使用了未来的帧作为参考帧，则未来的帧必须在当前帧之前编码，也就是帧的编码必须是乱序的
2. 当参考帧和当前帧的差异非常大时，不使用运动补偿可能更加高效，编码器可能选择使用帧内预测
3. 视频中的移动物体很少能恰恰匹配16x16的边缘，因此使用可变大小的块往往更加高效
4. 物体移动的距离可能不是整像素，例如物体可能在水平方向移动3.83像素的距离。因此一个好的预测算法会在搜索最佳匹配之前在参考帧中，在次像素级别进行插值

宏块的尺寸越小，则残余帧的Energy越低，预测越精准。但是相应的，计算复杂度越高。

为此，一个折衷的方式是：对于扁平、均匀的区域选择大的宏块尺寸；对于高度细节、复杂的移动区域选择小的宏块尺寸。

某些情况下，从参考帧的插值后（非整数像素）的采样位置进行预测可能获得更佳的效果。例如下图中，参考帧区域中像素被插值到半像素级别，这样匹配位置的精度可以提高一倍，通过搜索插值采样，可能获得更好的匹配。

通常来说，更加细粒度的插值可以提供更好的运动补偿效果，得到更低Engery的残余，代价是更高的复杂性。 但是这种效果的提升不是线性的，插值越精细，效果进一步的提升越小。

对当前块的空间预测，是基于当前帧中其它先前编码过的采样进行的。假设帧中的块以光栅扫描（Raster-scan） 顺序逐个编码，则所有左上方向的块都可以用于当前块的帧内预测。由于左上方向的块已经编码并存放到输出流，解码器很自然的可以用它们进行预测的重建。

帧内预测的具体算法有很多，H.264使用的是空间外推法（Spatial Extrapolation）。一个/多个预测由当前块上侧或左侧的外推采样构成。通常最靠近的采样最可能和当前块中的采用具有相关性，因而仅仅沿着上侧/左侧边缘的那些像素才会用来创建预测块。一旦预测块被创建，会被用来产生残余块，具体方式和帧间预测类似。

自然的视频帧是一系列采样构成的Grid，这种图片的原始格式很难被压缩，因为邻近的采样具有高相关性。下图左侧是某个自然视频帧的2D自相关（Autocorrelation）函数的曲面，高度表现了图片与其空间偏移之后的副本的相关性，底面的两个维度表示了空间偏移的方向。缓和的坡度提示了邻近样本的高度相关性。

而经过运动补偿的残余图像的自相关性函数如上图右侧所示，可以看到随着空间偏移的增大，相关性急剧的降低。这提示了邻近采样的若相关性。有效的运动补偿/帧间预测降低了残余图像的本地相关性，让其比原始的视频帧更加容易被压缩。

图像模型的功能是，进一步的对残余图像进行去相关（Decorrelate），让它能够更有效的被熵编码器所压缩。图像模型通常有三个处理阶段：

1. 转换（Transformation）：对图片进行去相关、让数据更加紧凑（Compact）
2. 量化（Quantization）：降低转换后数据的精度
3. 重排（Reordering）：对数据进行重新排序，让关键数值（Significant Values）分组在一起

运动补偿是预测性编码的一个例子，编码器基于过去/未来的某个帧创建当前帧中某个区域的预测，然后把预测从当前区域中减去，得到一个残余。如果预测成功的话，残余的Energy会比原始区域小，需要更少的比特来表示。

预测性编码是早期的视频编码器的基础，也是H.264的帧内编码的重要组件。空间预测需要基于先前传输的、当前帧已经编码好的区域的样本，这种预测方法有时被称为差分脉冲编码调制（Differential Pulse Code Modulation）。

下面的公式示意像素X的编码过程，我们假设帧基于光栅顺序处理。A、B、C是对于编解码器都可用的参考（相邻）像素，这些像素应该在X之前被编解码：

P(X) = (2A + B + C)/4
R(X) = X − P(X)

 解码器根据A、B、C可以重新构造出预测，然后X = R(X) + P(X)即解码出像素X。四个像素的位置关系如下图：

如果编码过程是有损的，也就是说残余被量化过，那么解码得到的A'/B'/C'并不和A/B/C完全一致，而依据A'/B'/C'推导出来的X'则会与X有更多的误差。这会导致编码器和解码器之间的累积性的误差，或者叫漂移（Drift）。为了避免这种漂移，编码器可以使用解码后的参考像素来构建残余，即：

P(X) = (2A’ + B'+ C‘) / 4

这样编码器、解码器使用相同的P(X)，也就避免了漂移。

上面介绍的预测性编码算法的效率取决于P(X)的精度，如果P(X)和X很接近，则残余的Engery很低，预测效率就高。但是，很难为复杂图像的所有区域选取一个通用的预测器。为了得到高性能，通常需要基于图像的本地统计信息进行自适应性的预测器选取。例如，对于图片中的扁平纹理、强竖直纹理、强水平纹理区域选取不同的预测器。由于你需要使用额外的bit来告知解码器使用了哪些预测器，因此要注意预测性能和流量消耗之间的权衡。

图片或者视频编码器的转换阶段的意图是，将图片或者运动补偿残余数据转换到转换域（Transform Domain）。选择转换算法取决于一系列准则：

1. 转换域中的数据应该是：
   1. 去相关的，也就是说，这些数据应该分离到最小相关性的分量中
   2. 紧凑的，大部分的Energy应该集中到数据的一小部分数值中
2. 转换必须是可逆的
3. 转换对计算资源的需求必须是可容忍的，包括内存、CPU

流行的图像/视频转换转发基本上分为两大类：

1. 基于块的：包括KLT、SVD、DCT。这些算法以NxN的采样为操作单元，其优点是内存用量小，适合压缩基于块的运动补偿残余。这类算法的缺点是块效应（Blockiness）明显
2. 基于图像的：在整个图像/帧上，或者大块的区域（所谓Tile）上操作。包括离散小波变换（Discrete Wavelet Transform，DWT）。这类算法对于静态图像的压缩处理由于上一类，但是需要更高的内存

量化器（Quantizer）将信号值范围X映射到一个较小的值范围Y。主要有两类量化器：

1. 标量量化器：将输入信号中的一个采样映射为一个量化的输出值
2. 向量量化器：将输入信号中的一组采样映射为一组量化值

对于一个基于转换的图像/视频编码器，量化器的输出是一个稀疏的数组。其中包含少量的非零系数，以及大量的零值系数。

重排阶段的工作就是把非零系数排列在一起，然后标识出这些系数在数组中的索引，实现压缩。

熵编码器把一系列表示视频序列的元素转换成适合传输和存储的压缩比特流。输入符号包括量化后的转换系数、整/次像素级别的移动向量、标记性编码、宏块头、图像头等。

在信息论中，熵编码属于无损压缩，且压缩不受媒介的特质影响。熵编码器可以把定长的输入符号替换为相应的可变长度的代号（Codeword），从而实现压缩。代号的长度和出现几率的负对数正相关，因而大部分公共符号具有最短的代号。

从不同的视角看，H.264可以有不同的含义：

1. 它是一个工业标准，定义了一种压缩视频格式
2. 一种流行的视频格式
3. 一套用于视频压缩的工具 

编码是视频类应用的基础技术，因为原始视频格式太大，难以传输或者存储。对视频编码进行标准化，可以让不同厂商开发的编码器、解码器、媒体存储能够方便的互操作。

典型的H.264应用，例如远程视频监控，视频从摄像头采集出来后被编码为H.264比特流，通过网络传输。终端应用解码比特流并获得原始视频：

H.264标准首次发布于2003年，之后经历了数次修订和更新。它基于早先的视频编码标准的设计理念，进一步提高了压缩视频的质量，在压缩、传输、存储方面有更大的灵活性。

H.264描述了一组用于压缩的工具/方法，规定了基于这些工具编码的视频如何呈现和解码。视频编码器可以选择一个工具，应用一些约束，然后处理视频流。H.264兼容的解码器必须能够使用工具组的某个子集 —— 所谓配置（Profile）。

通过预测、转换、编码等处理过程，H.264编码器生成一个H.264比特流。解码器则进行逆向处理——解码、反向转换、重构——以生成原始（Raw）视频序列。

每个视频帧/场都需要被编码器处理，帧/场被编码后，可能被放到已编码图像缓冲中（Coded Picture Buffer，CPB）。在编码后续帧时，编码器可以使用CPB。类似的，解码器在解码出一个帧后，将其放到已解码图像缓冲中（Decded Picture Buffer，DPB），在解码后续帧时可以使用DPB。

H.264的数据处理单元是16x16大小的宏块（Macroblock） 。

在编码器中，预测宏块从当前宏块中减去，得到一个残余宏块。残余宏块被转换、量化并编码。在此同时，量化后的数据被重新扫描、反向转换并加上预测宏块，得到一个编码后的帧版本，然后存储起来用于后续的预测：

在解码器中，宏块被解码、重新扫描、反向转换，得到一个编码过的残余宏块。解码器生成预测宏块后加上残余宏块，产生解码后的宏块：

预测阶段，包括帧间预测和帧内预测。H.264支持的预测方法很灵活，从而实现更精确的预测。帧内预测使用16x16或者4x4的块大小，从当前宏块的四周进行预测。帧间预测的块大小可以在16x16 - 4x4之间自由变动，参考帧可以来自过去或者未来。

预测阶段产生的残余采样，使用4x4或者8x8的整数变换（Integer Transform）——离散余弦变换的近似形式——进行转换，转换的输出是一组系数。系数的每个成员是一种标准化基本图式（Standard Basis Patterns）的权重值。通过系数可以重新创建出残余采样：

转换的结果进一步被量化，也就是，每个系数除以一个整数。量化后的转换系数精度降低：

视频编码最终产生的是一系列需要编码组成压缩比特流的数值，这些数值包括：

1. 量化后的转换系数
2. 供解码器重建预测的信息
3. 压缩数据结构相关信息
4. 和完整视频序列有关的信息 

这些数值和参数，以及语法元素（Syntax Elements），被可变长度编码/算术编码算法转换为二进制代码。

首先要进行的是对二进制比特流进行解码，解码语法元素并抽取上节所述的数值和参数。

然后是重扫描，每个系数乘以一个整数以近似的还原其原始值：

重扫描后的图式权重系数，加上标准化基础图式，经过反向离散余弦变换/整数变换可以重新创建出采样的残余数据：

得到采样残余后，解码器使用和编码器一样的预测，加上残余即得到原始图像。

H.264规范清晰的定义了一套格式，或者叫语法。用于呈现压缩视频及其相关信息。这套语法的总体结构图如下：

在最顶层， 一个H.264序列由一系列的包（Packet），或者叫网络抽象层单元（Network Abstraction Layer Unit，NALU）构成。NAL可以包含解码器需要用到的关键参数集，这些参数集指示解码器如何正确的解码帧（Frame）或切片（Slice）。所谓切片，是指被分解后的帧的一部分，帧可以仅仅包含一个切片

在下一层，切片由一系列编码过的宏块组成。每个宏块对应帧中16x16大小的块。

在最底层，宏块包含描述自己如何被编码的信息 —— 编码的具体方法、预测信息、残余采样等。

所谓H.264视频，是一种遵循特定规范——H.264/AVC语法——的视频序列。 此语法是H.264规范的一部分，它以语法元素的形式精确的描述了H.264视频序列结构的不同层面。

此语法是层次性的，它描述了最顶层的视频序列，以及下层的帧/场、切片，直到底层的宏块。控制参数可以：

1. 以独立的语法区段存储，例如参数集（Parameter Sets）
2. 嵌入为其它区段（宏块层）的一部分

H.264语法的层次性组织如下图所示：

说明如下：

1. 网络抽象层：由一系列的NAL单元组成：
   1. SPS、PPS是特殊的NAL单元，作为解码器特定通用控制参数变更的信号
   2. 编码后的视频数据对应视频编码层（Video Coding Layer）NAL单元，也被称为切片（Slice）。每个访问单元（Access Unit），即编码后的帧/场，可以由1-N个切片构成
2. 切片层：每个切片包括切片头、切片数据两部分。切片数据是一系列编码后的宏块，外加可能的跳过提示符。跳过提示符用于指示特定的宏块位置没有数据
3. 宏块层：每个编码后的宏块包括如下语法元素：
   1. MB类型：
      1. I：帧内编码
      2. P：基于一个参考帧进行帧间编码
      3. B：基于1-2个参考帧进行帧间编码
   2. 预测信息：I宏块的预测模式，P/B宏块的参考帧和移动向量
   3. 编码块图式（Coded Block Pattern CBP）：提示哪些明度块、色差块包含非零残余系数
   4. 量化参数（Quantization Parameter QP）：仅仅CBP非零的宏块具有此元素
   5. 残余数据：仅仅CBP非零的宏块具有此元素

编码后的视频序列总是以即时解码器刷新（Instantaneous Decoder Refresh，IDR）访问单元开始，其包括若干个IDR切片。IDR切片是一种特殊的帧内编码切片。IDR访问单元后面跟着很多普通的访问单元序列。当一个新的视频序列到达时，需要提前再次发送IDR切片。此外传输结束时也发送IDR切片。

H.264将帧定义为一组明度采样数组，外加两组对应的色差采样数组。场分为Top field、Bottom field，共同构成帧，两个场可以同时扫描或者交错扫描。术语图片（Picture）作为帧/场的通称。

帧/场被解码，形成解码后图片并被放置到解码后图片缓冲（Decoded Picture Buffer，DPB）。此缓冲中的图片可以用于：

1. 支持后续的帧间预测
2. 输出到显示组件

区分以下三个顺序很重要：

1. 解码顺序：图片从比特流中被解码的顺序
2. 显示顺序：图片输出到显示组件的顺序
3. 参考顺序：图片如何被排列以供其它图片进行帧间预测

帧和帧之间可能存在引用（时域预测）关系，因此它们的解码顺序必须是确定的。

解码序（Decoding Order）确定了编码后的帧/场的解码顺序，由切片头参数frame_num确定。一般情况下，当前帧的frame_num为先前参考帧的frame_num+1。

显示序（Display Order）即帧/场的播放顺序。由参数图像顺序计数器（POC，Picture Order Count）确定，POC参数包括TopFieldOrderCount、BottomFieldOrderCount。这两个参数也来自切片头，获取方法有三种：

1. 类型0：在每个切片头中，都包含了POC的最低有效位（Least Significant Bits），这种方式提供了灵活性但是占据更多字节。Type0示意如下图，箭头（从被参考帧发起）表示帧引用关系：
2. 类型1：在SPS中设立一个循环的POC计数器，POC依据此计数器循环计数，除非切片头使用Delta Offset
3. 类型2：直接从frame_num获得，解码序和显示序一致

图片编码后，如果允许被其它图片参考，则进入已解码图片缓冲（Decoded Picture Buffer，DPB），并被标记为以下两种之一：

1. 短期参考图片，以frame_num或者POC进行索引。把这类图片从DPB移除的方法有：
   1. 通过比特流中明确的命令移除
   2. 如果启用了DPB自动处理模式，并且DPB已满，自动移除最旧的图片
2. 长期参考图片，以LongTermPicNum进行索引，此数字基于图片被标记为长期参考帧时设置的参数LongTermFrameIdx推导。这类图片需要通过比特流中明确的命令移除

短期参考图片后续可以被赋予LongTermFrameIdx，导致它变为长期参考图片。

参考图像列表（Reference Picture List） 是存放参考图片引用的列表。对于P切片来说，使用单个列表list0；对于B切片来说，使用两个列表list0、list1。

在每个列表中，短期参考图片排在前面，短期参考图片的排列规则：

1. 如果当前切片是P，依赖于解码序
2. 如果当前切片是B，依赖于显示序

长期参考图片排在短期参考图片后面，且按照LongTermPicNum升序排列。

列表元素的排序细节很重要，因为要引用列表中前面的项需要的比特数更少。因此默认排序规则让“接近”当前图像的参考图像排在列表前面，这些参考图像中存在最佳预测匹配的几率更大：

1. P切片的list0：默认顺序是PicNum的降序，frame_num对MaxFrameNum取模得到PicNum
2. B切片的list0：默认顺序是：
   1. 如果参考图片的POC比当前图像早，则按POC降序
   2. 如果参考图片的POC比当前图片晚，则按POC升序
3. B切片的list1：默认顺序是：
   1. 如果参考图片的POC比当前图像早，则按POC升序
   2. 如果参考图片的POC比当前图片晚，则按POC降序

编码后的H.264数据以NAL单元这种数据包在网络中发送。每个NAL单元包含1字节的NALU头，后面跟着包含控制参数或者视频数据的比特流。

NALU头包含信息：

1. NALU的类型
   

   值	NALU类型	说明
   0	未使用
   1	Coded slice, non-IDR	典型的切片
   2	Coded slice data partition A	数据分区切片，分区A
   3	Coded slice data partition B	激活数据分区切片，分区B
   4	Coded slice data partition C	数据分区切片，分区C
   5	Coded slice, IDR	作为视频序列起点
   6	SEI	补充增强信息
   7	SPS	序列参数集，每序列一个
   8	PPS	图像参数集
   9	Access unit delimiter	提示下一个编码图片的切片类型
   10	End of sequence	提示下一个NALU是IDR
   11	End of stream	提示视频序列结束
   12	Filler	填充字节
   13-23	保留
   24-31	不保留，RTP打包用到

2. NALU的重要程度

NALU头固定为1字节长，其结构示意图如下：

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type    |
+---------------+

其中：

1. forbidden_zero_bit，第1位，必须为0
2. nal_ref_idc，第2-3位，重要程度。值越大越重要，当解码器过载时可以考虑把值为0的NALU丢弃。在RTP中使用，NRI还指示了传输的相对优先级
3. nal_unit_type，最后5位。类型6/9/10/11/12对应的NRI应该为00，类型7/8对应第NRI应该为11

参数集是携带了解码参数的NALU，这些参数对于后续若干切片是公用的，独立于切片发送参数集可以提高效率。 这些参数对于正确解码非常重要，在不可靠信道上传输视频流时，参数集可能丢失，可以考虑用更高的QoS发送参数集。

序列参数集（SPS）包含对整个视频序列有效的参数，例如Profile和Level、帧尺寸、某些解码器约束（例如参考帧最大数量）。SPS示例：

图像参数集（PPS）包含应用到一部分帧的参数，例如熵编码类型、活动参考图片数量、初始化参数。PPS继承特定SPS的参数。PPS示例：

直到切片头引用PPS之前，PPS没有被激活，也就是编码器不使用它。一旦应用，则一直有效，直到另一个PPS被激活。

SPS仅仅在引用它PPS激活时，才被激活。单一的SPS之后对整个流有效，而流以IDR切片开始，因而通常由IDR激活SPS。

每个编码后的帧/场都由1-N个切片组成。切片以切片头开始，后面跟着1-N个宏块，宏块的数量可以不固定。

切片大小的选择方式有：

1. 每个帧一个切片，很多H.264编码器选择这种方式
2. 每个帧分为N个切片，每个切片分为M个宏块。切片的比特数量随着运动量的变大而便多
3. 每个帧分为N个切片，每个切片包含的宏块数量不一定。这种方式可以让切片的比特数大致一致，用于固定长度的网络包

切片头携带了对于所有宏块通用的信息，例如：

1. 切片类型，限制了宏块可能的类型
2. 帧编号（Frame Number），此切片所属的帧

一个示例切片头如下（IDR/Intra，Frame0）：

切片数据为若干宏块的集合。有一种没有数据的宏块 —— Skip Macroblock，在很多编码序列中会出现。和熵编码器有关。

宏块层中包含解码一个宏块所需要的所有语法元素：

其中：

前文提到过，H.264支持一组工具 —— 处理编解码的算法和过程。这些工具中有些很基础，任何编解码器实现都需要用到，例如4x4的变换算法。另外一些工具是可选的，例如CABAC/CAVLC熵编码器。

通过按需选择标准中定义的工具，编码器的实现可以非常的灵活，编码器可以仅仅使用工具的某些子集。

H.264配置（Profile）规范了工具子集的定义。任何H.264比特流必须遵从Profile规范，使用子集中部分或者全部工具实现编码。一个Profile兼容的解码器，必须能够解码使用子集中任何工具编码的H.264比特流。

当前最广泛使用的Profile是Main，其包含的工具很好的在压缩性能和计算复杂度之间进行权衡。Constrained Baseline这个Profile是Main的一个子集，在低复杂度、低延迟的应用程序中非常流行，例如移动视频电话。

Extended、Main、Baseline、Constrained Baseline之间的关系如下图：

说明如下：

1. Baseline设计用于低复杂度、低延迟应用程序，例如移动视频电话。它支持：
   1. I帧、P帧
   2. 允许帧内预测、基于单个参考帧的运动补偿
   3. 使用基本的4x4整数变换
   4. 使用CAVLC熵编码
   5. 支持FMO、ASO、冗余切片，这些技术用于提高传输效率
2. 上面提到的最后三个工具并不流行，很多实现不能完整支持。排除了这三者的Profile就是Constrained Baseline
3. Extended是Baseline的超集，添加了某些提高网络流传输效率的工具
4. Main是Constrained Baseline的超级，支持CABAC编码和B帧

高配置分为4个级别，添加了一些编码工具，满足高质量应用程序（高分辨率、扩展比特深度、高色彩深度）的需要。High是Main的超集，添加特性：

1. 8x8变换
2. 8x8帧间预测，这提高了编码性能，特别是高空间分辨率情况下
3. 支持频率相关的量化器权重
4. 为Cr、Cb分开设置量化器参数
5. 支持单色差视频（4:0:0格式）

不同级别High和Main的关系如下图：

级别规定了帧尺寸、处理速度（每秒能够解码的帧或者块数量）、工作内存的最大需求量。Profile + Level共同构成了对解码器的约束条件。

照度分辨率、帧率和级别的关系如下表：

鉴于大部分H.264应用程序都牵涉到传输、存储比特流。H.264标准引入了一系列工具和特性，让传输过程更加高效和健壮。

需要注意：大部分商业编解码器没有支持这些特性。

如果包含某个帧部分或者全部的重复信息，一个切片可以被标记为冗余的。解码器通常基于非冗余切片重构帧，如果非冗余切片损坏或者丢失，则使用冗余切片。

冗余切片增强了健壮性，代价是更高的比特率。

任意切片顺序（Arbitrary Slice Order，ASO）允许帧中的切片以任意（非光栅序）的解码顺序排列。可以用于辅助解码错误的隐藏。

灵活宏块排序（Flexible Macroblock Ordering，FMO）让帧中的宏块被分配到一个或者多个切片组（Slice Groups）中。每个切片组包含1-N个切片。在切片组内部，宏块以光栅序编码，但是这些宏块在帧中的位置不一定相邻。宏块和切片组的对应关系由宏块分配映射（Macroblock Allocation Map）指定。

FMO可以增加容错性，因为每个切片组可以独立的解码。如果在使用交错排序的情况下，一个切片或者切片组丢失，其影响可以利用空间插值屏蔽掉。

SP和SI切片的用途是：

1. 允许高效的在不同视频流之间切换
2. 允许解码器进行高效的随机访问

例如，同一视频源使用不同码率在网络中传输，解码器可以在正常情况下使用高码率，并且在网络拥塞的时候切换到低码率。

该特性将切片分为三个区：NAL头

1. A分区：包含切片头、每个宏块的头
2. B分区：包含帧内预测的残余数据、SI切片宏块
3. C分区：包含帧间预测的残余数据、SP切片宏块

每个分区都是独立的NAL单元。A、B、C分区的容错度依次增高，传输时可以应用不同的QoS。

这三者的逐层封装关系如下图：

说明：

1. H.264语法元素被封装为RBSP，后者被封装为NALU。由于H.264语法元素是可变长度的，为了将RBSP字节对齐，尾部可能需要补零
2. RBSP封装进NALU的方式如下：
   1. 添加一字节的NALU头
   2. 按序添加模拟预防（Emulation Prevention）字节。为了防止起始码（Start Code）出现在NALU内部，每当出现和起始码前缀一致的3字节图式时，就插入一个模拟预防字节（二进制00000011）。解码器能够检测到模拟预防字节，进而知道其相邻的字节不是起始码
3. NALU可以作为传输协议的载荷。每个NALU都前缀一个起始码，起始码为三字节的特殊序列。解码器依赖起始码来判断NALU的边界 

相关文章：实时通信协议族。

H.264对传输协议没有任何规定，常用的传输协议是RTP。RTP是一种常见的打包协议，一般在UDP基础上运行。RTP Payload Formats为很多标准的音视频编码格式定义了标准。

本节主要讨论RFC 6184：RTP Payload Format for H.264 Video。

用于H.264传输时，RTP支持三种载荷结构。接收方可以根据载荷的首字节来识别载荷结构。这个直接也作为RTP载荷头，某些情况下还作为载荷的组成部分（第一字节）。

此首字节的格式和NALU头格式一致。其中NALU类型字段指明了载荷结构是哪一种：

1. 单NALU包：载荷中仅仅包含单个NALU，NALU类型取值范围在1-23之间
2. 聚合包：载荷中包含多个NALU。这种载荷结构具有4种子类型：
   1. STAP-A：单一时间聚合包，类型A。NALU类型为24
   2. STAP-B：单一时间聚合包，类型B。NALU类型为25
   3. MTAP16：多时间聚合包，使用16bit偏移。NALU类型为26
   4. MTAP24：多时间聚合包，使用24bit偏移。NALU类型为27
3. 片断单元：其中仅仅包含NALU的一部分，这种方式允许NALU拆分到多个RTP包中传输。这种载荷结构具有2种子类型：
   1. FU-A。NALU类型为28
   2. FU-B。NALU类型为29

此首字节的NRI字段，00表示可丢弃，这个语义和H.264规范是一致的，解码器不关心任何非零NRI的具体值。RFC6184对非零值的含义进行了延伸，用于表示传输相对优先级。MANE可以对高优先级的包进行更强的保护，防止丢包，11是最高优先级。

对NALU的打包模式有三种：

1. 单NALU模式，用于遵从H.241规范的系统
2. 非交错模式，用于可能不遵循H.241规定的系统。在此模式下，NALU的按解码序传输
3. 交错模式，用于不需要非常低的端对端延迟低系统。此模式允许NALU不按解码序传输

打包模式可以从SDP的packetization-mode字段获得：

1. 0或者没有该字段对应单NALU模式
2. 1对应非交错模式
3. 2对应交错模式

打包模式和载荷结构类型的兼容性表格如下：

此类型的载荷仅仅包含一个NALU，并且，NALU头即为RTP载荷头： 

NALU由NALU头、NALU载荷组成，前缀的开始码（00 00 00 01或者00 00 01）被清除后再打包。

引入聚合包的原因是不同网络的MTU不同：

1. 有线IP网络的MTU主要受限于以太网MTU，大概1500字节左右
2. IP/非IP无线网络的MTU首先的传输单元较小，大概254字节或者更少 

由于RTP通常基于UDP，UDP包的尺寸则受限于MTU。因此聚合包能够最高效率的使用MTU。

聚合包分为两大类，分别为单时间（STAP）、多时间（MTAP）聚合包。前者的NALU时间只有一个值。后者包含低NALU可能对应不同的时间。聚合包中的每个NALU都基于聚合单元打包：

STAP和MTAP共享以下打包规则：

1. RTP时间戳必须设置为包内所有NALU的最早的那个NALU-time
2. NALU类型必须正确设置
3. 如果所有NALU的F位均为0，F位必须清零
4. NRI必须设置为所有NALU中NRI的最大值

STAP-A载荷结构如下：

STAP-B载荷结构如下：

两者的主要区别是STAP-B有一个DON字段，它以传输序指定了第一个NALU的位置，后续NALU的DON = (第一个NALU的DON + 1) %65536。

STAP-A包含1-N个聚合单元，聚合单元的结构如下：

STAP-A、STAP-B的聚合单元的头部是16bit的网络序无符号整数，指示后续NALU的长度（字节）。聚合单元在RTP包内是字节对齐的。

MTAP载荷由一个16bit网络序无符号整数的解码序号基数（Decoding Order Number Base）和1-N个聚合单元组成。DONB的值为当前包中以NALU解码序计第一个NALU的DON值。

MTAP的聚合单元MTAP16的结构如下：

MTAP24的结构如下：

两种聚合单元都有如下字段：

1. 16bit的NALU大小
2. 8bit的解码序号差异（Decoding Order Number Difference，DOND）
3. Nbit的时间戳偏移，对于MTAP16 N = 16，对于MTAP24 N = 24

当NALU长度超过MTU后，可以使用分段包，让一个NALU分散在多个RTP包中。FU有两个子类，其中FU-A的结构如下：

FU-B必须配合交错打包模式使用。其结构如下：

FU indicator结构与NALU头一致，NALU类型取值28或29。

FU header结构如下：

+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type    |
+---------------+

其中：

1. S：1bit，如果设置此位，表示此FU是第一个NALU分片
2. E：1bit，如果设置此位，表示此FU是最后一个NALU分片
3. R：1bit，取值0
4. Type：NALU载荷类型

x264是VideoLAN开源的H.264编码器，特性包括：

1. 8x8和4x4自适应空域变换
2. 自适应B帧置入
3. B帧作为参考帧
4. 任意帧顺序
5. 支持CAVLC、CABAC熵编码
6. 自定义量化矩阵
7. 帧内预测：16x16, 8x8, 4x4等任意宏块大小
8. 帧间预测：所有分区大小，从16x16到4x4
9. 帧间双向预测：分区大小支持从16x16到8x8
10. 交错扫描—— 宏块级帧场自适应（Macro-block Adaptive Field Frame，MBAFF）
11. 多参考帧
12. 速率控制：常量量化器、常量质量、单步/多步ABR、可选VBV
13. 场景切换（Scenecut）检测
14. B帧中的空域/时域直接模式，自适应模式选择
15. 使用多个CPU并行编码
16. 预测性无损模式

git clone http://git.videolan.org/git/x264.git
cd x264
./configure --enable-debug --enable-static --enable-shared --prefix=/home/alex/CPP/lib/x264
make && make install && make clean

下面是一个编码QCIF尺寸的YUV序列的示例。CMake项目配置：

cmake_minimum_required(VERSION 3.6)
project(x264 C)

set(X264_HOME /home/alex/CPP/lib/x264)
include_directories(${X264_HOME}/include)

set(SRC_ENCODER encoder.c)
add_executable(encoder ${SRC_ENCODER})
target_link_libraries(
        encoder
        ${X264_HOME}/lib/libx264.so
)

 编码器源码：

#include <stdint.h>
#include <stdio.h>
#include <x264.h>

int main( int argc, char **argv ) {
    int width = 176, height = 144;    //QCIF
    x264_param_t param;
    x264_picture_t pic;
    x264_picture_t pic_out;
    x264_t *h;
    int i_frame = 0;
    int i_frame_size;
    x264_nal_t *nal;
    int i_nal;

    /* 应用编码器预设 */
    if ( x264_param_default_preset( &param, "fast", "zerolatency" ) < 0 ) goto fail;

    /* 在预设的基础上定制 */
    param.i_csp = X264_CSP_I420;      // 色彩空间：yuv 4:2:0 planar（三个数组）
    param.i_width = width;            // 帧尺寸
    param.i_height = height;
    param.b_vfr_input = 0;            // 可变帧率的输入：否
    param.b_repeat_headers = 1;       // 在每个I帧之前插入SPS/PPS
    param.b_annexb = 1;               // 在NALU之前插入4字节起始码

    /* 设置Profile，x264仅仅提供了Baseline选项，但是由于不支持某些特性，编码实际使用的是Constrained Baseline */
    if ( x264_param_apply_profile( &param, "baseline" ) < 0 ) goto fail;
    if ( x264_picture_alloc( &pic, param.i_csp, param.i_width, param.i_height ) < 0 ) goto fail;
#undef fail
#define fail fail2
    // 创建句柄
    h = x264_encoder_open( &param );
    if ( !h ) goto fail;
#undef fail
#define fail fail3

    int luma_size = width * height;    // 单帧包含的明度元素个数
    int chroma_size = luma_size / 4;   // 单帧包括的色差元素个数
    /* 循环编码所有帧  */
    FILE *in = fopen( "/home/alex/CPP/projects/clion/x264/qcif.yuv", "r" );
    FILE *out = fopen( "/home/alex/CPP/projects/clion/x264/qcif.h264", "w" );
    for ( ;; i_frame++ ) {
        /* 读取输入帧 */
        if ( fread( pic.img.plane[ 0 ], 1, luma_size, in ) != luma_size )
            break;
        if ( fread( pic.img.plane[ 1 ], 1, chroma_size, in ) != chroma_size )
            break;
        if ( fread( pic.img.plane[ 2 ], 1, chroma_size, in ) != chroma_size )
            break;

        pic.i_pts = i_frame;  // PTS，展现时间戳
        // 编码当前帧，nal是编码后的第一个NALU的指针，i_nal是NALU个数。返回编码后NALU的总字节数
        i_frame_size = x264_encoder_encode( h, &nal, &i_nal, &pic, &pic_out );
        if ( i_frame_size < 0 ) goto fail;
            // 将NALU的载荷写入到输出流
        else if ( !fwrite( nal->p_payload, i_frame_size, 1, out ))goto fail;
    }
    /* 写出延迟帧 */
    while ( x264_encoder_delayed_frames( h )) {
        i_frame_size = x264_encoder_encode( h, &nal, &i_nal, NULL, &pic_out );
        if ( i_frame_size < 0 ) goto fail;
        else if ( i_frame_size ) if ( !fwrite( nal->p_payload, i_frame_size, 1, out )) goto fail;
    }
    // 关闭编码器
    x264_encoder_close( h );
    // 清理内存
    x264_picture_clean( &pic );
    return 0;

#undef fail
    fail3:
    x264_encoder_close( h );
    fail2:
    x264_picture_clean( &pic );
    fail:
    return -1;
}

编码后原始的5.7MB的YUV序列产生了88.3KB的H.264 NALU序列，缩小了接近80倍。 以HEX打开输出文件：

0000 0001 6742 c00b db0b 13a1 0000 0300
0100 0003 0032 8f14 2ae0 0000 0001 68ca
83cb 2000 0001 0605 ffff 66dc 45e9 bde6
d948 b796 2cd8 20d9 23ee ef78 3236 3420 ...

可以看到：

1. NALU前缀了4字节的起始码HEX：0000 0001
2. 第1个NALU头为BIN：01100111，此单元是一个SPS
3. 第2个NALU是PPS
4. 第3个NALU是一个典型切片

The post H.264学习笔记 appeared first on 绿色记忆.

Kurento是一个WebRTC媒体服务器，同时提供了一系列的客户端API，可以简化供浏览器、移动平台使用的视频类应用程序的开发。Kurento支持：

1. 群组通信（group communications）
2. 媒体流的转码（transcoding）、录制（recording）、广播（broadcasting）、路由（routing）
3. 高级媒体处理特性，包括：机器视觉（CV）、视频索引、增强现实（AR）、语音分析

Kurento的模块化架构使其与第三方媒体处理算法 —— 语音识别、人脸识别 —— 很容易集成。

和大部分多媒体通信技术一样，Kurento应用的整体架构包含两个层（layer）或者叫平面（plane）：

1. 信号平面（Signaling Plane）：负责通信的管理，例如媒体协商、QoS、呼叫建立、身份验证等
2. 媒体平面（Media Plane）：负责媒体传输、编解码等

典型Kurento应用的整体架构如下图：

按分层的方式来划分，Kurento应用可以分为三层（类似于典型的Web应用）：

1. 展现层 —— 浏览器、移动应用、其它媒体源等应用客户端：
   1.  基于任意协议和应用逻辑层通信，发起信号处理
   2.  基于RTP/HTTP/WebRTC协议和KMS通信：
      1. 通过KMS的输入端点，传输媒体流到KMS
      2. 通过KMS的输出端点，从KMS获得媒体流
2. 应用逻辑层——应用服务器负责信号平面：
   1. 基于WebSocket/HTTP/REST/SIP等方式和应用客户端通信，进行信号处理
   2. 内嵌Kurento Client，基于Kurento Protocol与KMS通信，管理媒体元素/媒体管线
3. 服务层——KMS负责媒体平面，可以对输入流进行各种处理，并产生输出流

媒体协商（信号处理）阶段：

1. 客户端首先向应服务器请求某种媒体特性（例如请求一个九画面视频监控流、请求发布自己的SDP）。这块WebRTC没有规定，可以基于任何协议（HTTP/WS/SIP）实现
2. 应用服务器接收到请求后，执行特定的服务器端逻辑，例如AAA（认证授权审计）、CDR生成等
3. 应用服务器处理请求，并命令KMS实例化适当的媒体元素、构建媒体流（例如从多个RTSP源混合出九画面）
4. 媒体流构建完毕后，KMS应答应用服务器，后者应答客户端，告知其如何获取媒体服务

媒体交换阶段：

1. 客户端利用协商阶段收集的信息，向KMS发起请求（例如向目标端口发起UDP请求，获取九画面视频监控流）

下图是交互的序列示意，注意先后顺序：

Kurento允许基于WebRTC建立浏览器和KMS之间的实时多媒体会话：

1. 客户端基于SDP来发布自己的媒体特性，请求发送给应用服务器
2. 应用服务器根据SDP来创建合适的WebRTC端点，并请求KMS生成一个响应SDP
3. 应用服务器获得响应SDP后，将其返回给客户端
4. 由于双方都知道对方的SDP了，客户端和KMS可以进行媒体交换了

下图是交互的序列示意：

Kurento也可以作为一个媒体代理，让浏览器之间建立直接的媒体交换。交互序列仍然如上图，仅仅是KMS返回的SDP不同

WebRTC让浏览器能够进行实时的点对点通信（在没有服务器的情况下）。但是要想实现群组通信、媒体流录制、媒体广播、转码等高级特性，没有媒体服务器是很难实现的。

Kurento的核心是一个媒体服务器（Kurento Media Server，KMS），负责媒体的传输、处理、加载、录制，主要基于 GStreamer实现。此媒体服务器的特性包括：

1. 网络流协议处理，包括HTTP、RTP、WebRTC
2. 支持媒体混合（mixing）、路由和分发的群组通信（MCU、SFU功能）
3. 对机器视觉和增强现实过滤器的一般性支持
4. 媒体存储支持，支持对WebM、MP4进行录像操作，可以播放任何GStreamer支持的视频格式
5. 对于GStreamer支持的编码格式，可以进行任意的转码，例如VP8, H.264, H.263, AMR, OPUS, Speex, G.711

KMS基于模块化的设计，模块主要分为三类：

1. 核心（kms-core）
2. 媒体元素（kms-elements）
3. 过滤器（kms-filters）
4. 其它增强KMS的模块，例如kms-crowddetector, kms-pointerdetector, kms-chroma, kms-platedetector

KMS允许用户扩展自己的模块。

Kurento Protocol是一个网络协议，通过WebSocket暴露KMS的特性。

Kurento API是对上述协议的OO封装，通过此API能够创建媒体元素和管线。Kurento提供了API的Java、JavaScript绑定。

Kurento提供了Java、JavaScript（包括浏览器和Node.js）的客户端库，通过这些库你可以控制媒体服务器。对于其它编程语言，可以使用 Kurento Protocol协议（基于WebSocket/JSON-RPC）。

Kurento客户端API基于所谓媒体元素（Media Element）的概念。一个每天元素持有一种特定的媒体特性。例如：

1. 媒体元素WebRtcEndpoint的特性是，接收WebRTC媒体流
2. 媒体元素RecorderEndpoint的特性是，将接收到的媒体流录制到文件系统
3. 媒体元素FaceOverlayFilter则能够检测人脸，在其上方显示一个特定的图像

开箱即用的媒体元素如下图：

从开发者角度来说，操控媒体元素就好像搭积木。 你只需要按照期望的拓扑结构把它们连接起来就可以了。一系列连接起来的媒体元素称为媒体管线（Media Pipeline）。只有一个管线内部的媒体元素才能相互通信

当创建管道时，开发者需要明确希望使用到的特性，以及媒体连接（connectivity） —— 产生媒体的元素和消费媒体的元素之间的连接：

sourceMediaElement.connect(sinkMediaElement);
// 例如：客户端接收WebRTC流并录制到媒体服务器的文件系统
webRtcEndpoint.connect(recorderEndpoint);

为了简化浏览器客户端的WebRTC流处理，Kurento提供了工具WebRtcPeer，你仍然可以使用WebRTC的标准API，以及连接到WebRtcEndpoint。

你可以在64位Ubuntu 14.04 LTS上安装KMS：

docker create -it -h kurento --name kurento --network local --dns 172.21.0.1 --ip 172.21.0.6 docker.gmem.cc/ubuntu:14.04 bash

# 在上述容器中执行
echo "deb http://ubuntu.kurento.org trusty kms6" | sudo tee /etc/apt/sources.list.d/kurento.list
wget -O - http://ubuntu.kurento.org/kurento.gpg.key | sudo apt-key add -
sudo apt-get update
# 执行下面的命令安装KMS，可能需要手工选择依赖冲突处理方案
aptitude install kurento-media-server-6.0
# 选择降级gcc-4.8-base、libstdc++6的那个方案

要启动或者停止KMS服务，执行下面的命令：

# 启动服务
sudo service kurento-media-server-6.0 start
# 停止服务
sudo service kurento-media-server-6.0 stop

Trickle ICE是对ICE的扩展，它允许ICE代理（KMS、客户端）增量的收发candidates而不是交换完整的candidate列表。

由于使用了Trickle ICE协议， 目前的6.0版本的KMS和5.1-版本不兼容，你需要卸载老版本后重新安装：

sudo apt-get remove kurento-media-server
sudo apt-get purge kurento-media-server
sudo apt-get autoremove

注意sources.list文件和sources.list.d下的文件中，对kurento的引用也要删除。

在Ubuntu:14.04容器中安装后，关闭容器，提交为镜像：

docker commit kurento docker.gmem.cc/kurento:base

新建一个Docker项目：

FROM docker.gmem.cc/kurento:base

ADD /fs /
RUN chmod +x /entrypoint.sh

CMD ["/entrypoint.sh"] 

入口点脚本：

#!/usr/bin/env bash

sighdl() {
    echo
    echo -e "\033[44mKilling sub process $pid \033[0m"
    kill -TERM $pid
    echo -e "\033[44mStopping KMS \033[0m"
    service kurento-media-server-6.0 stop
    echo -e "\033[44mCleaning up log files \033[0m"
    rm -rf /var/log/kurento-media-server/*
}
trap  sighdl HUP INT PIPE QUIT TERM

service kurento-media-server-6.0 start

sleep 10

kmspid=`ps -A | grep kurento-media | xargs |cut -d" " -f1`
pushd /var/log/kurento-media-server > /dev/null
logfile=`find . -name "*pid$kmspid.log" | head -n 1`

# 持续输出当前日志的内容，确保容器不退出
tail -f $logfile &
pid=$!
# 捕获到信号的时候，下面的命令退出 —— 等待被中断
wait $pid

# 信号处理完毕后，执行下面的命令，如果tail这个子进程已经终止，则wait会立即退出
# 如果子进程正在处理TERM信号，则等待其处理完毕后，wait退出
# 如果没有这个double wait，则子进程有可能成为僵尸，因为没有父进程实际完成wait系统调用
wait $pid

构建新镜像：

docker build --force-rm -t docker.gmem.cc/kurento .

创建基于新镜像容器： 

docker create --name kurento -h kurento --dns 172.21.0.1 --network local --ip 172.21.0.6  --expose 8888 \
              -p 8888:8888 docker.gmem.cc/kurento

启动容器：

docker start -i kurento

要自己构建Kurento，可以参考本节的操作步骤。本节记录的操作步骤是在Ubuntu 14.04 TLS上执行的。

kms-filters依赖于此库：

pushd /home/alex/CPP/lib  > /dev/null
mkdir opencv
pushd opencv > /dev/null
wget https://codeload.github.com/opencv/opencv/zip/2.4.13.3 -O 2.4.13.zip
unzip -o -d . 2.4.13.zip 
mv opencv-2.4.13.3 2.4.13
mkdir build
pushd build > /dev/null
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/alex/CPP/lib/opencv/2.4.13 ..
make && make install
popd && popd

# Kurento的组件和源码安装在此
export KURENTO_HOME=/home/alex/CPP/lib/kurento
# 构建Kurento组件的通用CMake选项
export CMAKE_OPTS="-DCMAKE_INSTALL_PREFIX:STRING=$KURENTO_HOME -DCMAKE_MODULE_PATH:STRING=$KURENTO_HOME/share/cmake-2.8/Modules"
export BOOST_ROOT=/home/alex/CPP/lib/boost/1.65.1

pushd /home/alex/CPP/lib/kurento/src > /dev/null


# 构建kms-cmake-utils
git clone https://github.com/Kurento/kms-cmake-utils.git
pushd kms-cmake-utils  > /dev/null
mkdir build
pushd build > /dev/null
cmake $CMAKE_OPTS ..
make && make install
popd && popd


# 构建kurento-module-creator
git clone https://github.com/Kurento/kurento-module-creator.git
pushd kurento-module-creator > /dev/null
mvn package
# CMake模块统一存放处
cp target/classes/FindKurentoModuleCreator.cmake $KURENTO_HOME/share/cmake-2.8/Modules/
mkdir $KURENTO_HOME/kurento-module-creator
cp target/kurento-module-creator-jar-with-dependencies.jar $KURENTO_HOME/kurento-module-creator/
cp scripts/kurento-module-creator $KURENTO_HOME/kurento-module-creator/
export PATH=$PATH:$KURENTO_HOME/kurento-module-creator
popd


# 构建kms-jsonrpc
git clone https://github.com/Kurento/jsoncpp.git
pushd jsoncpp  > /dev/null
mkdir build
pushd build > /dev/null
# 需要修改$KURENTO_HOME/src/jsoncpp/src/lib_json/CMakeLists.txt
# 添加目标属性 SET_TARGET_PROPERTIES(jsoncpp_lib_static PROPERTIES COMPILE_FLAGS "-fPIC")
# 否则kms-jsonrpc的构建会报错 ...can not be used when making a shared object; recompile with -fPIC
cmake $CMAKE_OPTS ..
make && make install
popd && popd

git clone https://github.com/Kurento/kms-jsonrpc.git
pushd kms-jsonrpc > /dev/null
mkdir build
pushd build > /dev/null
# 下一步会报错 package 'kmsjsoncpp>=0.6.0' not found  
# 实际上我们刚刚构建好kmsjsoncpp，其Package config位于$KURENTO_HOME/lib/pkgconfig目录下
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$KURENTO_HOME/lib/pkgconfig
cmake $CMAKE_OPTS ..
export LIBRARY_PATH=$LIBRARY_PATH:$KURENTO_HOME/lib
# 报错 fatal error: json/json.h: No such file or directory
# 经过检查，使用的jsoncpp头文件路径是/home/alex/CPP/lib/kurento/include/kmsjsoncpp
# 而实际路径是/home/alex/CPP/lib/kurento/include
# 这是jsoncpp项目的pkgconfig模板错误导致，
# 手工修改$KURENTO_HOME/lib/pkgconfig/kmsjsoncpp.pc最后一行为Cflags: -I${includedir}
make && make install
popd && popd


# 构建kms-core
# 后续可能需要调试
export CMAKE_OPTS="$CMAKE_OPTS -DCMAKE_BUILD_TYPE:STRING=Debug"
sudo apt install libvpx-dev
# Kurento使用自己打包的gstreamer
echo "deb http://ubuntu.kurento.org trusty kms6" | sudo tee /etc/apt/sources.list.d/kurento.list
wget -O - http://ubuntu.kurento.org/kurento.gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt install libgstreamer1.5-dev libgstreamer-plugins-base1.5-dev

git clone https://github.com/Kurento/kms-core.git
pushd kms-core > /dev/null
mkdir build
pushd build > /dev/null
cmake $CMAKE_OPTS ..
# 构建时又找不到BOOST头文件
export CPATH=$CPATH:/home/alex/CPP/lib/boost/1.65.1/include
make && make install
popd && popd


# 构建kms-elements
export CMAKE_OPTS="$CMAKE_OPTS -DKURENTO_MODULES_DIR:STRING=$KURENTO_HOME/share/kurento/modules"
sudo apt-get install libusrsctp*
git clone https://github.com/Kurento/openwebrtc-gst-plugins.git
pushd openwebrtc-gst-plugins > /dev/null
./autogen.sh
./configure --prefix=$KURENTO_HOME
make && make install
popd

sudo apt-get install libnice-dev

git clone https://github.com/Kurento/kms-elements.git
pushd kms-elements > /dev/null
mkdir build
pushd build > /dev/null
cmake $CMAKE_OPTS ..
export CPATH=$CPATH:$KURENTO_HOME/include/gstreamer-1.5
make && make install
popd && popd


# 构建kms-filters
git clone https://github.com/Kurento/kms-filters.git
pushd kms-filters > /dev/null
mkdir build
pushd build > /dev/null
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/alex/CPP/lib/opencv/2.4.13/lib/pkgconfig
export LIBRARY_PATH=$LIBRARY_PATH:/home/alex/CPP/lib/opencv/2.4.13/lib
export CPATH=$CPATH:/home/alex/CPP/lib/opencv/2.4.13/include
# 修改CMake配置/home/alex/CPP/lib/kurento/src/kms-filters/CMakeLists.txt
# 第29-30行，去掉 -Wall -Werror 
cmake $CMAKE_OPTS ..
make && make install
popd && popd


# 构建 kurento-media-server
git clone https://github.com/Kurento/kurento-media-server.git
pushd kurento-media-server > /dev/null
mkdir build
pushd build > /dev/null
cmake $CMAKE_OPTS ..
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/alex/CPP/lib/kurento/lib/x86_64-linux-gnu
make && make install
popd && popd

运行，要运行自己构建的KMS，参考如下脚本：

#!/bin/bash
 cd /home/alex/CPP/lib/kurento/bin
 export CLIB_HOME=/home/alex/CPP/lib
 export KURENTO_HOME=$CLIB_HOME/kurento
 export LD_LIBRARY_PATH=$CLIB_HOME/boost/1.65.1/lib:$KURENTO_HOME/lib:$KURENTO_HOME/lib/x86_64-linux-gnu
./kurento-media-server -f $KURENTO_HOME/etc/kurento/kurento.conf.json -c $KURENTO_HOME/etc/kurento/modules/kurento

KMS的主配置文件位于/etc/kurento/kurento.conf.json，内容如下：

{
  "mediaServer" : {
    "resources": {
        // 当请求创建一个对象时，如果资源用量达到下面的阈值，抛出异常
        "exceptionLimit": "0.8",
        // 如果没有任何存活对象，且资源用量达到下面的阈值，则重启服务器
        "killLimit": "0.7",
        // 垃圾回收器活动间隔（秒）
        "garbageCollectorPeriod": 240
    },
    "net" : {
      // WS用于Kurento Protocol
      "websocket": {
         // 普通WS端口
         "port": 8888,
         // WSS端口、数字证书信息
         "secure": {
            "port": 8433,
            "certificate": "defaultCertificate.pem",
            "password": ""
          },
          "registrar": {
            "address": "ws://localhost:9090",
            "localAddress": "localhost"
          },
        // URL路径
        "path": "kurento",
        "threads": 10
      }
    }
  }
}

此外还有以下配置文件：

如果KMS位于NAT设备后面，你需要使用STUN或者TURN以便实现NAT穿透。大部分情况下STUN足够，在对称NAT的情况下才需要使用TURN。

要启用STUN支持，修改配置文件： 

; 解除注释：
stunServerAddress=<serverAddress>
stunServerPort=<serverPort>
; 公网有很多免费的STUN服务：
; 173.194.66.127:19302
; 173.194.71.127:19302
; 74.125.200.127:19302
; 74.125.204.127:19302
; 173.194.72.127:19302
; 74.125.23.127:3478
; 77.72.174.163:3478
; 77.72.174.165:3478
; 77.72.174.167:3478
; 77.72.174.161:3478
; 208.97.25.20:3478
; 62.71.2.168:3478
; 212.227.67.194:3478
; 212.227.67.195:3478
; 107.23.150.92:3478
; 77.72.169.155:3478
; 77.72.169.156:3478
; 77.72.169.164:3478
; 77.72.169.166:3478
; 77.72.174.162:3478
; 77.72.174.164:3478
; 77.72.174.166:3478
; 77.72.174.160:3478
; 54.172.47.69:3478

要启用TURN支持，解除注释：

turnURL=user:password@address:port

一个开源的TURN实现是coturn

KMS的日志默认存放在/var/log/kurento-media-server/目录下：

1. media-server_<timestamp>.<log_number>.<kms_pid>.log为本次运行的KMS日志
2. media-server_error.log为第三方错误日志
3. logs子目录存放历史日志

Kurento提供了Java/JavaScript的API，对于其它编程语言，目前需要通过WebSocket/JSON-RPC使用Kurento Protocol。 

本章仅仅进行概念上的阐述，如果需要了解针对具体语言的API，请参阅官方文档：

1. kurento-client-java：Java客户端
2. kurento-client-js：JavaScript客户端
3. kurento-utils-js：用于简化WebRTC应用开发的JavaScript工具

Kurento的主要类型的类图如下，可以看到MediaObject是所有类型的根，并且实现了组合模式：

媒体元素和媒体管线是最核心的API。

MediaElement是媒体流中，执行特定动作的功能单元。它让媒体特性对于应用开发者表现为自包含的黑盒，这些开发者不需要了解底层细节。

MediaElement可以通过mediaSrcs从其它媒体元素接收媒体，或者通过mediaSinks将媒体发送给其它媒体元素。

根据功能的不同，MediaElement可以分为：

1. 输入媒体元素：支持接收媒体，并将媒体注入到管线中。这类媒体元素有多种，实现从文件、网络、摄像头等来源读取媒体流
2. 过滤器：能够转换、分析媒体流，实现混合、AR之类的功能
3. HubPort：Hub负责管理管线中的多个媒体流。每个Hub有多个HubPort，这些HubPort连接其它媒体元素
4. 输出媒体元素：支持输出媒体，将媒体流带出管线。实现录像、在屏幕上播放、发送到网络等功能

MediaElement常常由Endpoint实现，后者可能同时作为输入、输出元素。

MediaPipeline是MediaElement构成的链条。链条可以有多个作为入口点的输入元素。由一个元素生成的输出流（SRC）可能输入到1-N个元素的输入流（SINK）：

端点是MediaElement的一种实现，能够输入、输出媒体流。端点类层次的类图如下：

这些端点的功能简述如下表：

recorder = new RecorderEndpoint.Builder(pipeline, "录像存储路径").build();
webrtcEndpoint.connect(recorder);

/home/alex/CPP/lib/kurento/src/kurento-media-server

关于端点，要注意：

1. 这些端点都是在KMS中运行的！尽管你会通过Java/Node的客户端，在应用服务器上操控端点，但是实质上都是基于Kurento协议向KMS发起远程调用
2. 端点可能具有SRC、SINK端子，分别用于发送媒体流到其它端点、接受其它端点的发来的媒体流。SRC、SINK是媒体管线内部概念
3. 端点可能对外部系统具有接收、发送媒体流的功能（但不叫SRC/SINK），例如WebRtcEndpoint。接收到的媒体流可以通过SRC发送给其它端点，其它端点发送到SINK的媒体流可以转发到外部系统
4. 端点自己的SRC可以连接到自己的SINK

代表一个运行在KMS中的WebRTC端点，是这类端点的控制接口。WebRTC端点可以和浏览器中的WebRTC客户端交互。例如环回视频流的那个实例，其媒体流向图如下：

说明如下：

1. 摄像头出来视频流，一方面在本地浏览器上渲染
2. 另外一方面，发送给KMS中的WebRTCEndpoint端点
3. 上一步的媒体流，到达SRC端子，进而发给自己的SINK端子（环回）
4. SINK端子的媒体流发回给浏览器
5. 浏览器在另外一个video元素中渲染视频流

WebRTC端点是P2P的WebRTC通信的一端，另一端可以是使用RTCPeerConnection接口的浏览器、Native的WebRTC应用程序、甚至是另一个KMS服务器。

为了建立WebRTC通信，两端必须进行SDP协商，其中一方作为邀请者（Offerer）另外一方作为应答者（Offeree），WebRTC端点可以作为两种角色之一。

当作为邀请者时：

1. KMS客户端调用generateOffer()方法后，KMS生成一个SDP offer，此Offer返回给KMS客户端（应用服务器），再被转发给浏览器
2. 浏览器处理上述Offer，并产生一个应答，应答传递给KMS客户端
3. 后者调用processAnswer()导致应答转发给KMS

当作为应答者时：

1. 浏览器生成一个SDP offer，发送到KMS客户端
2. KMS客户端调用processOffer()，SDP被转发给KMS，KMS生成应答，发送给KMS客户端
3. KMS客户端把应答转发给浏览器处理

SDP独立于ICE候选发送。Kurento使用优化了的ICE收发机制 ——  Trickle ICE。两端分别、独立的执行收集ICE候选：

1. 浏览器中候选会自动收集，你可以使用onicecandidate回调接收通知。此事件常常比SDP处理发生的更快
2. KMS必须依赖于客户端调用gatherCandidates()，并在此调用之前注册IceCandidateFound的监听器

KMS、浏览器每收集到一个ICE候选，就（以KMS客户端也就是应用服务器）为中介，发送给对方。接收到对方的ICE候选后，双方就会开始尝试建立双向连接。

需要注意WebRTC信号处理的异步性，假设你希望录制WebRTC端点的视频，在媒体流实际发送之前就执行录制是没有意义的。要感知WebRTC端点的状态，你需要监听端点的事件：

1. IceComponentStateChange，在WebRTC点对点连接性发生变化后立即发布。这个事件仅仅能用于检测底层的连接性，处于CONNECTED 状态不意味着媒体流就已经开始传输。连接性状态包括（RFC5245定义了它们之间的状态转换图）：
   1. DISCONNECTED  没有任何被调度的活动
   2. GATHERING 开始收集本地（KMS服务器）的ICE候选
   3. /home/alex/CPP/lib/kurento/src/kurento-media-serverCONNECTING  尝试创建连接，这在接收到对方的ICE候选后触发
   4. CONNECTED  至少一个有效的ICE候选对出现，导致双向连接成功
   5. READY  ICE结束，候选对选择完成
   6. FAILED  连接性检查已经完毕，但是媒体流连接没有建立
2. IceCandidateFound，一旦新的ICE候选可用即触发，这些候选必须被发送给对方
3. IceGatheringDone，所有ICE候选都被收集完毕后触发
4. NewCandidatePairSelected，当新的ICE候选对（本地、远程）可用时触发，当媒体会话已经进行后，此事件仍然可以触发 —— 一个更高优先级的ICE候选对被发现时
5. DataChannelOpen，数据通道打开时
6. DataChannelClose，数据通道关闭后

流控制、拥塞管理是WebRTC最重要的一项功能。WebRTC连接总是以一个较低的带宽开始，慢慢的加大到最大可用带宽。WebRTC 端点如果服务多个外部连接，那么它们将共享一个码流质量，这意味着一个新的外部连接接入后，现有连接的码流质量会下降（因为要从较低带宽开始）。

默认的带宽范围取值在100kbps-500kbps之间，可以单独设置SRC/SINK、音频/视频的带宽范围：

1. setMin/MaxVideoRecvBandwidth() 设置接收视频带宽
2. setMin/MaxAudioRecvBandwidth() 设置接收音频带宽
3. setMin/MaxVideoSendBandwidth() 设置发送视频带宽

带宽最大值在SDP中有声明。

WebRTC可以提供数据通道，并且支持可靠/不可靠、有序/无序的数据传输。要支持数据通道，必须在创建WebRtcEndpoint时显式说明，默认是不允许创建数据通道的

此端点从可Seek/不可Seek的媒体源中获取媒体流，并将流注入到KMS中。支持的URL格式：

1. 挂载到本地文件系统的文件：file:///path/to/file
2. 提供RTSP协议的摄像头：rtsp://、rtsp://username:password@ip:port...
3. Web服务器：http(s):///path/to/file、http(s)://username:password@/path/to/file

此端点支持以下操作：

这类媒体元素负责媒体的处理、机器视觉、AR等功能。 这些媒体元素的功能简述如下表：

FaceOverlayFilter filter = new FaceOverlayFilter.Builder(pipeline).build();
filter.setOverlayedImage("图片URL", -0.35F, -1.2F, 1.6F, 1.6F);

这类媒体对象能够管理多个媒体流。这些媒体对象的功能简述如下表：

Utils JS用于简化浏览器端WebRTC应用的开发。

执行下面的命令安装：

# 基于NPM
npm install kurento-utils
# 基于Bower
bower install kurento-utils

或者到这里下载压缩后的JS文件。

WebRtcPeer对RTCPeerConnection进行了包装。连接可以是单向的（进行发送或者接收），也可以是双向的（同时发送接收）。

下面的例子示意了如何基于Utils JS创建一个RTCPeerConnection，并与其它Peer进行会话协商：

// 信号处理通道，由你自己决定如何实现，它能够让客户端知道可以和谁通信、如何通信
// 典型的做法是，所有客户端公开一个自己的名字，同时以一条WebSocket连接到服务器
// 客户端通过名字发起通信请求，服务器负责中介会话协商
var signalingChannel = createSignalingChannel(peerName);

// 用于显示远程视频的元素
var videoInput = document.getElementById( 'videoInput' );
// 用于显示本地视频的元素
var videoOutput = document.getElementById( 'videoOutput' );
// getUserMedia约束条件
var constraints = {
    audio: true,
    video: {
        width: 640,
        framerate: 15
    }
};

var options = {
    localVideo: videoInput,
    remoteVideo: videoOutput,
    onicecandidate: function( candidate ){
        // 把本地candidate发送给Peer，基于Trickle ICE，也就是说，一旦发现一个候选，就立即发送
        // 不等待所有候选收集成功，这样效率更高。此回调可能被调用多次
        signalingChannel.sendCandidate(candidate );
    },
    mediaConstraints: constraints
};

// 创建一个连接。注意，在双方都需要创建连接，创建的时机，就是服务器确认了两者要进行通信之后
var webRtcPeer = kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv( options, function ( error ) {
    // 处理失败
    if ( error ) return onError( error );
    // 生成本地的SDP Offer
    this.generateOffer( onOffer );
} );

// 当收到Peer的candidate后，添加。下面的代码应该在信号处理的回调中调用
webRtcPeer.addIceCandidate(candidate);

// 当本地SDP Offer生成后，调用此回调
function onOffer( error, sdpOffer ) {
    if ( error ) return onError( error );
    // 发送SDP给Peer，Peer应该给出SDP应答，然后本地调用sdpAnswer回调
    signalingChannel.sendOffer( sdpOffer, sdpAnswer );
    function onAnswer( sdpAnswer ) {
        webRtcPeer.processAnswer( sdpAnswer );
    };
}

简述一下上例对应的业务流程：

1. 通信发起方A，根据接受方B的标识符，向服务器发送WS请求 —— 我要和B通信
2. 服务器通过WS推送信息给B，A想和你通信，你愿意吗？
3. 如果B愿意，服务器通过WS推送消息给A、B，你们可以通信了
4. A、B分别创建连接对象（WebRtcPeer）
5. WebRtcPeer会自动收集Candidate，你应该通过WS把Candidate发回服务器，服务器再中转给Peer
6. 一单A、B都收集到Candidate，它们就有可能进行点对点通信了（如果是局域网内）
7. A发起（Offer）一个会话描述（SDP），B接收到后，给出Answer
8. 根据双方的SDP，建立媒体流交换

数据通道允许你通过活动WebRTC连接传递二进制、文本数据。WebRtcPeer对数据通道的使用也提供了封装，将dataChannels选项设置为true即可使用：

var options = {
    localVideo: videoInput,
    remoteVideo: videoOutput,
    // 启用数据通道
    dataChannels: true,
    // 下面这个配置是可选的，允许你执行一些声明周期回调
    dataChannelConfig: {
        id: getChannelName(),
        onmessage: onMessage,
        onopen: onOpen,
        onclose: onClosed,
        onbufferedamountlow: onbufferedamountlow,
        onerror: onerror
    },
    onicecandidate: onIceCandidate
}

webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv( options, onWebRtcPeerCreated );

一旦webRtcPeer对象被创建，你就可以调用下面的方法，通过数据通道发送信息：

// 发送的数据类型取决于应用
webRtcPeer.send('Hello there');

数据通道的生命周期受限于其依赖的连接，

webRtcPeer.dispose()

Kurento是一个可拔插的框架，它的每个插件称为模块。模块分为三类。

这类模块安装了KMS就可以使用，包括：

这些模块用于增强KMS的基本功能，没有随KMS安装，包括：

sudo apt-get install kms-pointerdetector-6.0

sudo apt-get install kms-chroma-6.0

sudo apt-get install kms-crowddetector-6.0

sudo apt-get install kms-platedetector-6.0

你可以根据需要自己扩展KMS模块。

这是一个环回视频流的例子 —— 视频流发送给自己，需要一台客户端即可测试。通信流程如下：

1. 页面加载时，客户端自动创建一个到服务器的wss连接：
   

   var ws = new WebSocket('wss://' + location.host + '/helloworld'); 

   信号处理依赖此wss连接进行，信号格式为JSON，其id字段表示消息的类型。

2. 用户点击页面上的开始按钮，执行下面的逻辑：
   

   var options = {
      // 显示本地流的元素
      localVideo : videoInput,
      // 显示远程流的元素
      remoteVideo : videoOutput,
      // 当候选通信地址可用时，执行的回调
      onicecandidate : onIceCandidate
   }
   // 连接对象创建后执行的回调
   function( err ){
       if ( err ) console.error( err );
       // 生成SDP，成功后执行回调
       webRtcPeer.generateOffer( function( error, offerSdp ) {
           ws.send( JSON.stringify( {
               id : 'start',
               sdpOffer : offerSdp
           } ) );
       });
   }
   // 创建具有收、发能力的连接对象
   webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv( options, callback ); 

   也就是说，作为通信发起方：

   1. 创建一个连接对象WebRtcPeerSendrecv，此对象创建后，本地流立即就显示在localVideo这个video标签中
   2. 创建完毕后，即生成SDP，其内容如下（主要是发起方允许的连接方式、支持的媒体特性）：
      

      v=0
      # 第一个数字是会话标识，第二个数字是会话版本。后续三个参数和会话协商无关：网络类型Internet，地址类型IPv4，产生SDP的机器的地址
      o=- 6324724567974172241 2 IN IP4 127.0.0.1
      # 会话的名称，不常用
      s=-
      # 会话起止时间，都为0表示不限制时间
      t=0 0
      # BUNDLE分组将多个媒体行关联起来，在WebRTC中用于在同一RTP会话中传递多个媒体流
      a=group:BUNDLE audio video
      # 在PeerConnection声明周期中，赋予WebRTC媒体流唯一标识
      a=msid-semantic: WMS g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t
      
      ###  音频行  ### 
      # m表示这是一个媒体行，audio表示这是音频，后面是协议，最后的长串数字为媒体格式说明
      m=audio 38968 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
      # c表示这是一个连接行，表示收发数据通过什么IP进行。但是由于WebRTC强制使用ICE，因此这一行没什么用
      c=IN IP4 192.168.56.1
      # 明确说明用于RTCP的地址和端口
      a=rtcp:51004 IN IP4 192.168.56.1
      # 下面若干行都是ICE候选，ICE是用于NAT穿透的协议
      #           标识       1RTP/2RTCP 优先级  通信地址和端口
      a=candidate:2999745851 1 udp 2122260223 192.168.56.1 38968 typ host generation 0
      a=candidate:364622241 1 udp 2122194687 10.255.0.1 49487 typ host generation 0
      a=candidate:1051995033 1 udp 2122129151 172.18.0.1 52714 typ host generation 0
      a=candidate:410389623 1 udp 2122063615 172.21.0.1 54819 typ host generation 0
      a=candidate:2199032595 1 udp 2121998079 192.168.1.89 47718 typ host generation 0
      a=candidate:627415207 1 udp 2121932543 192.168.0.89 52455 typ host generation 0
      a=candidate:2999745851 2 udp 2122260222 192.168.56.1 51004 typ host generation 0
      a=candidate:364622241 2 udp 2122194686 10.255.0.1 59954 typ host generation 0
      a=candidate:1051995033 2 udp 2122129150 172.18.0.1 41985 typ host generation 0
      a=candidate:410389623 2 udp 2122063614 172.21.0.1 59234 typ host generation 0
      a=candidate:2199032595 2 udp 2121998078 192.168.1.89 58222 typ host generation 0
      a=candidate:627415207 2 udp 2121932542 192.168.0.89 36590 typ host generation 0
      # 下面两行是ICE参数
      a=ice-ufrag:Oyu3vwR19M1nxsx4
      a=ice-pwd:8RbNWdv799Hz7aXWj2DMIPGH
      # 下面两行是DTLS参数
      # DTLS-SRTP协商时使用的证书的指纹信息
      a=fingerprint:sha-256 58:BC:1A:0B:22:10:95:7B:C9:98:4A:D5:34:E9:44:85:FF:9D:A4:7B:07:39:36:FE:90:59:E0:14:3D:B9:21:6C
      a=setup:actpass
      # 用在BUNDLE中的标识符
      a=mid:audio
      # 定义RTP扩展头
      a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
      a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
      # 同时支持接收、发送
      a=sendrecv
      # 支持RTCP多路复用
      a=rtcp-mux
      # 解码器参数
      a=rtpmap:111 opus/48000/2
      a=rtcp-fb:111 transport-cc
      a=fmtp:111 minptime=10; useinbandfec=1
      a=rtpmap:103 ISAC/16000
      a=rtpmap:104 ISAC/32000
      a=rtpmap:9 G722/8000
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:106 CN/32000
      a=rtpmap:105 CN/16000
      a=rtpmap:13 CN/8000
      a=rtpmap:126 telephone-event/8000
      a=maxptime:60
      # SSRC参数
      a=ssrc:2978616353 cname:GrA29DQMxaUfd99u
      a=ssrc:2978616353 msid:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t 97776675-4490-4b74-a849-bbd46a722c89
      a=ssrc:2978616353 mslabel:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t
      a=ssrc:2978616353 label:97776675-4490-4b74-a849-bbd46a722c89
      m=video 46497 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
      c=IN IP4 192.168.56.1
      a=rtcp:9 IN IP4 0.0.0.0
      a=candidate:2999745851 1 udp 2122260223 192.168.56.1 46497 typ host generation 0
      a=candidate:364622241 1 udp 2122194687 10.255.0.1 34284 typ host generation 0
      a=ice-ufrag:Oyu3vwR19M1nxsx4
      a=ice-pwd:8RbNWdv799Hz7aXWj2DMIPGH
      a=fingerprint:sha-256 58:BC:1A:0B:22:10:95:7B:C9:98:4A:D5:34:E9:44:85:FF:9D:A4:7B:07:39:36:FE:90:59:E0:14:3D:B9:21:6C
      a=setup:actpass
      
      ### 视频行 ### 
      a=mid:video
      a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
      a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
      a=extmap:4 urn:3gpp:video-orientation
      a=sendrecv
      a=rtcp-mux
      # 支持的视频编码
      a=rtpmap:100 VP8/90000
      # 如果客户端是Firefox、Chrome 61 —— 支持H264
      a=rtpmap:120 VP8/90000
      a=rtpmap:126 H264/90000
      a=rtpmap:97 H264/90000
      # 则出现以上三行
      a=rtcp-fb:100 ccm fir
      a=rtcp-fb:100 nack
      a=rtcp-fb:100 nack pli
      a=rtcp-fb:100 goog-remb
      a=rtcp-fb:100 transport-cc
      a=rtpmap:101 VP9/90000
      a=rtcp-fb:101 ccm fir
      a=rtcp-fb:101 nack
      a=rtcp-fb:101 nack pli
      a=rtcp-fb:101 goog-remb
      a=rtcp-fb:101 transport-cc
      a=rtpmap:116 red/90000
      a=rtpmap:117 ulpfec/90000
      a=rtpmap:96 rtx/90000
      a=fmtp:96 apt=100
      a=rtpmap:97 rtx/90000
      a=fmtp:97 apt=101
      a=rtpmap:98 rtx/90000
      a=fmtp:98 apt=116
      a=ssrc-group:FID 3977515695 1979665708
      a=ssrc:3977515695 cname:GrA29DQMxaUfd99u
      a=ssrc:3977515695 msid:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t 153f4d5f-ba5b-4772-8700-aff4474d8652
      a=ssrc:3977515695 mslabel:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t
      a=ssrc:3977515695 label:153f4d5f-ba5b-4772-8700-aff4474d8652
      a=ssrc:1979665708 cname:GrA29DQMxaUfd99u
      a=ssrc:1979665708 msid:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t 153f4d5f-ba5b-4772-8700-aff4474d8652
      a=ssrc:1979665708 mslabel:g8OrPwtoxMptMUo5k12OkvC8opycXELqVG9t
      a=ssrc:1979665708 label:153f4d5f-ba5b-4772-8700-aff4474d8652

   3. 上述SDP以消息类型start发送给服务器
3. 服务器接收到start消息后，执行以下逻辑：
   

   // 创建媒体管线
   MediaPipeline pipeline = kurento.createMediaPipeline();
   // 在管线中添加一个WebRTC端点
   WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
   // 连接WebRTC端点到自己
   webRtcEndpoint.connect(webRtcEndpoint);
   
   // 创建一个用户会话（UserSession不属于KMS 客户端API的组成部分）
   UserSession user = new UserSession();
   // 连接到的管线
   user.setMediaPipeline(pipeline);
   // 连接到的端点，注意此端点的输入、输出是同一个流
   user.setWebRtcEndpoint(webRtcEndpoint);
   // 以WebSocket会话标识时别用户https://localhost:8443/#
   users.put(session.getId(), user);
   
   // 处理SDP
   String sdpOffer = jsonMessage.get("sdpOffer").getAsString();
   // 由端点来处理SDP，生成应答
   String sdpAnswer = webRtcEndpoint.processOffer(sdpOffer);
   // 以消息类型startResponse将应答SDP通过WebSocketSession发回给客户端
   JsonObject response = new JsonObject();response.addProperty("id", "startResponse");
   response.addProperty("sdpAnswer", sdpAnswer);
   synchronized (session) {
       session.sendMessage(new TextMessage(response.toString()));
   }
   
   // 一旦收集到服务器的ICE候选信息，即以消息类型iceCandidate发送给客户端
   webRtcEndpoint.addIceCandidateFoundListener(new EventListener<IceCandidateFoundEvent>() {
     @Override
     public void onEvent(IceCandidateFoundEvent event) {
       JsonObject response = new JsonObject();
       response.addProperty("id", "iceCandidate");
       response.add("candidate", JsonUtils.toJsonObject(event.getCandidate()));
       try {
         synchronized (session) {
           session.sendMessage(new TextMessage(response.toString()));
         }
       } catch (IOException e) {
         log.error(e.getMessage());
       }
     }
   });
   // 为某个端点收集服务器的ICE候选信息
   webRtcEndpoint.gatherCandidates();

   服务器生成的SDP应答内容如下：

   v=0
   o=- 3713658153 3713658153 IN IP4 0.0.0.0
   s=Kurento Media Server
   c=IN IP4 0.0.0.0
   t=0 0
   a=msid-semantic: WMS kGkOSxP0iFTu9aRzm53BNz0fROtBq1HxLFje
   a=group:BUNDLE audio video
   m=audio 1 UDP/TLS/RTP/SAVPF 111 0
   a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
   a=mid:audio
   a=rtcp:9 IN IP4 0.0.0.0
   a=rtpmap:111 opus/48000/2
   a=rtpmap:0 PCMU/8000
   a=setup:active
   a=sendrecv
   a=rtcp-mux
   a=fmtp:111 minptime=10; useinbandfec=1
   a=maxptime:60
   a=ssrc:1475810019 cname:user35735626@host-c1cf1e49
   a=ice-ufrag:/Jml
   a=ice-pwd:RCpQ+o7Ybof5B5mxYDGM17
   a=fingerprint:sha-256 B4:72:A8:44:90:3D:CF:1B:8E:30:93:09:AC:66:BF:05:60:D7:0B:C3:C3:AA:28:7D:44:46:8E:55:17:61:4F:43
   m=video 1 UDP/TLS/RTP/SAVPF 100
   a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
   a=mid:video
   a=rtcp:9 IN IP4 0.0.0.0
   # 使用VP8作为视频编码格式
   a=rtpmap:100 VP8/90000
   a=rtcp-fb:100 ccm fir
   a=rtcp-fb:100 nack
   a=rtcp-fb:100 nack pli
   a=rtcp-fb:100 goog-remb
   a=setup:active
   a=sendrecv
   a=rtcp-mux
   a=ssrc:101029323 cname:user35735626@host-c1cf1e49
   a=ice-ufrag:/Jml
   a=ice-pwd:RCpQ+o7Ybof5B5mxYDGM17
   a=fingerprint:sha-256 B4:72:A8:44:90:3D:CF:1B:8E:30:93:09:AC:66:BF:05:60:D7:0B:C3:C3:AA:28:7D:44:46:8E:55:17:61:4F:43

4. 客户端接收到startResponse消息后，调用下面的方法处理SDP应答：
   

   webRtcPeer.processAnswer(message.sdpAnswer, function(error) {
       if (error) console.error(error);
   });

5. 关于Ice Candidate的处理上面没有提及，这会异步的进行：
   1. 客户端连接创建后，就会自动收集ICE候选，一旦收集到，就调用如下回调：
      

      function onIceCandidate(candidate) {
          ws.send(JSON.stringify({
              id : 'onIceCandidate',
              candidate : candidate
          }));
      }

      候选的内容如下：

      {
          // 此候选的通信地址
          "candidate":"candidate:2999745851 1 udp 2122260223 192.168.56.1 36777 typ host generation 0 ufrag waE0gMnNFX3ug+yW",
          // 此候选关联的媒体流的标识（identification-tag）
          "sdpMid":"audio",
          // 此候选关联SDP中媒体描述的索引
          "sdpMLineIndex":0
      }

      也就是说，以消息类型onIceCandidate发送给服务器

   2. 服务器接收到onIceCandidate消息后，将其保存到用户对象中：
      

      UserSession user = users.get(session.getId());
      IceCandidate candidate = new IceCandidate(
          jsonCandidate.get("candidate").getAsString(),
          jsonCandidate.get("sdpMid").getAsString(),
          jsonCandidate.get("sdpMLineIndex").getAsInt()
      );
      user.addCandidate(candidate);

   3. 随着客户端候选的收集，onIceCandidate消息会被发送很多次，后续的sdpMid可能是video，sdpMLineIndex可能是1

   4. 服务器端在创建端点后，也同样会自动收集ICE候选信息，并以iceCandidate消息发送给客户端。候选的内容如下：
      

      {
          "candidate": "candidate:5 1 TCP 1019216383 172.21.0.6 9 typ host tcptype active",
          "sdpMid":"video",
          "sdpMLineIndex":1
      }

   5. 客户端做如下处理：
      

      webRtcPeer.addIceCandidate(parsedMessage.candidate, function(error) {
          if (error)  console.error(error);
      });

   6. 随着服务器端候选的收集， iceCandidate消息也会被发送多次

6. 随着候选信息的收集，webRtcPeer有了足够的信息，它会在remoteView元素中渲染远程媒体流
7. 当用户点击停止按钮后，调用

   webRtcPeer.dispose()

   并发送一个stop类型的消息
8. 服务器收到stop消息后，清理用户数据：
   

   UserSession user = users.remove(session.getId());
   user.release();

   1. 释放用户数据的时候，会调用

      mediaPipeline.release()

      释放媒体管线
9. 页面卸载时，客户端自动关闭wss连接：
   

   ws.close();

在这个HelloWorld例子中，媒体流不是简单的由客户端发给自己，而是由服务器中转。也就是说，通信的Peer是服务器、客户端。

可以在上例的Loopback媒体管线上插入一个FaceOverlayFilter，在检测到人脸时，附加一个帽子图片到人脸上方：

UserSession user = new UserSession();
MediaPipeline pipeline = kurento.createMediaPipeline();
WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder(pipeline).build();
user.setWebRtcEndpoint(webRtcEndpoint);

// 注意媒体管线在KMS中运行
FaceOverlayFilter faceOverlayFilter = new FaceOverlayFilter.Builder(pipeline).build();
faceOverlayFilter.setOverlayedImage(“https://172.21.0.1:8443/img/mario-wings.png", -0.35F, -1.2F, 1.6F, 1.6F);
// 连接WebRTC端点的SRC（输出）到FaceOverlayFilter的SINK（输入）
webRtcEndpoint.connect(faceOverlayFilter);
// 连接FaceOverlayFilter的SRC（输出）到WebRTC的SINK（输入）
faceOverlayFilter.connect(webRtcEndpoint);

首先初始化连接：

// 仅仅需要发送数据，不需要接收
webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerSendonly(
    {
        localVideo : video,
        onicecandidate : function(){ /* 发送本地ICE候选信息给服务器 */ }
    },
    function( err ){
        webRtcPeer.generateOffer(function( err, offerSdp ){
            /* 发送SDP，消息类型presenter */
        });
    }
)

服务器接收到presenter消息后，会发送一个presenterResponse消息过来。如果服务器同意当前客户端作为发布者，则发布者调用：

webRtcPeer.processAnswer(message.sdpAnswer);
// 否则关闭连接

服务器发来的ICE候选消息的处理，和前面的例子一样。 

首先也是初始化连接：

webRtcPeer = new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly( options, function( err ){
    this.generateOffer(function(){
        /* 发送SDP，消息类型viewer */
    });
});

viewerResponse、 服务器发来的ICE候选消息的处理，和发布者一样。

当服务器接收到发布者发来的presenter消息时，执行：

1. 记录一个发布者的会话对象，本质上是基于WS客户端标识对发布者进行时别
2. 创建媒体管线：
   

   pipeline = kurento.createMediaPipeline();
   // 设置发布者的端点对象
   presenterUserSession.setWebRtcEndpoint(new WebRtcEndpoint.Builder(pipeline).build());
   // 当服务器的ICE候选准备好之后，发送给发布者客户端：
   presenterUserSession.getWebRtcEndpoint().addIceCandidateFoundListener( e-> {
       // 作为iceCandidate事件发送
   });
   
   // 处理发布者的SDP
   String sdpOffer = jsonMessage.getAsJsonPrimitive("sdpOffer").getAsString();
   String sdpAnswer = presenterWebRtc.processOffer(sdpOffer);
   // 然后以presenterResponse消息发送SDP应答给发布者
   
   // 最后，为发布者收集ICE候选信息
   presenterWebRtc.gatherCandidates();

3. 当接收到发布者的ICE候选后，把这些信息记录到代表发布者的会话对象中：
   

   presenterUserSession.addCandidate(cand); // 处理方式和HelloWorld那个例子相同 

到目前为止，尚未发生任何媒体流的传输工作。因为没有人查看者。

当有查看者接入后，服务器首先收到一个viewer信息，并执行：

1. 如果当前没有发布者，返回viewerResponse消息，其response属性为rejected
2. 如果当前有发布者，则为其创建UserSession对象、WebRtcEndpoint端点，并发此端点加入到之前创建的管线中：
   

   UserSession viewer = new UserSession(webSocketSession);
   WebRtcEndpoint nextWebRtc = new WebRtcEndpoint.Builder(pipeline).build();
   viewer.setWebRtcEndpoint(nextWebRtc);
   viewer.getWebRtcEndpoint().addIceCandidateFoundListener( e-> {
       // 作为iceCandidate事件发送
   });
   
   // 重要：将发布者的SRC连接到查看者的SINK
   presenterUserSession.getWebRtcEndpoint().connect(nextWebRtc);
   
   // 处理查看者的SDP
   String sdpOffer = jsonMessage.getAsJsonPrimitive("sdpOffer").getAsString();
   // SDP应答总是调用请求者的端点对象获得
   String sdpAnswer = nextWebRtc.processOffer(sdpOffer);
   // 然后以viewerResponse消息发送SDP应答给发布者
   
   // 最后，为观看者收集ICE候选信息
   nextWebRtc.gatherCandidates();

当由更多的查看者连接进来后，发布者端点的SRC将连接到更多的SINK，呈现出星状结构。从ICE候选信息来看，貌似媒体流都是从服务器中转的。

这个在实现上没有特别的地方，参与通话双方的WebRTC端点，需要配置为首尾相连。

此外，业务逻辑部分需要实现拒接之类的功能。

相当于每个参与者都进行一对多广播。在实现时，往往会抽象出会议房间（Group）的概念，房间内的每个人都需要对其它人进行广播。

每个参与者都需要创建一个发送端点，N-1个接收端点，一共N个video元素。

此外，一旦有新人加入、旧人退出，就需要通知房间的所有参与者，进行客户端资源清理、UI更新。

这类应用场景中，媒体流的来源主要有两类：

1. 基于ONVIF框架协议，视频流基于RTSP/RTP传输
2. 由设备SDK提供，SDK可能提供标准格式的码流、视频帧，或者解码后的原始图像

视频监控的主要需求包括：

1. 实时监控，特别是多画面实时监控
2. 录像回放
3. 视频分析，例如移动侦测、模式识别

为了简化开发，我们对Kurento、信号处理进行了组件化封装。

代表一个WebRTC客户端与Kurento的媒体会话：

package cc.gmem.study.kurento;


import org.kurento.client.Endpoint;
import org.kurento.client.IceCandidate;
import org.kurento.client.MediaPipeline;
import org.kurento.client.WebRtcEndpoint;

import java.security.Principal;
import java.util.ArrayList;
import java.util.List;

public class MediaSession {

    private String id;

    private Principal principal;

    private MediaPipeline pipeline;

    private WebRtcEndpoint endpoint;

    private List<IceCandidate> candidatesPending;

    public MediaSession( String id ) {
        this.id = id;
        candidatesPending = new ArrayList<>();
    }

    public MediaPipeline getPipeline() {
        return pipeline;
    }

    public void setPipeline( MediaPipeline pipeline ) {
        this.pipeline = pipeline;
    }

    public Endpoint getEndpoint() {
        return endpoint;
    }

    public synchronized void setEndpoint( WebRtcEndpoint endpoint ) {
        this.endpoint = endpoint;
        // ICE可能在端点创建之前就送达
        if ( candidatesPending != null ) {
            candidatesPending.forEach( cp -> {
                endpoint.addIceCandidate( cp );
            } );
            candidatesPending = null;
        }
    }

    @Override
    public String toString() {
        return String.format( "id = %s  ep = %s  pp = %s", getId(), getEndpoint(), getPipeline() );
    }

    public String getId() {
        return id;
    }

    public Principal getPrincipal() {
        return principal;
    }

    public void setPrincipal( Principal principal ) {
        this.principal = principal;
    }

    public synchronized void addIceCandidate( IceCandidate candidate ) {
        // ICE可能在端点创建之前就送达
        if ( endpoint == null ) {
            candidatesPending.add( candidate );
        } else {
            endpoint.addIceCandidate( candidate );
        }
    }
}

Spring Boot应用程序，信号处理以STOMP作为子协议：

package cc.gmem.study.kurento;

import org.kurento.client.KurentoClient;
import org.kurento.client.KurentoClientBuilder;
import org.kurento.client.MediaPipeline;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.messaging.Message;
import org.springframework.messaging.MessageChannel;
import org.springframework.messaging.simp.SimpMessagingTemplate;
import org.springframework.messaging.simp.config.ChannelRegistration;
import org.springframework.messaging.simp.config.MessageBrokerRegistry;
import org.springframework.messaging.simp.stomp.StompCommand;
import org.springframework.messaging.simp.stomp.StompHeaderAccessor;
import org.springframework.messaging.support.ChannelInterceptorAdapter;
import org.springframework.messaging.support.MessageHeaderAccessor;
import org.springframework.util.AntPathMatcher;
import org.springframework.web.socket.config.annotation.AbstractWebSocketMessageBrokerConfigurer;
import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
import org.springframework.web.socket.config.annotation.StompEndpointRegistry;
import sun.security.acl.PrincipalImpl;

import java.security.Principal;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

@SpringBootApplication
@EnableWebSocketMessageBroker
public class VideoSurveillanceApp extends AbstractWebSocketMessageBrokerConfigurer {

    private static final Logger LOGGER = LoggerFactory.getLogger( VideoSurveillanceApp.class );

    private Map<String, MediaSession> sessions = new ConcurrentHashMap<>();

    public void registerStompEndpoints( StompEndpointRegistry registry ) {
        // 信号处理在 /signal下进行
        registry.addEndpoint( "/signal" );
    }

    @Override
    public void configureMessageBroker( MessageBrokerRegistry registry ) {
        registry.setApplicationDestinationPrefixes( "/app" );
    }

    @Override
    public void configureClientInboundChannel( ChannelRegistration registration ) {
        registration.setInterceptors( new ChannelInterceptorAdapter() {
            @Override
            public Message<?> preSend( Message<?> message, MessageChannel channel ) {
                StompHeaderAccessor accessor = MessageHeaderAccessor.getAccessor( message, StompHeaderAccessor.class );
                String simpSessionId = (String) accessor.getHeader( "simpSessionId" );
                MediaSession session = getMideaSession( simpSessionId );
                if ( StompCommand.CONNECT.equals( accessor.getCommand() ) ) {
                    // 设置当前用户身份
                    String login = accessor.getNativeHeader( "login" ).get( 0 );
                    Principal principal = new PrincipalImpl( login );
                    accessor.setUser( principal );
                    session.setPrincipal( principal );
                    LOGGER.info( "User {} connected with session id {}", login, simpSessionId );
                }
                // 每次处理消息之前，设置session头，便于消息处理方法注入之
                accessor.setHeader( "session", session );
                return message;
            }
        } );
    }

    private MediaSession getMideaSession( String simpSessionId ) {
        if ( sessions.containsKey( simpSessionId ) ) {
            return sessions.get( simpSessionId );
        } else {
            MediaSession session = new MediaSession( simpSessionId );
            sessions.put( simpSessionId, session );
            return session;
        }
    }

    @Bean
    public KurentoClient kurentoClient() {
        return new KurentoClientBuilder().setKmsWsUri( "ws://172.21.0.6:8888/kurento" ).connect();
    }

    public static void main( String[] args ) {
        new SpringApplication( VideoSurveillanceApp.class ).run( args );
    }
}

封装一些模板代码：

package cc.gmem.study.kurento;

import org.kurento.client.KurentoClient;
import org.kurento.client.MediaPipeline;
import org.kurento.client.WebRtcEndpoint;
import org.springframework.messaging.simp.SimpMessagingTemplate;
import org.springframework.stereotype.Service;

import javax.inject.Inject;

@Service
public class KurentoService {

    @Inject
    private KurentoClient client;

    @Inject
    private SimpMessagingTemplate template;

    /**
     * 初始化一个媒体管线
     *
     * @return
     */
    public MediaPipeline createMediaPipeline() {
        return client.createMediaPipeline();
    }

    /**
     * 在媒体管线上创建一个与WebRTC浏览器客户端通信的端点
     *
     * @param pipeline 管线
     * @param sdpoffer 浏览器发送来的SDP邀请
     * @param user     浏览器的身份
     * @return 运行在KMS中的WebRTC端点
     */
    public WebRtcEndpoint createWebRtcEndpoint( MediaPipeline pipeline, String sdpoffer, String user, String namespace ) {
        WebRtcEndpoint webRtcEndpoint = new WebRtcEndpoint.Builder( pipeline ).build();
        // 处理SDP
        String sdpAnswer = webRtcEndpoint.processOffer( sdpoffer );
        template.convertAndSendToUser( user, namespace + "/sdpanswer", sdpAnswer );
        // 处理ICE候选
        webRtcEndpoint.addIceCandidateFoundListener( event -> {
            String dest = namespace + "/icecandidate";
            template.convertAndSendToUser( user, dest, event.getCandidate() );
        } );
        webRtcEndpoint.gatherCandidates();
        return webRtcEndpoint;
    }
} 

对stomp.js进行简单的封装：

1. 每个客户端在一个名字空间内操作
2. 订阅总是针对/user前缀进行
3. 发送总是针对/app前缀进行 

代码如下：

class StompClient {
    /**
     * 选项：
     * url，WebSocket连接地址
     * namespace，不包含/app、/user的目的地前缀
     * login，用户名
     * passcode，密码
     */
    constructor( options ) {
        this.namespace = options.namespace || {};
        this.pending = [];
        this.stomp = Stomp.over( new WebSocket( options.url ) );
        this.stomp.heartbeat.outgoing = 20000;
        this.stomp.connect( options.login, options.passcode, ( frame ) => {
            this.connected = true;
            this.processPending();
        } );
    }

    processPending() {
        if ( this.connected ) {
            let pending = this.pending;
            this.pending = [];
            pending.forEach( callback => callback() );
        }
    }

    recv( destination, callback ) {
        this.pending.push( () => {
            this.stomp.subscribe( '/user' + this.namespace + destination, ( frame ) => {
                callback( this.decode( frame.body, frame.headers[ 'content-type' ] ), frame );
            } );
        } );
        this.processPending();
    }

    encode( obj ) {
        return JSON.stringify( obj );
    }

    decode( str, mimeType ) {
        // 自动分析MIME类型，进行适当的解析
        if ( mimeType.startsWith( 'application/json;' ) ) {
            return JSON.parse( str );
        }
        else {
            return str;
        }
    }

    send( destination, object ) {
        this.pending.push( () => {
            this.stomp.send( '/app' + this.namespace + destination, {
                "content-type": "application/json;charset=UTF-8"
            }, this.encode( object ) );
        } );
        this.processPending();
    }

    disconnect() {
        this.stomp.disconnect();
    }
}

对Kurento Utils的WebRtcPeer进行封装。 

WebRTCEndpoint的STOMP消息目的地格式：  前缀 + 名字空间 + 消息类型。消息类型包括：

1. sdpoffer，表示浏览器客户端发起SDP邀请
2. sdpanswer，表示KMS客户端发给浏览器的SDP应答
3. icecandidate，双方交换ICE候选
4. stop，客户端请求停止会话
5. 其它消息类型

代码如下：

class WebRTCEndpoint {
    constructor( mode, options ) {
        /**
         * 选项：
         * remoteVideo，显示远程视频流的元素
         */
        options = options || {};
        let stomp = new StompClient( {
            url: options.url,
            namespace: options.namespace,
            login: options.login
        } );

        let webRtcPeerType;
        switch ( mode ) {
            case WebRTCEndpoint.MODE_SEND:
                webRtcPeerType = kurentoUtils.WebRtcPeer.WebRtcPeerSendonly;
                break;
            case WebRTCEndpoint.MODE_RECV:
                webRtcPeerType = kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly;
                break;
            case WebRTCEndpoint.MODE_SEND_RECV:
                webRtcPeerType = kurentoUtils.WebRtcPeer.WebRtcPeerSendrecv;
                break;
        }
        stomp.recv( '/icecandidate', candidate => {
            this.peer.addIceCandidate( candidate );
        } );
        stomp.recv( '/sdpanswer', answer => {
            this.peer.processAnswer( answer );
        } );
        options.onicecandidate = candidate => {
            stomp.send( '/icecandidate', candidate );
        }
        this.peer = webRtcPeerType( options, err => {
            this.peer.generateOffer( ( error, sdpOffer ) => {
                stomp.send( '/sdpoffer', sdpOffer );
            } );
        } );
        this.stomp = stomp;
    }

    dispose() {
        this.stomp.send( '/stop', "bye" );
        this.stomp.disconnect();
        this.peer && this.peer.dispose();
    }
}
WebRTCEndpoint.MODE_SEND = 0;
WebRTCEndpoint.MODE_RECV = 1;
WebRTCEndpoint.MODE_SEND_RECV = 2; 

以下情况下可以考虑RTSP接入：

1. IP摄像头或者NVR直接提供流RTSP协议服务器
2. 通过SDK获取码流，手工创建RTSP协议服务器

对于第二种方式，还可以考虑利用Kurento的RTPEndpint，直接通过RTP协议发送媒体流到KMS。

IP摄像头常常会提供某种基于流的接入方式：

1. RTSP/H.264：这类摄像头通常用在视频监控领域。它们通过RTSP协议来建立RTP媒体会话 —— 信号处理基于RTSP进行而媒体流直接通过RTP传输。不同的摄像头厂商支持的RTP profile可能不同，AVP（用于音视频会议的RTP profile，最小化控制。RTP Profile for Audio and Video Conferences
   with Minimal Control）是一种常用的profile。视频编码方式也有不同的选择，典型的是 H.264
2. HTTP/MJPEG：这类摄像头基于HTTP协议进行信号处理和媒体传输，视频流被编码为JPEG的序列。这类摄像头的硬件比较简单，资源（包括电量）消耗少但是视频质量差

要实现WebRTC到IP摄像头的媒体互操作性，两者的码流格式必须兼容，这种码流转换的工作是由某种WebRTC网关负责的（例如Kurento）。此网关需要完成：

1. 和摄像头交互，也就是网关需要理解RTSP/RTP或者HTTP
2. 解码从摄像头取得的码流，例如H264或者MJPEG
3. 将码流重新编为浏览器支持的格式，例如VP8是WebRTC最广泛支持的编码
4. 通过WebRTC协议把码流发送给客户端

此工作流示意如下图：

在Chrome中WebRTC使用的视频编码格式一直是VP8/VP9，直到Chrome 50才支持H264。你可以使用标记enable-webrtc-h264-with-openh264-ffmpeg打开H264支持（最新的Chrome 61此标记默认是打开的）。

H264被微软Edge的ORTC、Firefox、移动设备、遗留视频系统支持。移动设备大部分支持H264硬件解码，这意味着播放视频不会过于消耗电池，这一点很关键。

目前的情况并不乐观，主要是不同系统对于H.264的支持程度不同，它们可能支持不兼容的Profile，因而存在互操作性问题。

WebRTC协议栈使用SAVPF这一RTP profile， 其含义是针对基于RTCP的反馈的扩展安全RTP profile（Extended Secure RTP Profile for Real-time Transport Control Protocol Based Feedback），SAVPF主要包括两个RTP profile：

1. SAVP：AVP的基础上包含安全特性
2. AVPF：用于及时的向媒体流的发送者反馈信息

SAVPF的意义在于，提供安全RTP通信的基础上支持反馈。WebRTC客户端会向WebRTC网关发送反馈信息（在RTCP包中），通知网关可能影响到媒体质量的网络状况。

大多数IP摄像头仅仅支持AVP，这意味着，网关无法把WebRTC的反馈传递给IP摄像头。网关必须自己管理好反馈信息，或者用行话说，网关必须终结（terminate）RTCP反馈。

这一点很重要，如果网关没有正确处理反馈，WebRTC客户端可能出现严重的QoS问题，通常是视频画面卡死。卡死的具体原因是：

1. PLI（画面丢失提示，Picture Loss Indication）反馈：如果此反馈没有被网关正确处理，只要出现丢包，画面可能随机的卡死。这和VP8编码器的工作机制有关。VP8允许长时间没有关键帧生成（以分钟计），当PLI出现后网关应该立即生成新的关键帧，否则直到下一次关键帧（周期性的）到达，客户端都无法解码。某些网关的解决方式是，频繁的生成关键帧，这种做法的劣势是大量消耗带宽，导致视频质量差
2. REMB（接收者估算的最大比特率， Receiver Estimated Maximum Bitrate）反馈：如果网关没有处理此反馈，且没有任何拥塞控制机制，则网关就不可能指示VP8编码器降低比特率。这样随着接入的客户端便多，网络带宽不够用后，视频质量变差

将Kurento作为WebRTC网关时，上述互操作性问题已经被解决，你需要了解以下三点：

1. PlayerEndpoint这个端点支持从各种各样的源读取视频流，这些源可以是RTSP/RTP、HTTP/MJPEG。这意味着PlayerEndpoint有能力从IP摄像头读取码流
2. WebRtcEndpoint这个端点支持完整的WebRTC协议栈，能够正确处理RTCP反馈：
   1. 每当PLI包被收到，WebRtcEndpoint会命令VP8编码器立即生成一个新的关键帧
   2. 内置了拥塞控制，且响应REMB包。必要时命令VP8编码器降低比特率
3. 不可知媒体特性：当两个不兼容的媒体元素连接在一起时，Kurento会自动进行编码格式转换。也就是说H.264/MJPEG到VP8的转码会自动发生，不需要开发人员干预

RTSP到WebRTC的媒体管线示意如下：

客户端代码：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>WebRTC Video Surveillance - RTSP Preview</title>
    <script src="js/stomp.js"></script>
    <script src="js/stomp-wrapper.js"></script>
    <script src="js/adapter.js"></script>
    <script src="js/kurento-utils.js"></script>
    <script src="js/webrtc-endpoint.js"></script>
</head>
<body onunload="endpoint.dispose();">
<div>
    <video id="remoteVideo" autoplay width="427px" height="240px"></video>
</div>
<script>
    let endpoint = new WebRTCEndpoint( WebRTCEndpoint.MODE_RECV, {
        url: 'ws://172.21.0.1:9090/signal',
        namespace: '/rtsp/preview',
        login: new Date().getTime(),
        remoteVideo: document.getElementById( 'remoteVideo' )
    } );
</script>
</body>
</html>

服务器代码：

package cc.gmem.study.kurento;

import org.kurento.client.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.messaging.handler.annotation.Header;
import org.springframework.messaging.handler.annotation.MessageMapping;
import org.springframework.messaging.simp.SimpMessagingTemplate;
import org.springframework.stereotype.Controller;

import javax.inject.Inject;
import java.security.Principal;

@Controller
@MessageMapping( RtspPreviewController.NAMESPACE )
public class RtspPreviewController {

    private static final Logger LOGGER = LoggerFactory.getLogger( RtspPreviewController.class );

    public static final String NAMESPACE = "/rtsp/preview";

    @Inject
    private KurentoService kurento;

    @MessageMapping( "/icecandidate" )
    public void onIceCandidate( IceCandidate candidate, @Header MediaSession session ) {
        WebRtcEndpoint endpoint = (WebRtcEndpoint) session.getEndpoint();
        session.addIceCandidate( candidate );
        return;
    }

    @MessageMapping( "/stop" )
    public void onStop( @Header MediaSession session ) {
        session.getEndpoint().release();
        session.getPipeline().release();
    }

    @MessageMapping( "/sdpoffer" )
    public void onSdpOffer( String sdpoffer, Principal principal, @Header MediaSession session ) {

        MediaPipeline pipeline = kurento.createMediaPipeline();
        session.setPipeline( pipeline );

        PlayerEndpoint.Builder peb = new PlayerEndpoint.Builder( pipeline, "rtsp://admin:12345@192.168.0.196:554/ch1/main/av_stream" );
        PlayerEndpoint playerEndpoint = peb.build();
        playerEndpoint.addMediaFlowInStateChangeListener( e -> {
            LOGGER.info( "RTSP input flow state changed, media type: {}, media state: {}", e.getMediaType(), e.getState() );
        } );

        WebRtcEndpoint webRtcEndpoint = kurento.createWebRtcEndpoint( pipeline, sdpoffer, principal.getName(), NAMESPACE );
        session.setEndpoint( webRtcEndpoint );

        playerEndpoint.connect( webRtcEndpoint );
        playerEndpoint.play();
    }
}

没有什么本质区别，只有一些技术上的细节需要处理：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>WebRTC Video Surveillance - RTSP Preview</title>
    <script src="js/stomp.js"></script>
    <script src="js/stomp-wrapper.js"></script>
    <script src="js/adapter.js"></script>
    <script src="js/kurento-utils.js"></script>
    <script src="js/webrtc-endpoint.js"></script>
    <style>
        body {
            background-color: #02686c;
        }

        .nvbar {
            font-family: sans-serif;
            height: 30px;
            display: flex;
        }

        .title {
            font-size: 18px;
            margin-left: 12px;
            font-weight: bold;
            color: rgba(255, 255, 255, .8);
            text-shadow: 2px 2px 1px rgba(0, 0, 0, .8);
            line-height: 20px;
            vertical-align: text-bottom;
        }

        .subtitle {
            font-size: 14px;
            font-weight: bold;
            font-style: italic;
            margin-left: 24px;
            color: rgba(255, 255, 255, .5);
            line-height: 20px;
            vertical-align: text-bottom;
        }

        #videos {
            display: flex;
            flex-wrap: wrap;
        }

        #videos video {
            margin: 3px;
        }

        video {
            border-radius: 5px;
            border: 6px solid rgba(0, 0, 0, .5);
        }

        video:hover {
            border: 6px solid rgba(163, 163, 163, 0.5);
            cursor: pointer;
        }
    </style>
</head>
<body onunload="dispose();">
<div class="nvbar">
    <div class="title">基于WebRTC+Kurento的视频监控示例</div>
    <div class="subtitle">http://172.21.0.1:9090/rtsp-preview.html</div>
</div>
<div id="videos"></div>

<script>
    let endpoints = [];
    let videos = document.getElementById( 'videos' );
    for ( let ch = 1; ch <= 21; ch++ ) {
        let video = document.createElement( 'video' );
        video.autoplay = true;
        video.width = 352 / 2;
        video.height = 288 / 2;
        videos.appendChild( video );
        let endpoint = new WebRTCEndpoint( WebRTCEndpoint.MODE_RECV, {
            url: 'ws://172.21.0.1:9090/signal',
            namespace: '/rtsp/preview/ch1',
            // 因为执行速度太高，之前的new Date().getTime()两次调用会重复
            login: Math.random(),
            remoteVideo: video
        } );
        endpoints.push( endpoint );

    }
    function dispose() {
        endpoints.forEach( e => e.dispose() );
    }
</script>
</body>
</html>

服务器器端，每个视频通道使用一个名字空间（STOMP目的地中缀）： 

package cc.gmem.study.kurento;

import org.kurento.client.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.messaging.handler.annotation.DestinationVariable;
import org.springframework.messaging.handler.annotation.Header;
import org.springframework.messaging.handler.annotation.MessageMapping;
import org.springframework.stereotype.Controller;

import javax.inject.Inject;
import java.security.Principal;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

@Controller
@MessageMapping( RtspPreviewController.NSP )
public class RtspPreviewController {

    private static final Logger LOGGER = LoggerFactory.getLogger( RtspPreviewController.class );

    public static final String NSP = "/rtsp/preview";

    @Inject
    private KurentoService kurento;

    private Map<String, MediaPipeline> mediaPipelines = new ConcurrentHashMap<>();

    @MessageMapping( "/{ch}/icecandidate" )
    public void onIceCandidate( @DestinationVariable String ch, IceCandidate candidate, @Header MediaSession session ) {
        WebRtcEndpoint endpoint = (WebRtcEndpoint) session.getEndpoint();
        session.addIceCandidate( candidate );
        return;
    }

    @MessageMapping( "/{ch}/stop" )
    public void onStop( @DestinationVariable String ch, @Header MediaSession session ) {
        Endpoint endpoint = session.getEndpoint();
        // 获取连接到当前端点SINK的那些连接，注意，PlayerEndpoint会创建三个连接过来，分别用于AUDIO、VEDIO、DATA
        endpoint.getSourceConnections().forEach( data -> {
            MediaElement source = data.getSource();
            MediaElement sink = data.getSink();
            source.disconnect( sink );
        } );
        endpoint.release();

    }

    @MessageMapping( "/{ch}/sdpoffer" )
    public void onSdpOffer( @DestinationVariable String ch, String sdpoffer, Principal principal, @Header MediaSession session ) {
        // 媒体管线现在不是当前会话独占了，而是每个通道一个
        PlayerEndpoint playerEndpoint = getPlayerEndpoint( ch );
        MediaPipeline pipeline = playerEndpoint.getMediaPipeline();
        session.setPipeline( pipeline );

        WebRtcEndpoint webRtcEndpoint = kurento.createWebRtcEndpoint( pipeline, sdpoffer, principal.getName(), NSP + '/' + ch );
        session.setEndpoint( webRtcEndpoint );

        playerEndpoint.connect( webRtcEndpoint );
    }

    private synchronized PlayerEndpoint getPlayerEndpoint( String ch ) {
        MediaPipeline pipeline = getMediaPipline( ch );
        if ( pipeline == null ) {
            pipeline = kurento.createMediaPipeline();
            mediaPipelines.put( ch, pipeline );
            PlayerEndpoint.Builder peb = new PlayerEndpoint.Builder( pipeline, getRtspUrlFor( ch ) );
            PlayerEndpoint playerEndpoint = peb.build();
            playerEndpoint.addMediaFlowInStateChangeListener( e -> {
                LOGGER.info( "RTSP input flow state changed, media type: {}, media state: {}", e.getMediaType(), e.getState() );
            } );
            playerEndpoint.play();
            return playerEndpoint;
        } else {
            PlayerEndpoint playerEndpoint = null;
            for ( MediaObject mo : pipeline.getChildren() ) {
                if ( mo instanceof PlayerEndpoint ) {
                    playerEndpoint = (PlayerEndpoint) mo;
                }
            }
            return playerEndpoint;
        }
    }

    private MediaPipeline getMediaPipline( String ch ) {
        return mediaPipelines.get( ch );
    }

    /**
     * 获取指定通道的RTSP URL
     *
     * @param ch 通道号
     * @return
     */
    private String getRtspUrlFor( String ch ) {
        return "返回此通道的RTSP地址";
    }
} 

即使开到21画面，客户端运行仍然非常流畅（ i7-4940MX ），完全可以满足视频监控领域的多画面需求：

前面我们已经提到过，Chrome 61默认已经开启了H264支持，其它很多浏览器也支持H264。如果KMS不进行转码，则对服务器配置要求可以大大降低。

首先，为Kurento安装插件：

apt install openh264-gst-plugins-bad-1.5

要强制KMS仅仅使用H264，可以修改KMS配置文件，注释掉VP8的支持：

"videoCodecs" : [
    {
      "name" : "H264/90000"
    }
]

注意：

1. 一定要确保你的客户端都支持基于H264的WebRTC视频传输，才可以进行上述修改
2. 进行上述修改后，如果客户端不支持H264，那么SDP应答将会不完整，缺少媒体格式说明：
   

   m=video 0 UDP/TLS/RTP/SAVPF    # 后面缺少媒体格式代码

   这会导致客户端WebRTC报错：

   Failed to parse SessionDescription. m=video 0 UDP/TLS/RTP/SAVPF Expects at least 4 fields.

通过SDP Offer/Answer可以查看浏览器和KMS协商使用H.264作为视频编码方式。

在浏览器地址栏输入

chrome://webrtc-internals

在公司的环境下测试，如果使用子码流的话，Chrome 61、Firefox都可以正常多画面播放。

但是采用主码流的情况下，运行效果实在太差：花屏、周期性卡死：

打开chrome://webrtc-internals可以看到帧经常无法解析（framesDecoded计数不增加）。具体原因还需要深入研究，但我估计可能的相关因素有：

1. 根据SDP，摄像头的H.264 Profile是420029，即Baseline；而Chrome支持的H.264 Profile是42e01f，即Constrained Baseline。也就是两者的Profile不兼容。这导致Kurento需要进行转码
2. 如果进行SDP伪造，让Kurento相信Chrome支持420029，则完全无法播放。这意味着Chrome可能的确无法解码420029
3. 转码工作依赖GST插件openh264-gst-plugins-bad-1.5完成，此插件可能存在质量问题

9月19日更新：

被摄像头给骗了……SDP声称的H.264 Profile和它实际使用的Profile并不一致。默认情况下这款摄像头使用的H.264 Profile为Main，手工配置之后则可以使用Baseline。

不过，就算改成Baseline，和Chrome/Firefox支持的Constrained Baseline仍然不兼容（注意：实际上很多编码器不使用Baseline特性针对Constrained Baseline的差集，也就是说两个Profile的编码结果很可能是兼容的）。进行SDP伪造的话，播放花屏、很快卡死。 

很多情况下，监控客户端都开启重要视频通道构成的固定多画面监控。这种情况下，可以考虑在流媒体服务器端把多画面合成GRID（例如四画面、九画面），好处是：

1. 降低客户端解码压力
2. 降低通信复杂度，不需要开启多个媒体连接甚至信号连接了

更多WebRTC术语参考webrtcglossary。

注册监听器，当流结束后，重新调用play()：

playerEndpoint.addEndOfStreamListener( e -> {
    playerEndpoint.play();
} );

The post 基于Kurento搭建WebRTC服务器 appeared first on 绿色记忆.

安防类项目中通常都有视频监控方面的需求。视频监控客户端主要是Native应用的形式，在Web端需要利用NPAPI、ActiveX之类的插件技术实现。

但是，IE式微，Chrome也放弃了NPAPI，另一方面，监控设备硬件厂商的视频输出格式则逐渐标准化。这让基于开放、标准化接口的Web视频监控成为可能。

本文讨论以HTML5及其衍生技术为基础的B/S架构实时视频监控解决方案。主要包括两方面的内容：

1. 视频编码、流媒体基础知识，以及相关的库、框架的介绍
2. 介绍可以用于视频监控的HTML5特性，例如媒体标签、MSE、WebRTC，以及相关的库、框架

本文仅仅简介若干种备选的解决方案，本站其它文章进行了更加深入的探讨：

1. H.264学习笔记
2. 实时通信协议族
3. 基于Kurento搭建WebRTC服务器
4. 基于Broadway的HTML5视频监控

音频、视频的编码（Codec，压缩）算法有很多，不同浏览器对音视频的编码算法的支持有差异。H264这样的监控设备常用的视频编码格式，主流浏览器都有某种程度的支持。

常见的音频编码算法包括： MP3, Vorbis, AAC；常见的视频编码算法包括： H.264, HEVC, VP8, VP9。

编码后的音频、视频通常被封装在一个比特流容器格式（container）中，这些格式中常见的有： MP4, FLV, WebM,  ASF, ISMA等。

视频解码工作通常由浏览器本身负责，配合video实现视频播放。

现代浏览器的JS引擎性能较好，因此出现了纯粹由JS实现的解码器JSMpeg，它能够解码视频格式MPEG1、音频格式MP2。支持通过Ajax加载静态视频文件，支持低延迟（小于50ms）的流式播放（通过WebSocket）。JSMpeg包括以下组件：

1. MPEG-TS分流器（demuxer）。muxer负责把视频、音频、字幕打包成一种容器格式，demuxer则作相反的工作
2. MPEG1视频解码器
3. MP2音频解码器
4. WebGL渲染器、Canvas2D渲染器
5. WebAudio音频输出组件

JSMpeg的优势在于兼容性好，几乎所有现代浏览器都能运行JSMpeg。

JSMpeg不能使用硬件加速。在iPhone 5S这样的设备上，JSMpeg能够处理720p@30fps视频。

比起现代解码器，MPEG1压缩率较低，因而需要更大的带宽。720p的视频大概占用250KB/s的带宽。

下面我们尝试利用ffmpeg编码本地摄像头视频，并通过JSMpeg播放。

创建一个NPM项目，安装依赖：

npm install jsmpeg --save
npm install ws --save

JSMpeg提供了一个中继器，能够把基于HTTP的MPEG-TS流转换后通过WebSocket发送给客户端。此脚本需要到Github下载。 下面的命令启动一个中继器：

node ./app/websocket-relay.js 12345 8800 8801
# Listening for incomming MPEG-TS Stream on http://127.0.0.1:8800/<secret>
# Awaiting WebSocket connections on ws://127.0.0.1:8801/
# 实际上在所有网络接口上监听，并非仅仅loopback

下面的命令捕获本地摄像头（Linux），并编码为MPEG1格式，然后发送到中继器：

# 从摄像头/dev/video0以480的分辨率捕获原始视频流
ffmpeg -s 640x480 -f video4linux2 -i /dev/video0 \
       # 输出为原始MPEG-1视频（JSMpeg可用），帧率30fps，比特率800kbps
       -f mpegts -codec:v mpeg1video -b 800k -r 30 http://127.0.0.1:8800/12345
# 在我的机器上，上述ffmpeg私有内存占用18MB

上述命令执行后，中继器控制台上打印：

Stream Connected: ::ffff:127.0.0.1:42399

客户端代码：

var player = new JSMpeg.Player( 'ws://127.0.0.1:8801/', {
    canvas: document.getElementById( 'canvas' ),
    autoplay: true
} ); 

Broadway是一个基于JavaScript的H.264解码器，其源码来自于Android的H.264解码器，利用Emscripten转译成了JavaScript，之后利用Google的Closure编译器优化，并针对WebGL进一步优化。

注意：Broadway仅仅支持Baseline这个H.264 Profile。

h264-live-player是基于Broadway实现的播放器，允许通过WebSocket来传输NAL单元（原始H.264帧），并在画布上渲染。我们运行一下它的示例应用：

git clone https://github.com/131/h264-live-player.git
cd h264-live-player
npm install

因为我的机器是Linux，所以修改h264-live-player/lib/ffmpeg.js， 把ffpmeg的参数改为：

var args = [
    "-f", "video4linux2",
    "-i",  "/dev/video0" ,
    "-framerate", this.options.fps,
    "-video_size", this.options.width + 'x' + this.options.height,
    '-pix_fmt',  'yuv420p',
    '-c:v',  'libx264',
    '-b:v', '600k',
    '-bufsize', '600k',
    '-vprofile', 'baseline',
    '-tune', 'zerolatency',
    '-f' ,'rawvideo',
    '-'
];

然后运行

node server-ffmpeg

老牌的编解码库，支持很多的音频、视频格式的编解码，支持多种容器格式，支持多种流协议。关于ffpmeg的详细介绍参见Linux命令知识集锦。

ffpmeg除了提供开发套件之外，还有一个同名的命令行工具，直接使用它就可以完成很多编解码、流转换的工作。

类似的库是libav，ffpmeg和它的功能非常相似，特性更多一些。

官网自称是最好的H.264编码器。特性包括：

1. 提供一流的性能、压缩比。特别是性能方面，可以在普通PC上并行编码4路或者更多的1080P流
2. 提供最好的视频质量，具有最高级的心理视觉优化
3. 支持多种不同应用程序所需要的特性，例如电视广播、蓝光低延迟视频应用、Web视频

有了上面介绍的HTML5标签、合理编码的视频格式，就可以实现简单的监控录像回放了。但是，要进行实时监控画面预览则没有这么简单，必须依赖流媒体技术实现。

所谓多媒体（Multimedia）是指多种内容形式 —— 文本、音频、视频、图片、动画等的组合。

所谓流媒体，就是指源源不断的由提供者产生，并持续的被终端用户接收、展示的多媒体，就像水流一样。现实世界中的媒体，有些天生就是流式的，例如电视、广播，另外一些则不是，例如书籍、CD。

流媒体技术（从传递媒体角度来看）可以作为文件下载的替代品。

流媒体技术关注的是如何传递媒体，而不是如何编码媒体，具体的实现就是各种流媒体协议。封装后的媒体比特流（容器格式）由流媒体服务器递送到流媒体客户端。流媒体协议可能对底层容器格式、编码格式有要求，也可能没有任何要求。

直播流（Live streaming）和静态文件播放的关键差异：

1. 点播的目标文件通常位于服务器上，具有一定的播放时长、文件大小。浏览器可以使用渐进式下载，一边下载一边播放
2. 直播不存在播放起点、终点。它表现为一种流的形式，源源不断的从视频采集源通过服务器，传递到客户端
3. 直播流通常是自适应的（adaptive），其码率随着客户端可用带宽的变化，可能变大、变小，以尽可能消除延迟

流媒体技术不但可以用于监控画面预览，也可以改善录像播放的用户体验，比起简单的静态文件回放，流式回放具有以下优势：

1. 延迟相对较低，播放能够尽快开始
2. 自适应流可以避免卡顿

主流的用于承载视频流的流媒体协议包括：

<video src="http://movie.m3u8" height="329" width="480"></video>

视频监控通常都是CS模式（而非P2P），在服务器端，你需要部署流媒体服务。

这是一个开源的跨平台多媒体框架。通过它你可以构建各种各样的媒体处理组件，包括流媒体组件。通过插件机制，GStreamer支持上百种编码格式，包括MPEG-1, MPEG-2, MPEG-4, H.261, H.263, H.264, RealVideo, MP3, WMV, FLV

Kurento、Flumotion是基于GStreamer构建的流媒体服务器软件。

Live555是流媒体服务开发的基础库，支持 RTP/RTCP/RTSP/SIP等协议，适合在硬件资源受限的情况下使用（例如嵌入式设备）。

基于Live555的软件包括：

1. Live555媒体服务器，完整的RTSP服务器
2. openRTSP，一个命令行程序，支持提供RTSP流、接收RTSP流、把RTSP流中的媒体录像到磁盘
3. playSIP，可以进行VoIP通话
4. liveCaster，支持组播的MP3流媒体服务

流媒体服务实现有很多，它们中的一些在最初针对特定的流协议，大部分都走向多元化。例如，Red5是一个RTMP流媒体服务器，Wowza是一个综合的流媒体服务器，支持WebRTC的流媒体服务在后面的章节介绍。

HTML5支持

<audio>

<video>

此标签用于在浏览器中创建一个纯音频播放器。播放静态文件的示例：

<audio controls preload="auto">
    <source src="song.mp3" type="audio/mpeg">
    <!-- 备选格式，如果浏览器不支持mp3 -->
    <source src="song.ogg" type="audio/ogg">
    <!-- 如果浏览器不支持audio标签，显示下面的连接 -->
    <a href="audiofile.mp3">download audio</a>
</audio>

此标签用于在浏览器中创建一个视频播放器。播放静态文件的示例：

<!-- poster指定预览图，autoplay自动播放，muted静音 -->
<video controls width="640" height="480" poster="movie.png" autoplay muted>
  <source src="movie.mp4" type="video/mp4">
  <!-- 备选格式，如果浏览器不支持mp4 -->
  <source src="movie.webm" type="video/webm">
  <!-- 可以附带字幕 -->
  <track src="subtitles_en.vtt" kind="subtitles" srclang="en" label="English">
  <!-- 如果浏览器不支持video标签，显示下面的连接 -->
  <a href="videofile.mp4">download video</a>
</video>

在画布中，你可以进行任意的图形绘制，当然可以去逐帧渲染视频内容。

音频、视频播放器标签也可以利用JavaScript编程式的创建，示例代码：

var video = document.createElement( 'video' );
if ( video.canPlayType( 'video/mp4' ) ) {
    video.setAttribute( 'src', 'movie.mp4' );
}
else if ( video.canPlayType( 'video/webm' ) ) {
    video.setAttribute( 'src', 'movie.webm' );
}
video.width = 640;
video.height = 480; 

媒体源扩展（Media Source Extensions，MSE）是一个W3C草案，桌面浏览器对MSE的支持较好。MSE扩展流video/audio元素的能力，允许你通过JavaScript来生成（例如从服务器抓取）媒体流供video/audio元素播放。使用MSE你可以：

1. 通过JavaScript来构建媒体流，不管媒体是如何捕获的
2. 处理自适应码流、广告插入、时间平移（time-shifting，回看）、视频编辑等应用场景
3. 最小化JavaScript中处理媒体解析的代码

MSE定义支持的（你生成的）媒体格式，只有符合要求的容器格式、编码格式才能被MSE处理。通常容器格式是ISO BMFF（MP4），也就是说你需要生成MP4的片断，然后Feed给MSE进行播放。

MediaSource对象作为video/audio元素的媒体来源，它可以具有多个SourceBuffer对象。应用程序把数据片段（segment）附加到SourceBuffer中，并可以根据系统性能对数据片段的质量进行适配。SourceBuffer中包含多个track buffer —— 分别对应音频、视频、文本等可播放数据。这些数据被音频、视频解码器解码，然后在屏幕上显示、在扬声器中播放：

要把MediaSource提供给video/audio播放，调用：

video.src = URL.createObjectURL(mediaSource);

wfs是一个播放原始H.264帧的HTML5播放器，它的工作方式是把H.264 NAL单元封装为 ISO BMFF（MP4）片，然后Feed给MSE处理。

flv.js是一个HTML5 Flash视频播放器，基于纯JS，不需要Flash插件的支持。此播放器将FLV流转换为ISO BMFF（MP4）片断，然后把MP4片断提供给video元素使用。

flv.js支持Chrome 43+, FireFox 42+, Edge 15.15048+以上版本的直播流 。

Streamedian是一个HTML5的RTSP播放器。实现了RTSP客户端功能，你可以利用此框架直接播放RTSP直播流。此播放器把RTP协议下的H264/AAC在转换为ISO BMFF供video元素使用。Streamedian支持Chrome 23+, FireFox 42+, Edge 13+，以及Android 5.0+。不支持iOS和IE。

在服务器端，你需要安装Streamedian提供的代理（此代理收费），此代理将RTSP转换为WebSocket。Streamedian处理视频流的流程如下：

WebRTC是一整套API，其中一部分供Web开发者使用，另外一部分属于要求浏览器厂商实现的接口规范。WebRTC解决诸如客户端流媒体发送、点对点通信、视频编码等问题。桌面浏览器对WebRTC的支持较好，WebRTC也很容易和Native应用集成。

使用MSE时，你需要自己构建视频流。使用WebRTC时则可以直接捕获客户端视频流。

使用WebRTC时，大部分情况下流量不需要依赖于服务器中转，服务器的作用主要是：

1. 在信号处理时，转发客户端的数据
2. 配合实现NAT/防火墙穿透
3. 在点对点通信失败时，作为中继器使用

主要是捕获客户端摄像头、麦克风。在视频监控领域用处不大，这里大概了解一下。流捕获通过navigator.getUserMedia调用实现： 

<script type="text/javascript">
    navigator.getUserMedia = navigator.webkitGetUserMedia || navigator.getUserMedia;
    var success = function ( stream ) {
        var video = document.getElementById( 'camrea' );
        // 把MediaStream对象转换为Blob URL，提供给video播放
        video.src = URL.createObjectURL( stream );
        video.play();
    }
    var error = function ( err ) {
        console.log( err )
    }
    // 调用成功后，得到MediaStream对象
    navigator.getUserMedia( { video: true, audio: true }, success, error );
</script>
<video id="camrea" width="640" height="480"/>

三个调用参数分别是：

1. 约束条件，你可以指定媒体类型、分辨率、帧率 
2. 成功后的回调，你可以在回调中解析出URL提供给video元素播放
3. 失败后的回调

捕获音频类似：

navigator.getUserMedia( { audio: true }, function ( stream ) {
    var audioContext = new AudioContext();

    // 从捕获的音频流创建一个媒体源管理
    var streamSource = audioContext.createMediaStreamSource( stream );

    // 把媒体源连接到目标（默认是扬声器）
    streamSource.connect( audioContext.destination );
}, error );

MediaStream对象提供以下方法：

1. getAudioTracks()，音轨列表
2. getVideoTracks()，视轨列表

每个音轨、视轨都有个label属性，对应其设备名称。

Camera.js是对getUserMedia的简单封装，简化了API并提供了跨浏览器支持：

camera.init( {
    width: 640,
    height: 480,
    fps: 30, // 帧率
    mirror: false,  // 是否显示为镜像
    targetCanvas: document.getElementById( 'webcam' ), // 默认null，如果设置了则在画布中渲染

    onFrame: function ( canvas ) {
        // 每当新的帧被捕获，调用此回调
    },

    onSuccess: function () {
        // 流成功获取后
    },

    onError: function ( error ) {
        // 如果初始化失败
    },

    onNotSupported: function () {
        // 当浏览器不支持camera.js时
    }
} );
// 暂停
camera.pause();
// 恢复
camera.start();

掠食者视觉是基于Camera实现的一个好玩的例子（移动侦测）。

在端点之间（Peer）发送流之前，需要进行通信协调、发送控制消息，即所谓信号处理（Signaling），信号处理牵涉到三类信息：

1. 会话控制信息：初始化、关闭通信，报告错误
2. 网络配置：对于其它端点来说，本机的IP和端口是什么
3. 媒体特性：本机能够处理什么音视频编码、多高的分辨率。本机发送什么样的音视频编码

WebRTC没有对信号处理规定太多，我们可以通过Ajax/WebSocket通信，以SIP、Jingle、ISUP等协议完成信号处理。点对点连接设立后，流的传输并不需要服务器介入。信号处理的示意图如下：

下面的代表片段包含了一个视频电话的信号处理过程：

// 信号处理通道，底层传输方式和协议自定义
var signalingChannel = createSignalingChannel();
var conn;

// 信号通过此回调送达本地，可能分多次送达
signalingChannel.onmessage = function ( evt ) {
    if ( !conn ) start( false );

    var signal = JSON.parse( evt.data );
    // 会话描述协议（Session Description Protocol），用于交换媒体配置信息（分辨率、编解码能力）
    if ( signal.sdp )
    // 设置Peer的RTCSessionDescription
        conn.setRemoteDescription( new RTCSessionDescription( signal.sdp ) );
    else
    // 添加Peer的Candidate信息
        conn.addIceCandidate( new RTCIceCandidate( signal.candidate ) );
};

// 调用此方法启动WebRTC，获取本地流并显示，侦听连接上的事件并处理
function start( isCaller ) {
    conn = new RTCPeerConnection( { /**/ } );

    // 把地址/端口信息发送给其它Peer。所谓Candidate就是基于ICE框架获得的本机可用地址/端口
    conn.onicecandidate = function ( evt ) {
        signalingChannel.send( JSON.stringify( { "candidate": evt.candidate } ) );
    };

    // 当远程流到达后，在remoteView元素中显示
    conn.onaddstream = function ( evt ) {
        remoteView.src = URL.createObjectURL( evt.stream );
    };

    // 获得本地流
    navigator.getUserMedia( { "audio": true, "video": true }, function ( stream ) {
        // 在remoteView元素中显示
        localView.src = URL.createObjectURL( stream );
        // 添加本地流，Peer将接收到onaddstream事件
        conn.addStream( stream );


        if ( isCaller )
        // 获得本地的RTCSessionDescription
            conn.createOffer( gotDescription );
        else
        // 针对Peer的RTCSessionDescription生成兼容的本地SDP
            conn.createAnswer( conn.remoteDescription, gotDescription );

        function gotDescription( desc ) {
            // 设置自己的RTCSessionDescription
            conn.setLocalDescription( desc );
            // 把自己的RTCSessionDescription发送给Peer
            signalingChannel.send( JSON.stringify( { "sdp": desc } ) );
        }
    } );
}

// 通信发起方调用：
start( true );

主要牵涉到的接口是RTCPeerConnection，上面的例子中已经包含了此接口的用法。WebRTC在底层做很多复杂的工作，这些工作对于JavaScript来说是透明的： 

1. 执行解码
2. 屏蔽丢包的影响
3. 点对点通信：WebRTC引入流交互式连接建立（Interactive Connectivity Establishment，ICE）框架。ICE负责建立点对点链路的建立：
   1. 首先尝试直接
   2. 不行的话尝试STUN（Session Traversal Utilities for NAT）协议。此协议通过一个简单的保活机制确保NAT端口映射在会话期间有效
   3. 仍然不行尝试TURN（Traversal Using Relays around NAT）协议。此协议依赖于部署在公网上的中继服务器。只要端点可以访问TURN服务器就可以建立连接
4. 通信安全
5. 带宽适配
6. 噪声抑制
7. 动态抖动缓冲（dynamic jitter buffering），抖动是由于网络状况的变化，缓冲用于收集、存储数据，定期发送

通过RTCDataChannel完成，允许点对点之间任意的数据交换。RTCPeerConnection连接创建后，不但可以传输音视频流，还可以打开多个信道（RTCDataChannel）进行任意数据的交换。RTCDataChanel的特点是：

1. 类似于WebSocket的API
2. 支持带优先级的多通道
3. 超低延迟，因为不需要通过服务器中转
4. 支持可靠/不可靠传输语义。支持SCTP、DTLS、UDP几种传输协议
5. 内置安全传输（DTLS）
6. 内置拥塞控制

使用RTCDataChannel可以很好的支持游戏、远程桌面、实时文本聊天、文件传输、去中心化网络等业务场景。

WebRTC adapter是一个垫片库，使用它开发WebRTC应用时，不需要考虑不同浏览器厂商的API前缀差异。

本节列出一些WebRTC的代码示例，这些例子都使用adapter.js。

// 指定分辨率
// adapter.js 支持Promise
navigator.mediaDevices.getUserMedia( { video: { width: { exact: 640 }, height: { exact: 480 } } } ).then( stream => {
    let video = document.createElement( 'video' );
    document.body.appendChild( video );
    video.srcObject = stream;
    video.play();
} ).catch( err => console.log( err ) );

// video为video元素
canvas.getContext('2d').drawImage(video, 0, 0, canvas.width, canvas.height);

我们首先尝试的方案是直接使用RTSP源，原因是海康、大华主流厂商的较新的IP摄像头均支持暴露标准化的RTSP流。

使用VLC播放器，打开网络串流：rtsp://admin:12345@192.168.0.196:554/ch1/main/av_stream，视频源为公司门口的海康摄像头的主码流（main，子码流为sub）。

发现可以正常播放，说明视频格式应该是标准的。VLC菜单 Tool ⇨ Codec Info查看，编码格式为H264。

浏览器无法直接使用RTSP协议，因此，需要有服务器端来处理视频源的RTSP，将其转换为：

1. 通过WebSocket发送的视频片断，由客户端的：
   1. JSMpeg/Broadway直接解码，渲染到画布
   2. 或者，构造MP4片断Feed给MSE播放
2. 或者，通过WebRTC网关，转换后提供给客户端的WebRTC代码处理
3. 或者，使用浏览器插件机制，例如Chrome的NaCl

Streamedian的服务器端需要授权，我们选用了另外一个实现。

H5S是一个基于live555实现的开源的HTML5 RTSP网关，支持将RTSP/H264流输入转换为HTML5 MSE支持的H264，客户端基于MSE。

尝试在容器中运行H5S：

docker create --name ubuntu-16.04 -h ubuntu-16 --network local --dns 172.21.0.1 --ip 172.21.0.6 -it docker.gmem.cc/ubuntu:16.04 bash
docker start ubuntu-16.04
docker exec -it ubuntu-16.04 bash

apt update && apt install wget
wget https://raw.githubusercontent.com/veyesys/release/master/h5stream/H5S-r1.0.1128.16-Ubuntu-16.04-64bit.tar.gz
tar xzf H5S-r1.0.1128.16-Ubuntu-16.04-64bit.tar.gz && mv H5S-r1.0.1128.16-Ubuntu-16.04-64bit h5s-1.0

cd h5s-1.0
export LD_LIBRARY_PATH=`pwd`/lib/:$LD_LIBRARY_PATH
# 指定两次密码，可能H5S存在bug，不这样报身份验证失败
./h5ss rtsp://admin:12345@192.168.0.196:554/ch1/sub/av_stream admin 12345

使用H5S自带的基于MSE的客户端代码 + Chrome 49，播放后发现画面静止。控制它查看发现解码错误。打开chrome://media-internals/，发现错误Media segment did not begin with key frame. Support for such segments will be available in a future version。看样子是提供给SourceBuffer的数据不是以关键帧开始导致，未来版本的Chrome可能取消此限制。

换成Chrome 50，可以正常播放，但是流畅度较差，播放一段时间后出现卡死的情况。

H5S实现不完善，在不修改源码的情况下，服务器端只能接入一路视频输入。客户端也存在不流畅、卡死的问题，不适合生产环境。

在上文中我们已经成功尝试了利用JSMpege + WebSocket的方式，在网页中显示摄像头捕获的视频。ffmpeg转换RTSP也是非常简单的：

ffmpeg -i rtsp://admin:12345@192.168.0.196:554/ch1/main/av_stream -s 427x240 -f mpegts -vcodec mpeg1video -b 800k -r 30 http://127.0.0.1:8800/12345

可以使用JSMpeg自带的简单Node.js服务器测试：

node ./app/websocket-relay.js 12345 8800 8801 

下面是客户端代码，默认JSMpeg会基于WebGL渲染，但是我的机器最多开到8画面，开9画面时出现警告：

Too many active WebGL contexts. Oldest context will be lost，且第一画面丢失，简单的通融方法是，第9画面使用Canvas2D渲染：

new JSMpeg.Player( 'ws://127.0.0.1:8801/', {
    canvas: document.getElementById( 'canvas9' ),
    autoplay: true,
    // 浏览器对WebGL context的数量有限制
    disableGl: true
} ); 

渲染截图：

这种方式客户端解码压力较大，同时开9画面的352x288视频，我的机器上CPU占用率大概到40%左右，画面变化较为剧烈的时候会出现卡顿现象。

与JSMpeg类似，Broadway也是JavaScript解码工具。关键之处是，Broadway支持的视频编码是H.264，意味着可能免去消耗服务器资源的视频重编码。

最初的尝试并不顺利，根据IP摄像头的RTSP Describe应答（SDP），我们推断其H.264 Profile为Baseline，但是不转码的情况下Broadway根本无法播放。后来查看ffmpeg的日志输出，发现其实际上使用的Profile是Main。进一步尝试，发现摄像头是可以配置为Baseline的：

只需要把编码复杂度设置为低，H.264的Profile就从Main变为Baseline。

设置完毕后，仍然基于h264-live-player的Demo进行测试，使用如下命令行抽取原始H.264帧：

ffmpeg -i rtsp://admin:12345@192.168.0.196:554/ch1/main/av_stream -c:v copy -f rawvideo  -

即可免转码的进行实时视频预览了。 

此实现方式更多细节信息请参考基于Broadway的HTML5视频监控。

Chrome放弃NPAPI之后，插件开发需要使用PPAPI /NaCl。目前能找到的实现有VXG Chrome Plugin，这是一个商业产品，需要授权。除了RTSP之外，还支持RTMP、HLS等协议。

插件方案的缺点是，需要安装，而且仅仅针对单种浏览器。优势则是灵活性高，理论上性能可以做的很好。

WebRTC相关的框架非常多，经过简单的比较，我们决定从Kurento入手。主要原因是：

1. 容易扩展的模块化设计
2. 提供Java客户端、JS客户端
3. 可以在服务器端合成多画面，这样可以减轻客户端解码压力，特别是那些低配置的客户端
4. 内置对RTSP协议的支持

基于Kurento搭建WebRTC服务器一文详细讨论了这种实现方式。

这里的设备，主要包括：网络硬盘录像机（NVR）、视频服务器、IP摄像头。为了便于二次开发，硬件厂商都为这些设备配置的相应的SDK套件。这些SDK通常都提供了：实时码流预览、录像文件回放、播放控制（如：暂停、单帧前进、单帧后退）、获取码流基本信息、播放截图等功能。

我们的基本目标是，通过SDK得到标准化的码流，例如H264格式。具体如何操作，得看厂商的SDK，但是思路基本是：

1. 如果SDK直接支持获取标准格式的流，例如RTSP，那么备选方案一就可以直接用上
2. 如果SDK支持获取标准编码的视频帧，例如H264，那我们只需要将其包装为合适的容器格式，再通过RTSP/HTTP的方式发送出去
3. 如果SDK支持获取解码后的原始图像数据，例如RGB、YV12，我们可以基于H264再次编码，然后按第2步方式处理。这种方式对服务器性能要求比较高，CPU压力较大，PC机处理不了多少个通道
4. 如果都不支持，只提供了封装好的播放控件 —— 这个就比较悲催了，不过通过OS底层API，例如Windows的GDI应该也是可以实现，否则那些屏幕录像软件怎么做的呢？

根据Linux版本的海康设备网络编程指南的描述，我们应该可以：

1. 调用NET_DVR_Init进行SDK初始化
2. 调用NET_DVR_Login登陆到目标设备
3. 调用NET_DVR_RealPlay进行播放，此时返回一个实时播放句柄
   1. 如果设备支持RTSP协议取流：针对上述句柄调用NET_DVR_SetStandardDataCallBack，可以设置一个标准的数据回调函数，此回调会接受到标准码流，这对应上面的第1种思路
   2. 如果设备不支持RTSP协议取流：针对上述句柄调用NET_DVR_SetRealDataCallBack，然后通过PlayM4播放库中的PlayM4_SetDecCallBack回调得到yv12格式的原始图像。这对应上面的第3种思路

cmake构建配置：

cmake_minimum_required(VERSION 3.6)
project(hikvision)

include_directories(/home/alex/CPP/lib/hcnedsdk/include)

set(SOURCE_FILES getstream.cpp)
add_executable(getstream ${SOURCE_FILES})
target_link_libraries(getstream /home/alex/CPP/lib/hcnedsdk/lib/libhcnetsdk.so)

 C++代码：

#include <HCNetSDK.h>
#include <stdio.h>
#include <cstring>
#include <unistd.h>

// RTSP协议取流
void CALLBACK cbStdData( LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, DWORD dwUser ) {
    switch ( dwDataType ) {
        case NET_DVR_SYSHEAD:        // 系统头数据，回调的第一个包是40字节的文件头
            break;
        case NET_DVR_STREAMDATA:     // 基于私有协议时：视频流数据（包括复合流和音视频分开的视频流数据）
            break;
        case NET_DVR_STD_VIDEODATA:  // 基于标准协议时：标准视频流数据（RTP包）
            break;
        case NET_DVR_STD_AUDIODATA:  // 基于标准协议时：标准音频流数据
            break;
        case NET_DVR_SDP:            // SDP信息(RTSP传输时有效)
            break;
        case NET_DVR_PRIVATE_DATA:   // 私有数据,包括智能信息叠加等
            break;
    }
}

int main() {
    // SDK初始化
    BOOL result = NET_DVR_Init();
    if ( !result ) return 1;

    // 同步登陆
    NET_DVR_USER_LOGIN_INFO struLoginInfo = { 0 };
    struLoginInfo.bUseAsynLogin = 0;
    strcpy( struLoginInfo.sDeviceAddress, "192.168.0.196" );
    struLoginInfo.wPort = 8000;
    strcpy( struLoginInfo.sUserName, "admin" );
    strcpy( struLoginInfo.sPassword, "12345" );
    NET_DVR_DEVICEINFO_V40 struDevInfo = { 0 };
    LPNET_DVR_DEVICEINFO_V30 lpDevInfo30;
    long lUserID = NET_DVR_Login_V40( &struLoginInfo, &struDevInfo );
    if ( lUserID < 0 ) {
        printf( "登陆失败，错误码 %d\n", NET_DVR_GetLastError());
        NET_DVR_Cleanup();
        return 1;
    } else {
        lpDevInfo30 = &struDevInfo.struDeviceV30;
        printf( "成功登陆到设备：%s\n", lpDevInfo30->sSerialNumber );
        printf( "SDK字符串编码方式（1 GB2312，2 GBK，3 BIG5，6 UTF-8）：%d\n", struDevInfo.byCharEncodeType );
        printf( "设备类型（31 高清网络摄像机）：%d\n", lpDevInfo30->wDevType );
        printf( "模拟通道起始号：%d，模拟通道个数%d，数字通道起始号：%d，数字通道个数%d\n", lpDevInfo30->byStartChan, lpDevInfo30->byChanNum,
                lpDevInfo30->byStartDChan, lpDevInfo30->byIPChanNum + lpDevInfo30->byHighDChanNum << 8 );
        printf( "主码流是否支持RTSP方式：%s，子码流是否支持RTSP方式：%s\n", lpDevInfo30->byMainProto > 0 ? "是" : "否",
                lpDevInfo30->bySubProto > 0 ? "是" : "否" );
    }

    // 启动预览
    NET_DVR_PREVIEWINFO struPrevInfo = { 0 };
    struPrevInfo.hPlayWnd = NULL;    // Linux 64 位系统不支持软解码功能
    struPrevInfo.lChannel = 1;       // 预览通道号
    struPrevInfo.dwStreamType = 0;   // 0-主码流， 1-子码流， 2-码流 3， 3-码流 4，以此类推
    struPrevInfo.dwLinkMode = 0;     // 0- TCP 方式， 1- UDP 方式， 2- 组播方式， 3- RTP 方式， 4-RTP/RTSP， 5-RSTP/HTTP
    struPrevInfo.bBlocked = 1;       // 0- 非阻塞取流， 1- 阻塞取流
    struPrevInfo.byProtoType = 1;    // 应用层取流协议使用RTSP
    LONG lRealHandle = NET_DVR_RealPlay_V40( lUserID, &struPrevInfo, NULL, NULL );
    if ( lRealHandle == -1 ) {
        printf( "启动预览失败，错误码 %d\n", NET_DVR_GetLastError());
        NET_DVR_Logout( lUserID );
        NET_DVR_Cleanup();
        return 1;
    }

    if ( lpDevInfo30->byMainProto ) {
        printf( "设置获取标准码流的回调\n" );
        // 仅支持对 支持RTSP协议取流的设备的 标准码流回调
        NET_DVR_SetStandardDataCallBack( lRealHandle, cbStdData, NULL );
    }

    sleep( 120 );
    // 停止预览
    NET_DVR_StopRealPlay( lRealHandle );
    // 登出
    NET_DVR_Logout( lUserID );
    // SDK清理
    NET_DVR_Cleanup();
    return 0;
}

运行脚本：

export HKLIB_HOME=/home/alex/CPP/lib/hcnedsdk/lib
export LD_LIBRARY_PATH=$HKLIB_HOME:$HKLIB_HOME/HCNetSDKCom
./getstream 

此程序运行后，会自动获取到基于RTSP协议的媒体流，回调函数会反复被调用：

1. 第一次调用为40字节的头，不太清楚有什么用
2. 第二次调用传递了SDP
3. 后续调用传递标准音视频数据，其内容是RTP封包

基于HTM5的视频监控，媒体流从采集设备到浏览器，主要路径如下图所示：

对上图的说明如下：

1. 在设备层，需要以某种方式获得码流，以流协议的方式发送出去。最常用的方式是RTSP/RTP。流的可能获取路径为：
   1. 设备直接暴露RTSP协议端点，并且发送标准码流
   2. 设备SDK允许获取标准码流，需要自己以RTSP协议发送
   3. 设备SDK允许获得解码后的逐帧，需要直接编码为H264，然后以RTSP发送
2. 流媒体层通常需要引入专门的流媒体服务器，这类服务器能够在内部进行各种流协议的转换，可以解除客户端对特定流协议的依赖
3. 客户端和服务器端的传输方式，可以有TCP、HTTP、P2P（WebRTC）、WebSocket等多种。其中
   1. 直接的TCP协议浏览器是不支持的，这意味着RTSP/RTMP等协议，在浏览器端必须要有插件才可以使用
   2. WebSocket通常配合JSMpeg或者MSE使用，由程序向JSMpeg/MSE不断Feed视频帧
4. 客户端解码展示的技术主要有三类：
   1. 浏览器内置的解码能力，主要通过video标签，MSE属于此类
   2. JavaScript软解码，主要是JSMpeg、Broadway
   3. 插件机制，例如Chrome的NaCl

能够免于引入流媒体层的方案，需要：设备能直接暴露标准码流的RTSP端点，并且安装浏览器插件。缺点也很明显，一个是设备的访问密码暴露给了客户端，第二个是目前没有成熟、开源的插件可用。我相信主要原因是合理技术方向不在于此，没人愿意去开发。

直接使用设备层的RTSP端点，可能存在兼容性问题。一个是它发送的码流是否标准化，第二个是市场上有多少设备没有暴露RTSP端点。

客户端方面，JSMpeg是兼容性较好的方案，WebRTC/MSE都有部分平台不支持（但是桌面级的浏览器大部分支持）。JSMpeg的缺点是：

1. 如果基于WebGL渲染，受限于浏览器WebGL上下文最大数量，多画面可能无法渲染。某些流媒体服务器支持在服务器端合成多画面Grid，可以规避此缺点
2. 如果基于Canvas2D渲染，画质较差（我的机器上还有莫名其妙的斜线）
3. 对码流格式要求严格，仅仅支持MPEG-TS，此格式压缩比差，网络带宽占用大
4. 性能相对较差，尽管使用了MPEG-TS这种简单的视频格式，基于JavaScript解码渲染仍然使客户端压力较大。我的机器（i7-4940MX / Quadro K5100M / Ubuntu 14.04 LTS）上会出现卡顿情况

和JSMpeg类似的库是Broadway，后者能够进行Baseline的H.264解码。如果设备支持Baseline H.264输出，使用Broadway可以很好的解决服务器端转码导致的资源消耗问题。

1. Audio and Video Delivery
2. W3C Recommendation - Media Source Extensions™
3. WebRTC Project Home
4. HTML5 视频直播（三）

The post HTML5视频监控技术预研 appeared first on 绿色记忆.

N打开面板，在Display控件中，把Lines设置为0

左键按住其源面板由上角的grabber（小三角），稍微拖动一下即可。

按O键启用。其效果是：以选中的元素为基准，按照特定的衰减函数，对物体进行整体变换。离选中元素越近的元素，受变换的影响越大。选择的轴心点也会影响到变换的效果

操作步骤：

1. 以边选择模式，选中一个边，按Ctrl B执行倒角
2. 移动鼠标，可以修改倒角面的大小
3. 滚动滚轮，可以对倒角面进行细分，产生圆角效果
4. 按F6，可以设置属性，Profile用于控制形成凸面还是凹面（曲率）

注意：F6的设置会被记住，下一次倒角其参数被自动使用

即Tools面板中Transform字段集中的Shrink/Fatten功能，快捷键Alt S。所谓法向缩放，就是让各面分别沿着其法线的方向进行放大或者缩小，在设计建筑时可以用到。操作步骤：

1. Alt 右键，选取需要缩放的循环面
2. 按E挤出，立即回车，不进行实质上的挤出操作
3. Alt S激活法向缩放，在缩放期间，可以按S启用Even Thickness

效果图如下：

顶部的凸台就是利用法线缩放生成的。 

选中多个面并进行挤出时，可以按Alt E调出选项：

1. Region，默认的挤出方式，所有面统一方向
2. Individual faces，各面沿着自己的法线方向挤出

注意：E键挤出后，用右键取消，实际上相当于0距离挤出，也就是新的面已经存在。要取消，应该通过Ctrl Z。

即Tools面板Add字段集中的Spin按钮，快捷键Alt R。一般在编辑模式的正交视图下、侧面进行操作。可以让目标Mesh以3D游标为中心，旋转一定的角度。下图是平面绕旋转100度的效果示意：

即Tools面板Add字段集中的刀片（切割）、Select（选择）按钮，快捷键分别为K、Shift K。

刀片工具，用于在Mesh表面切分出更多的面出来，操作完毕后，按Enter确认。

选择工具，要求首先选择一系列的面，然后Shift K绘制一个路径（直线），Enter确认。路径经过的地方，会被切分出新的面。

即Tools面板Add字段中的切割（Bisect）按钮，可以用一个平面来割掉Mesh的一部分。操作步骤：

1. 进入编辑模式，按A全选目标Mesh
2. 点击Bisect按钮，单击一点作为平面起点，然后拖拽，到终点处再次单击，定义一个切割平面
3. 按F6，Fill表示是否对截面进行填充，Clear Inner/Outer指示切除平面内侧还是外侧的哪一部分

可以在编辑模式下，根据两个几何图像的并、交、差集，确定Mesh的最终形态。例如，用立方体对球体进行打洞的例子：

1. 创建一个UV球，进入编辑模式，取消选择
2. 创建一个Cube，缩放，使其穿过球体。此时Cube处于选中状态
3. 按Ctrl F，选择Intersect（Boolean），按F6
   1. Boolean取值Difference，表示保留未选中元素中、不属于选中元素的部分，即打洞
   2. Boolean取值Intersect，表示保留两者共同的部分
   3. Boolean取值Union，表示保留两者的并集

可以连接多个游离平面的循环边，创建多个面。操作步骤：

1. 在编辑模式下，为一个Mesh创建多个游离的平面
2. 选中所有平面，按快捷键W，选择Bridge Edge Loops，按F6
   1. Connect Loops，可以选择开放/闭合最后一个、第一个面
   2. Number of Cuts，对创建的新面进行细分

注意游离平面的顺序、旋转角度很重要。桥接也可以用于其它二维几何图形。

LoopTools的Bridge也可以实现类似的功能。

选中若干面，按Ctrl F，选择Solidify，然后F6，可以增加厚度（立体化）。

编辑模式，点击启用吸附，右侧Snap Element选择顶点。在你移动顶点时，会自动吸附到临近的顶点，合而为一。

1. 添加Curve ⇨ Path，进入编辑模式。选中一个点，按E可以凸起
2. 右侧曲线面板，设置Active Spline的Order为2可以绘制直角管道
3. 右侧曲线面板，设置Shape为3D，Fill为Full。Bevel的Depth、Resolution可以用来绘制圆管
4. 完毕后，Alt + C转换为Mesh

使用此插件，可以方便制作拓扑曲面。

操作步骤：

1. 作为参考的物体，可以在右侧大纲中，点击，禁止在Viewport中选中
2. 添加一个Mesh，例如平面，进入编辑模式，删除其所有顶点。即将制作的曲面将以此Mesh为容器
3. 左侧选择GP面板（Grease Pencil），Data Source选择Object，Stroke Placement选择Surface。表示手绘线体置于参考物体表面
4. 按住D，在参考物体表面绘制线条，切换视角你会注意到，线条沿着物体表面延伸
5. 左侧选择Tools面板，找到Bsurfaces一段，点击Add Surface，F6修改参数
6. 工具栏点击，其后的下拉框选择，点选。这些设置表示转换（移动/缩放/旋转）时吸附到参考物体表面
7. A全选所有元素，按一下G，不做任何变动，G仅仅是触发一下转换

类似的，你可以在执行上节第6步的情况下，转换细分过的平面，让它吸附到参考物体的表面。

该插件需要启用，在编辑模式下，按W键可以看到LoopTools的菜单项

可以连接两对游离的循环边，生成新的面。功能类似于Bridge Edge Loops。

可以让选中的面几何的外边缘圆化。

选取几个采样点，基于这些点曲线化一系列相邻的边。 示例：

图中上半部分，呈现为桔黄色的三个点，被选中作为采样点。然后按W键选择Loop Tools ⇨ Curve，即可得到下半部分的效果。

具有平缓曲线的效果，以上图下半部分为例，选中曲线上的所有点，然后W键选择Loop Tools  ⇨ Relax，Shift R重复，即可逐步的让曲线平缓。

吸附倒GP线：使用蜡笔绘制一条曲线，然后选中曲线上所有点，自动连接曲线点、蜡笔Mesh化后的点，形成多个面。

放样，可以把两个或者是多个二维曲线符合成三维物体。比如下面这个效果是利用3个在Z方向圆心重合的Circle进行Loft得到的：

等距：可以让一条曲线上的点分布的更加均匀。

简单操作步骤：

1. 进入编辑模式
2.  按U键，打开UV映射菜单
   1. Unwrap，直接展开，基于缝合边设定进行展开
   2. Smart UV project，智能UV映射
3. 选择智能UV映射，F6打开属性菜单
   1. Island Margin，孤岛边距，可以设置各个展开面的边距。避免“贴图出血”

1. 切换到边选择模式
2. 选定缝合边，所谓缝合边，是指从它们裁剪开物体的边
3. Ctrl + E，标记缝合边（Mark Seam）
4. A全选，U选择Unwrap

盒子十字展开技巧：侧面四个边、顶面3个边作为缝合边。

圆柱展开技巧：上下底，外加任意一条竖边作为缝合边。通常选择正交视图的前/侧视图的正前方的那个边

点击按钮，则编辑模式下，选区和UV保持同步

在面选择模式下，Ctrl + L可以选择同一UV孤岛中的所有面。做复杂UV展开时可以Shift + H 隐藏未选择部分 。

The post Blender知识集锦 appeared first on 绿色记忆.

/*
 * SDKDirectPlayBack.cpp
 *
 *  Created on: May 14, 2014
 *      Author: WangZhen
 */
#include <stdio.h>
#include <windows.h>
#include "HCNetSDK.h"
#include <time.h>

class RealPlayInfo
{
    public:
        LONG lUserID;
        LONG lRealPlayHandle;
        RealPlayInfo() :
                lUserID( -1 ), lRealPlayHandle( -1 )
        {
        }
        ;
        bool isSucceed()
        {
            return this->lUserID >= 0;
        }
};
void CALLBACK g_ExceptionCallBack( DWORD dwType, LONG lUserID, LONG lHandle, void* pUser )
{
    switch ( dwType )
    {
        case EXCEPTION_RECONNECT :
            printf( "Reconnecting...%d\n", time( NULL ) );
            break;
        default :
            break;
    }
}

RealPlayInfo* StartRealPlay( HWND hWnd, char* ip, int port = 8000, int chnl = 1, char* user = "admin", char* pswd = "12345" )
{
    RealPlayInfo* info = new RealPlayInfo;
    NET_DVR_DEVICEINFO_V30 struDeviceInfo;
    info->lUserID = NET_DVR_Login_V30( ip, 8000, user, pswd, &struDeviceInfo ); //登录
    if ( info->lUserID < 0 )
    {
        printf( "Failed to logged on to %s, Error Code: %d\n", ip, NET_DVR_GetLastError() );
        return info;
    }
    else
    {
        printf( "Logon successful.\n" );
    }
    NET_DVR_SetExceptionCallBack_V30( 0, NULL, g_ExceptionCallBack, NULL );
    //启动预览并设置回调数据流
    NET_DVR_PREVIEWINFO struPlayInfo = { 0 };
    //使用SDK直接解码
    struPlayInfo.hPlayWnd = hWnd;
    //预览通道号
    struPlayInfo.lChannel = chnl;
    //0主码流，1子码流
    struPlayInfo.dwStreamType = 0;
    //0 TCP，1 UDP，2 多播，3 RTP，4 RTP/RTSP，5 RSTP/HTTP
    struPlayInfo.dwLinkMode = 0;
    //0- 非阻塞取流，1- 阻塞取流
    struPlayInfo.bBlocked = 1;
    info->lRealPlayHandle = NET_DVR_RealPlay_V40( info->lUserID, &struPlayInfo, NULL, NULL );
    if ( info->lRealPlayHandle < 0 )
    {
        printf( "Failed to start RealPlay.\n" );
        NET_DVR_Logout( info->lUserID );
        return info;
    }
    else
    {
        printf( "RealPlay started successfully.\n" );
    }
    return info;
}
void StopRealPlay( RealPlayInfo* info )
{
    if ( !info->isSucceed() ) return;
    printf( "Stopping RealPlay.\n" );
    //停止预览
    NET_DVR_StopRealPlay( info->lRealPlayHandle );
    //注销用户
    NET_DVR_Logout( info->lUserID );
}

LRESULT CALLBACK WndProc( HWND, UINT, WPARAM, LPARAM ); //窗口过程声明

int main()
{
    HINSTANCE hInstance = GetModuleHandle( NULL );
    static TCHAR szAppName[] = TEXT( "HikSDKDirectPlayBack" );
    HWND hWnd;
    MSG msg;
    WNDCLASS wndclass;
    wndclass.style = CS_HREDRAW | CS_VREDRAW;
    wndclass.lpfnWndProc = WndProc;
    wndclass.cbClsExtra = 0;
    wndclass.cbWndExtra = 0;
    wndclass.hInstance = hInstance;
    wndclass.hIcon = LoadIcon( NULL, IDI_APPLICATION );
    wndclass.hCursor = LoadCursor( NULL, IDC_ARROW );
    wndclass.hbrBackground = ( HBRUSH ) GetStockObject( BLACK_BRUSH );
    wndclass.lpszMenuName = NULL;
    wndclass.lpszClassName = szAppName;
    RegisterClass( &wndclass );
    int w = 640;
    int h = 480;
    hWnd = CreateWindow(
            szAppName,
            TEXT("MinGW海康SDK直播实例"),
            WS_OVERLAPPEDWINDOW,
            (GetSystemMetrics(SM_CXSCREEN) - w)/2,
            (GetSystemMetrics(SM_CYSCREEN) - h)/2,
            w,
            h,
            NULL,
            NULL,
            hInstance,
            NULL
    );
    printf( "Main window created.\n" );
    printf( "Prepare to render main window.\n" );
    ShowWindow( hWnd, 10 );
    UpdateWindow( hWnd );
    while ( GetMessage( &msg, NULL, 0, 0 ) )
    {
        TranslateMessage( &msg );
        DispatchMessage( &msg );
    }
    return msg.wParam;
}
//窗口过程定义
LRESULT CALLBACK WndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM IParam )
{
    HDC hdc;
    PAINTSTRUCT ps;
    RECT rect;
    static RealPlayInfo* info;
    switch ( message )
    {
        case WM_CREATE :
            NET_DVR_Init();
            NET_DVR_SetConnectTime( 2000, 1 );
            NET_DVR_SetReconnect( 10000, true );
            info = StartRealPlay( hwnd, "192.168.0.196" );
            return 0;
        case WM_DESTROY :
            PostQuitMessage( 0 );
            StopRealPlay( info );
            NET_DVR_Cleanup();
            return 0;
    }
    return DefWindowProc( hwnd, message, wParam, IParam );
}

The post 基于MinGW的海康视频监控开发 appeared first on 绿色记忆.

原理：使用滤色混合模式，可以使底层图像变亮，让人的皮肤看起来更白

步骤：

1. 使用套索勾画出皮肤轮廓的选区，羽化10像素左右
2. CTRL+J将选取复制到新图层
3. 设置新图层的混合模式为滤色，不透明度为45%
4. 为新图层添加图层蒙板
5. 点击图层蒙板，前景色设置为白色，然后使用不透明度50%的橡皮擦修改边缘

The post 人像处理技巧 appeared first on 绿色记忆.

也叫做色彩模型、色彩系统，基于色素的基本颜色（例如发光的三原色RGB）进行组合（例如相加）能够得到的所有颜色的集合，定义了一个颜色空间。

颜色空间也被指代用于简化对其的描述的抽象数学模型，这些模型把色彩定义为元组（通常包括3或者4元素），你可以把每个颜色看做N维（元组元素个数）空间中的一个点。

色彩空间帮助理解设备的色彩处理能力，例如摄像头能看到什么颜色、显示器能渲染什么颜色、打印机能打印什么颜色。

常用色彩空间：

The post 图像处理知识集锦 appeared first on 绿色记忆.

The post Photoshop知识集锦 appeared first on 绿色记忆.