Je considère différentes façons de diffuser un grand nombre de vidéos en direct sur l'écran dans linux/X11, en utilisant plusieurs processus indépendants.Flux vidéo en direct massif en utilisant Linux
J'ai commencé le projet initialement avec des textures openGL/GLX et openGL, mais c'était une impasse. La raison: "changement de contexte". Il s'avère que (surtout nvidia) fonctionne mal lorsque plusieurs processus (multi-indépendants) manipulent des textures rapides, en utilisant plusieurs contextes. Il en résulte dans des accidents, se fige, etc.
(voir le fil suivant: https://lists.freedesktop.org/archives/nouveau/2017-February/027286.html)
je me suis finalement transformé en Xvideo et il semble fonctionner très bien. Mes tests initiaux montrent que Xvideo gère le vidage vidéo ~ 10 fois plus efficacement que openGL et ne plante pas. On peut démontrer ce fonctionnement ~ 10 clients vlc avec 720p @ 25fps et en essayant à la fois Xvideo et OpenGL sortie (n'oubliez pas de mettre tout en plein écran).
Cependant, je soupçonnais que Xvideo utilise, sous le capot, openGL, donc nous allons voir si je reçois ce droit ..
Les deux Xvideo et GLX sont des modules d'extension de X11, mais:
(a) par immersion vidéo Xvideo:
XVideo considère tout l'écran comme un port de dispositif et le manipule directement (il a ces puissances comme Dieu, étant une extension à X11)
.. donc il suffit d'un seul contexte du pilote graphique. Appelons ce contexte 1.
Processus 1 Services Xvideo demandes d'une certaine fenêtre .. Xvideo parvient dans une certaine partie de l'écran, en utilisant le contexte 1.
processus services de 2 demandes d'un certain fenêtre .. Xvideo gère dans une certaine partie de l'écran, en utilisant le contexte 1.
(B) à travers la texture GLX et openGL "manuellement" dumping vidéo le dumping:
Le processus 1 demande un contexte à glx, récupère le contexte 1 et commence à rejeter des textures avec lui.
Le processus 2 demande un contexte à glx, obtient le contexte 2 et commence à rejeter des textures avec lui.
Est-ce que je comprends bien?
Existe-t-il un moyen d'obtenir, en utilisant OpenGL directement, la situation (A)?
.. il est possible que l'on doive abandonner GLX complètement, ce qui commence à être un peu dur.
Vous avez tort de supposer que XVideo sous le capot utilisait OpenGL. XVideo est une extension indépendante du protocole X11 et peut parfaitement être prise en charge par les GPU qui ne supportent pas le tramage 3D. Cependant, pour des raisons d'efficacité, vous devriez probablement utiliser VDPAU au lieu de XVideo. Aussi ce qui vous empêche d'utiliser un seul contexte OpenGL dans un seul processus? Vous pouvez parfaitement décoder dans un traitement séparé (disons en utilisant ffmpeg), et passer les données décodées à travers des tuyaux dans un processus d'affichage. – datenwolf
En ce qui concerne vdpau, il est maintenant pris en charge dans les pilotes opensource par mesa, mais ils semblent encore un peu verts. Vdpaus pilote propriétaire de Nvidia ont toutes sortes de restrictions artificielles à partir du nombre de décodeurs vdpau simultanés autorisés à des profils h264 autorisés (ils ne veulent pas vous vendre leurs cartes gfx uber-cher) - ne recommande pas nvidia vdpau même à mon pire ennemi! .. vous ne saurez jamais combien de threads vdpau vous pouvez décoder et avec quel profil/niveau h264. –
En ce qui concerne l'utilisation d'un processus "maître" unique pour le dumping de texture openGL, je pensais à cette possibilité aussi, mais en utilisant la mémoire partagée. Envoyer des bitmaps décodés, 720p @ 25 fps provenant de plusieurs sources par pipes .. ne sont pas des pipes manipulées par le noyau? Auraient-ils assez de capacité pour quelque chose comme ça? –