关于直播视频流处理后再转播的技术架构选型

[mikulch]

最近有一些需求都跟这个有关，以前都没做过这种实时视频流的处理，都是 crud boy 。目前后端语言是一定要选 java 的。 但是对于这一块基本上一片空白。大家有什么推荐的教程或者书籍么？网上自己搜了下，没什么特别满意的比较全面的教程。

[zliea]

1. 不是每一帧数据都请求 API 。
2. 并发请求 API ，要求 API 可以并发执行，然后等待固定延迟后再推数据。
一个直播流就需要这么大的计算量，有没有考虑同时多个直播流，如果有趁早考虑边缘计算。

[mikulch]

@zliea 并发请求 api 的话如何保证帧数返回的顺序呢？
另外不是每一帧都请求的话，因为数据这边要做标注，如果不每一帧都请求的话，画面上就会出现上一帧标注了，下一帧不标注的情况，这样就感觉很奇怪。

等待固定延时后再推送和一帧一帧的好像都差不多哇。速度还是那么慢。

[zliea]

1. 每一帧做一个标记 request id ，API 返回的时候把标记 request id 也要返回回来，然后重排。
2. “不是每一帧数据都请求 API”，这个意味着标注不更新，就是假定每 4 帧取第 1 帧计算，那么 2-4 帧的标注也是第 1 帧的标注去合成。

[mikulch]

@zliea 明白了，就是 2-4 帧都用第一帧的标注这个如果业务上要求，视频中的某一张图片上如果出现新的物品，需要标注出来。
如果没标注出来的话，继续用下一个 4 帧的第一帧的标注来解决这个思路吗？这样子有图片在 4 个帧间隔之间出现又消失，不然好像没啥问题。似乎确实是个好办法，大佬有在业务上使用过这种做法吗，实际观看的时候会有啥效果影响吗？


另外第一点确实是个好方法，相当于一个线程拉取了再一个一个的处理，确实可以节约一些 io 等待的时间。谢谢大佬。