音视频基础概念

前言

本节主要阐述音视频的一些基础概念，以及一些基本流程。

视频播放原理

视频播放原理从视频文件结构、播放原理、音视频同步和转码过程四个方面，简要阐述音视频的基础概念。

视频文件结构

视频文件由文件信息和音视频数据组成，不同的封装格式决定了视频文件的具体结构。常见的封装格式包括 .mp4、.avi、.flv、.hls 等，一些流媒体协议如 RTMP、RTSP、HTTP-FLV 等也可以被视为特殊的封装形式。

1. 文件信息
   文件信息记录了视频文件的元数据，如封装格式、编码格式、时长、分辨率以及其他 meta 信息。这些信息为后续对音视频数据的解压缩和播放提供了必要的指引。
2. 音视频数据
   音视频数据是经过压缩处理后的数据块，通常音频数据与视频数据交叉存储。需要注意的是，每一小块音频或视频数据不一定对应独立的一帧。音视频文件中通常包含多个轨道（Track），例如音频轨道、视频轨道，甚至字幕轨道。播放器通常只会选择一个音频轨道和一个视频轨道进行播放，但原则上支持多轨道并存。

视频播放原理

播放视频的过程主要涉及解封装和解码两个步骤。

1. 解封装（Demux）
   播放视频时，播放器会按照顺序读取音视频数据块并解封装。解封装的作用是提取出音视频的压缩数据，但这些压缩数据还不能直接播放。封装格式决定了视频文件的数据结构和数据块的存储规则。
2. 解码（Decode）
   解码是将解封装后的压缩数据进行解压缩的过程。解码过程依赖于特定的编码格式及其对应的解码器，例如 H.264、H.265、AAC 等。编码格式决定了音视频数据的压缩方式及算法，因此不同编码格式的解码器程序也不相同。

音视频同步原理

音视频同步的关键在于时间戳（Timestamp）。

1. 时间戳类型

   • 解码时间戳（DTS）：指示解码器按照顺序解码音视频数据块的顺序。
   • 播放时间戳（PTS）：指示播放器在具体时间播放对应的音频采样或视频帧。

2. 时间基换算

   时间戳通常是相对时间，需要通过时间基进行换算，最终得到对应的绝对播放时间。播放器根据 PTS 信息来实现音频与视频的同步播放。

转码过程原理

转码的核心是对视频文件进行重新编码。

1. 解封装与解码
   提取音视频数据块并进行解码，生成未压缩的图像帧和音频采样。
2. 处理
   对解码后的数据进行处理，如调整分辨率、修改采样率、裁剪画面等。
3. 重新编码与封装
   将处理后的数据重新编码为指定的编码格式，并按照目标封装格式重新打包成完整的视频文件。

视频基础参数概念

在音视频领域，视频的组成离不开一帧帧画面的累积和它们的动态连接。理解视频的基础参数方便更好地掌握视频处理中的核心要点。

单个视频帧

单个视频帧可以看作是一张静态图片，主要包含以下几个重要参数：

• 分辨率：指图像的宽高像素大小，如 1920×1080。标识如 “1080P” 中的 “P” 表示逐行扫描（Progressive），而 “I” 表示隔行扫描（Interlaced）。常见分辨率：
  • 4K：3840*2160
  • 2K：2560*1440
  • 1080P：1920*1080
  • 720P：1280*720
  • 360P：640*360
• 像素：指分辨率长宽相乘后的值。例如，1920×1080 的分辨率包含 207 万像素点。
• DPI（Dots Per Inch）：表示每英寸像素密度，主要用于衡量图片或屏幕显示的精细程度。
• 色彩空间模型：定义像素记录颜色的方式，常见模型包括 RGB 和 YUV。其中，RGB 更适合显示设备，YUV 则常用于视频压缩和传输。

多个视频帧

当视频由多个帧组成时，额外引入了一些重要参数：

• 帧率：表示每秒播放的帧数，单位为 fps（Frames Per Second）。常见的帧率如 24fps（电影帧率）、30fps（普通视频）、60fps（高刷新率视频）。
• 播放时间戳 PTS：标记每一帧在视频播放中的时间点，用于确保音视频同步。
• 码率：又称音频比特率，码率就是一秒钟的数据量大小，单位为 kbps 或 Mbps。再不压缩的情况下，原始码率=采样数*位深度*声道数，码率越高，画质越好，但占用存储或带宽越多。

H.264 和 H.265

在视频编码中，H.264 和 H.265 是两种主流压缩编码格式，引入了 IPB 帧的概念，用于提高视频压缩效率：

• I帧（Intra-coded Frame）：独立帧，包含完整画面信息，可单独解码， 数据量是最大的。

• P帧（Predicted Frame）：预测帧，基于前一帧进行编码， 数据并不完整， 只记录差异信息。

• B帧（Bi-directional Frame）：双向预测帧，基于前后帧进行压缩，压缩效率最高。

• GOP（Group of Pictures）指的是一组完整的视频帧，如gop设置为25，那么编码器会让每25帧的第一帧必定为I帧 。如果帧率也是25帧，那每秒的第一帧就必定是I帧。

这些特殊帧通过减少冗余信息存储，大幅降低了视频文件的体积，同时在解码时恢复出流畅画面。

不同场景关注的点（无论是什么场景，都需要关注码率、最大码率的设置 ）：

• 在线播放：一般不需要特别关心I帧、B帧、P帧、GOP。 但是如果出现未加载完视频跳转不太流畅等问题的话，则可能是视频的某两个I帧相隔特别远，为了防止这种问题，可以将GOP设置为帧率的4-5倍，保证每4-5秒必有一个I帧。
• 直播场景：I帧、B帧、P帧、GOP都需要特变关注。I帧是独立的帧，B帧、P帧的播放实质上都需要依赖I帧，所以流媒体服务器需要设置缓存I帧，这样首屏花屏的问题会得到一定程度缓解。出现局部花屏时还需要设置GOP，GOP一般设置为帧率的1-2倍，保证每1-2秒必有I帧。这样的话，理论上只有在1-2秒这个间隙中开始拉流才会出现花屏问题。

音频基础参数概念

音频采样的基本概念

音频采样是音频数字化的基础，以下是音频采样中四个核心概念：采样、位深度、声道和采样率。

• 采样是对声音信号在某一刻的声音强度进行记录的过程。音频的最小单位并不是一帧，而是一个采样点。采样点记录了当前时刻的声音样本，这些样本通过模数转换（ADC，Analog-to-Digital Conversion）生成可存储的数字化数据。

• 位深度（Bit Depth）是指每个采样点的数据存储大小。位深度越大，声音的动态范围和细节就越丰富。例如，16位深度可以记录 2¹⁶（65536）种不同的振幅变化，是音频文件中最常见的位深度，广泛用于网络视频和音频文件。而24位深度则常用于高品质音频。

  • 16位深度：每个采样点占2字节。
  • 24位深度：每个采样点占3字节，能表现更精细的声音动态。

• 声道（Channel）决定了音频的空间感和方向性。常见的声道配置包括：

  • 单声道（Mono）：只有一个声道，音频播放时所有声音都集中于一个音源。
  • 双声道（Stereo）：有左右两个声道，提供立体声效果。双声道的采样数据量是单声道的两倍。
  • 多声道（如5.1、7.1声道）：用于影院音效，多个声道数据会按照顺序排列存储，播放时按对应的扬声器输出。

• 采样率（Sampling Rate）是每秒对声音进行采样的次数，单位是赫兹（Hz）。采样率越高，声音的还原度越好。但需注意，采样率越高，文件大小也越大。常见采样率：

  • 44.1 kHz：音质可满足 CD 标准。
  • 48 kHz：常见于影视音频，音质略高于 CD 标准。
  • 96 kHz 或更高：常见于专业录音或高解析音频格式。

单个音频帧的概念

为了实现音视频同步播放，音频引入了“音频帧”的概念。

音频帧是将一小段时间内的多个音频采样数据打包形成的结构化数据单元。由于每个采样点的数据量很小，如果为每个采样点附加播放时间戳（PTS，Presentation Timestamp），会严重浪费存储空间。因此，音频采样数据会打包成音频帧，一个音频帧对应一段连续的采样数据。优点：

• 减少时间戳占用的存储空间。
• 提高音频文件的播放效率。

音频帧示例：假设音频的采样率为 48 kHz，位深度为 16 位，声道数为 2：

• 每秒有 48,000 个采样点。
• 每个采样点的大小为 16 位 × 2 声道 = 4 字节。
• 每秒的音频数据大小为 48,000 × 4 = 192 KB。

如果将 1 秒的采样数据分为 100 帧，每帧包含 480 个采样点，则每帧的数据大小为 480 × 4 = 1920 字节。每帧的播放时长为 1 秒 ÷ 100 帧 = 10 毫秒。

多个音频帧与播放的关系

当音频文件被打包为多个音频帧后，播放时间戳（PTS）、码率和编码格式决定了播放效果和质量：

播放时间戳（PTS） 是指音频帧的播放开始时间。

• 每个音频帧的 PTS 指示其在播放中的起始点。

• 播放时，采样数据会按采样频率连续输出，直到下一帧的 PTS 到达。

• 优化意义：保证音视频同步，尤其在变速播放或跳转播放时，PTS 是核心参考。

码率（Bitrate）是指音频每秒的数据量大小，单位为 kbps（千位每秒）。原始码率计算公式：码率=采样率×位深度×声道数。如：采样率为 48 kHz，位深度为 16 位，双声道码率为：48,000×16×2=1536000bps=1536kbps

• 高码率：音质更好，但文件更大。
• 低码率：音质下降，但适合网络传输。

编码格式决定了音频数据的压缩和存储方式，是影响音频质量和播放效率的重要因素。常见编码格式包括：

• 无损格式：如 WAV、FLAC，保留了完整的音频数据，但文件较大。
• 有损格式：如 MP3、AAC，压缩掉人耳不敏感的频段数据，文件更小，但音质会有所损失。

直播工作原理

直播的核心在于实时传输和播放音视频流，与普通视频转码不同，直播的输入和输出均为实时流媒体（直播流），而不是静态视频文件。整个直播过程可以概括为三个主要环节：直播流数据获取、直播转码和直播流数据输出。

直播工作流程概述

直播流程的关键在于引入两个流媒体服务。

• 流媒体服务 A：用于接收直播源数据（直播流推送到此服务）。
• 流媒体服务 B：用于分发处理后的直播流供用户观看。

转码模块从流媒体服务 A 拉取直播流进行处理，处理后的直播流再推送到流媒体服务 B。用户可从流媒体服务 B 拉取视频流观看。如果直播的推流协议与观看协议一致，则可仅使用一个流媒体服务。
简化流程为：直播流数据获取 → 转码 → 直播流数据输出。

直播源数据获取

直播源数据通常通过网络传输，需要流媒体服务作为中转站，不同场景的获取方式如下：

1. 直播平台场景：
   • 主播通过推流工具（如 OBS）将音视频流推送到直播平台的流媒体服务。
   • 常用协议：RTMP。
2. 转播场景：
   • 直接从对方流媒体服务拉取直播流进行转播。
   • 常用协议：RTMP、HLS、HTTP-FLV、RTSP 等。
3. 录播场景（文件直播）：
   • 直播源是静态视频文件，不需要流媒体服务中转，直接读取文件推流。

直播转码

转码是将直播源中的音视频流解码处理后重新编码并封装的过程。完成转码后，处理好的直播流推送到流媒体服务供用户观看。

• 观看协议选择：
  • 低延迟协议：RTMP、WebRTC（适合实时互动场景，但 RTMP 已不被主流浏览器支持，因 Flash 停用）。
  • 高兼容性协议：HTTP-FLV、HLS（适合大部分播放器和浏览器，但延迟较高）。

4. 直播流输出及直播 CDN

直接将直播流输出给用户观看会消耗大量带宽。以 2Mbps 的直播流为例，100Mbps 带宽的服务器理论上只能支持 50 人观看。为应对大规模并发访问，通常需要引入直播 CDN（内容分发网络）。

1. 直播 CDN 的作用：
   • CDN 作为分发节点，可以分摊请求压力。
   • 转码后的直播流通过 RTMP 推送到 CDN，CDN 自动生成多种观看协议（如 RTMP、HTTP-FLV、WebRTC、HLS 等）供用户选择。
2. 直播转码与 CDN 的关系：
   • CDN 一般不提供复杂的转码功能，只支持简单的协议转换（如解封装与重封装，性能消耗较低）。
   • 如果需要码率调整、分辨率更改等复杂操作，需要依赖额外的转码服务（如云服务或自建转码模块）。

直播协议

常见的直播协议主要有：HTTP-FLV、HLS、RTMP、WebRTC 和 RTSP。

RTMP 协议

RTMP（Real-Time Messaging Protocol）是一种用于推流和拉流的协议，常用于将直播源推送到 CDN。由于浏览器不再支持 Flash，RTMP 目前主要用于推流。

