simple - Linux: captura de video de la pantalla de escritorio a través de la red y VNC framerate

simple screen recorder (1)

Lo siento por la pared de texto - TL; DR:

¿Cuál es la velocidad de cuadros de la conexión VNC (en cuadros / seg) o, mejor dicho, quién la determina: cliente o servidor?
Cualquier otra sugerencia para la captura de pantalla del escritorio, pero "con código de tiempo correcto" / con tasa de cuadros sin color (con un período estable); ¿Y con posibilidad de obtenerlo como secuencia de imágenes sin comprimir (o sin pérdida)?

En pocas palabras: tengo un problema típico al que me enfrento: a veces desarrollo hardware y quiero grabar un video que muestre los dos comandos ingresados en la PC (''captura de escritorio'') y las respuestas del hardware (''video en vivo'') . Sigue una parte de una introducción, antes de llegar a los detalles específicos.

Introducción / Contexto

Mi estrategia, por ahora, es usar una cámara de video para grabar el proceso de prueba de hardware ( como video ''en vivo'' ) y hacer una captura de escritorio al mismo tiempo. La cámara de video produce un video 29.99 (30) FPS MPEG-2 .AVI; y quiero obtener la captura de escritorio como una secuencia de imágenes de PNG a la misma velocidad de cuadros que el video. La idea, entonces, sería: si la velocidad de fotogramas de los dos videos es la misma; entonces podría simplemente

Alinee la hora de inicio de la captura del escritorio, con el punto correspondiente en el video ''en vivo''
Configure una picture-in-picture , donde se coloca una versión reducida de la captura de escritorio, como superposición, sobre el video ''en vivo''
- (donde una parte de la pantalla en el video ''en vivo'' sirve como fuente de sincronización visual con la superposición de ''captura de escritorio'')
Exportar un video ''final'' combinado, comprimido adecuadamente para Internet

En principio, supongo que se podría usar una herramienta de línea de comandos como ffmpeg para este proceso; sin embargo, preferiría usar una GUI para encontrar el punto de inicio de alineación para los dos videos.

Finalmente, lo que también quiero lograr es preservar la máxima calidad al exportar el video ''final'': el video ''en vivo'' ya está comprimido cuando sale de la cámara, lo que significa una degradación adicional cuando pasa a través del códec Theora .ogv - por eso me gustaría mantener los videos originales, y usar algo como una línea de comando para generar un video ''final'' de nuevo, si se requiere una compresión / resolución diferente. Esta es la razón por la que me gusta tener el video de ''captura de escritorio'' como una secuencia PNG (aunque creo que cualquier formato sin comprimir funcionaría): tomo medidas para ''ajustar'' el escritorio, por lo que no hay muchos gradientes y codificación sin pérdidas. (es decir, PNG) sería apropiado.

Opciones de captura de escritorio

Bueno, hay muchos problemas en este proceso en Ubuntu Lucid, que uso actualmente ( y puedes leer sobre algunas de mis dificultades en 10.04: Superposición de video / edición compuesta con Theora ogv - Ubuntu Forums ). Sin embargo, uno de los problemas cruciales es la suposición de que la velocidad de fotogramas de los dos videos entrantes es igual: en realidad, generalmente la captura del escritorio es de una tasa de cuadros más baja; Y lo que es peor, muy a menudo los marcos no están sincronizados .

Esto, entonces, requiere la molestia de sentarse frente a un editor de video, y cortar y editar manualmente clips de menos de un segundo a nivel de cuadro, lo que requiere horas de trabajo para lo que será un video de 5 minutos al final. Por otro lado, si los dos videos (''en vivo'' y ''captura'') tuvieran la misma velocidad de cuadros y sincronización: en principio, no necesitaría más de un par de minutos para encontrar el punto de sincronización de inicio en un editor de video - y el resto del procesamiento de video ''combinado'' podría ser manejado por una sola línea de comando. Por eso, en esta publicación, me gustaría centrarme en la parte de captura de escritorio .

Por lo que puedo ver, solo hay algunas alternativas viables (en lugar de 5 maneras de hacer un screencast Your Linux Desktop ) para la captura de escritorio en Linux / Ubuntu (tenga en cuenta que normalmente uso una computadora portátil como objetivo para la captura de escritorio):

