音视频知识总结

一、常见的流媒体文件.mp4 .mkv .avi .flv都是音视频封装格式，这些封装格式由视频流、音频流、参数信息组成。

二、原始音频数据是PCM数据，音频原始数据在计算机中的计算方式为采样率*位深*声道数，采样率单位赫兹(HZ)，指每秒钟对声音的采集次数，位深表示单个采样声音的精度或者声音强度范围，当位深作为一个值存在的时候所表示的是精度，而作为位深这个概念本身存在的时候表示的是声音的强度范围，比如16bit位深是16个二进制位能表示65535个不同强度的声音信息，就像标尺上有65535个刻度，如果提升到20bit，意味着刻度数增加。刻度数增加意味着可以使原有的刻度更精确，或者让刻度的范围变的更广。声道数这个概念本质就是多份声音采集，如果录音时声道数为2，那么录制时就有采集两份音频数据，由此得出PCM原始音频数据占用的内存大小。

音频压缩分有损压缩和无损压缩，无论哪种压缩方式，最终大小肯定比PCM数据小，无损有AAL、APE、FLAC等，有损压缩有mp3、aac、ogg等。

其中mp3压缩在高码率128kbps以上的音频中还原度更好，码率是指一秒钟声音的大小是多少位二进制，由于位深和声道基本都是固定的，相当于常量，由此得出，码率越高也意味着采样率越高，码率越低意味着采样率越低，mp3的适合场景是普通音乐文件。

aac压缩在低码率下表现较好，在视频文件中大多采用这种格式，视频的音频流对声音的要求没有比纯音乐那么高。

ogg在各种范围的码率下表现都非常好，缺点就是普及度不够，兼容性不行，常用语音视频通话中。

三、原始视频数据格式为YUV格式，也称YCrCb，Y是亮度分量，U和V是色度分量，Cr表示红色分量与亮度分量的差异，Cb表示蓝色分量与亮度分量的差异，对计算机中对视频数据的算法处理大多都是基于YUV的，诸如H264、H265都是在处理YUV数据，如果要在显示器中显示，必须要转换为RGB数据，因为显示器只认RGB，显示器中一个像素有三个发光点，分别表示红、绿、蓝三种颜色，所有颜色都由这三种颜色组成。从YUV数据转RGB不是固定的算法，而是有多套标准，这也是为什么opengl在将YUV数据渲染到屏幕中需要一个矩阵信息，这个矩阵就是这套标准。YUV有很多名称，如YUV420\YUV420P\YUV444\YUV422\I420\NV21\NV12，无论怎么变化，这些名称都只表示两个维度上YUV数据在计算机中的区别，其中一个维度是YUV三个分量的比例信息，420、21、12字眼的代表4个Y分量共用一个UV分量，422代表两个 Y分量共用一个UV分量，444就表示一个Y使用一个U、一个V，有点类似RGB，但是YUV和RGB不是一个概念，但是他们都是表达的单个像素信息，另一个维度是YUV数据在计算机中的排列方式，其中后面不代P的，在计算机中YUV数值交错存储，带P或者NV开头的表示的是水平存储，意味着计算机中Y先存储，后面放U和V,NV21和NV12的区别就是U在前还是V在前。不管怎么样，他们的区别就是在计算机中的个数比例和数值排列顺序的差异。

大多数视频都是采用420格式数据，也就是YUV比例4:1:1，也就是1个字节的Y+四分之1个字节的U和四分之1字节的V，也就是1.5个字节就表示了一个像素，而对应的RGB数据需要3个字节表示，所以RBG大小是YUV420数据的两倍，相当于YUV舍弃了人眼不敏感的色度信息来"压缩"了像素数据，对于这种"压缩"，因为人眼是感知是弱的，相当于就是变相的无损压缩，但这也不能称之为压缩，因为图像采集的原始数据本身就是YUV格式。

四、常见的视频压缩算法为h264、h265，谷歌的vp8，vp9，微软的av1，最为常用的是h264、h265压缩算法，h264在软件中的名称为mpeg4/avc，简称avc，h265简称hevc。h264、h265它们是一种标准，是一套算法的集合，因为这些算法比较固定，所以在计算机中设计了独立的芯片dsp，dsp芯片专门负责编码或者解码h264\h265格式的视频，这种解码方式称为硬件解码，黑苹果、黑群晖jellyfin中所谓的硬件加速其实就是调用专用dsp芯片对音视频进行编解码处理，从而不占用cpu资源，除了硬件解码外，h264\h265算法本质就是计算，交给cpu计算称为软解码，软解码会耗费cpu资源，不过cpu性能过剩的今天也变得无所谓了，至于dsp芯片内部工作原理就是编码算法的具体实现，内部就是对一帧一帧的数据进行编码，它编码输出和解码输入的单位为一帧数据。

