原则
基本步骤是:采集-压缩编码-封装-流式传输-分发-流媒体协议观看。
收集
我们知道计算机只知道二进制，所以视频采集其实就是把我们实际看到的东西转换成二进制格式的过程，采集就是转换成二进制流的过程。
实际上，这部分实际测试对它的关注较少，因为客户端处理的是所有收集到的原始视频或音频流。这里要知道采集的格式视频是YUV，音频是PCM。
YUV，其中“Y”代表亮度(明度或亮度)，即灰度值；而“U”和“V”代表色度(chro***或chro***)，用来描述图像的颜色和饱和度，并指定像素的颜色。
处理
治疗过程主要是美颜和滤镜，以美颜为主。美容有两步，一是去死皮，二是美白。想要拥有正确的美颜，需要加上人脸识别技术和皮肤识别技术。
这里说一下题外话。可以说压缩编码前的美颜处理是最自然的，也有不足之处，无法修改。所以也有通过播放器渲染“美”的方法。嗯，效果，呵呵。不幸的是，这就是我们的项目美容过滤器所做的。我个人还是不能认同。这种方法的缺点很明显。画质不忍直视，也拖累了帧数。优点是修改和实现非常简单，成本低。
对于原流的处理，除了滤镜的美观，还可以自定义logo，修改屏幕内容。
压缩编码
首先要知道，一个视频是由画面组成的，若干个画面不断移动形成一个动画，也就是一个视频，每一个画面称为一帧(我想起小时候玩的一个小玩具，一个小笔记本，里面有很多相似的画面，然后像翻书一样快速的翻过来，形成一个动画)。
原始视频流很大，需要压缩，所以最简单的办法就是“猜”。如果根据前一帧猜测下一帧和后面几帧，就不用存储那么多数据了。
所以压缩编码就是把采集的数据分成相关的帧，然后N帧一起为一组，称为GOP(图片组)。该组中的帧被分成I/B/P帧。我们把I帧称为关键帧，B/P帧称为参考帧，其中B称为双向参考帧，P称为前向参考帧。B/P帧没有I帧是不能播放的，因为B/P帧是基于I帧的变化。
编码是如何压缩的？
压缩的作用是去除冗余信息，主要有以下几个方向。当然，冗余还不止这些:
空冗余
时间冗余
视觉冗余
编码冗余
空冗余:
比如下面作者正在使用的壁纸，可以发现有些颜***域非常相似甚至相同，以至于这些重复的区域在空之间是冗余的，而空之间的冗余属于帧内压缩，是指一幅图像内的压缩。
时间冗余:
根据时间关系产生的冗余，可以根据前一帧和变化量推断出下一帧的冗余。比如下图(网上搜的一个图)显示动作是有规律的，唯一的区别就是变化(可以想到开发中动画的定义，先定义一个图像，然后调用api使其旋转、放大、移动、透明)。那么这就是时间冗余。
视觉冗余:
这个百度百科还挺详细的。我摘录一段:
在多媒体技术的应用领域，人眼是图像信息的接收者。视觉冗余是相对于人眼的视觉特性而言的。人类的视觉系统感觉不到图像的任何变化，通常它具有以下特征:
对亮度变化敏感，对色度变化相对不敏感。
对静止图像敏感，对运动图像相对不敏感。
对图像的水平线和垂直线敏感，对斜线相对不敏感。
对整体结构敏感，对内部细节相对不敏感。
对低频信号敏感，对高频信号相对不敏感(例如，对边缘附近的细节或突变不敏感)。
……
因此，图像的色度信号、运动图像、高频信号中包含的一些数据，相对于人眼来说，对图像的清晰度没有贡献，被人眼视为冗余，这就是视觉冗余。
也就是说，视觉冗余是为了消除人类视觉的不敏感，达到压缩的目的。
但是，不排除有些人非常在意这些细节。比如，一个不能每次都测试的东西一旦发到外网，总会有反馈。乍一看，颜色不对，多了一根线。真的是折磨！
编码冗余:
因为不同编码方式或不同图片压缩后产生的二进制长度不一致，意味着编码过程中每个像素使用的比特数大于实际信息熵(实际上是计划与实际不匹配造成的余量)，那么就出现了冗余，这与图像和编码方式不同。编码冗余也叫信息熵冗余。
关系？
这仍然很重要。GOP分组，I帧是关键帧，在空之间冗余，B/P帧是参考帧，是时间冗余。然后，继续编码以去除视觉冗余和编码冗余。最后这个过程就完成了。
通用编码格式
这里需要对比一下常用的编码标准。深入的原理就不涉及了(不是算法层，太多接触是没必要的)，但是你要知道利弊！
综上所述，目前项目的编码格式是最主流的h.2***+aac编码方案，主要为:
移动端要考虑兼容性，硬件解码一般支持h.2***
考虑到性能，h.265消耗大量资源，为了有好的体验，需要快速编码，节省资源。
密封和包装
然后是包装。包装其实就是包装。h.2***和aac压缩编码后如何结合？是包装。比如一个酱油瓶，里面装的是酱油，压缩打码后就是成品。放在瓶子里就是包装，然后标上“云欢牌酱油”，也就是标注meatadata信息。除了打包，打包还可以打上时间戳，避免声音和画面不同步。
推流
实际上有两种推送协议，基于tcp的rtmp，基于udp的webRTC和私有协议。
Rtmp是adobe的专有协议，不再维护，push stream需要封装成flv。
优点:支持主流和cdn，使用最多，实现简单。创业公司用这个是成本最低的。
缺点:基于tcp，tcp有超时重传的机制，也就是说在弱网络下，稳定性可能会有问题。
WebRTC视频会议被谷歌(没错，又是谷歌，一家伟大的公司)广泛使用和制作。
优点:开源，基于udp意味着直播时可以针对弱网指定一些丢包策略。
缺点:cdn支持差
基于udp的私有协议一般都是大公司自己实现的。缺点是cdn支持不好，然后需要一定的技术来开发它们。
接收流媒体
一般最多支持三种流媒体协议:
Rtmp和http-flv:
都是flv格式，延迟2~4s，实时性差不多，但不同的是http在客户端存储flv，rtmp在服务器端存储，所以不支持网页播放。
hls:
唯一支持h5播放的流媒体协议，延迟4~10s，格式为ts+m3u8。看的时候，下载一组。先ts视频，再通过m3u8的索引观看。因为要先下载一段(N个ts文件+一个m3u8文件)，所以延迟跟段数有关，实时性能不会很好。
摘要
最后一次回顾。
原理流程:
采集–>:处理–>:压缩–>:封装–>:推流–>:分发–>流媒体观看
h2***和h265的比较，rtmp，http-flv和hls的异同，帧内压缩和帧间压缩，GOP的概念。
本文来自暮以随然投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/498004.html
微信扫一扫 