Haga que su PC objetivo (computadora portátil) clone el escritorio en su salida VGA; use un hardware VGA a compuesto o VGA a S-video para obtener una señal de video de VGA; Usa la tarjeta de captura de video en una PC diferente para capturar video
Utilice recordMyDesktop en la PC de destino
Configure un servidor VNC ( vi no en Ubuntu; o vncserver ) en la PC de destino para ser capturado; use el software de captura VNC (como vncrec ) en una PC diferente para capturar / grabar la transmisión VNC ( que posteriormente se puede convertir en video ).
Usa ffmpeg con la opción x11grab
* ( use alguna herramienta en la PC de destino, que haría una transferencia DMA de un marco de imagen de escritorio directamente - desde la memoria intermedia del marco de la tarjeta gráfica hasta la memoria del adaptador de red )

Tenga en cuenta que la utilidad de los enfoques anteriores está limitada por mi contexto de uso: la PC objetivo que quiero capturar, generalmente ejecuta un software (que utiliza el hardware probado) que se mueve alrededor de grandes cantidades de datos; Lo mejor que podría decir sobre la descripción de un sistema de este tipo es "apenas estable" :) Supongo que esto es similar a los problemas que enfrentan los jugadores cuando desean obtener una captura de video de un juego exigente. Y tan pronto como empiezo a usar algo como recordMyDesktop , que también usa un poco de recursos y quiere capturar en el disco duro local, inmediatamente tengo graves bloqueos del kernel (a menudo sin vmcore generado).

Por lo tanto, en mi contexto, normalmente asumo la participación de una segunda computadora, para ejecutar la captura y grabación del escritorio de la PC ''destino''. Aparte de eso, los pros y los contras que puedo ver hasta ahora con las opciones anteriores, se incluyen a continuación.

(Preparación de escritorio)

Para todos los métodos que se analizan a continuación, tiendo a "preparar" el escritorio de antemano:

Eliminar fondos e iconos de escritorio
Ajuste la resolución a 800x600 a través de Sistema / Preferencias / Monitores ( gnome-desktop-properties )
Cambie la profundidad del color a 16 bpp (usando xdpyinfo | grep "of root" para verificar)

... para minimizar la carga en el software de captura de escritorio. Tenga en cuenta que cambiar la profundidad del color en Ubuntu requiere cambios en xorg.conf; sin embargo, " No se encuentra xorg.conf (se) en / etc / X11 (Ubuntu 10.04) ", por lo que es posible que deba ejecutar sudo Xorg -configure primero.

Con el fin de mantener bajo el uso de recursos gráficos, también solía tener el compiz deshabilitado, o más bien, tenía ''Sistema / Preferencias / Apariencia / Efectos visuales'' configurado en "Ninguno". Sin embargo, después de que intenté habilitar compiz configurando ''Efectos visuales'' en "Normal" ( que no se guarda ), puedo notar que las ventanas en la pantalla LCD se vuelven a dibujar mucho más rápido; Así que lo guardo así, también para captura de escritorio. Me parece un poco extraño: ¿cómo podrían los efectos causar una actualización más rápida de la pantalla? No parece que se deba a un controlador propietario (la tarjeta es " Controlador de Gráficos Integrado de la Familia Intel Corporation N10 ", y Ubuntu no ofrece ninguna opción de controlador propietario al cambiar de compiz ), aunque podría ser que todo el desenfoque y los efectos solo engañan a mis ojos :)).

Clonación VGA

Bueno, esta es la opción más cara (ya que requiere la compra adicional de no solo uno, sino dos piezas de hardware: convertidor VGA y tarjeta de captura de video); y se aplica principalmente a computadoras portátiles (que tienen tanto una pantalla como una salida VGA adicional; para computadoras de escritorio, es posible que también tenga que invertir en una tarjeta gráfica adicional o en un hardware de clonación VGA).

Sin embargo, también es la única opción que no requiere ningún software adicional de la PC de destino (y, por lo tanto, utiliza un 0% de potencia de procesamiento de la CPU de destino) - Y también la única que dará un video con una tasa de cuadros verdadera y sin problemas de 30 fps (ya que se realiza mediante hardware separado, aunque, con la suposición de que la desalineación de los dominios de reloj, presente entre piezas de hardware individuales, es despreciable).

En realidad, como ya tengo algo como una tarjeta de captura, ya he invertido en un convertidor VGA, con la expectativa de que eventualmente me permitirá producir videos finales "combinados" con solo 5 minutos de búsqueda del punto de alineación y un solo comando línea; pero todavía tengo que ver si este proceso funcionará según lo previsto. También estoy vagando por lo posible que será capturar el escritorio como video sin comprimir @ 800x600, 30 fps.

grabar mi escritorio

Bueno, si ejecuta recordMyDesktop sin ningún argumento, primero comienza con la captura (lo que parece) de los datos de imagen sin procesar, en una carpeta como /tmp/rMD-session-7247 ; y después de presionar Ctrl-C para interrumpirlo, codificará estos datos de imagen sin procesar en un archivo .ogv. Obviamente, la captura de datos de imágenes grandes en el mismo disco duro que el software de mi prueba (que también mueve grandes cantidades de datos), suele ser la causa de un ataque instantáneo :)

Por lo tanto, lo que intenté hacer es configurar Samba para compartir un disco en la red; luego, en la PC de destino, me conectaría a esta unidad y le recordMyDesktop a recordMyDesktop que usara esta unidad de red (a través de gvfs ) como ubicación de sus archivos temporales:

recordmydesktop --workdir /home/user/.gvfs/test/ on/ 192.168.1.100/capture/ --no-sound --quick-subsampling --fps 30 --overwrite -o capture.ogv

Tenga en cuenta que, si bien este comando usará la ubicación de red para archivos temporales (y por lo tanto hace posible que recordMyDesktop ejecute en paralelo con mi software), tan pronto como presiona Ctrl-C, comenzará a codificar y guardar capture.ogv directamente. en el disco duro local del objetivo (aunque, en ese momento, no me importa :))

La primera de mis molestias con recordMyDesktop es que no puede indicarle que guarde los archivos temporales y evite codificarlos al final: puede usar Ctrl + Alt + p para pausar, o puede presionar Ctrl-C rápidamente después del primero. hacer que se estrelle; que luego dejará los archivos temporales ( si no presionas Ctrl-C lo suficientemente rápido la segunda vez, el programa "Limpiará el caché ..." ). Luego puedes correr, decir:

recordmydesktop --rescue /home/user/.gvfs/test/ on/ 192.168.1.100/capture/rMD-session-7247/

... para convertir los datos temporales en bruto. Sin embargo, la mayoría de las veces, recordMyDesktop se segfault en medio de realizar este "rescate". Aunque, la razón por la que quiero conservar los archivos temporales, es tener la fuente sin comprimir para el montaje de imagen en imagen. Tenga en cuenta que la " --on-the-fly-encoding " evitará el uso de archivos temporales por completo, a la espera de que se utilice más potencia de procesamiento de la CPU (lo que, para mí, también es causa de bloqueos).

Luego, está la tasa de cuadros - obviamente, puede establecer la --fps N cuadros solicitada usando la --fps N '' --fps N ''; sin embargo, eso no es garantía de que realmente obtenga esa tasa de fotogramas; por ejemplo, obtendría:

recordmydesktop --fps 25 ... Saved 2983 frames in a total of 6023 requests ...

... para una captura con mi software de prueba en ejecución; lo que significa que la tasa realmente alcanzada es más como 25 * 2983/6032 = 12.3632 fps!

Obviamente, los cuadros se caen, y en su mayoría se muestran como la reproducción de video es demasiado rápida . Sin embargo, si reduzco los fps solicitados a 12, entonces, de acuerdo con los informes guardados / totales, logro algo así como 11 fps; y en este caso, la reproducción de video no se ve acelerada. Y todavía no he intentado alinear tal captura con un video en vivo, así que no tengo idea si esos cuadros que realmente se han guardado, también tienen una marca de tiempo precisa.

Captura de VNC

La captura VNC, para mí, consiste en ejecutar un servidor VNC en la PC ''destino'' y ejecutar vncrec (edición twibright) en la PC ''grabadora''. Como servidor VNC, uso vino , que es "Sistema / Preferencias / Escritorio remoto (Preferencias)". Y al parecer, incluso si la configuración de vino no es la cosa más fácil de administrar, vino como servidor no parece ser demasiado exigente para la PC ''objetivo''; ya que no he experimentado bloqueos cuando se ejecuta en paralelo con mi software de prueba.

Por otro lado, cuando vncrec está capturando en la PC ''grabadora'', también se abre una ventana que le muestra el escritorio ''objetivo'' tal como se ve en ''tiempo real''; cuando hay grandes actualizaciones (es decir, ventanas enteras en movimiento) en el ''objetivo'', se pueden ver, de manera bastante visible, problemas con la frecuencia de actualización / actualización en el ''registrador''. Pero, solo para pequeñas actualizaciones (es decir, solo un cursor que se mueve sobre un fondo estático), las cosas parecen estar bien.

Esto me hace preguntarme sobre una de mis preguntas principales con esta publicación: ¿qué es lo que establece la tasa de cuadros en una conexión VNC?

No he encontrado una respuesta clara a esto, pero a partir de fragmentos de información ( ver refs a continuación ), deduzco que:

El servidor VNC simplemente envía los cambios (cambios de pantalla + clics, etc.) lo más rápido posible, cuando los recibe; limitado por el ancho de banda máximo de red que está disponible para el servidor
El cliente VNC recibe los eventos de cambio demorados y alterados por la conexión de red, e intenta reconstruir la secuencia del "video" del escritorio, nuevamente tan rápido como sea posible.

... lo que significa que uno no puede indicar nada en términos de una frecuencia de cuadros estable y periódica (como en el video).

En lo que respecta a vncrec como cliente, los videos finales que recibo generalmente se declaran como 10 fps, aunque los marcos pueden desplazarse / distorsionarse (lo que luego requiere el corte en los editores de video). Tenga en cuenta que vncrec-twibright/README indica: " La frecuencia de muestreo de la película es 10 por defecto o anulada por la variable de entorno VNCREC_MOVIE_FRAMERATE, o 10 si no se especifica. "; sin embargo, la página del manual también indica " VNCREC_MOVIE_FRAMERADO - Especifica la velocidad de fotogramas de la película de salida. Tiene un efecto solo en modo de película. El valor predeterminado es 10. Intente 24 cuando su transcodificador vomite de 10. ". Y si uno mira en la vncrec/sockets.c " vncrec/sockets.c ", puede ver:

void print_movie_frames_up_to_time(struct timeval tv) { static double framerate; .... memcpy(out, bufoutptr, buffered); if (appData.record) { writeLogHeader (); /* Writes the timestamp */ fwrite (bufoutptr, 1, buffered, vncLog); }

... lo que muestra que algunas marcas de tiempo están escritas, pero no sé si esas marcas de tiempo se originan en la PC "original" de "destino" o en la "grabadora". EDITAR : gracias a la respuesta de @kanaka, verifiqué a través de vncrec/sockets.c nuevo, y puedo ver que es la función writeLogHeader que llama a gettimeofday ; por lo tanto, las marcas de tiempo que escribe son locales, es decir, se originan en la PC ''grabadora'' ( y, por lo tanto, estas marcas de tiempo no describen con precisión cuándo se originaron los marcos en la PC ''destino'' ).

En cualquier caso, todavía me parece que el servidor envía, y vncrec como el cliente recibe, cuando sea ; y solo en el proceso de codificación de un archivo de video a partir de la captura sin formato, se establece / interpola alguna forma de velocidad de cuadros.

También me gustaría indicar que en mi computadora portátil ''objetivo'', la conexión de red cableada está interrumpida ; por lo tanto, la conexión inalámbrica es mi única opción para obtener acceso al enrutador y a la red local, a una velocidad mucho más baja que los 100 MB / s que el enrutador podría manejar desde conexiones cableadas. Sin embargo, si la fluctuación en los cuadros capturados se debe a marcas de tiempo incorrectas debido a la carga en la PC ''destino'', no creo que un buen ancho de banda de la red ayude demasiado.

Finalmente, en lo que se refiere a VNC, podría haber otras alternativas para probar, como el servidor VNCast ( prometedor, pero requiere algo de tiempo para compilar desde la fuente, y se encuentra en la "versión experimental temprana" ); o MultiVNC ( aunque, simplemente parece un cliente / espectador, sin opciones para grabar ).

ffmpeg con x11grab

No he jugado con esto, pero lo he intentado en conexión con netcat ; esta:

# ''target'' ffmpeg -f x11grab -b 8000k -r 30 -s 800x600 -i :0.0 -f rawvideo - | nc 192.168.1.100 5678 # ''recorder'' nc -l 0.0.0.0 5678 > raw.video #

... captura un archivo, pero ffplay no puede leer el archivo capturado correctamente; mientras:

# ''target'' ffmpeg -f x11grab -b 500k -r 30 -s 800x600 -i :0.0 -f yuv4mpegpipe -pix_fmt yuv444p - | nc 192.168.1.100 5678 # ''recorder'' nc -l 0.0.0.0 5678 | ffmpeg -i - /path/to/samplimg%03d.png

produce imágenes .png, pero con artefactos de compresión (resultado de la compresión involucrada con yuv4mpegpipe , supongo).

Por lo tanto, no me está gustando demasiado ffmpeg + x11grab actualmente, pero tal vez simplemente no sé cómo configurarlo para mis necesidades.

* (tarjeta gráfica -> DMA -> red)

Lo cierto es que no estoy seguro de que exista algo así. De hecho, apostaría a que no. Y no soy un experto aquí, pero especulo:

Si la transferencia de memoria DMA se puede iniciar desde la tarjeta gráfica (o su búfer que mantiene el mapa de bits del escritorio actual) como fuente y el adaptador de red como destino , entonces, en principio, debería ser posible obtener una captura de escritorio sin comprimir con una correcta ( y decente) framerate. El punto en el uso de la transferencia DMA sería, por supuesto, liberar al procesador de la tarea de copiar la imagen del escritorio a la interfaz de la red ( y, por lo tanto, reducir la influencia que el software de captura puede tener en los procesos que se ejecutan en la PC ''destino'' - especialmente los que se ocupan de RAM o disco duro ).

Una sugerencia como esta, por supuesto, asume que: hay enormes cantidades de ancho de banda de red ( para 800x600, 30 fps al menos 800 * 600 * 3 * 30 = 43200000 bps = 42 MiB / s, lo que debería estar bien para 100 MB locales) / s redes ); un montón de disco duro en la otra PC que realiza la "grabación", y finalmente, un software que luego puede leer los datos en bruto y generar secuencias de imágenes o videos basados en ellos :)

