简介

GOP， Group of picture

  • 关键帧的周期，也就是两个IDR帧之间的距离，一个帧组的最大帧数，一般而言，每一秒视频至少需要使用一个关键帧，增加关键帧个数可以改善质量，但是同时增加带宽和网络负载。
  • 需要说明的是，通过提高GOP值来提高图像质量是有限度的，在遇到场景切换的情况是，H.264解码器会自动强制插入一个帧，此时实际的GOP值被缩短了。另一个方面，在一个GOP中，P，B帧是由I帧预测得到的。当I帧的图像质量比较差时，会影响到一个GOP中后续的P，B帧的图像质量，直到下一个GOP开始才有可能恢复，所以GOP也不宜设置过大。

码率/码流

  • 码流（Data Rate）是指视频文件在单位时间内使用的数据流量，也叫码率或码流率，通俗一点的理解就是取样率，是视频编码中画面质量控制中最重要的部分，一般我们用的单位是kb/s或者Mv/s。
  • 一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。
    • 码流越大，说明单位时间内取样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。
  • 当然，码流越大，文件体积也越大，其计算公式是：文件体积=时间*码率/8
  • 通常来说，一个视频文件包括了画面及声音，例如一个RMVB的视频文件，里面包含了视频信息和音频信息，音频及视频都有各自不同的采样方式和比特率，也就是说，同一个视频文件，音频和视频的比特率并不是一样的，而我们所说的一个视频文件码流率大小，一般是指视频文件中音频及视频信息码流率的综合。
  • 以国内最流行的RMVB视频文件为例，RMVB中的VB，指的是VBR，即Variable Bit Rate的缩写，中文含义是可变比特率，他标识RMVB采用的是动态编码的方式，把较高的采样率用于复杂的动态画面，而把较低的采样率用于静态画面，合理利用资源，达到画质与体积可兼得的效率
  • 码率和取样率最根本的差别就是码率是针对源文件来讲的

采样率

  • 采样率，也成为采样速度或采样频率，定义了每秒从连续信号中提取并组成离散信号的采样个数，它用赫兹Hz来表示。
  • 采样率是指将模拟信号转换成数字信号时采样频率，也就是单位时间内采样多少点。一个采样点数据有多少比特。
  • 比特率是指每秒传送的比特数，单位为bps（bit per second），比特率越高，传送的数据越大，音质越好。
  • 比特率=采样率 * 采样位数*声道数

比特率

  • 比特率是指每秒传送的比特数，单位为bps (bit per second)
  • 比特率越高，传送的数据越大。在视频领域，比特率通常翻译为码率
  • 比特率表示经过编码（压缩）后的音，视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1.
  • 比特率与音，视频压缩的关系，简单的说就是比特率越高，音，视频的质量就越好，但是编码后的文件就越大
  • 比特率是指将数字声音，视频由模拟格式转化成数字格式的采样率，采样率越高，还原后的音质，画质就越好
  • 常见编码模式：
    • VBR(Variable Bitrate)， 动态比特率，也就是没有固定的比特率，压缩软件在压缩时根据音频数据即时确定使用什么比特率，这是以质量为前提兼顾文件大小的方式，推荐的编码模式
    • ABR(Average Bitrate)， 平均比特率，是VBR的一种插值参数。LAME针对CBR不佳的文件体积比和VBR生成文件大小补丁的特点独创了这种编码模式。ABR在指定的文件大小内，以每50帧（30帧约一秒）为一段，低频和不敏感频率使用相对低的流量，高频和大动态表现时使用高流量，可以作为VBR和CBR的一种折中选择
    • CBR（Constant Bitrate），常数比特率，指文件从头到尾都是一种位比特率，相对于VBR和ABR来说，它压缩出来的文件体积最大，而音质相对于它们来说不会有明显的提高

帧速率

  • 帧速率，也成为FPS(frames per second)， 是指每秒刷新的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次

