我正在考虑使用多个独立进程将大量实况视频流式传输到Linux/X11中的屏幕。使用Linux的大规模实况视频流
我最初使用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，这开始有点硬核。
你错在假设的XVideo引擎盖下是使用OpenGL。 XVideo是X11协议的独立扩展，可以完美支持缺乏3D光栅化支持的GPU。但为了提高效率，您应该使用VDPAU而不是XVideo。还有什么阻止您在单个进程中使用单个OpenGL上下文？你可以非常好地解码单独处理（比如使用ffmpeg），并通过管道将解码的数据传递到显示过程。 – datenwolf
关于vdpau，现在支持mesa的开源驱动程序，但它们似乎仍然有点绿。 Nvidia专有驱动程序的vdpaus有多种允许同时使用的vdpau解码器到允许的h264配置文件（他们不会向你推销他们超级昂贵的gfx卡）的人为限制 - 不会推荐专有的nvidia vdpau甚至是我最大的敌人！ ..你永远不会知道你可以解码多少个vdpau线程以及什么h264配置文件/级别。 –
关于使用单个“主”进程openGL纹理转储..我也想到这种可能性，但通过使用共享内存。通过管道从多个源发送解码位图，720p @ 25 fps ..不是由内核处理的管道？他们是否有足够的能力来完成这样的事情？ –