la diffusion vidéo en continu vers et à partir de sources multiples

Question

Je voulais avoir quelques idées sur la manière dont certains d'entre vous aborderaient ce problème. J'ai un robot qui tourne sous linux et qui utilise une webcam (avec un driver v4l2) comme un de ses capteurs. J'ai écrit un panneau de contrôle avec gtkmm. Le serveur et le client sont écrits en C++. Le serveur est le robot, le client est le "panneau de contrôle". L'analyse de l'image se fait sur le robot, et j'aimerais retransmettre la vidéo de la caméra au panneau de contrôle pour deux raisons : A) pour le plaisir B) pour superposer les résultats de l'analyse d'image

Ma question est donc la suivante : quelles sont les bonnes façons de transmettre la vidéo de la webcam au panneau de contrôle et de donner la priorité au code du robot pour la traiter ? Cela ne m'intéresse pas d'écrire mon propre schéma de compression vidéo et de le faire passer par le port réseau existant, un nouveau port réseau (dédié aux données vidéo) serait mieux je pense. La deuxième partie du problème est de savoir comment afficher la vidéo dans gtkmm ? Les données vidéo arrivent de manière asynchrone et je n'ai pas le contrôle sur main() dans gtkmm, donc je pense que ce serait délicat.

Je suis ouvert à l'utilisation de choses comme vlc, gstreamer ou toute autre bibliothèque de compression générale que je ne connais pas.

merci !

EDIT : Le robot a un processeur de 1GHz, et fait tourner une version de linux semblable à celle d'un bureau, mais pas de X11.

Answer 1

Gstreamer résout presque tout cela pour vous, avec très peu d'efforts, et s'intègre également très bien avec le système d'événements Glib. GStreamer comprend des plugins de source V4L, des widgets de sortie gtk+, divers filtres pour redimensionner / encoder / décoder la vidéo, et mieux encore, des sources et des puits de réseau pour déplacer les données entre les machines.

Pour les prototypes, vous pouvez utiliser l'outil "gst-launch" pour assembler des pipelines vidéo et les tester, puis il est assez simple de créer des pipelines par programme dans votre code. Recherchez 'GStreamer network streaming' pour voir des exemples de personnes qui font cela avec des webcams et autres.

Answer 2

Je ne suis pas sûr des technologies utilisées, mais cela peut s'avérer être un énorme problème de synchronisation ***** si vous voulez éviter les trames perdues. Je diffusais une vidéo en continu vers un fichier et le réseau en même temps. Ce que j'ai fini par faire, c'est utiliser un grand tampon circulaire avec trois pointeurs : un pour l'écriture et deux pour la lecture. Il y avait trois threads de contrôle (et quelques threads d'encodage supplémentaires) : un qui écrivait dans le tampon et faisait une pause s'il atteignait un point du tampon non lu par les deux autres, et deux threads de lecture qui lisaient dans le tampon et écrivaient dans le fichier/réseau (et faisaient une pause s'ils prenaient de l'avance sur le producteur). Comme tout était écrit et lu sous forme de trames, la surcharge de synchronisation pouvait être réduite au minimum.

Mon producteur était un transcodeur (à partir d'une autre source de fichiers), mais dans votre cas, vous voudrez peut-être que la caméra produise des images entières dans le format qu'elle utilise normalement et ne fasse que le transcodage (avec quelque chose comme ffmpeg) pour le serveur, tandis que le robot traite l'image.

Votre problème est toutefois un peu plus complexe, car le robot a besoin d'un retour d'information en temps réel et ne peut donc pas se mettre en pause et attendre que le serveur de diffusion en continu rattrape son retard. Il est donc préférable de transmettre les images au système de contrôle aussi rapidement que possible et d'en mettre quelques-unes en mémoire tampon circulaire séparément pour la diffusion en continu vers le "panneau de contrôle". Certains codecs gèrent mieux les trames perdues que d'autres, de sorte que si le réseau prend du retard, vous pouvez commencer à écraser les trames à la fin de la mémoire tampon (en veillant à ce qu'elles ne soient pas lues).

Answer 3

Quand vous dites "un nouveau port vidéo" et que vous commencez à parler de vlc/gstreaming, j'ai du mal à comprendre ce que vous voulez. Il est évident que ces logiciels aideront à la diffusion en continu et à la compression via un certain nombre de protocoles, mais il est clair que vous aurez besoin d'un "port réseau" et non d'un "port vidéo" pour envoyer le flux.

Si ce que vous voulez vraiment, c'est envoyer la sortie d'affichage via une alimentation vidéo/tv sans fil, c'est une autre affaire, mais vous aurez besoin des conseils d'experts en matériel plutôt que d'experts en logiciel pour cela.

Aller de l'avant. J'ai fait beaucoup de streaming sur les protocoles MMS/UDP et vlc le gère très bien (en tant que serveur et client). Cependant, il est conçu pour les ordinateurs de bureau et n'est peut-être pas aussi léger que vous le souhaitez. Quelque chose comme gstreamer, mencoder ou ffmpeg par contre sera mieux je pense. Quel type de CPU le robot possède-t-il ? Vous aurez besoin d'un peu de puissance si vous prévoyez une compression en temps réel.

Du côté client, je pense que vous trouverez un certain nombre de widgets pour gérer la vidéo dans GTK. Je m'y intéresserais avant de me préoccuper des détails de l'interface.