分辨率

  • 就是帧大小，每一帧就是一幅图像
  • 计算输出文件大小公式：
    • (音频编码率(KBit为单位)/8 + 视频编码率(KBit为单位)/8) * 影片总长度（秒为单位） = 文件大小（MV为单位）

      图像处理 行宽(linesize) 步长(stride) 间距(pitch)

  • 间距，有很多别名，在使用ffmpeg解码时，称为linesize；使用ffmpeg转换格式时，称为stride

  • 间距，在大多数情况下，其数值和图像的宽度是相同的
  • 现在计算机的cpu都是32位或者64位，一次最少读取4个字节或者8个字节，如果少于这些，反而要做一些额外的工作，会花更长的时间，所以会有一个概念叫做内存对齐，将结构体的长度设为4或8的倍数。
  • 间距，也是因为同样的理由出现。图像的操作通常按行操作的，如果图像的所有数据都紧密排列，那么会发生非常多次的读取非对齐内存，会影响效率
  • 间距，就是指图像中的一行图像数据所占的存储空间的长度，它是一个大于等于图像宽度的内存对齐的长度。这样每次以行为基准读取数据的时后就能内存对齐，虽然可能会导致内存浪费，但是在内存充裕的今天已经无所谓了。

图像 编码

JPEG编码

  • 参考信息
    • https://zhuanlan.zhihu.com/p/145847377 : 海思MPP技术笔记

Base64编码

  • Base64 是一种编码方式，最早出现在电子邮件传输协议中。
    • 电子邮件问世之初，传递消息时只支持 ASCII 字符，后来随着电子邮件的广泛使用，传递非ASCII字符内容的需求增加，例如：传输中文、传输文件（图片、视频）。
    • 为解决这一问题，最好的方案是在不改变传输协议的基础上，做一种扩展方案来支持非ASCII内容传输，
    • 把非 ASCII 字符用ASCII来表示，Base64编码应运而生。
  • Base64 是一种基于64个 ASCII 字符来表示二进制数据的表示方法
  • Base64 将8比特位为一个单元的字节数据拆分为以6个比特位为一个单元的二进制片段，每6个比特位单元对应Base64索引表中的一个字符，这样最终构成一个超过编码前字节数据33%的字符串。
  • Base64 中64个可打印字符包括字母A-Z、a-z、数字0-9，此外还有两个字符为+和/，这样构成了共有64字符的Base64索引表
    • base64-map
  • 为什么一些Base64后的字符中末尾有“==”
    • 编码前字节数正好被3整除，转化为二进制ASCII 编码（ 3*8=24 ）后，正好可以被6整除。
    • 若编码前字节数不能被3整除，最后会余出1个或2个字节，那么编码时需要：
      • 使用 000000 字节值在末尾补足，使其字节数能够被3整除；
      • 编码时补位的6个比特位单元用 = 表示。

视频基本概念

容器

  • 熟悉的mp4, rmvb, mkv, avi是多媒体容器文件格式（或称多媒体封装格式），所谓容器，**是指将不同的数据流（视频流，音频流，字幕流）封装在一个文件（载体）中。
  • 播放时各种流分别进行解码等处理，然后输出到显示器和音响等设备进行播放。多媒体容器格式不同于编码格式，一个容器中可以封装多种编码格式的媒体流。
  • 流封装了实际的媒体数据，例如视频流，音频流和字幕流等。一般情况下，流中的数据只能使用一种编码格式。

帧率

  • 帧率(frames per second, fps)，是每秒画面刷新的次数，帧率越高视频越流畅。
  • 一般来说，30fps就是可以接受的，60fps则可以明显提升交互感，但一般超过75fps就不容易察觉到有明显的流畅度提升了

分辨率

  • 分辨率表示画面的精细程度，通常用像素密度来表示,常用的单位为ppi（像素每英尺），通常像素密度越高画面越精细，模糊程度越低
  • 对于视频文件而言，像素密度是无法控制的（由播放器和显式设备决定）。我们通常用视频的向素数来表示它的分辨率，例如1080x640, 640x320等

