Cómo hicimos que compartir pantalla fuera cuatro veces más rápido

La latencia al compartir pantalla es uno de esos problemas que solo notas cuando es mala. Un presentador hace clic para pasar a la siguiente diapositiva y la sala que mira la pantalla compartida lo ve un instante y medio después. No está roto, exactamente, solo desajustado. A lo largo de varias versiones, analizamos a fondo de dónde venía ese retraso en la función de compartir pantalla de Cliqer y redujimos la latencia constante de más de dos segundos a alrededor de medio segundo, una mejora de aproximadamente cuatro veces. Esta es la versión en lenguaje sencillo de cómo lo hicimos.

No vamos a escondernos tras nombres en clave ni a fingir que hubo una solución mágica. Hubo tres correcciones independientes, cada una dirigida a un lugar distinto donde se escondía el retraso, y sus efectos se sumaron.

Por qué compartir pantalla tiene retraso

Cuando compartes una pantalla, tienen que ocurrir tres cosas antes de que un espectador vea un fotograma: tu equipo tiene que capturarlo, codificarlo en vídeo y enviarlo. Cualquiera de esos pasos puede añadir retraso discretamente, y el efecto se acumula. Un codificador lento, más un búfer prudente, más la espera de la siguiente actualización de fotograma completo pueden sumar fácilmente dos o tres segundos, incluso con una conexión rápida.

Lo complicado es que ninguno de ellos parece roto por separado. La captura funciona. La codificación funciona. La transmisión llega. Simplemente llega tarde, y «simplemente tarde» es difícil de diagnosticar sin medir cada fase por separado.

Corrección uno: dejar de codificar la misma imagen dos veces

La primera fuente de retraso era trabajo desperdiciado. Las pantallas compartidas y las salidas NDI se codificaban dos veces internamente, una por cada ruta de salida, y una diapositiva estática se volvía a codificar continuamente aunque no hubiera cambiado nada en pantalla. Eso duplicaba la carga del codificador sin ningún beneficio visual y hacía que el flujo estuviera siempre más ocupado de lo necesario, lo que empuja cada fotograma más atrás en la cola.

Eliminar la pasada de codificación duplicada, y omitir la recodificación cuando la imagen no ha cambiado, liberó de inmediato un margen de CPU considerable. Menos competencia por el codificador significa que cada fotograma que sí necesita codificarse se procesa antes.

Corrección dos: ajustar el búfer sin perder resiliencia

La segunda fuente era el búfer situado entre el codificador y la red, la parte que existe para absorber breves fallos de la red de modo que un tirón en la conexión no se convierta en un tirón en pantalla. Los búferes de este tipo son por naturaleza un compromiso: si son demasiado pequeños, un fallo menor provoca cortes visibles; si son demasiado generosos, estás añadiendo retraso a cada fotograma por si algo sale mal más adelante.

El búfer se había dimensionado con generosidad, lo que significaba que añadía retraso a cada fotograma en el caso habitual para protegerse de un caso poco frecuente. Ajustarlo redujo el retraso en el peor de los casos de unos segundos a muy por debajo de uno, sin dejar de superar breves fallos de red sin cortes visibles. Es el tipo de corrección que parece un pequeño cambio de número en un diff y que en realidad es una decisión sobre qué modo de fallo prefieres tener.

Corrección tres: no hacer esperar a los nuevos espectadores hasta el siguiente fotograma clave

La tercera corrección se centró en un momento concreto y molesto: qué pasa cuando alguien se une a una pantalla compartida que ya está en marcha. La compresión de vídeo funciona enviando fotogramas completos, llamados fotogramas clave, solo de vez en cuando, con fotogramas más ligeros del tipo «qué ha cambiado desde la última vez» entre medias. Un espectador que se une a mitad de la transmisión no puede interpretar esos fotogramas intermedios hasta que recibe un fotograma clave en el que apoyarse, y antes eso significaba esperar al siguiente programado, hasta tres segundos después.

La solución fue mantener en caché el fotograma clave más reciente y entregarlo a un nuevo suscriptor en el momento en que se une, en lugar de hacerle esperar al siguiente según la programación. Junto con la temporización de fotogramas basada en intervalos que se describe en nuestra documentación sobre compartir pantalla, los nuevos espectadores ven ahora el vídeo a los pocos milisegundos de unirse a una pantalla compartida, en lugar de esperar hasta tres segundos al siguiente fotograma clave.

Si sumas las tres correcciones, la latencia constante de más de dos segundos de la que casi nadie terminaba de fiarse pasó a ser de alrededor de medio segundo, una mejora de aproximadamente cuatro veces, con menos uso de CPU y menos ancho de banda que antes. La velocidad de fotogramas completa también importa aquí: el vídeo de programa había estado limitado discretamente a unos 31 fotogramas por segundo independientemente de la fuente, así que ahora una pantalla compartida a 60 fps se ve tan fluida en el extremo receptor como en la propia pantalla del presentador.

Qué significa esto si estás presentando ahora mismo

Nada de esto requiere que cambies ningún ajuste. Se incluye en el flujo de compartir pantalla de la app de escritorio y se aplica tanto si compartes un solo monitor en una sala pequeña como si diriges una producción completa en Studio con varias fuentes, incluidos flujos de trabajo con vMix que dependen de una señal rápida y predecible. En Cliqer 3, el vídeo de Studio en Mac es sin copias (zero copy): los fotogramas de cámara, las fuentes y el Program permanecen en la memoria de la GPU, y el codificador por hardware lee el Program directamente de la superficie de la GPU. Cliqer 3 también muestra en todo momento la velocidad de fotogramas del Program y la carga de GPU y CPU en la línea de estado de Studio, para que puedas comprobar la velocidad de fotogramas por ti mismo en pleno evento. Si quieres equilibrar calidad y ancho de banda además del trabajo de latencia, los ajustes de compartir pantalla cubren la elección de códec, la resolución y la tasa de bits, y la versión de escritorio 2.2.0 añadió la opción de incluir directamente el audio del sistema o del micrófono en una pantalla compartida.

Para configuraciones híbridas en las que el retraso era más visible, sobre todo con un presentador remoto que mira una pantalla compartida y reacciona en directo, esto se complementa con nuestra guía para corregir la latencia al compartir pantalla en reuniones híbridas y nuestra explicación de por qué la latencia del control remoto en milisegundos importa tanto en el lado del control como en el del vídeo.

Adónde va el resto de la latencia

Compartir pantalla es solo una parte del recorrido. La otra es la propia ruta de red: si la conexión entre el presentador y el espectador es directa o retransmitida, y qué ocurre en redes que bloquean el tráfico directo entre pares. Tratamos esa parte, incluido por qué en algunas redes nunca se puede eliminar por completo, en Los servidores TURN explicados y ¿Es seguro WebRTC?.

Preguntas frecuentes

Pruébalo tú mismo

La forma más rápida de notar la diferencia es compartir una pantalla y observar la cara de otra persona cuando la ve. Descarga Cliqer gratis y prueba a compartir pantalla con tu propia configuración, o consulta todas las funciones de compartir pantalla y compara los planes en precios.