rtmp 地址是 rtmp:// 开头，推流地址与拉流地址相同，在高并发下可能会出现不稳定的问题，所以rtmp一般只用作直播源推流、推流到直播CDN等场景。rtmp 协议需要特定的流媒体服务软件，如 SRS、加入了 rtmp 插件的 Nginx 等，此类流媒体软件实际上就是音视频数据的中转站，数据一般在内存中循环覆盖，不会写入磁盘。

rtmp 协议的延迟一般比较低，rtmp 协议延迟一般在1~3秒左右，rtmp 通信建立在 tcp 长连接通道上，在封装音视频数据时会强制切片，限制每个数据包的大小强制切片也一定程度保证了实时性。有一定的弱网抵抗能力，因为每个数据包都不会太大，所以当某个数据包校验失败时，重新发送的成本不会太大，但也由于合并数据包会加大CPU压力，所以是有一定的性能消耗的。

rtmp 协议还有一些变种协议，如 RTMPT、RTMPS 等

应用场景：推流至 CDN，再通过其他协议拉流。

HTTP-FLV 协议

HTTP-FLV 是基于 HTTP 的 FLV 数据流协议，适合拉流观看。

特点：

• 低延迟：延迟 1-3 秒，略高于 RTMP。
• 易部署：兼容性强，无需特殊服务端支持。

不足：

• 需要插件（如 flv.js）支持浏览器播放。
• 仅支持拉流。

组合应用：RTMP 推流 + HTTP-FLV 拉流是目前主流方案。

HLS 协议

HLS（HTTP Live Streaming）协议并不严格是一个流式协议。它的工作原理是通过HTTP协议下载静态文件。

组成结构

1. .ts碎片视频文件：每个文件的长度通常为几秒。
2. .m3u8索引文件：记录了这些视频碎片文件的地址，客户端获取到该索引文件后，通过HTTP协议下载对应的碎片视频文件并开始播放。

HLS协议工作原理。

• 客户端播放：客户端通过访问以 http:// 开头、.m3u8 结尾的地址，获得视频内容的播放信息。
• 静态文件：HLS 协议中的视频文件和索引文件是直接存储在磁盘上的，因此不需要专门的流媒体服务软件，像 Nginx 等 HTTP 服务就可以提供 HLS 支持。

应用场景

• 点播模式

可以通过转码软件直接生成 HLS 相关的 .ts 和 .m3u8 文件；也可以在 Nginx 加入 RTMP 插件，接收 RTMP 推流，再转为 HLS 文件。在直播场景下，.ts 碎片视频文件每隔几秒钟生成一次，且 .m3u8 索引文件不断更新。旧的视频文件会被删除，保持文件数量不超过设定的上限。

• 直播模式

由于 HLS 的相关文件是无状态的静态文件且文件大小有限，负载均衡和 CDN 加速效果良好。在点播场景中，HLS 协议的优势非常明显，视频播放更流畅、加载跳转更顺滑。客户端根据 .m3u8 索引文件来下载对应的 .ts 视频文件，快速开始播放。HLS 协议的直播延迟较大，一般为5-30秒，使用CDN时可能更长，甚至达到1分钟左右。

直播与点播的差异

• 点播：视频文件和索引文件通常是静态的，文件大小固定，适合通过 CDN 进行加速。
• 直播：视频数据实时生成并打包成 .ts 文件，索引文件频繁更新，客户端需要定期获取最新的 .m3u8 文件。直播时的延迟较高，HLS 协议在直播场景中的表现较为逊色。

HLS的二级索引

.m3u8 索引文件支持二级索引，可以包含多个不同质量的流（如高清、标清、流畅等）。播放器可以根据当前网络带宽自动切换播放流，这也是大多数网页播放器提供“自动”功能的原因。

Web-RTC

WebRTC（Web Real-Time Communication）最初设计为一种点对点的视频和语音通话协议，但由于其低延迟的特性，在某些直播场景中也被广泛应用。

WebRTC协议特点

1. 点对点通信：WebRTC是一种点对点协议，支持直接在浏览器或应用间建立连接，减少中间环节的延迟。
2. 基于UDP：使用UDP协议进行数据传输，支持流式发送数据，延迟比RTMP更低，理论延迟可低至1秒以内。
3. 实时性强：适合需要高交互性的直播场景，例如直播带货、互动课堂等。

应用场景

• 直播推流和观看：
  • WebRTC协议支持推流和拉流，地址通常以 webrtc:// 开头，且推流和拉流地址相同。
  • 在直播场景中，WebRTC提供低延迟体验，使得观众和主播的互动更加即时。