比特率

  • 比特率(bit rate)，又称码率，表示多媒体流每秒输出的字节数，单位为KB/s, Kbps等，同样的压缩算法，比特率越高音视频的质量越好。
  • 可变码率(Variable Bitrate, VBR)，指的是编码其的输入码率可以根据输入源信号的复杂度进行自适应调整，以在输出质量保持不变的条件下尽可能减少数据量。VBR适用于存储，不太使用于流式传输。
  • 固定码率(Constant Bitrate, CBR), 指的是编码器输出码率固定，CBR不适合存储，对于复杂内容可能没有足够码率进行编码，从而导致质量下降，同时会在简单内容部分浪费一些码率

采样率

  • 采样率，指的是每秒钟对音频信号的采样次数，采样频率越高，声音还原度越高，声音更加自然，单位是赫兹Hz
  • 音频文件一般使用的采样率是44.1kHz，也就是一秒钟采样44100次，实验发现低于这个值就会由较明显的损失，而高于这个值人的耳朵已经很难分别，而且增加了数字音频所占的空间

视频编码

  • 视频流可以看作图片的序列，我们把这个序列中的一张图片称为一帧。若存储视频中所有的帧，则会导致数据量过大，不便于存储和传输。
  • 统计表明大多数视频相邻帧之间的区别并不大，所以对于一段变化不大的视频，我们可以先完整编码帧A，其后的B帧只需要编码与A帧不同的部分，B帧后的C帧则只编码与B帧的差异。如此递推，将一段视频编码为一个序列。
  • 当某个图像与之前的图像变化很大，导致无法参考前面的帧来生成，就结束上一个序列，并且将该帧完整编码开始一个新的序列
  • H264是目前流行的一种视频编码算法，它定义了三种帧：完整编码的I帧，参考I帧只包含差异的P帧，以及参考前后帧编码的B帧
  • H264采用的核心算法是帧内压缩和帧间压缩。
    • 帧内压缩是生成I帧的算法
    • 帧间压缩是生成B帧和P帧的算法
  • 通常，把完成编码的I帧称为关键帧。因为解码非关键帧需要解码其参考的帧，因此在截图等不需要全部解码的操作中，经常截取关键帧以提升性能。

视频基础知识和视频格式

  • 网站上的视频，是常说的网络流媒体
  • 将视频缓存到本地成一个文件，是常说的本地视频文件

视频封装格式（简称视频格式，也称为容器）

  • 视频格式是视频播放软件为了能够播放视频文件而赋予视频文件的一种识别符号

  • 换句话讲，视频格式规定了和播放器的通信协议

  • 首先，MP4, AVI, MKV等都是本地视频文件的后缀，在wiindows系统下，用于提示操作系统应该采用哪个应用程序打开。
  • 而在流媒体领域，这些都被称为视频封装格式，因为除了音视频流外，它们还包含了一些辅助信息以及组织音频的方式。

  • 不同格式的视频在不同平台上用户体验不同，很大原因在于对音视频的组织方式带来的差异。

  • 视频封装格式，是在编码的音视频基础上进行一次“包装”，添加与播放相关的协议数据。（不一定正确）

视频协议

  • 视频协议，是针对网络流媒体而言的，也就是只有在有网络时通过浏览器或者移动端APP才能看到的视频，目前常见的协议有RTSP， RTMP， HLS，HTTP等

  • 有的文章会把视频协议归入视频封装格式，因为它们都同时携带了音视频和metadata，以及协议/格式需要的其他信息。
  • 以FFMpeg为例，它并不区分视频格式和视频协议。

