Recientemente, estoy intentando transmitir un escritorio remoto usandoffmpeg. El objetivo es poder enviar lo que se muestra en la pantalla de una computadora a otra computadora y al mismo tiempo poder elegir configuraciones como la resolución de salida, etc.
Es un pequeñocasi trabajandoprueba de concepto. Cuando termine, podré reemplazar VNC usandoffmpegtransmitiendo conx2xosinergiapara reenviar eventos de teclado y mouse.
Ahora puedo comenzar a transmitir usando:
ffmpeg -f x11grab -s "1600x1200" -i ":0" \
-f alsa -i pulse \
-s 800x600 -b 200k -f mpegts - \
| mplayer -cache 1024 -
#
# I have pulse audio configured so that `-i pulse` will
# The output can sent through for example netcat to another host
#
La latencia depende de las opciones de codificación. Con estas opciones, el retraso entre la actualización de la pantalla y la actualización del vídeo es de unos 800 ms.
Lo que estoy tratando de lograr:
- Alcanza una latencia de100 ms.
Cuando
mplayerse ejecuta se queja de que no puede buscar en los flujos de aprendizaje y haysin audio. Todavía tengo el sonido cuando guardo la salida en un archivo y la reproduzco.EDITAR: Después de agregar
-cache, los mensajes para buscar en transmisiones lineales ya no aparecen. Cambiar el formato de salida para-f mpegtsque el audio funcione.Sería fantástico si la codificación no tomara el 100% de uno de los núcleos de la CPU (objetivo secundario).
Después de investigar un poco en Internet, creo que estos problemas están relacionados con los códecs/opciones que debo usar. Sin embargo, no conozco las diferencias entre las posibilidades existentes. ¿Podría darme algunas opciones que solucionarían mis problemas? Además, ¿es VLC una buena alternativa y, de ser así, cuáles serían los comandos equivalentes para transmitir de un escritorio a otro?
Respuesta1
La transmisión desde el escritorio A al escritorio B es un problema interesante. Si no necesita video/audio, es posible que desee registrarse en el protocolo NX. Es mucho más eficiente que VNC. FreeNX es un servidor y NoMachine y otros son clientes de NX. Hay otros servidores, gratuitos y comerciales.
También se está trabajando en una capacidad de escritorio remoto de alto rendimiento, SPICE, como proyecto F/LOSS. Creo que Redhat está tomando la iniciativa.http://spice-space.org/
No sé si estas son respuestas útiles, pero ¿quizás solo sean pistas para algo más útil?
Para la transmisión de vídeo, probablemente sea necesario evitar la sobrecarga de un protocolo de escritorio completo.
Respuesta2
Recientemente tuve que configurar la transmisión de baja latencia con requisitos aún más estrictos que los del cartel original (OP). Ideé una solución que funciona lo suficientemente bien como para usarla como monitor adicional para mi computadora portátil, con entrada fluida del mouse y el teclado.
En el lado emisor, utilicé el siguiente ffmpegcomando:
ffmpeg -video_size 1920x1080 -r 30 -framerate 30 -f x11grab -i :0.0+0x0 \
-b:v 40M -maxrate 50M -bufsize 200M \
-field_order tt -fflags nobuffer -threads 1 \
-vcodec mpeg4 -g 100 -r 30 -bf 0 -mbd bits -flags +aic+mv4+low_delay \
-thread_type slice -slices 1 -level 32 -strict experimental -f_strict experimental \
-syncpoints none -f nut "tcp://10.0.0.1:1234"
La parte crítica de este comando es el argumento -g 100, que agrega tiempo entre fotogramas clave, reduciendo la tasa de bits de la transmisión.
En el lado receptor, usé ffplay(incluido con ffmpeg) para mostrar la transmisión en una Raspberry Pi 3:
ffplay -autoexit -flags low_delay -framedrop -strict experimental \
-vf setpts=0 -tcp_nodelay 1 "tcp://10.0.0.1:1234\?listen"
Si bien me doy cuenta de que la pregunta original tiene más de una década y que la potencia de procesamiento disponible para el usuario promedio ha mejorado significativamente desde entonces, estos dos comandos brindan un punto de partida razonable para cualquiera que busque configurar una transmisión de baja latencia a través de una red local. incluso en hardware de gama baja.