Las demandas de ancho de banda y disco duro con las que podría vivir, siempre y cuando haya garantía tanto para un framerate estable como para datos sin compresión; por lo que me encantaría escuchar si ya existe algo como esto.

- - - - - -

Bueno, creo que fue así, tan breve como pude ponerlo :) Cualquier sugerencia para herramientas, o procesos, que pueden resultar con una captura de escritorio

en formato sin comprimir (en última instancia, se puede convertir en una secuencia de imágenes PNG sin comprimir / sin pérdida), y
con un "timecoded correctamente", framerate estable

..., que en última instancia se prestará a un procesamiento "sencillo" y sencillo de la línea de comandos para generar videos superpuestos de "imagen en imagen": ¡será muy apreciado!

Gracias de antemano por cualquier comentario,
¡Aclamaciones!

Referencias

Usted debe obtener una placa para una pregunta tan larga como fuera. ;-)

En respuesta a su pregunta principal, VNC utiliza el protocolo RFB, que es un protocolo de almacenamiento remoto de cuadros (por lo tanto, el acrónimo) no un protocolo de transmisión de video. El cliente VNC envía un mensaje FrameBufferUpdateRequest al servidor que contiene una región de ventana de visualización en la que el cliente está interesado y un indicador incremental. Si no se establece el indicador incremental, el servidor responderá con un mensaje FrameBufferUpdate que contiene el contenido de la región solicitada. Si se establece el indicador incremental, el servidor puede responder con un mensaje FrameBufferUpdate que contiene las partes de la región solicitadas que han cambiado desde la última vez que el cliente fue enviado a esa región.

La definición de cómo interactúan las solicitudes y las actualizaciones no está definida de forma precisa. El servidor no necesariamente responderá a cada solicitud con una actualización si nada ha cambiado. Si el servidor tiene varias solicitudes en cola del cliente, también se le permite enviar una única actualización en respuesta. Además, el cliente realmente necesita poder responder a un mensaje de actualización asíncrono del servidor (no en respuesta a una solicitud) de lo contrario, el cliente no estará sincronizado (porque RFB no es un protocolo enmarcado).

A menudo, los clientes simplemente se implementan para enviar solicitudes de actualización incrementales para toda la ventana gráfica de frame buffer en un intervalo periódico y manejar cualquier mensaje de actualización del servidor a medida que llegan (es decir, no se hace ningún intento de vincular solicitudes y actualizaciones).

Here hay una descripción de los mensajes FrameBufferUpdateRequest.