h264压缩方式分为帧内压缩和帧间压缩，帧内压缩原理来源于渐变，科学家发现一幅图像相邻像素之间的差异不会很大，也就是相邻像素之间有一定的连续性，它们大多是线性的关系。所以科学家们将一张图片像素进行分组，拆分为一个个小单元，其中有4*4，16*16等像素单元，这些单元称为宏块，基于像素之间色值的连续性，它们将宏块的第一行和第一列像素值保留，宏块其他的值舍弃，同时记录一个向量，向量具有方向，根据向量的方向和第一行第一列的像素值就能推倒出其他像素的信息，这就是基于宏块的帧内压缩原理。也就是一帧可以分为很多个宏块。

帧间压缩就是在视频中连续的画面中，前一帧和后一帧的宏块大多都是相同的，唯一不同的区别是宏块的位置，所以h264将帧分为i、b、p三种类型的帧，i帧为关键帧，保留了完整的宏块信息，而b帧既要参考前面的i帧，又要参考后面的p帧，它保存的大部分是宏块的位移信息，但也有少部分是宏块的完整信息，而p帧参考的是前面的i帧，也是保存了宏块的唯一信息，从而达到了帧间压缩的效果。

h264在计算机中编码后的数据除了帧数据还有对帧和视频的描述信息，这些信息也以一帧的形式出现，称为sps和pps，每一个网络帧称之为一个NAL，NAL之间以0x0000001分隔，后面一个字节是NAL的类型，后面就是具体的NAL数据了，由于NAL之间大多数是像素数据，像素数据范围是0-255，所以这种小而多的数据非常适合采用哥伦布编码，哥伦比编码的原理就是在前面补0，前面有几个零表示后面的数据是多少位的，它是一种变长的编码方式。

h265和h264的有相同的地方，也有不同的地方，相同的是它们都是采用了帧内、帧间预测方式，只不过具体的方式有差异，h265的宏块最大是64*64，所以更具压缩比，但h265同时能保证视频细节更好，h265对色彩差异大和色彩差异小的像素区域分别对待，像素差异大的区域会继续将大的宏块切分，直到最小切分位4*4，同时增加预测方向数目，这样保证了细节又保证了压缩比，帧间预测和h264相同。因为h265对于i帧需要更多的配置信息，所以h265的i帧比h264大，b帧和p帧会比h264小非常多，同样的，h265的网络帧NAL，如sps\pps和h264有很大不同。

四、音视频通信解决方案主要有两种，一种是以延迟性较高但是支持并发数高的直播技术，以RTMP协议为主，另一种是延迟较低的音视频通话或者音视频会议，以webrtc为主。之所以出现这两种方案，是因为需求不一样，直播面对的是一对N的场景，画面的要求也不高，这种场景适合采用服务器转发技术，而音视频会议是一对一或者几个对几个的问题，注重实时性，所以需要客户端直接连接，采用p2p技术。

rtmp本身是一个协议，它支持h264\h265\aac等视频编码协议，在其数据上增加了一些协议定义的字节，经服务器流转到各终端，来实现直播，rtmp直播过程为:

webrtc解决方案的核心是p2p互联，所以这种架构下的服务端有两个角色，一个角色是负责前期沟通的信令服务器，还有一个角色是负责打通两端的ice服务器，信令服务器负责房间的创建、负责各端进入离开房间的消息通知，也负责各端之间媒体协商信息的传递(sdp传递)，也就是在媒体协商阶段，各端是没有直接连接的，媒体协商主要对音视频编解码的各种参数达成一致，为后面互通做准备，ice服务器主要负责建立通道，建立通道有前期的各端nat信息的获取(candidate)，通过信令服务器转发，然后建立连接后，通过RTP/RTCP来传输流媒体数据，其中rtcp是控制协议，因为RTP主要基于udp协议，udp协议是不可靠的，所以要rtcp来控制。一个简单的webrtc的流程为: