音视频开发实战路径：Linux内核、C++流水线与FFmpeg源码深度解析

1. 这条学习路线不是“从零开始”，而是“从踩坑开始”

音视频开发这个领域，我带过不下三十个转行过来的工程师，有做Java后端三年想跳槽的，有嵌入式干了五年想往多媒体方向靠的，也有刚毕业手握C++成绩单但连ffmpeg -i input.mp4 -c:v libx264 -b:v 1M output.mp4都跑不通的新手。他们共同的问题不是“学不会”，而是“不知道该学什么、为什么这么学、以及学完之后到底能干什么”。市面上那些标着“音视频开发入门”的教程，90%都在教你怎么编译FFmpeg、怎么用avcodec_open2()打开一个解码器——可没人告诉你：为什么必须先理解Linux进程调度对实时音视频帧处理的影响？为什么WebRTC的NACK机制在千兆局域网里反而比PLI更耗CPU？为什么你写的C++解封装代码在Ubuntu 22.04上跑得好好的，一放到ARM64的国产Linux板子上就段错误？

这不是理论空谈。去年我帮一家做教育直播硬件的团队重构推流模块，他们原来的方案是用Node.js调用FFmpeg CLI做RTMP推流，结果在高并发场景下，CPU飙到95%，延迟从800ms拉到3.2秒。问题根源根本不在FFmpeg参数，而在Node.js事件循环和LinuxO_NONBLOCKsocket读取之间的竞争——当网络抖动导致RTMP chunk接收不连续时，Node.js主线程被阻塞，整个音视频流水线就卡死。最后我们用C++重写了核心IO层，把socket读取、NALU切分、时间戳校准全部下沉到epoll+线程池模型里，延迟压到320ms以内，CPU占用降到42%。这个过程里，C++不是用来炫技的，而是解决Linux内核态与用户态数据搬运效率瓶颈的刚需；FFmpeg不是拿来当黑盒调用的，而是你必须亲手改它的libavformat/rtmp.c才能绕过某个特定CDN厂商的私有协议扩展；WebRTC也不是只配配RTCPeerConnection配置项就完事的，你得看懂webrtc/src/modules/rtp_rtcp/source/ulpfec_receiver.cc里那个FEC包重组的滑动窗口逻辑，否则丢包率一过15%画面就雪花满屏。

所以这篇路线图，不按“语言→库→框架”这种教科书顺序排，而是按真实项目里你每天要面对的问题链来组织：从第一行代码运行在哪个OS上开始，到最后一帧画面稳定输出到终端屏幕为止。它不承诺“三个月成为专家”，但保证你每走一步，都知道这步踩在哪个技术断层上、为什么非跨不可、跨过去之后能接住什么级别的需求。如果你现在正对着./configure --enable-shared --disable-static --prefix=/usr/local命令发呆，或者纠结该先啃《深入理解计算机系统》还是直接抄WebRTC的PeerConnection示例，那接下来的内容，就是为你省掉至少六个月的试错时间。

2. Linux：不是运行环境，而是音视频开发的“操作系统内核”

很多人把Linux当成“一个能跑FFmpeg的系统”，这是音视频开发最大的认知陷阱。实际上，Linux本身就是音视频开发的第一层API——你写的每一行C++代码，最终都要通过Linux内核提供的系统调用（syscall）与硬件打交道。而音视频数据流的特殊性（高吞吐、低延迟、强实时性），让Linux内核的几个关键子系统成了你必须亲手调试的“基础设施”。

2.1 文件系统与内存映射：为什么mmap()比fread()快3倍？

假设你要实现一个本地MP4文件的硬解播放器。常规做法是用fread()把文件数据一块块读进内存缓冲区，再交给解码器。但实测发现：在4K@60fps的H.265文件上，fread()的平均IO延迟高达12.7ms，而mmap()稳定在3.2ms以内。原因在于Linux的页缓存（page cache）机制：mmap()直接把文件物理页映射到进程虚拟地址空间，解码器访问数据时触发缺页中断（page fault），内核自动从磁盘加载对应页；而fread()需要经过VFS层、块设备驱动、DMA控制器多层拷贝，每次调用都有上下文切换开销。

