複数の独立したプロセスを使用して、膨大な数のライブビデオをlinux/X11の画面にストリームするさまざまな方法を検討しています。Linuxを使用した大規模なライブビデオストリーミング
私は最初にOpenGL/GLXとopenGLテクスチャでプロジェクトを開始しましたが、それは致命的でした。理由は： "コンテキストの切り替え"。いくつかの（独立した複数の）プロセスが、複数のコンテキストを使用して、高速ペーステクスチャで操作しているとき、特に（nvidia）がうまく動作しないことが判明します。私は最終的にXVideoのになって、非常にうまく動作するようです
：これは
は（https://lists.freedesktop.org/archives/nouveau/2017-February/027286.html次のスレッドを参照）など、クラッシュになりフリーズします。私の最初のテストでは、XvideoがビデオダンプをOpenGLよりも10倍効果的に処理し、クラッシュしないことが示されています。 1つは、実行中の〜10 vlcのクライアントで、720p @ 25fpsで、XvideoとOpenGLの両方の出力を試してみることができます（すべてのフルスクリーンを入れてください）。
：
しかし、私はXVideoのとGLXの両方がX11の拡張モジュールですが、... XVideoのは、ボンネットの下に、OpenGLを使用していますので、私はこの権利を取得していた場合を見てみましょうということ
を疑っています（A）XVideoのを通してビデオをダンプ：
XVideoのデバイスポートとして画面全体を考慮し
（それはX11の拡張され、これらの神のような力を持っている）、それを直接操作します210
..グラフィックスドライバからは、シングルコンテキストが必要です。特定のウィンドウのコンテキスト1
プロセス1つの要求XVideoのサービスを呼び出す.. XVideoのコンテキストを特定するための1
プロセス2つの要求XVideoのサービスを使用して、画面の特定の部分にそれを管理することができウィンドウ.. XVideoのはダンピングGLXおよびOpenGLテクスチャを介してビデオ "手動" をダンプコンテキスト1
（B）を使用して、画面の特定の部分にそれを管理する：
-
を
プロセス1は、glxからコンテキストを要求し、コンテキスト1を取得し、コンテキスト1を取得してテクスチャをダンプします。
プロセス2はglxからコンテキストを要求し、コンテキスト2を取得し、それにテクスチャをダンプします。
私はこの権利を得ていますか？
状況（A）を直接OpenGLを使用して達成する方法はありますか？
.. GLXを完全に削除しなければならない可能性があります。これは少しハードコアになり始めます。
あなたがフードの下XVideoのは、OpenGLを使用していたと仮定で間違っています。 XVideoはX11プロトコルへの独立した拡張機能であり、3DラスタライズをサポートしていないGPUで完全にサポートできます。しかし、効率を上げるために、おそらくXVideoの代わりにVDPAUを使用するべきです。また、単一のプロセスで単一のOpenGLコンテキストを使用することを止めるのは何ですか？別々に処理された（例えば、ffmpegを使って）完全にデコードし、デコードされたデータをパイプを通して表示プロセスに渡すことができます。 – datenwolf
vdpauに関しては、メサによってopensourceドライバでサポートされるようになりましたが、まだまだ緑色のようです。 Nvidia独自のドライバのvdpausには、許可されたh264プロファイル（許可されていないgfxカードをあなたに売ることはできません）に許可されている同時vdpauデコーダの数から人為的な制限があります - 私の最悪の敵に対しても独自のnvidia vdpauを勧めません！あなたは解読できるvdpauスレッドの数とh264のプロファイル/レベルを知ることはできません。 –
OpenGLテクスチャのダンプのための単一の "マスタ"プロセスの使用に関して、私はこの可能性についても考えていましたが、共有メモリを使用しました。パイプで複数のソースからのデコードされたビットマップ、720p @ 25fpsを送信しています..カーネルで処理されるパイプではありませんか？彼らはこのようなことに十分な能力を持っていますか？ –