c++ std::map 多线程肯定要加锁啊，修改也要加锁啊，增加肯定也要加锁啊.

自动调用图表？没这么智能的 ide 吧，有很多运行时决定的调用关系根本没法静态全分析吧。
看代码只要有全局搜功能，声明，实现跳转，find all reference 这些功能就够了，这个任何 ide，或编辑器像 vscode 加个插件就能实现了。
其它的分析还是要靠理解，文档，业务逻辑和调试日志了。

你这个和 std::async + future 用法有点像的

你都知道崩溃当时是空指针了，肯定是某个线程改了，这个看代码就可以解决了吧。coredump 应该是崩溃时的虚拟内存映射。

是做播放器还是混流? 同步的唯一参考就是时戳啊.你这个方法没太看懂,音视频时戳都是恒定均匀吗,这种整体除法做步进不太靠谱吧
以 ffplay 中视频同步到音频的原理来说,就是一定周期往声卡喂音频 samples 数据,以 lc-aac 为例子,解码后一帧 1024 个 samples,假设当前播放到第 5 帧内的第 100 个 samples,计算时间则是<第五帧的 pts+duration of 100 samples>得出一个时间,然后展示这个离这个时间最近的视频就可以了.原理就是这样

ffmpeg 命令行吗,发出来看看

这种音视频底层封装编解码一般都是 c c++，因为生态摆在那。还是用 c 或 c++去搞吧。或者你自己找找有没有 Java 包干这个的，java 不是号称什么包都有吗。

大致的模型，主线程分段读，每读一段分发到 uv_queue_work 去处理，设置完成回调，回调中做发送处理。
问题 1， 读处理要控制内存，可以简单控制一下任务数量，发出去一个任务加一，发送完成一个减一，达到上限就休息一下，更精细的就记录内存使用量。精确等待控制可以用 cond signal 来做。否则 sleep 一下也可以。
问题 2， 顺序写回在回调里做，弄个数组存完成任务序号，回调里顺序检测数组从头开始发送，碰到还没完成的回调返回即可。记录一下上次顺序完成序号，下次检测从上次完成序号开始。

跑回调的线程和发任务的线程是同一个，所以上面检测都是线程安全的。

asio 这里不管 buffer，要你自己提供也就是自己管理，所以回调函数没有 buffer，因为你自己知道 buffer 在哪里。

物极必反,粘包警察都有了,lz 还在笑粘包

没太看懂关键点，是 p2p cdn 吗？ 腾讯体育直播已经应用了 p2p cdn，抓包看是在 m3u8 里扩展了一些标签。

AirPlay 协议是公开的吗，是类似 rtsp?

我记得 ffmpeg 有 filter 可以的，但是效果不太好

这是检测解码是否有错来判断视频完整性，音频应该没办法，一般音频编码单元之间没有参考关系。要检测完整性，应该有原始参照，和原始比呗，或者通过原始信息获知完整性。

完整性

我也在学 rust，学着玩

没看清楚,我好像说的是方案 1

看了看你说的方案 2,意思是想要解码前在关键帧处拼成一段码流,这样完全没有两个并行解码了,是这个意思吧.

不想要并行解码那么先停掉第一个解码器,再开启第二个解码器就可以了,事实也确实应该这么做,并行逻辑反而复杂了,当然这个切换期间保证渲染 buffer 不要耗尽,保证接缝处时间戳连续就可以了.

除非是带 startcode 的 h264 码流,且 idr 帧前是有 sps,pps 的这种你可以接起来送到解码器,否则像 mp4,mkv 不同分辨率的还是要重开解码器的

我要有左耳朵耗子那个钱都财富自由了，还中年危机，这中年危机和一般人讲的怕是不一样吧

用 2 肯定可行，原理上没啥问题，剩下的都是业务逻辑。收到切换事件后开始并行解码目标分辨率，然后保证无缝接入渲染队列，再把原分辨率解码停了，具体实现还是看你整个架构