我正在考虑使用多种独立的进程，以不同的方式在linux/x11中将大量实时视频流到屏幕上。
我最初是用opengl/glx和opengl纹理开始这个项目的，但那是个死胡同。原因是：“语境转换”。结果发现（特别是nvidia）在多个（独立的多个）进程使用多个上下文以快节奏纹理进行操作时性能很差。这会导致碰撞、冻结等。
（请参阅以下线程：https://lists.freedesktop.org/archives/nouveau/2017-February/027286.html）
我终于变成了xvideo，它看起来工作得很好。我的初步测试显示xvideo处理视频转储的效率是opengl的10倍，而且不会崩溃。我们可以演示如何使用720p@25fps运行~10个vlc客户机，并尝试xvideo和opengl输出（记住要全屏显示）。
不过，我怀疑xvideo在幕后使用opengl，所以让我们看看我是否做得对。
xvideo和glx都是x11的扩展模块，但是：
（a）通过xvideo倾倒视频：
xvideo将整个屏幕视为一个设备端口，并直接对其进行操作（它拥有类似上帝的力量，是x11的扩展）
……所以它只需要一个图形驱动程序的上下文。我们称之为上下文1。
进程1请求某个窗口的xvideo服务。xvideo使用上下文1将它管理到屏幕的某个部分。
进程2请求某个窗口的xvideo服务。xvideo使用上下文1将它管理到屏幕的某个部分。
（b）通过glx和opengl纹理转储“手动”转储视频：
进程1从glx请求上下文，获取上下文1并开始转储纹理。
进程2从glx请求上下文，获取上下文2并开始转储纹理。
我说得对吗？
直接使用opengl有什么方法可以实现情景（a）？
……人们可能不得不完全放弃glx，这开始有点核心。
最佳答案
已经有一段时间了，但我终于用opengl纹理和多线程技术把它整理出来了。这似乎是最好的方法：
https://elsampsa.github.io/valkka-core/html/process_chart.html
（免责声明：我做到了）
关于linux - 使用Linux进行海量实时视频流，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/42139815/