FFmpeg中AVPacket/AVFrame需手动管理生命周期，依赖引用计数；音视频同步关键在正确设置PTS/DTS；SDL2简化跨平台渲染与音频播放；WebRTC强制异步回调与所有权明确。
FFmpeg核心结构体的生命周期必须手动管理
AVPacket 和 AVFrame 不是普通 C++ 对象，没有析构函数，不遵循 RAII。它们内部靠引用计数（refcount）控制资源归属，误用 new/delete 或裸指针拷贝会直接导致 double free、内存泄漏或野指针崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 分配用
av_packet_alloc()/av_frame_alloc()，不是new - 拷贝必须用
av_packet_ref()/av_frame_ref()，不能memcpy或结构体赋值 - 释放必须配对调用
av_packet_unref()/av_frame_unref()，不是av_packet_free()（后者只在 alloc 后未 ref 时才该用） - 多线程间传递前，确保已调用 ref；线程退出前，必须 unref
音视频同步本质是 PTS/DTS 时间轴对齐
花屏、音画不同步、卡顿，80% 源于时间戳处理错误。FFmpeg 中 AVPacket 的 dts（解码时间戳）、pts（显示时间戳）和 AVFrame 的 pts 并非自动生成，尤其在采集+编码流程中，常为 AV_NOPTS_VALUE，需手动计算并写入。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 采集端（如 V4L2/AVCapture）输出原始帧时，应记录系统时间（
clock_gettime(CLOCK_MONOTONIC, &ts)），转为微秒后作为初始 pts - 编码后，
avcodec_send_frame()→avcodec_receive_packet()流程中，pkt->pts和pkt->dts通常为空，需根据输入帧 pts + 编码器 delay 推算（例如 H.264 B 帧会导致 dts - 封装进 MP4/FLV 时，
AVFormatContext依赖pkt->pts做 muxer 内部时钟对齐，若全为 -1，muxer 会强行插值，导致跳帧或堆积
SDL2 是跨平台渲染与音频播放的事实标准胶水层
不用 SDL2 直接调 OpenGL/Vulkan 或 Win32 GDI/QuartzCore，等于主动给自己加 500 行平台适配代码。它不负责编解码，但解决了音视频开发中最琐碎也最易出错的一环：把解码后的 AVFrame（YUV）或 PCM 数据，以低延迟、线程安全的方式送到屏幕和声卡。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 视频渲染必走
SDL_Texture+SDL_UpdateYUVTexture()（YUV420P）或SDL_UpdateTexture()（RGB），别自己映射显存 - 音频播放用
SDL_OpenAudioDevice()注册回调函数，在回调里从队列取 PCM 数据填充stream缓冲区，切勿阻塞主线程 -
SDL_PushEvent()是主线程与音视频线程通信的唯一安全方式，避免全局变量或裸 mutex 争用 - 初始化顺序必须是：
SDL_Init()→SDL_CreateWindow()→SDL_CreateRenderer()，漏掉任一环节在 macOS 上可能黑屏无报错
WebRTC 的 C++ API 天然排斥“一次性写完”式开发
WebRTC 的 webrtc::PeerConnectionInterface 等核心类全部基于抽象接口 + 工厂方法 + 异步回调设计。所有操作（create offer、set remote description、add ICE candidate）都返回 void，结果通过 Observer 回调通知。这不是风格问题，而是为应对网络不可靠性做的强制约束。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每个
PeerConnection必须绑定独立的webrtc::PeerConnectionObserver实现，且 observer 生命周期不得早于 connection - 信令交换（offer/answer）和 ICE candidate 传输必须走同一条可靠通道（如 WebSocket），但 WebRTC 本身不提供该通道，需你自行实现并桥接到
SetLocalDescription等调用 - 媒体轨道（
webrtc::VideoTrackInterface）的 source 必须继承webrtc::VideoTrackSource并重写state()和remote()，否则 Android/iOS 上无法采集摄像头 - 调试时务必开启
RTC_LOGS=3环境变量，日志里LogMessage输出的ssrc、rtt、jitter_buffer_delay_ms是定位卡顿/花屏的第一手依据
