transmisión de video hacia y desde múltiples fuentes

Question

Quería obtener algunas ideas sobre cómo algunos de ustedes abordarían este problema. Tengo un robot, que ejecuta Linux y utiliza una cámara web (con un controlador v4l2) como uno de sus sensores. He escrito un panel de control con gtkmm. Tanto el servidor como el cliente están escritos en C++. El servidor es el robot, el cliente es el "panel de control". El análisis de imágenes está sucediendo en el robot, y me gustaría volver a transmitir el vídeo de la cámara al panel de control por dos razones: A) para la diversión B) para superponer los resultados de análisis de imágenes

Así que mi pregunta es decir, ¿cuáles son algunas buenas formas de transmitir video desde la cámara web al panel de control, así como dar prioridad al código del robot para procesarlo? No me interesa escribir mi propio esquema de compresión de video y ponerlo a través del puerto de red existente; creo que un nuevo puerto de red (dedicado a los datos de video) sería lo mejor. La segunda parte del problema es ¿cómo se muestra el video en gtkmm? Los datos de video llegan de manera asincrónica y no tengo control sobre main() en gtkmm, así que creo que eso sería complicado.

Estoy abierto a usar cosas como vlc, gstreamer o cualquier otra librería de compresión general que desconozca.

gracias!

EDIT: El robot tiene un procesador de 1GHz, ejecutando un escritorio como la versión de Linux, pero no X11.

Answer 1

Gstreamer soluciona casi todo esto por usted, con muy poco esfuerzo, y también se integra muy bien con el sistema de eventos Glib. GStreamer incluye plugins fuente V4L, widgets de salida gtk +, varios filtros para redimensionar/codificar/decodificar el video, y lo mejor de todo, receptor de red y fuentes para mover los datos entre las máquinas.

Para el prototipo, puede usar la herramienta 'gst-launch' para ensamblar las tuberías de video y probarlas, entonces es bastante simple crear las tuberías programáticamente en su código. Busque la 'transmisión en red de GStreamer' para ver ejemplos de personas que hacen esto con cámaras web y similares.

Answer 2

No estoy seguro acerca de las tecnologías reales utilizadas, pero esto puede terminar siendo una gran sincronización ***** si desea evitar los marcos caídos. Transmitía un video a un archivo y a una red al mismo tiempo. Lo que finalmente terminé haciendo fue usar un gran buffer circular con tres punteros: uno de escritura y dos de lectura. Había tres hilos de control (y algunos hilos de codificación adicionales): uno que escribía en el búfer que pausaría si alcanzaba un punto en el búfer no leído por los otros, y dos hilos de lectura que leerían del búfer y escribirían en el archivo/red (y pausa si se adelantaron al productor). Como todo estaba escrito y leído como marcos, la sobrecarga de sincronización podría mantenerse al mínimo.

Mi productor era un transcodificador (de otra fuente de archivo), pero en su caso, es posible que desee que la cámara produzca cuadros enteros en el formato que normalmente tiene y solo transcodifica (con algo como ffmpeg) para el servidor , mientras el robot procesa la imagen.

Su problema es un poco más complejo, ya que el robot necesita comentarios en tiempo real, por lo que no puede pausar y esperar a que el servidor de transmisión se ponga al día. Por lo tanto, es posible que desee obtener marcos en el sistema de control lo más rápido posible y almacenarlos en una memoria intermedia circular por separado para transmitirlos al "panel de control". Ciertos códecs manejan fotogramas perdidos mejor que otros, por lo que si la red se atrasa puede comenzar a sobrescribir fotogramas al final del búfer (teniendo cuidado de que no se lean).

Answer 3

Cuando dice 'un nuevo puerto de video' y luego comienza a hablar sobre vlc/gstreaming, me resulta difícil encontrar lo que desea. Obviamente, estos paquetes de software ayudarán a transmitir y comprimir a través de una serie de protocolos, pero es evidente que necesitará un "puerto de red" y no un "puerto de video" para enviar la transmisión.

Si lo que realmente quiere decir es enviar la salida de la pantalla a través de la alimentación inalámbrica de video/tv, es otro asunto, sin embargo necesitará asesoramiento de expertos en hardware en lugar de expertos en software.

En marcha. He realizado muchas transmisiones por los protocolos MMS/UDP y vlc lo maneja muy bien (como servidor y cliente). Sin embargo, está diseñado para computadoras de escritorio y puede no ser tan ligero como lo desee. Algo como gstreamer, mencoder o ffmpeg en la mano va a ser mejor, creo.¿Qué tipo de CPU tiene el robot? Necesitarás un poco de gruñido si estás planificando la compresión en tiempo real.

En el lado del cliente, creo que encontrará una serie de widgets para manejar videos en GTK. Lo analizaría antes de preocuparme por los detalles de la interfaz.