对图像的水平线条和竖直线条敏感，对斜线相对不敏感。对整体结构敏感，对内部细节相对不敏感。因此，包含在色度信号、运动图像、图像高频信号中的一些数据，相对于人眼而言，并不能对增加图像的清晰度作出贡献，被人眼视为多余的，这就是视觉冗余。也就是说视觉冗余就是排除掉人类视觉不敏感的地方，达到压缩的目的。推流推流协议的话其实就两个，基于tcp的rtmp和udp的webRTC和私有协议rtmp是adobe的私有协议，已经不再维护，推流需要封装成flv。
原理
基本步骤为：采集–压缩编码–封装–推流–分发–流媒体协议观看
采集
我们知道计算机都是只认识二进制的，所以对于视频采集，其实就是把实际看到的东西转为二进制的格式，采集就是转为二进制流的过程。
这部分其实实际测试中关注的是比较少的，因为客户端针对的都是采集好的原始视频或音频流做处理，这里要知道采集成的格式视频是YUV，音频是PCM。
YUV来说，其中“Y”表示明亮度（Luminance或Luma），也就是灰阶值；而“U”和“V” 表示的则是色度（Chrominance或Chroma），作用是描述影像色彩及饱和度，用于指定像素的颜色。
处理
处理的过程主要是美颜和滤镜了，重点说说美颜，美颜有两步，一个是磨皮，一个是美白，要想正确美颜，所以还需要加上人脸识别技术和皮肤识别技术。
这里要说说题外话，美颜在压缩编码前处理可以说是最自然的，缺点也有，不能修改。所以也有一种是通过播放器渲染”美颜”。效果嘛，呵呵。可惜的是我们项目美颜滤镜就是这样做的，个人还是不敢苟同的，这样做缺点非常明显，画质不忍直视，还要十分拖累帧数，优点嘛，修改和实现非常简单，成本也低
在针对原始流的处理，除了滤镜美颜外，还可以自定义打logo，修改画面内容。
压缩编码
首先，要知道的是，一个视频是由一个个画面组成的，多个画面连续运动便构成了动画，也就是视频，一个个画面我们称为帧(笔者想起小时候玩的小玩具，一个小本本，里面有很多相似的图画，然后像翻书那样快速翻过，形成了动画)。
原始视频流是很大的，需要压缩，那么最简单的办法就是”推测”，根据前一帧推测后一帧后者几帧，那么就不用存储这么多数据了。
所以压缩编码就是把采集到的数据分成有关联的一帧帧，那么N个帧合在一起就是一个组，我们叫GOP(group of picture)。这个组里面的帧，我们划分成I/B/P帧，我们把I帧叫做关键帧，B/P帧叫做参考帧，其中B叫双向参考帧，P叫向前参考帧，没有I帧B/P帧也没法播放，因为B/P帧是参考I帧的变化而成的。
压缩编码到底怎么压缩的？
压缩编码的作用是去掉冗余信息，主要有以下几个方向，当然冗余不止这几个哈：
空间冗余
时间冗余
视觉冗余
编码冗余
空间冗余：
比如下面这幅笔者正在用的壁纸，可以发现有的颜色区域非常类似甚至一样，这样这些重复的区域就是空间冗余了，空间冗余是属于帧内压缩的，是指在一个图像内的压缩。
时间冗余：
根据时间关系产生的冗余，根据前一帧和变化量可以推测出后一帧的冗余，比如下面的图(网上搜的一幅图)，动作是比较规律的，不同的只是变化(可以想成开发中动画的定义，先定义一个图像，然后调用api让它旋转、放大、移动和透明)，那么这就是时间冗余。
视觉冗余：
这个百度百科挺详细的，我摘取一段下来：
在多媒体技术的应用领域中，人的眼睛是图像信息的接收端。视觉冗余是相对于人眼的视觉特性而言的，人类的视觉系统并不能对图像画面的任何变化都能感觉到，通常情况下具有以下特点：
对亮度的变化敏感，对色度的变化相对不敏感。
对静止图像敏感，对运动图像相对不敏感。
对图像的水平线条和竖直线条敏感，对斜线相对不敏感。
对整体结构敏感，对内部细节相对不敏感。
对低频信号敏感，对高频信号相对不敏感（如：对边沿或者突变附近的细节不敏感）。
……
因此，包含在色度信号、运动图像、图像高频信号中的一些数据，相对于人眼而言，并不能对增加图像的清晰度作出贡献，被人眼视为多余的，这就是视觉冗余。
也就是说视觉冗余就是排除掉人类视觉不敏感的地方，达到压缩的目的。
但是，你不排除有的人就是对这些细节很在意啊，比如每次测试不出来的东西，一发到外网，总有人反馈，一看，颜色不对啦，多了一根线啦，真是折磨人呢！
编码冗余：
因为不同编码方式或者不同的图片压缩后产生的二进制长度是不一致的，指在编码过程中每个像素使用的比特位大于实际的信息熵(其实就是计划和实际不匹配产生的余量咯)，那么就产生了冗余，这和图像和编码方式有区别的，编码冗余也叫信息熵冗余。
关系？
还是有关系的，GOP分组，I帧是关键帧，是空间冗余，B/P帧是参考帧，是时间冗余，然后继续编码，去除视觉冗余和编码冗余等，最后这一过程就完成了。
常用编码格式
这里需要对比一下常用的编码标准了，深入的原理不会涉及(不是算法层了，接触太多反而没必要)，但是你要知道优缺点呢！
那么综上，目前项目的编码格式定位最主流的h.264 + aac的编码方案，主要是为了：
移动端要考虑兼容性，硬解一般都支持h.264
要考虑性能，h.265资源消耗比较大，而且为了体验良好需要快速编码并保存资源
封装
然后到封装了，封装其实就是打包啊，压缩编码后h.264和aac，要怎么结合在一起呢，就是封装呀，举个例子，一个酱油瓶，里面装的酱油，酱油就是压缩编码后的成品，装到瓶子里就是封装，然后打上”cloudhuan牌酱油”，就是打上meatadata信息。封装除了是包装外，还可以打上时间戳，避免音画不同步呢。
推流
推流协议的话其实就两个，基于tcp的rtmp和udp的webRTC和私有协议
rtmp是adobe的私有协议，已经不再维护，推流需要封装成flv。
优点：主流，cdn都支持，用的最多，实现简单，创业公司用这个成本最低
缺点：基于tcp的，tcp有超时重传的机制，意味着弱网下，稳定性可能会出问题
webRTC视频会议用得比较多，google出品(对，又是google，一个伟大的公司)
优点：开源的，基于udp意味着直播的时候可以对弱网指定一些丢包策略。
缺点：cdn支持不良
基于udp的私有协议，大公司一般会自己实现了，缺点同样是cdn支持不好，然后要有一定技术才能去开发。
接收流媒体
流媒体协议用的最多了就三个，一般都是支持的：
rtmp和http-flv：
都是flv的格式，延迟都是2~4s，实时性都差不多，却别在于http是存储flv在客户端的，而rtmp是存储在服务器端的，都不支持web播放
hls：
唯一一个支持h5播放的流媒体协议，延迟4~10s，格式是ts + m3u8，观看的时候先把一组.ts视频下载，然后通过m3u8的索引去观看，因为要先下载一段(N个ts文件+一个m3u8文件)，所以延迟和段数有关，实时性不会太好。
总结
最后复习一下
原理流程：
采集–>处理–>压缩编码–>封装–>推流–>分发–>流媒体观看
h264和h265比较、rtmp、http-flv、hls的异同点、帧内压缩和帧间压缩以及GOP的概念
