应使用AVIOInterruptCB中断回调配合原子标志控制avformat_open_input阻塞退出：必须在调用前设置interrupt_callback，回调中读取std::atomic并返回1终止；RTSP/TCP下还需结合socket超时与timeout选项双重保障，且需确保内存序正确。
avformat_open_input 阻塞时怎么安全退出
直接杀线程或 close socket 会导致内存泄漏、资源未释放，甚至 FFmpeg 内部状态错乱。根本解法是让 avformat_open_input 主动放弃连接尝试，而不是强行中断。
FFmpeg 从 4.0 开始支持自定义 AVIOContext + 中断回调，这是唯一可控且线程安全的方式：
- 创建一个
AVIOInterruptCB回调函数，在其中检查用户设定的原子标志（如std::atomic）stop_requested - 把回调挂到
AVFormatContext的interrupt_callback字段上，**必须在调用avformat_open_input前设置** - 注意：该回调会被 FFmpeg 在每次 I/O 操作前轮询调用，不是仅一次；返回非零值即中止当前操作
示例关键片段：
std::atomic<bool> stop_flag{false};
AVIOInterruptCB int_cb = {
[](void* opaque) -> int {
return static_cast<:atomic>*>(opaque)->load() ? 1 : 0;
},
&stop_flag
};
<p>AVFormatContext* fmt_ctx = avformat_alloc_context();
fmt_ctx->interrupt_callback = int_cb;</p>
<p>int ret = avformat_open_input(&fmt_ctx, url, nullptr, nullptr);
if (ret </p></:atomic></bool>
RTSP/TCP 模式下超时与中断双重控制
单纯依赖 interrupt_callback 可能不够快——比如 DNS 解析卡住、TCP SYN 重传等待期间，回调根本不会被触发。这时需要底层 socket 层配合。
解决方案是接管 IO：用 avio_open2 构造自定义 AVIOContext，手动创建带超时的 socket（Linux 用 setsockopt(SO_RCVTIMEO)，Windows 用 setsockopt(SO_SNDTIMEO)），再传给 RTSP 协议栈。
- 启用
-rtsp_transport tcp参数（对应代码中设置AVDictionary* opts的"rtsp_transport"为"tcp"） - 通过
av_dict_set(&opts, "timeout", "5000000", 0)设置微秒级超时（注意单位！5000000 = 5 秒） - 该 timeout 对 TCP 连接建立和读写都生效，但不替代
interrupt_callback——两者要同时使用
av_read_frame 被阻塞时如何响应中断
拉流开始后，av_read_frame 可能在网络卡顿、服务器静默时无限等待。它同样受 interrupt_callback 控制，但有个关键前提：
- 必须确保
AVFormatContext的interrupt_callback在avformat_open_input后**未被覆盖或清空**（某些封装库会重置它） - 若使用
avformat_find_stream_info，它内部也会调用av_read_frame，所以中断回调需全程有效 - 调用
av_read_frame返回AVERROR(EAGAIN)或AVERROR_EOF是正常流程；返回AVERROR_EXIT才表示被中断回调主动终止
常见误操作：在子线程里只设置一次回调，但主线程修改了 stop_flag，而子线程没做 memory order 保证 → 加 memory_order_acquire 读取。
多线程环境下 stop_flag 的可见性陷阱
最隐蔽的问题不是 FFmpeg API 本身，而是 C++ 内存模型导致的标志读取失效。即使你在主线程设了 stop_flag.store(true)，工作线程里的回调仍可能永远读到 false。
- 必须用
std::atomic，不能用普通 bool + volatile（volatile 不提供跨线程同步语义） - 回调函数内读取用
load(std::memory_order_acquire)，主线程写入用store(true, std::memory_order_release) - 如果使用
std::condition_variable配合，注意 notify 时机要在 flag 修改之后，且唤醒后仍需再次检查 flag
没有原子同步保障的中断，90% 的情况下看似“能用”，实则在高负载或特定 CPU 架构下必现假死。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