提示：在嵌入式Linux设备（如RK3399）上，mmap()还能绕过CPU缓存一致性协议。我们曾用mmap()将摄像头YUV数据直接映射到GPU纹理内存，避免了memcpy()带来的额外带宽占用，帧率提升18%。

2.2 进程调度与实时优先级：SCHED_FIFO不是摆设

音视频流水线里最致命的延迟来源，往往不是算法本身，而是Linux默认的CFS（Completely Fair Scheduler）调度策略。比如一个音频采集线程，如果被标记为普通SCHED_OTHER优先级，在系统负载稍高时，可能被调度器挂起20ms以上——这对48kHz采样率的音频来说，意味着丢失960个采样点，必然触发Jitter Buffer重填，造成卡顿。

正确做法是用pthread_setschedparam()将关键线程设为SCHED_FIFO，并赋予足够高的sched_priority（通常设为50-80）。但注意：SCHED_FIFO线程一旦获得CPU，会一直运行直到主动让出或被更高优先级线程抢占。我们曾遇到一个bug：视频编码线程设为SCHED_FIFO后，因内部死循环未加usleep(1)，导致整个系统无响应。解决方案是在循环体中插入nanosleep()，并确保所有SCHED_FIFO线程都有明确的退出路径。

2.3 网络栈与零拷贝：sendfile()如何把RTMP推流延迟砍掉40%

RTMP推流的核心瓶颈常在内核态到用户态的数据拷贝。传统方式：read()从socket读取数据→write()写入文件/内存→再send()发出去，经历三次内存拷贝。而sendfile()系统调用允许内核直接把文件描述符A的数据，通过DMA引擎搬移到socket描述符B的发送队列，全程不经过用户态内存。

实测对比（1080p@30fps RTMP流）：

注意：sendfile()要求源文件描述符支持mmap()（如普通文件），且目标socket需启用TCP_NODELAY。在ZLMediaKit这类服务中，sendfile()被用于TS切片分发，但RTMP chunk发送仍需自定义IO模型——因为RTMP协议要求chunk header必须动态计算，无法直接sendfile()。

2.4 设备驱动与V4L2：摄像头数据不是“即插即用”

很多新手以为cv::VideoCapture(0)就能拿到摄像头数据，但在工业场景中，这行代码背后是Linux V4L2（Video for Linux 2）驱动框架的完整握手流程：

1. open("/dev/video0")触发内核加载对应摄像头驱动（如ov5640、gc2053）
2. ioctl(fd, VIDIOC_QUERYCAP, &cap)查询设备能力（是否支持MJPEG/YUYV/H264）
3. ioctl(fd, VIDIOC_S_FMT, &fmt)设置输出格式（分辨率、像素格式、帧率）
4. ioctl(fd, VIDIOC_REQBUFS, &req)申请DMA缓冲区（通常3-4个buffer环形队列）
5. mmap()将每个buffer映射到用户空间，ioctl(fd, VIDIOC_QBUF, &buf)入队
6. poll()等待POLLIN事件，ioctl(fd, VIDIOC_DQBUF, &buf)出队获取数据

我们曾在一个国产ARM平台遇到问题：摄像头驱动只实现了VIDIOC_S_FMT但没实现VIDIOC_ENUM_FMT，导致OpenCV无法枚举支持的格式，set(CV_CAP_PROP_FOURCC)始终失败。最终方案是绕过OpenCV，直接用V4L2 API手动设置v4l2_format.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV，再通过libyuv做YUYV→NV12转换供H.264编码器使用。

3. C++：不是语法练习，而是构建音视频流水线的“钢筋骨架”

音视频开发中的C++，绝不是刷LeetCode式地练std::vector和shared_ptr。它是一套精密的工程实践体系：既要对抗内存泄漏这种“慢性病”，又要预防std::move()误用导致的“猝死式崩溃”。下面这些细节，都是我在ZLMediaKit二次开发、FFmpeg源码魔改、WebRTC Native层集成中反复验证过的硬核经验。

