音视频同步不能只靠系统时钟，因硬件延迟差异大，必须以实际播放的音频帧位置为锚点；sdl2中需用堆分配的原子变量指针传入回调，线程安全更新与读取，避免栈变量、竞态和内存泄漏。
音视频同步为什么不能只靠系统时钟
因为不同设备的音频输出缓冲、视频渲染管线、硬件解码器延迟差异很大，单纯用 std::chrono::steady_clock 对齐时间戳会快速漂移。真正可行的同步点是「已实际播放的音频帧位置」——这必须通过音频后端回调拿到，而 C++ 多媒体框架（如 FFmpeg + SDL2 或 GStreamer C++ binding）通常只暴露裸指针接口来传递该信息。
如何用指针安全接收音频播放位置（以 SDL2 为例）
SDL2 的音频回调函数签名是 void audio_callback(void* userdata, Uint8* stream, int len)，其中 userdata 是你传入的任意指针。常见错误是直接传栈变量地址，比如 &playback_pos，回调执行时栈已销毁，读到的是垃圾值。
- 必须传堆分配或全局生命周期的对象地址，例如：
new std::atomic<int64_t>(0)</int64_t>或指向类成员的this - 在回调中更新时，务必用原子操作：
static_cast<:atomic>*>(userdata)->store(current_sample_pos, std::memory_order_relaxed)</:atomic> - 视频线程读取时也要用
load()，避免编译器优化掉重复读取 - 别忘了在退出前
delete堆指针，否则内存泄漏
用指针传递 AVSyncContext 结构体给解码线程
FFmpeg 解封装后，音视频流的时间基（time_base）、起始 DTS（start_time）必须统一管理。把同步状态封装成结构体，用指针跨线程共享比拷贝更高效，但要注意对齐和竞态。
- 结构体字段必须按访问频率排序，高频读写的字段（如
audio_pts、video_pts）放前面，减少 cache line 伪共享 - 所有跨线程读写字段都得是
std::atomic类型，不要用volatile—— 它不保证原子性也不约束内存序 - 初始化时用
memset(ptr, 0, sizeof(*ptr))清零，避免未初始化 padding 字节导致 memcmp 判定失败 - 如果用
std::shared_ptr<avsynccontext></avsynccontext>，确保所有线程持有时长覆盖整个播放周期，否则析构可能发生在回调中途
指针误用导致音画撕裂的典型现象与排查
画面卡顿但音频流畅，或音频突然跳帧，大概率是同步指针被多线程非安全修改。最隐蔽的坑是 SDL2 音频回调和主线程共用一个 AVSyncContext*，但没加锁又没用原子类型。
- 现象：
av_rescale_q计算出的视频显示时间突变为负数 → 检查audio_pts是否被其他线程覆写为 0 或极大值 - 现象：画面每 2 秒闪一次 → 指针指向的缓冲区被提前
av_frame_unref()，后续解码写入越界 - 用 AddressSanitizer 编译，运行时捕获
heap-use-after-free或data-race报告，比加日志更快定位 - 别依赖
std::this_thread::sleep_for补偿偏移——它无法对抗硬件调度抖动，应改用基于音频时钟的动态插帧/丢帧逻辑
音视频指针同步的本质不是“让两个时间数字相等”，而是让视频帧的显示时机始终锚定在音频已推进的真实位置上。这个锚点只能通过回调里的指针传递，而它的生命周期、内存序、线程可见性，任何一个环节出问题，偏移就会指数级放大。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
