说说直播链路：采集→预处理（美颜滤镜）→编码→推流

直播链路可以形象地比喻为一条“短视频/直播的内容加工与运输流水线”。数据从主播的手机摄像头，一路奔跑最终变成网络包发送出去。

下面是针对 采集 → 预处理（美颜滤镜） → 编码 → 推流 每一个环节的工程实现核心、底层原理与技术大厂的避坑指南：

一、 采集（Capture）：数据的源头

采集是把物理世界的音视频，通过硬件设备变成计算机能识别的原始数字信号。

• 视频采集：

  • 核心动作：通过手机摄像头（Camera1 / Camera2 / CameraX 或 iOS AVFoundation）获取图像。

  • 底层格式：通常输出为 YUV 格式（如 NV21, I420）或者直接输出 GPU 纹理（Texture OES）。

• 音频采集：

  • 核心动作：通过麦克风（Android AudioRecord / iOS AudioUnit）采集音频。

  • 底层格式：输出为未压缩的 PCM 原始脉冲数据（通常采用 44.1kHz 采样率、16位采样深度、双声道）。

• ⚠️ 避坑指南：

  • 不要用 CPU 做格式转换：Camera 采集到的 NV21 数据如果用 CPU 转成 RGB 再送给美颜，会导致 CPU 瞬间飙升。正确做法：直接让 Camera 输出 OES 纹理，或者用 OpenGLES 的 Shader 在 GPU 里面做 YUV 到 RGB 的转换。

二、 预处理（Preprocessing）：美颜与滤镜的魔法

预处理是直播体验的“灵性和门面”，这一步完全在 GPU 中完成。

• 核心动作：

  1. 磨皮与美白：使用双边滤波（Bilateral Filter）或高斯模糊算法，在保留眼睛、眉毛等边缘细节的同时，平滑皮肤部分的颜色。

  2. 大眼瘦脸（人脸关键点形变）：通过人脸识别 SDK（如 SenseTime, Face++, 或者是开源的 Mediapipe）拿到人脸的几十个或上百个特征点，通过 局部平移/缩放矩阵公式 对眼睛和下巴区域的纹理坐标进行拉伸。

  3. 滤镜（LUT）：通过一张颜色查找图（Look-Up Table），将图像的颜色按照矩阵重新映射，实现复古、日系等风格。

• 工程架构：

  • 使用 FBO（Frame Buffer Object，帧缓冲区对象） 进行链式渲染。

  • 链路为：OES 纹理 -> FBO1（磨皮美白） -> FBO2（瘦脸大眼） -> FBO3（贴纸/滤镜） -> 最终 2D 纹理。

• ⚠️ 避坑指南：

  • 不要频繁读写显存：严禁在预处理每帧时调用 glReadPixels 把数据抓回内存。这会导致 GPU 管线阻塞，帧率暴跌。全链路必须使用 TextureID（纹理句柄） 在 GPU 内部流转。

三、 编码（Encoding）：数据的极限压缩

预处理完的图像（如 1080P/30fps）数据量极大，一秒钟高达上百兆，如果不压缩，任何网络都无法传输。

• 视频编码（Video Encoding）：

  • 算法原理：去除时间冗余（前后两帧画面很像，只记差值）和空间冗余（天空一片蓝，只记区域）。

  • 主流格式：H.264 (AVC) 兼容性最好；H.265 (HEVC) 压缩率高 30%~50%，但部分老设备硬解会发热。

  • 硬编 vs 软编：Android 的 MediaCodec 和 iOS 的 VideoToolbox 是硬编，直接调用手机内置芯片，速度极快且省电。FFmpeg (X264/X265) 是软编，消耗 CPU。

• 音频编码（Audio Encoding）：

  • 主流格式：AAC (Advanced Audio Coding)。将高频、低频以及人耳听不到的声音剃除，高保真压缩。

• ⚠️ 避坑指南：

  • 合理设置 GOP（画面组）：GOP（I帧间隔）要设置在 1~2 秒。如果主播画面静止，部分硬编码器会自动拉长 GOP，导致观众进直播间时拿不到关键帧（I帧）而长时间黑屏。必须配置强制产生 I 帧的周期。

四、 推流（Streaming）：长途运输

将编码好的音视频数据，按照特定的网络协议“打包”并“发送”到 CDN（内容分发网络）的边缘节点。

• 数据封装（Muxing）：

  • 把编码出来的 H.264 裸流（NALU 数组）和 AAC 音频流，打包成特定格式（如 FLV 标签 或 RTMP 报文），并且为它们打上严格对齐的 PTS（显示时间戳）。

• 传输协议：

  • RTMP：最经典。基于 TCP，可靠、兼容性无敌，但弱网下容易产生丢包重传造成的严重堆积。

  • SRT / WebRTC（快直播）：现代主流。基于 UDP，自带 FEC（前向纠错）和 ARQ（丢包重传机制），延迟可以从 RTMP 的 3~5 秒压缩到 1 秒以内。

• 工程核心：非阻塞队列：

  • 推流不能在编码线程同步做。必须把打包好的数据丢入一个发送 Buffer 队列。由专门的 Socket 发送线程去异步读取。

• ⚠️ 避坑指南：

  • 时间戳溢出与错乱：音视频的时间戳起点必须一致（通常从 0 开始计数），如果音视频时间戳差值超过 100ms，观众端就会出现音画不同步或画面一卡一卡的现象。

🌟 总结架构图

【采集端】 ──(OES 纹理/PCM)──> 【预处理（GPU）】 ──(2D 纹理)──> 【编码器（硬编）】 ──(NALU/AAC)──> 【推流队列（内存）】 ──(RTMP/UDP)──> 【CDN节点】
  Camera                                OpenGL                         MediaCodec                       Muxer 打包                        Socket 发送
  Microphone                                                            VideoToolbox                     环形缓冲区缓冲区