3.1 RAII与资源生命周期：为什么AVFormatContext*不能裸指针管理？

FFmpeg的C风格API（如avformat_open_input()返回AVFormatContext*）极易引发资源泄漏。常见错误写法：

AVFormatContext* fmt_ctx = nullptr; avformat_open_input(&fmt_ctx, "input.mp4", nullptr, nullptr); // ... 处理逻辑 avformat_close_input(&fmt_ctx); // 忘记调用？内存泄漏！

正确做法是封装RAII类：

class FFmpegFormatContext { private: AVFormatContext* ctx_ = nullptr; public: FFmpegFormatContext(const char* url) { int ret = avformat_open_input(&ctx_, url, nullptr, nullptr); if (ret < 0) throw std::runtime_error("avformat_open_input failed"); } ~FFmpegFormatContext() { if (ctx_) avformat_close_input(&ctx_); } // 禁止拷贝，允许移动 FFmpegFormatContext(const FFmpegFormatContext&) = delete; FFmpegFormatContext& operator=(const FFmpegFormatContext&) = delete; FFmpegFormatContext(FFmpegFormatContext&& other) noexcept : ctx_(other.ctx_) { other.ctx_ = nullptr; } AVFormatContext* get() const { return ctx_; } };

这样即使函数中途抛异常，析构函数也会自动释放资源。更重要的是，移动语义让你能在pipeline中安全传递上下文：

auto demuxer = std::make_unique<FFmpegFormatContext>("input.mp4"); auto decoder = std::make_unique<FFmpegDecoder>(std::move(demuxer)); // demuxer自动置空

3.2 内存对齐与SIMD加速：alignas(32)不是装饰品

H.264解码中的IDCT（反离散余弦变换）和运动补偿，大量使用SSE/AVX指令。这些指令要求操作数内存地址必须16/32字节对齐，否则触发SIGBUS信号。FFmpeg内部用av_malloc()分配内存，它默认按32字节对齐，但你自己申请的缓冲区呢？

错误示范：

uint8_t* yuv_data = new uint8_t[width * height * 3 / 2]; // 可能不对齐！

正确写法（C++17）：

alignas(32) uint8_t yuv_data[width * height * 3 / 2]; // 栈上分配，强制对齐 // 或堆上分配 uint8_t* yuv_data = static_cast<uint8_t*>(aligned_alloc(32, size)); // 使用后必须 aligned_free(yuv_data)

我们在优化一个4K解码器时，仅通过alignas(32)修复内存对齐，AVX2加速的IDCT函数性能提升23%——因为CPU不再需要额外指令做地址对齐检查。

3.3 多线程与无锁队列：为什么std::queue在音视频流水线里是毒药？

音视频流水线天然需要多线程协作：采集线程→编码线程→网络发送线程。但std::queue配合std::mutex的锁保护，在高吞吐场景下会成为瓶颈。实测1080p@60fps流，std::queue的push()/pop()平均耗时达1.8μs，而无锁队列（如moodycamel::ConcurrentQueue）稳定在0.3μs。

更关键的是锁的副作用：当编码线程因mutex.lock()阻塞时，采集线程仍在持续写入数据，若缓冲区满则必须丢帧。而无锁队列通过CAS（Compare-And-Swap）原子操作，让生产者/消费者完全异步，丢帧决策由队列容量策略控制，而非线程调度。

我们的实战方案：

// 使用 moodycamel::ConcurrentQueue 实现帧队列 moodycamel::ConcurrentQueue<std::unique_ptr<AVFrame>> frame_queue{1024}; // 生产者（采集线程） frame_queue.enqueue(std::move(frame)); // 消费者（编码线程） std::unique_ptr<AVFrame> frame; if (frame_queue.try_dequeue(frame)) { encode_frame(frame.get()); }

3.4 ABI兼容性与动态链接：-fPIC和-D_GLIBCXX_USE_CXX11_ABI=0的血泪教训

当你把自研的音视频SDK打包成.so供其他团队调用时，ABI（Application Binary Interface）不一致会导致诡异崩溃。典型场景：你的SDK用GCC 11编译（默认C++11 ABI），而客户项目用GCC 9（旧ABI），std::string的内存布局不同，传参时std::string对象被截断。

解决方案有二：

1. 统一工具链：强制所有团队使用相同版本GCC/Clang，并在CMakeLists.txt中声明：