视频流

  • 常见的词语有：
    • h264码流，yuv流，编码流，解码流，原始流，裸流，或者 未压缩的流
  • 归纳的讲，视频流，一定只有两种形式
    • 经过压缩算法压缩的流数据，称为编码流，又因为目前压缩/编码算法以H264为主，因此常常称为H264码流
    • 未经过压缩的流数据，是解码后的流数据，称为原始流，可以想象视频是由一幅一幅在时间上连续的“图像”组成的，而因为视频内部的“图像”是YUV，因此也常常称为YUV流
  • 总结
    • h264码流，压缩后的流， 编码流 ： 是压缩/编码后的视频流
    • yuv流，解码流，未压缩的流 ： 是未经过压缩/编码的视频流
    • 裸流，是一个具有歧义的词，是上下文内容，既可以是前者，也可以是后者
  • 因此，在阅读任何流媒体相关的文章时，看到视频流都应该搞清楚，是编码/压缩的,还是没有
    • 在生活中，接触到的视频文件绝大部分都是编码/压缩后的
    • 在网络传输场景中，绝大部分也是编码/压缩后的。
    • 只有在视频播放时，看到的是一帧帧被转码为RGB的解码后的视频流
  • 编码/压缩在流媒体领域是一项非常重要的技术：
    • 从H264码流到YUV流的过程称为解码，反之称为编码

帧

  • 流媒体领域，流很重要，流的基本元素帧同样重要。

  • 对于视频编码/压缩而言，它的核心是采用尽量小的空间存储一组时间上连续的帧数据
  • 而对于视频解码而言，就是把被编码/压缩后的一组数据尽量恢复成原来的样子。
    • 能够被100%恢复的编码/压缩算法称为无损压缩，反之称为有损压缩

  • 帧，可以联想成平时看到的一幅幅“图像”，只不过我们平时接触的图片是RGB格式的，而视频帧通常是YUV格式的

  • 帧，为什么采用YUV格式？YUV是什么？
    • 在达到最大压缩率的情况下，能够保证对人眼感知的失真度最小。YUV的三个通道中，其中Y表示明亮度，也就是灰阶值；而U和V表示的则是色度。科学家研究发现，人眼对UV的敏感度最低，因此可以大比例地压缩UV两个通道的数值
    • 为了向前兼容黑白电视

  • YV12， YU12， NV12， NV21等，统称为视频的存储格式，也就是说，计算机是如何存储一帧视频的

  • 视频编解码而衍生的帧名词
    • I帧， P帧， B帧和IDR帧
    • GOP， Group Of Pictures，一般来说，指的是两个I帧之间的间隔
    • PTS, Presentation Time Stamp， 显示时间戳，它用来告诉播放器该什么时候显示这一帧的数据
    • DTS, Decoding Time Stamp， 解码时间戳，它的意义在于告诉解码器在什么时候解码这一帧的数据

JPG-JPEG（JFIF） 文件解码-文件结构

  • 参考链接：https://blog.csdn.net/ymlbright/

  • JPEG文件使用的数据存储方式有多种。最常用的格式称为JPEG文件交换格式（JPEG File Interchange Format，JFIF）

  • 而JPEG文件大体上由一个个数据段组成，数据段包含：标记码(Tag)、数据长度、数据

  • 标记码由两个字节构成，其前一个字节是固定值0xFF，后一个字节则根据不同意义有不同数值
  • 在每个标记码之前还可以添加数目不限的无意义的0xFF填充，也就说连续的多个0xFF可以被理解为一个0xFF，并表示一个标记码的开始。而在一个完整的两字节的标记码后，就是该标记码对应的压缩数据流，记录了关于文件的诸种信息。
  • 常用的标记有SOI、APP0、DQT、SOF0、DHT、DRI、SOS、EOI
  • 注意，SOI等都是标记的名称。在文件中，标记是以标记码形式出现的。例如SOI的标记代码为0xFFD8，即在JPEG文件中的如果出现数据0xFFD8，则表示此处为一个SOI标记
    • SOI （0xFFD8） – 代表JFIF图像数据的开始
    • APP0 （0xFFE0） – 应用程序标记 0
    • APPn （0xFFEn） – 拓展应用程序标记 2~15， 为其他应用程序保留
    • DQT （0xFFDB） – 量化表，存储了对扫描数据进行量化的 8*8 矩阵
    • SOFx （0xFFCx） – 图像帧开始
    • DHT （0xFFC4） – Huffman表，存储了对扫描数据进行压缩的Huffman表，共4张，DC直流2张，AC交流2张
    • SOS （0xFFDA） – 扫描数据开始
    • scanData – 图像的压缩数据，为了不与之前的标记码（Tag）混淆，数据中遇到 0xFF 时，需要进行判断
      • 0xFF00：表示 0xFF 是图像数据的组成部分
      • 0xFFD0~0xFFD7：RSTn标记，遇到标记时，对差分解码变量进行重置（归0）
      • 0xFFD9：图像结束标记，图像压缩数据至此结束
    • EOI （0xFFD9） – 代表JFIF图像数据的结束，即文件结尾

腾讯 开发者社区

  • 文章链接：https://cloud.tencent.com/developer/article/1385273

  • 就音频而言，无论是算法多样性，Codec种类还是音频编解码复杂程度都远远比视频要高。

  • 视频的Codec目前还主要是以宏块为处理单元，预测加变换的混合编码框架，例如H.264和H.265都是在这一框架下

直播和点播

  • 从广义上来讲，直播和点播都是一种视频播放场景
  • 如果想要简单地区分二者，确实可以通过判断当前播放的视频画面是不是实时的来区分
    • 如果是实时的画面就是直播，
    • 如果不是实时的画面就是点播
  • 直播
    • 视频直播播放的视频内容是实时的视频画面，视频源是实时的媒体流。
    • 视频直播的播放内容稍纵即逝，无法回退和快进。
    • 日常生活中的视频直播场景非常多，比如直播带货、视频会议、赛事直播等
  • 点播
    • 视频点播播放的视频内容是非实时的视频画面，
    • 视频源是已经存在的视频文件或者媒体源，可以多次使用，可以回退和快进。
    • 日常生活中的视频点播场景也非常多，比如有线电视、网络点播、短视频等
  • 直播和点播的工作流程
    • 视频直播会涉及一个比较完整的视频处理流程，包括视频画面和声音采集、视频编码、组包发送、网络传输、收包解包、视频解码、视频渲染和声音播放等
    • 视频点播包括的流程就比较少了，一般只涉及文件读取、网络传输、视频解码、视频渲染和声音播放等流程，不会涉及视频画面和声音采集、视频编码、组包
  • 技术架构
    • 视频直播，常见的低延时方案大多是 RTC （Real time communication）方案，比如 WebRTC；大会直播类的场景一般是 CDN 方案，常用 rtmp、hls 等流媒体协议方案
    • 视频点播，常用的有电视信号和网络协议，比如 http，https 等，视频格式有 m3u8、mp4、flv、mkv、mxf 等。由于上述网络协议和传输信号的差异，视频直播和视频点播的播放器方案有所不同，也是二者的显著差异之一

RTC

什么是RTC？

  • RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的RTC技术一般指的是WebRTC技术，已经被 W3C 和 IETF 发布为正式标准

  • 由于几乎所有主流浏览器都支持 WebRTC 标准 API ，因此也让浏览器之间无插件化的音视频互通成为可能， 大大降低了音视频开发的门槛，开发者只需要调用 WebRTC API 即可快速构建出音视频应用

  • 更广义的RTC技术，不单单局限于音视频，包括IM(Instant messaging,即时通讯)、图片、白板、文件共享等富媒体在内的实时交互也属于RTC技术范畴。

一套完善的RTC服务应用的技术

  • RTMP只是TCP上的一个标准协议，所以接入是一个标准体系，推流端可以是OBS( Open Broadcaster Software)这种直播软件工具，也可自开发rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已经弃用）、服务端有技术成熟的CDN(Content Delivery Network，即内容分发网络)技术和设施进行分发、Native的播放器或者flv.js/hls.js这种开源播放器组件，遵循rtmp、flv、hls标准即可，接入成本比较低。而一个完善的RTC服务应用，需要从推流端、服务端、到拉流端，一整套完整的全链路闭环技术。

  • 互动连麦+服务端转推rtmp至CDN，CDN分发给观众。