视频和音频从采集到最终呈现的完整过程，是一个涉及数据流处理的复杂系统。虽然两者处理的物理信号不同，但整体架构都遵循“采集 -> 预处理 -> 编码 -> 传输 -> 解码 -> 渲染”的核心链路。以下是分别针对视频和音频的详细解析：
一、 视频的处理全流程
视频处理的核心在于处理庞大的图像数据量，并通过压缩和传输协议实现高效、低延迟的呈现。
采集 (Capture)：一切始于摄像头等光学设备。传感器（Sensor）将光学信号转化为原始的电信号（如RAW Bayer格式），此时数据仅记录了亮度信息，还不是完整的彩色图像。
预处理 (Pre-processing)：原始数据会经过ISP（图像信号处理器）进行去马赛克、白平衡、降噪等处理，输出YUV等格式。随后，还会进行美颜、滤镜、畸变矫正等端侧图像处理，以提升画面观感。
编码 (Encoding)：由于原始视频数据量极大（例如1080P视频每秒可达上百兆），必须通过H.264、H.265等算法进行压缩。编码过程会利用帧内压缩和帧间预测（I帧、P帧、B帧）技术，大幅剔除冗余信息，降低数据体积。
封装与传输 (Container & Transport)：编码后的数据（ES流）会被打包进MP4、FLV、TS等“容器”中，并附加时间戳等元数据。随后，通过RTMP、WebRTC、HLS等网络协议，以数据流或分片的形式推送到服务器或客户端。
解码 (Decoding)：接收端首先进行“解封装”，分离出音视频压缩数据。接着，通过硬件或软件解码器将压缩数据还原为原始的YUV图像帧。在此阶段，系统会根据PTS（显示时间戳）和DTS（解码时间戳）进行音视频同步，确保声画对齐。
渲染显示 (Rendering)：解码后的YUV数据会被转换为屏幕显示的RGB色彩空间。随后，端侧利用GPU等算力进行最终的画质增强、缩放等处理，并将图像帧推送到显存，最终在屏幕上逐帧显示出来。
二、 音频的处理全流程
音频处理的核心在于将连续的声波转化为数字信号，并在保证听感的前提下进行高效传输与空间还原。
采集 (Capture)：麦克风将空气中的机械声波振动转化为连续的模拟电信号。
预处理 (Pre-processing)：模拟信号经过ADC（模数转换器）进行采样和量化，变成离散的数字PCM数据。同时，系统会执行3A算法（AEC回声消除、ANS降噪、AGC自动增益），以净化人声并提升通话质量。
编码 (Encoding)：为了节省带宽，PCM数据会通过AAC、Opus、MP3等编码器进行压缩。编码器会利用人耳的听觉掩蔽效应，去除“听不见”的频率信息，在音质和文件大小之间取得平衡。
封装与传输 (Container & Transport)：编码后的音频流同样会被封装，并通过网络协议传输。对于实时互动场景（如WebRTC），通常采用UDP/RTP协议以降低延迟；对于点播或直播，则可能采用HLS等分片传输协议。
解码 (Decoding)：接收端接收到数据包后，经过缓冲和抗丢包处理（如FEC前向纠错），由解码器将压缩数据还原为PCM数字音频信号。
渲染显示 (Rendering)：音频的“渲染”是指将数字信号转化为物理声音。对于沉浸式音频（如Dolby Atmos），渲染器会根据元数据和当前设备的扬声器布局（或耳机双耳模型），计算出每个声源在3D空间中的位置和增益。最后，数字信号通过DAC（数模转换器）还原为模拟电信号，驱动扬声器或耳机振动发声。
三、推流端（如 WebRTC）的采集同步
在 WebRTC 等实时音视频通信中，推流端的采集同步是解决音画不同步的第一道关卡。与点播文件不同，实时推流没有预先封装好的时间戳，因此推流端必须自行建立并维护一个统一的时间基准。
推流端采集同步的核心原理可以总结为：“统一时钟源 + 协议映射对齐”。以下是具体的实现机制与难点解析：
1. 核心前提：统一采集时钟源
在采集阶段，必须确保音频设备（如麦克风）和视频设备（如摄像头）使用的是系统启动后的同一个单调递增时钟源（Monotonic Clock），绝对避免使用可能回跳的墙上时间（Wall Clock）。如果底层硬件驱动使用了独立的时钟源，从源头上就会产生无法挽回的偏差。
2. 时间戳的生成与映射（RTP + RTCP）
由于音频和视频在 WebRTC 中是作为独立的流进行传输的，它们各自拥有独立的时钟频率（例如音频通常为 48kHz，而视频 RTP 时间戳遵循惯例使用 90kHz）。为了让接收端能将它们对齐，推流端依赖 RTP 和 RTCP 协议的配合：
RTP 时间戳：推流端在采集和编码后，为每一帧音视频数据打上基于各自采样率递增的 RTP 时间戳。
RTCP SR（Sender Report）映射：推流端会周期性地发送 RTCP SR 报告。这个报告的核心作用是将当前的 RTP 时间戳与绝对时间（NTP 墙钟时间）进行绑定映射。接收端正是利用这些映射关系，将音视频流对齐到同一个绝对时间轴上，从而防止时钟漂移的无限累积。
3. 推流端面临的“异步”挑战
即便时钟源统一，推流端在工程实现上依然面临巨大的挑战，因为音视频的采集与编码管线是完全独立的：
硬件时钟漂移（Clock Drift）：摄像头和麦克风由不同的物理振荡器驱动。消费级硬件的振荡器通常存在 20 到 100 ppm（百万分之）的频率误差。这意味着即使没有任何网络问题，经过 10 分钟的通话，两个硬件之间也可能累积出 30ms 的相对漂移，超过一小时就会达到人耳能明显察觉的 180ms。
编码耗时不对称：音频编码（如 Opus）极其轻量且耗时稳定，通常不到 1ms 就能处理完 20ms 的音频帧；而视频编码（如 VP8/H.264）则非常耗时且波动剧烈。例如，遇到画面剧烈运动或场景切换触发 I 帧（关键帧）编码时，视频编码耗时可能会激增到 20ms 以上。这种编码管线上的耗时差异，会导致音视频数据包在推流端打包发送时就已经产生了错位。
综上所述，推流端的采集同步不仅仅是打个时间戳那么简单，它需要底层硬件时钟的协同、编码管线的性能优化，以及 RTCP 协议的周期性校准，才能确保送到网络传输层的数据在时间轴上是基本对齐的。