• 服务器支持：
  • 虽然WebRTC是点对点协议，但在直播场景中需要通过WebRTC服务器实现流媒体服务。
  • 常用的流媒体服务器软件包括SRS，支持高效的WebRTC流处理。

RTSP 协议

RTSP 一般不用作直播场景，RTSP 一般用作摄像头、监控等硬件设备的实时视频流观看与推送上。尽管 RTSP 协议也支持推流/拉流，且支持 TCP、UDP 切换以及其他诸多优点。但是泛用性不足，特别是现在的浏览器都不支持 RTSP 的播放。

在线视频格式

记下来主要讨论封装格式的作用、以及一些主流封装格式（MP4、FLV、HLS），详细解析它们的特点、优劣及适用场景。

封装格式的作用

一个视频文件实际上分为三层结构：封装、编码和基础数据。播放器要正确播放视频，必须同时支持这三层格式。

大多数封装格式不限制音视频数据的基础参数（如帧率、分辨率、采样率等）。封装格式的核心作用是对音频、视频及元数据进行统一的组织和管理，并按特定规则编排成文件。

虽然封装格式本身不会改变音视频数据的质量，但它对特定场景的播放表现有显著影响。例如：

• MKV 支持外挂字幕和多语言切换。
• FLV、HLS 在在线播放场景下，首帧播放和未加载跳转的表现更优。

MP4格式

MP4 是当前最常见的封装格式，文件通常以 .mp4 结尾。它以高兼容性、灵活性强、适用范围广闻名，是目前几乎所有播放器和浏览器都支持的封装格式。

MP4 文件是树状结构，由多个数据块嵌套组成。关键数据块包括：

1. ftyp：存储编码格式和标准信息，用于解码器选择。
2. mdat：存储音视频的原始数据（通常不带时间戳）。
3. moov：存储元数据和播放时间戳的映射关系，是播放器计算音视频帧播放时间的关键。

在在线播放场景中，如果 MP4 文件的 moov 数据块未能提前加载，视频往往会出现长时间的加载等待。因此，对于需要快速播放的 MP4 文件，应将 moov 数据块放在 mdat 之前，以加速首帧播放。

适用场景：

• 短视频（文件较小，时长较短）：直接使用 MP4 格式即可，方便快捷，且兼容性高。
• 长视频（文件较大，时长较长）：不推荐使用 MP4 格式，因为CDN 加速效果较差，长时间播放可能会导致中断等问题。

FLV格式

FLV 是 Adobe 主导的网络视频封装格式，与 RTMP 和 HTTP-FLV 协议紧密相关。它专为网络视频设计，网页只需引入 flv.js 插件即可播放。

FLV 的最大优势在于，每个音视频数据块都有时间戳标识。这种设计让 FLV 在首帧播放和未加载跳转场景中表现出色。

然而，FLV 文件在未加载跳转时，可能会因未建立关键帧索引而出现报错或中断的问题。因此，网络视频使用 FLV 格式时，应确保建立关键帧索引以提升用户体验。

适用场景：

• 直播和长视频：FLV 格式的稳定性优于 MP4，更适合大文件和长时间播放。
• 普通 CDN 加速效果较差：若采用 FLV 大文件播放，可配合专门的大文件 CDN 解决方案。

HLS格式

HLS 是一种将视频切片为多个小文件的封装格式。其基本原理是将视频分割成若干 .ts 碎片文件，并通过 .m3u8 索引文件管理这些碎片。在线播放时，播放器按需下载碎片文件，加载播放。

相比于 MP4 和 FLV，HLS 格式在长视频场景下表现更优，尤其是在：

• 未加载跳转：可以快速切换至指定位置播放。
• CDN 加速：更好地支持大规模分发。
• 多线程预加载：提高加载速度。

不过，HLS 格式在短视频场景中的优势并不显著，且由于 .ts 文件是独立的可播放视频，会额外增加流量消耗。此外，HLS 视频需要网站系统自行转封装或借助云服务完成，增加了复杂性。

适用场景：

• 长视频和直播：HLS 格式能充分利用其切片机制，在高并发环境下保障流畅播放。
• 短视频：优势不明显，可根据需求选择其他封装格式。

常用基础框架

• 编解码框架：FFmpeg、GStreamer
• 图像处理框架：OpenCV
• 复杂图像生成：OpenGL

参考链接：https://blog.csdn.net/daniel_leung/category_12192843.html