   set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_compile_options(-fPIC -D_GLIBCXX_USE_CXX11_ABI=0) # 兼容旧ABI

2. C接口封装：所有对外API用纯C函数，内部用C++实现。例如：

   // sdk.h typedef struct AVCodecContext AVCodecContext; extern "C" { AVCodecContext* create_encoder(const char* codec_name); int encode_frame(AVCodecContext* ctx, uint8_t* yuv_data, int width, int height); void destroy_encoder(AVCodecContext* ctx); }

   这样彻底规避C++ ABI问题，且方便Java/Python通过JNI/ctypes调用。

4. FFmpeg：不是命令行工具，而是音视频开发的“瑞士军刀内核”

网上90%的FFmpeg教程停留在ffmpeg -i input.mp4 -vf scale=640:480 output.mp4，但这只是冰山一角。真正决定你能否搞定复杂需求的，是深入libavcodec、libavformat、libswscale三大核心库的源码逻辑。下面这些实战案例，来自我们为某车企定制车载DVR系统的经历。

4.1 解封装（Demuxing）：如何从RTSP流中精准提取H.264 Annex B NALU？

RTSP流的H.264数据通常以RTP包传输，每个RTP payload包含一个或多个NALU（Network Abstraction Layer Unit），但FFmpeg默认的AVPacket只提供原始payload，你需要自己解析RTP头、提取NALU、并按Annex B格式（0x00000001前缀）组装。

关键步骤：

1. 创建自定义AVInputFormat，重写read_packet()函数
2. 在read_packet()中解析RTP头（RFC 3550），提取payload_type和sequence_number
3. 对H.264 payload，根据start_code_prefix（0x00000001或0x000001）分割NALU
4. 将每个NALU前缀补全为4字节0x00000001，写入AVPacket.data

我们曾遇到某海康IPC的私有RTSP流，其RTP payload不遵循标准H.264打包规则，nal_unit_type字段被篡改。最终方案是绕过FFmpeg的h264_rtp解复用器，用libsrtp直接解析RTP，再手动构造AVPacket。

4.2 编解码（Codec）：为什么avcodec_send_packet()必须配对avcodec_receive_frame()？

FFmpeg 3.0+的编码/解码API采用“推送-拉取”模型，这是为支持异步硬件加速（如Intel QSV、NVIDIA NVENC）设计的。常见错误是只调avcodec_send_packet()不调avcodec_receive_frame()，导致内部缓冲区堆积，最终send_packet()返回AVERROR(EAGAIN)。

正确流程（解码为例）：

// 发送压缩数据包 int ret = avcodec_send_packet(dec_ctx, &pkt); if (ret < 0 && ret != AVERROR(EAGAIN)) { // 错误处理 } // 循环拉取解码帧（可能一次send对应多次receive） while (ret >= 0) { ret = avcodec_receive_frame(dec_ctx, frame); if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) break; if (ret < 0) { /* 错误处理 */ } // 处理frame }

注意：avcodec_receive_frame()可能返回AVERROR(EAGAIN)，表示内部缓冲区暂无完整帧，需等待下次send_packet()。这与旧版avcodec_decode_video2()的同步模型完全不同。

4.3 转码（Transcoding）：如何用libswscale实现YUV420P→RGB24的零拷贝转换？

libswscale的sws_scale()函数默认会分配新内存存储转换结果，但在嵌入式设备上，频繁malloc/free会引发内存碎片。我们的优化方案是预分配RGB缓冲区，并让sws_scale()直接写入：

// 预分配RGB缓冲区（32字节对齐） alignas(32) uint8_t rgb_data[width * height * 3]; uint8_t* rgb_planes[] = {rgb_data, nullptr, nullptr, nullptr}; int rgb_linesizes[] = {width * 3, 0, 0, 0}; // 创建SWS上下文（只创建一次） struct SwsContext* sws_ctx = sws_getContext( width, height, AV_PIX_FMT_YUV420P, width, height, AV_PIX_FMT_RGB24, SWS_BILINEAR, nullptr, nullptr, nullptr); // 转换（直接写入预分配内存） sws_scale(sws_ctx, yuv_planes, yuv_linesizes, 0, height, rgb_planes, rgb_linesizes);

实测在RK3399上，预分配方案比每次malloc快1.7倍，且避免了内存分配失败风险。

4.4 自定义协议（Custom Protocol）：如何让FFmpeg支持私有RTMP扩展？

某CDN厂商要求RTMP连接时携带自定义auth_token参数，标准FFmpeg不支持。解决方案是注册自定义URLProtocol：

static int my_rtmp_open(URLContext* h, const char* filename, int flags) { // 解析filename中的auth_token char token[256]; parse_auth_token(filename, token); // 调用原生rtmp_open，但修改connect参数 return original_rtmp_open(h, modified_url, flags); } static const URLProtocol my_rtmp_protocol = { .name = "myrtmp", .url_open = my_rtmp_open, // ... 其他函数指针 }; // 注册协议 av_register_protocol(&my_rtmp_protocol);

然后用myrtmp://host/app/stream?token=xxx即可调用你的协议。这比修改FFmpeg源码更安全，且便于升级。

5. WebRTC：不是“浏览器里的音视频”，而是实时通信的“协议操作系统”

WebRTC常被误解为“前端技术”，但它真正的价值在于其底层协议栈（STUN/TURN/DTLS/SRTP/RTP/RTCP）构成了一套完整的实时通信操作系统。你在Chrome里看到的RTCPeerConnection，只是这个操作系统的“图形界面”。要真正掌控质量，必须深入libwebrtc的C++层。

5.1 网络层：为什么TURN服务器不是“万能中继”，而是最后防线？

STUN用于NAT穿透，TURN用于中继。但很多团队盲目部署TURN，导致带宽成本飙升。实际策略应是：

• 第一优先级：P2P直连（通过STUN获取公网IP+端口）
• 第二优先级：UDP打洞失败时，尝试TCP打洞（WebRTC支持TCP候选者）
• 第三优先级：仅当UDP/TCP均失败时，才启用TURN

我们在教育直播项目中发现：78%的用户能通过STUN直连，15%通过TCP打洞成功，仅7%需要TURN。TURN带宽成本是STUN的20倍以上，必须严格限制其使用。

提示：WebRTC的iceTransportPolicy可设为relay强制TURN，但生产环境应设为all，让ICE框架自动选择最优路径。

5.2 媒体层：MediaStreamTrack背后的“轨道工厂”模式

MediaStreamTrack不是简单的音视频流容器，而是一个可动态切换的“轨道工厂”。例如，你想在会议中切换摄像头，不是销毁重建RTCPeerConnection，而是：

// 获取新摄像头轨道 navigator.mediaDevices.getUserMedia({video: true}) .then(stream => { const newTrack = stream.getVideoTracks()[0]; // 替换现有轨道 sender.replaceTrack(newTrack); });

replaceTrack()会触发ontrack事件，远端自动接收新轨道，无需重新协商SDP。这比传统的“停止-重启”方案延迟降低90%。

5.3 拥塞控制：GCC（Google Congestion Control）如何动态调整码率？

WebRTC的拥塞控制算法（GCC）是其低延迟的核心。它通过RTCP Receiver Report（RR）反馈的丢包率、到达时间间隔（jitter）、往返时延（RTT），实时计算可用带宽（BWE）。关键参数：

我们在弱网测试中发现：将max_bitrate_bps从3000k降至1500k，可使5%丢包率下的卡顿率从32%降至8%。

5.4 数据通道（DataChannel）：不只是“传文本”，而是实时信令的“高速公路”

RTCDataChannel常被用于传输聊天消息，但它真正的优势在于超低延迟的二进制数据传输。我们用它实现远程桌面控制指令（键盘鼠标事件），延迟稳定在15ms以内，远优于HTTP轮询（200ms+）。

关键配置：

const config = { ordered: false, // 允许乱序，降低延迟 maxRetransmits: 0, // 关闭重传，用应用层ACK protocol: 'binary' // 二进制协议，避免base64编码开销 }; const dc = pc.createDataChannel('control', config);

注意：ordered: false意味着数据包可能乱序到达，需在应用层添加序列号（sequence number）和去重逻辑。

6. 工程落地：从Demo到量产的“五道关卡”

写个能跑通的Demo只需一天，但让音视频模块在百万级用户产品中稳定运行，要闯过五道硬核关卡。这些不是理论，而是我们交付23个音视频项目后总结的“血泪清单”。

6.1 第一关：跨平台构建——CMake不是“写个hello world”，而是“构建矩阵”

音视频SDK必须支持Windows/Linux/macOS/Android/iOS，而每个平台的构建约束完全不同：

• Windows：VS2019+需启用/MDd（Debug）或/MD（Release）运行时库，且FFmpeg需静态链接libiconv
• Linux ARM64：必须交叉编译，--arch=aarch64 --cross-prefix=aarch64-linux-gnu-
• Android：NDK r21+要求APP_PLATFORM=android-21，且FFmpeg需禁用asm（--disable-asm）
• iOS：Xcode需设置VALID_ARCHS=arm64，且libavcodec需开启--enable-neon

我们的CMakeLists.txt核心片段：

# 根据平台自动选择架构 if(ANDROID) set(CMAKE_SYSTEM_NAME Android) set(CMAKE_ANDROID_NDK ${ANDROID_NDK}) set(CMAKE_ANDROID_ARCH_ABI arm64-v8a) elseif(IOS) set(CMAKE_SYSTEM_NAME iOS) set(CMAKE_OSX_ARCHITECTURES "arm64") endif() # FFmpeg构建选项 set(FFMPEG_CONFIGURE_ARGS "--prefix=${CMAKE_BINARY_DIR}/ffmpeg" "--enable-shared" "--disable-static" "--disable-doc" "--disable-programs" ) if(IOS OR ANDROID) list(APPEND FFMPEG_CONFIGURE_ARGS "--disable-asm") endif()

6.2 第二关：内存泄漏检测——valgrind不是“跑一次就行”，而是“每提交必跑”

音视频模块内存泄漏的隐蔽性极强。我们曾遇到一个bug：AVFrame的data[0]被av_frame_unref()释放，但data[1]（UV平面）因指针别名未被清理，导致每帧泄漏2MB。valgrind --tool=memcheck --leak-check=full是唯一可靠手段。

CI流水线强制规则：

• 所有音视频模块单元测试必须通过valgrind检测
• 内存泄漏阈值：definitely lost: 0 bytes，possibly lost: 0 bytes
• 检测覆盖：包括avcodec_open2()/avcodec_close()、sws_getContext()/sws_freeContext()等关键资源对

6.3 第三关：性能压测——不是“测单机”，而是“测网络拓扑”

音视频性能不能只看单机CPU占用，必须模拟真实网络拓扑：

• 上行链路：用tc（traffic control）限速tc qdisc add dev eth0 root tbf rate 2mbit burst 32kbit latency 300ms
• 下行链路：tc qdisc add dev eth0 root netem loss 5% delay 100ms
• 并发压力：用wrk -t10 -c100 -d30s https://api.example.com/push模拟100路推流

关键指标：

• 首帧延迟（TTFF）：≤800ms（4G网络）
• 端到端延迟：≤1500ms（含编码+网络+解码）
• 卡顿率：≤0.5%（连续2秒无帧视为卡顿）

6.4 第四关：日志与监控——不是“printf”，而是“结构化追踪”

音视频问题定位依赖精准日志。我们弃用printf()，采用spdlog+ 自定义sink：

• 日志分级：trace（NALU级操作）、debug（帧级事件）、info（会话级状态）、warn（丢帧/重传）、error（崩溃）
• 结构化字段：{"stream_id":"abc123","pts":123456,"dts":123400,"size":12800}
• 实时监控：日志通过syslog-ng转发到ELK，用Kibana看板监控error日志突增、warn日志趋势

6.5 第五关：合规与安全——不是“功能上线”，而是“过审上线”

音视频模块涉及敏感合规项：

• 国密算法：SM4加密媒体流，SM2签名SDP协商
• 等保要求：RTMP/WebRTC连接必须TLS 1.2+，禁用SSLv3
• 隐私保护：摄像头采集需用户显式授权（AndroidCAMERA权限+REQUEST_PERMISSIONS）
• 内容审核：对接阿里云/腾讯云音视频审核API，实时检测涉黄/涉政帧

我们在某政务视频会议系统中，因未启用SM4加密，被等保测评机构一票否决。最终方案是：在libwebrtc的DtlsTransport层注入SM4加解密钩子，确保所有DTLS握手数据经国密算法保护。

7. 学习路径执行建议：拒绝“收藏吃灰”，坚持“每日一帧”

这条路线图的价值，不在于你“知道”多少概念，而在于你“做过”多少帧的处理。我的建议是：用真实项目驱动学习，每天完成一个可验证的“最小闭环”。

7.1 第一周：Linux环境下的“第一帧”

目标：在Ubuntu 22.04上，用C++调用FFmpeg API，读取一个MP4文件的首帧，并保存为PNG。

• Day1：编译FFmpeg（./configure --enable-shared --prefix=/usr/local）
• Day2：写C++程序，调用avformat_open_input()打开文件
• Day3：找到视频流，调用avcodec_find_decoder()获取解码器
• Day4：解码首帧，用libswscale转换为RGB24
• Day5：用stb_image_write保存为PNG
• Day6：用perf分析热点，确认sws_scale()是否为瓶颈
• Day7：尝试用mmap()替代fread()，对比IO延迟

关键检查点：生成的PNG是否能正常打开？用ffprobe -v quiet -show_entries frame=pkt_pts_time input.mp4验证PTS时间戳是否匹配。

7.2 第二周：WebRTC的“第一个连接”

目标：用libwebrtcC++ API，实现两个进程间的P2P音视频通话。

• Day1：下载libwebrtc预编译库（https://github.com/aisouard/webrtc-builds）
• Day2：创建PeerConnection，配置STUN服务器
• Day3：实现CreateOffer/SetLocalDescription流程
• Day4：实现SetRemoteDescription/CreateAnswer流程
• Day5：添加MediaStreamTrack，捕获本地摄像头
• Day6：接收远端视频流，渲染到SDL窗口
• Day7：用Wireshark抓包，验证STUN Binding Request是否发出

关键检查点：Wireshark中是否看到STUN Binding Request？远端是否收到RTCP Sender Report？

7.3 第三周：性能优化的“第一次调优”

目标：将上述WebRTC demo的端到端延迟从2.1秒压到800ms以内。

• Day1：用chrome://webrtc-internals记录初始延迟数据
• Day2：调整start_bitrate_bps为1000k，观察BWE变化
• Day3：启用VP8的temporal_layers，测试分层编码效果
• Day4：在Linux上用tc模拟20%丢包，启用NACK
• Day5：将SCHED_FIFO应用于编码线程，测量调度延迟
• Day6：用perf record -e sched:sched_switch分析线程切换频率
• Day7：对比优化前后chrome://webrtc-internals的jitterBufferDelay曲线

关键检查点：jitterBufferDelay是否从1200ms降至300ms？pliCount是否显著减少？

这条路没有捷径，但每一步都算数。当你能独立写出一个在ARM64板子上稳定跑100小时的推流服务，当你能看懂webrtc/src/modules/audio_coding/neteq/normal.cc里那个自适应抖动缓冲算法，当你在客户现场用strace -p $(pidof your_app) -e trace=recvfrom,sendto三分钟定位出网络卡顿根因——你就不再是“学音视频开发的人”，而是“音视频开发者”了。