¿Qué tan bueno es realmente compartir pantalla con WebRTC? Puse a prueba cuatro códecs

Siempre me ha intrigado saber cómo se comparan los diferentes códecs al compartir pantalla con WebRTC. Así que decidí comprobarlo probando los cuatro más comunes: VP8, VP9, H.264 y AV1.

Para asegurar la fiabilidad de los resultados, realicé pruebas con diversos tipos de contenido y condiciones de red. No me basé únicamente en impresiones visuales, sino que utilicé comparaciones fotograma a fotograma, calculé la relación señal-ruido máxima (PSNR) y extraje estadísticas detalladas de WebRTC para obtener una visión clara y basada en datos.

Para ir un paso más allá, incluso creé un plugin personalizado para Chrome que rastrea el uso de la CPU durante la codificación y la decodificación. Esto me permitió ver con claridad cómo cada códec afecta el rendimiento del sistema, porque la calidad es excelente, pero no si tu ordenador está al límite intentando mantener el ritmo.

Analicé métricas clave como la tasa de bits, la velocidad de fotogramas, la resolución, la cuantificación (QP), la PSNR y la carga de la CPU. Con base en todo esto, elaboré algunas recomendaciones prácticas para ayudar a quienes intentan optimizar el uso compartido de pantalla WebRTC para sus propios casos de uso.

Acerca del experimento

Por qué compartir pantalla no es tan sencillo como parece

Si alguna vez has compartido tu pantalla durante una videollamada y has notado que la calidad baja o que el video se entrecorta, no eres el único. Mantener una pantalla compartida nítida y fluida es más complicado de lo que parece.

¿El problema? La clave está en la variedad. Algunos contenidos son estáticos, como una presentación de diapositivas o un documento. En otras ocasiones, se comparten vídeos de alta velocidad. Estos diferentes tipos de contenido exigen características muy diferentes del códec. Por ejemplo, los vídeos de alta velocidad consumen mucho ancho de banda, mientras que las imágenes estáticas son más sensibles a los artefactos de compresión que pueden hacer que se vean borrosas o con bloques.

Si a esto le sumamos problemas reales de internet, como la pérdida de paquetes o las caídas de ancho de banda, la situación se complica aún más. Por eso, elegir el códec adecuado y ajustar su funcionamiento es fundamental para que la pantalla compartida sea de alta calidad y responda con fluidez.

Ya existe mucha investigación sobre el rendimiento de los códecs de vídeo en escenarios generales de streaming. Sin embargo, compartir pantalla tiene sus propias peculiaridades. No se trata solo de ver un vídeo, sino de interactuar en tiempo real, y los tipos de contenido son muy diversos. Esto significa que la investigación habitual no siempre es aplicable.

Lo que me propuse hacer

Quería profundizar en este caso práctico específico. Mi objetivo era observar el rendimiento de diferentes códecs al compartir la pantalla, especialmente en condiciones reales como la variación de los tipos de contenido y las condiciones de red impredecibles.

Para ello, diseñé un método para evaluar la calidad de la pantalla compartida con la mayor precisión posible, no solo por su aspecto, sino con el respaldo de métricas y datos sólidos. A lo largo del proceso, aprendí mucho sobre qué códecs ofrecen el mejor rendimiento y cómo optimizarlos para obtener un mejor rendimiento en aplicaciones en tiempo real.

Una cosa quedó clara rápidamente: el rendimiento al compartir la pantalla depende realmente de lo que se comparte. Un vídeo de ritmo rápido se comporta de forma muy diferente a un documento estático o a una navegación lenta por una página web.

Para mantener la imparcialidad y la coherencia, me aseguré de que cada prueba se ejecutara con las mismas condiciones: misma resolución, mismo punto de partida y misma duración. De esta forma, podía estar seguro de que los resultados dependían exclusivamente del rendimiento del códec, no de una variable accidental.

Creé dos casos de prueba diferentes para simular situaciones de compartir pantalla en la vida real:

• Vídeo de alta velocidad : Este fue un clip real de motociclistas acelerando por un bosque. Mucho movimiento rápido, paisajes detallados y un entorno visual en constante cambio: perfecto para llevar la compresión al límite.

• Texto con desplazamiento automático : Creé una página HTML sencilla con texto e imágenes, y luego usé JavaScript para desplazarla a una velocidad constante. Imita un uso común, como compartir un documento o leer una página web.

Estos dos tipos de contenido me dieron una buena combinación para probar cómo cada códec maneja diferentes desafíos, desde mantenerse al día con el movimiento hasta preservar la claridad en escenas más estáticas.

Cómo configuré todo

Para probar correctamente los códecs, necesitaba una configuración sólida que pudiera capturar todo , tanto lo que se enviaba como lo que se recibía. Empecé con una herramienta llamada webrtc-sandbox (por cierto, puedes aprender sobre esta herramienta y muchas más en mi otra publicación: " Aprendiendo WebRTC en la práctica: Mejores herramientas y demostraciones "), que es ideal para experimentar con los componentes internos de WebRTC. Terminé modificándola bastante para gestionar mejor la pantalla compartida y asegurarme de poder grabar tanto las transmisiones de vídeo salientes como las entrantes. Cada prueba me proporcionó dos archivos de vídeo: uno para lo enviado y otro para lo recibido, que utilicé posteriormente para el análisis comparativo.

Pero no me limité al vídeo. También quería rastrear lo que sucedía internamente. Para ello, extraje estadísticas detalladas de WebRTC directamente del navegador Chrome. Estas estadísticas me permitieron comprender el rendimiento de cada códec y el comportamiento de la red simulada durante cada prueba.

Un aspecto importante del rompecabezas era el uso de la CPU , y resultó ser un poco complicado. La versión normal de Chrome no permite que los plugins monitoricen la carga de la CPU en pestañas individuales, así que usé una versión de desarrollo del navegador y escribí mi propio plugin para solucionarlo.

Me centré específicamente en medir el uso de la CPU de la pestaña que enviaba o recibía la pantalla compartida. De esta forma, excluí las tareas de renderizado no relacionadas de otras partes del navegador. Dado que tanto el envío como la recepción se realizaron en la misma pestaña, los números que obtuve fueron una vista combinada, pero bastante similares a los que se verían en un caso práctico. (Aclaración: la codificación suele afectar más a la CPU que la decodificación).

Recopilación de datos: 157 ejecuciones de prueba después...

Una vez lista la configuración, llegó el momento de ejecutar los experimentos, y realicé muchos. Repetí las pruebas en la misma máquina una y otra vez, utilizando diferentes condiciones de red y configuraciones de códec para comprobar su rendimiento. En total, recopilé 157 puntos de datos , asegurándome de que cada combinación de condiciones de prueba estuviera bien representada.

Esto me proporcionó un conjunto de datos sólido con el que trabajar y me permitió realizar un análisis profundo del comportamiento de compartir pantalla en WebRTC en diferentes escenarios. Esto es lo que estaba probando específicamente:

• Tipo de vídeo :
  Utilicé dos tipos de contenido de pantalla compartida para reflejar casos de uso comunes:
  • Vídeo de alto movimiento : imágenes del mundo real con toneladas de cambios de píxeles en cada fotograma.
  • Texto con desplazamiento automático : elementos visuales mayoritariamente estáticos, pero con píxeles que cambian de posición a medida que se desplaza el texto.
• Códec :
  Probé los cuatro códecs para compartir pantalla más populares:
  • AV1
  • H.264
  • VP8
  • VP9
• Ancho de banda de la red :
  Dado que el ancho de banda juega un papel importante en la calidad del video (especialmente en las videollamadas), simulé una variedad de condiciones de red para ver qué tan bien cada códec manejaba un ancho de banda ajustado o fluctuante.

Al mezclar y combinar estas variables de manera estructurada, pude imitar escenarios de uso compartido de pantalla del mundo real: el tipo que encontrarías en una videollamada, durante una demostración en vivo o en una sesión remota colaborativa.

Solucionando los fallos: cómo hice que las pruebas fueran más fiables

Como ocurre con la mayoría de los experimentos, las primeras pruebas no fueron tan fluidas como esperaba. Inmediatamente surgieron dos problemas importantes:

1. Inicio manual = Tiempos desorganizados. Al principio, iniciaba la pantalla compartida manualmente, literalmente pulsando un botón. ¿El problema? Era casi imposible sincronizar el inicio de la grabación con el del vídeo. Eso significaba que cada prueba tenía tiempos ligeramente diferentes, lo que distorsionaba las comparaciones.
2. Enviado vs. Recibido = Desincronizado. Incluso en el momento oportuno, el video en tiempo real presenta sus propias peculiaridades. Debido a la codificación, la decodificación y los retrasos de la red, las transmisiones enviadas y recibidas nunca se alineaban perfectamente. Esto hacía casi imposible comparar la calidad fotograma a fotograma.

Para resolver estos problemas, hice un par de mejoras clave:

• Sincronización programática : En lugar de iniciar todo manualmente, escribí código para sincronizar el inicio del vídeo o el desplazamiento del texto con la grabación. De esta forma, cada prueba comenzó exactamente al mismo tiempo en ambos extremos: problema resuelto.
• Coincidencia de fotogramas con código QR : Para solucionar el problema de desincronización, añadí una pequeña superposición de código QR al vídeo compartido. Este pequeño marcador actuó como una marca de tiempo: me permitió comparar fotogramas entre las transmisiones enviadas y recibidas con precisión. De repente, el análisis fotograma a fotograma se volvió factible (y mucho más preciso).

Había algo más que debía tener en cuenta: la tasa de bits adaptativa de WebRTC . Una de sus características más interesantes es que ajusta automáticamente la calidad del vídeo según el ancho de banda disponible. Sin embargo, este ajuste no es instantáneo; tarda unos segundos en estabilizarse. Por lo tanto, añadí un breve retraso antes de iniciar la grabación. Esto le dio tiempo al sistema para estabilizarse en la tasa de bits objetivo, de modo que los resultados reflejaran la calidad real que se obtendría una vez estabilizada la calidad.

Estos cambios hicieron que el experimento fuera mucho más confiable y me dieron confianza de que los datos que estaba recopilando realmente reflejaban cómo se comporta el uso compartido de pantalla en el mundo real.

Lo que medí (y por qué es importante)

Recopilé muchos datos durante estas pruebas, pero para mantener las cosas sencillas y fáciles de comparar, me concentré en algunas métricas fundamentales que realmente cuentan la historia de cómo funciona cada códec en un escenario de uso compartido de pantalla.

Esto es lo que miré:

• Velocidad de cuadros
  Esto me indica cuántos fotogramas por segundo se codificaron, enviaron y recibieron. Es un buen indicador de la fluidez de la transmisión de vídeo: una mayor velocidad de fotogramas suele significar una experiencia más fluida.
• Resolución
  La resolución se centra en la cantidad de detalle visual que se conserva. Analicé la cantidad de píxeles por fotograma en cada etapa (enviados y recibidos) para comprobar si los códecs conservaban la calidad de la imagen o la reducían para ahorrar ancho de banda.
• Calidad de vídeo
  Utilicé un par de métricas clave aquí:
  • Parámetro de cuantificación (QP) : un QP más bajo generalmente significa mejor calidad.
  • Relación señal-ruido máxima (PSNR) : proporciona una idea numérica de la diferencia entre el vídeo recibido y el original. Cuanto mayor sea, mejor.
• Uso de CPU
  El rendimiento de los códecs no se trata solo de lo que ves, sino también de lo que tu equipo hace en segundo plano. Medí la potencia de CPU utilizada para codificar y decodificar en cada prueba, normalizada a lo largo del tiempo, para ver qué códecs son ligeros y cuáles consumen muchos recursos.

Al analizar estas métricas, pude comparar los códecs no solo en términos de calidad, sino también de fluidez, eficiencia y exigencia. Esto me ayudó a identificar las ventajas y desventajas de cada códec en situaciones reales de pantalla compartida.

Finalmente llegamos a los resultados

¿Qué tan importante es el tipo de contenido? Mucho más de lo que crees

Una de las conclusiones más sorprendentes de mis experimentos fue cuánto afecta el tipo de contenido que se comparte al rendimiento de la pantalla compartida, tanto en términos de calidad de video como de uso de recursos. Y esto se cumplió con todos los códecs que probé.

La idea es bastante simple: cuando cambian más píxeles de un fotograma a otro (como en un vídeo rápido), el sistema tiene que trabajar más. Esto significa que se necesita más ancho de banda y la CPU tiene que trabajar más para mantener el ritmo.

Tomemos como ejemplo AV1 . Al usarlo para compartir una pantalla de 1,5 megapíxeles, el ancho de banda requerido variaba considerablemente según el contenido compartido. En un caso, donde el contenido era más dinámico, AV1 tuvo que enviar una cantidad considerablemente mayor de datos para mantener la fluidez de la transmisión. Capturé esto en el siguiente gráfico , que muestra el drástico impacto de la complejidad del contenido en el uso del ancho de banda.

Pero no es sólo el ancho de banda: tu hardware también lo siente.

El siguiente gráfico muestra cómo cambia el uso de la CPU según el contenido compartido. De nuevo, usando AV1 como ejemplo, se puede ver claramente que las imágenes más complejas requieren mucha más potencia de CPU para mantener la misma velocidad de fotogramas y resolución.

Esto no es exclusivo de AV1. Todos los códecs se basan en los mismos principios básicos para codificar y decodificar vídeo, por lo que cabría esperar un comportamiento similar, pero los datos revelan una historia diferente. La carga de la CPU no solo varía con el contenido, sino también según el códec utilizado.

Para facilitar la comparación, he elaborado la siguiente tabla , que muestra el consumo de CPU de cada códec al transmitir un vídeo de 1,5 megapíxeles a unos 24 fotogramas por segundo, una configuración bastante típica para compartir la pantalla sin problemas. Los resultados destacan algunas diferencias importantes en la eficiencia de cada códec al usar el hardware.

Así que, si estás creando u optimizando algo que depende del uso compartido de pantalla WebRTC, la conclusión es clara: tanto el contenido como la elección del códec son importantes. Y mucho.

Comparación de códecs: velocidades de cuadros, carga de la CPU y los costos reales de la calidad

Al compartir la pantalla, una de las primeras cosas que se nota es la fluidez (o no) del video. Ahí es donde entra en juego la velocidad de fotogramas . Si compartes contenido con mucho movimiento, como reproducción de video o animaciones, una velocidad de fotogramas más alta es esencial para evitar transmisiones entrecortadas y difíciles de ver.

Para esta parte del experimento, me centré en el rendimiento de la velocidad de fotogramas con diferentes códecs, manteniendo todo lo demás constante: la misma resolución (aproximadamente 1,5 megapíxeles) y el mismo contenido en cada prueba. Utilicé la configuración contentHint WebRTC para asegurarme de que la resolución se mantuviera estable en todos los casos.

En la siguiente imagen , se puede observar cómo los diferentes códecs gestionan el contenido con alto movimiento a medida que aumenta el ancho de banda. En el eje x: tasa de bits en Mbps. En el eje y: velocidad de fotogramas en fotogramas por segundo (fps).

Esto es lo que destacó:

• H.264 y AV1 tomaron la delantera una vez que el ancho de banda alcanzó los 2 Mbps o más, y ambos entregaron más de 20 fps: una experiencia fluida que se puede lograr incluso con una conexión 3G decente.
• VP8 y VP9 no se mantuvieron a la par. Se mantuvieron en torno a la mitad de la velocidad de fotogramas en las mismas condiciones y necesitaban 4 Mbps o más para resultar usables, lo cual no siempre es realista en redes de gama baja.

Luego pasé a contenido de poco movimiento (una página de texto que se desplaza lentamente) para ver cómo funcionan los códecs cuando no hay muchos cambios entre los cuadros.

Como era de esperar, tanto H.264 como AV1 obtuvieron mejores resultados en este escenario, con AV1 a la cabeza . Esto se debe a una función llamada Copia Intrabloque , que permite a AV1 omitir la recodificación de partes de la pantalla que no han cambiado. Es increíblemente eficaz para compartir pantalla estática o semiestática.

En el siguiente gráfico , puede ver con qué eficiencia AV1 maneja estas situaciones de poco movimiento, manteniendo el uso del ancho de banda impresionantemente bajo y al mismo tiempo manteniendo una alta calidad visual.

Pero… hay un equilibrio entre ambas cosas.

AV1 puede ofrecer mejores imágenes y mejor compresión, pero también consume más CPU . La siguiente imagen lo muestra claramente: el uso de CPU de AV1 aumenta constantemente a medida que aumenta la tasa de bits, superando ampliamente a H.264. H.264 tiene una gran ventaja en este aspecto gracias a la aceleración de hardware generalizada, que mantiene la carga de CPU baja y estable.

Curiosamente, VP9 consume incluso más CPU que AV1, siguiendo una tendencia similar, pero con picos más altos. Tanto VP9 como AV1 se basan en algoritmos complejos para ofrecer una buena calidad, pero esto tiene un precio: consumen mucha energía del procesador.

Hubo un giro inesperado al revisar el contenido de baja resolución . Esta vez, VP8 y VP9 se veían bastante eficientes, consumiendo menos CPU que AV1, como se muestra en el siguiente gráfico .

AV1, a pesar de estar diseñado para compartir pantalla, seguía siendo el que más CPU consumía. ¿Por qué? Todas esas optimizaciones que le ayudan a comprimir vídeo de alta velocidad también añaden sobrecarga, incluso cuando no hay mucha actividad en pantalla.

¿Una razón importante para esto? AV1 aún carece de una compatibilidad generalizada con la codificación por hardware . Si bien la decodificación es relativamente ligera, la codificación se realiza principalmente por software, lo que supone un uso intensivo de la CPU, especialmente en situaciones en tiempo real como el uso compartido de pantalla, donde tanto la codificación como la decodificación se realizan constantemente.

Aquí es donde la situación se complica para dispositivos portátiles como laptops y tabletas. Sin aceleración de hardware, códecs como AV1 pueden consumir energía rápidamente y consumir recursos, lo cual no es ideal cuando estás en movimiento. Hasta que se generalice una mejor compatibilidad de hardware, las funciones avanzadas de AV1 conllevan un coste de rendimiento bastante considerable.

Códecs y resolución: ¿Qué sucede cuando se prioriza la velocidad de cuadros?

Hasta ahora, los resultados que he compartido provienen de pruebas que mantuvieron la resolución constante. Cuando el ancho de banda era limitado, el sistema respondía reduciendo la velocidad de fotogramas , lo cual es lógico para contenido estático o texto. Pero ¿qué pasa si el objetivo es mantener la fluidez , incluso si eso implica sacrificar la resolución?

Para explorar esto, realicé un nuevo conjunto de experimentos donde WebRTC se configuró para priorizar la velocidad de fotogramas . Esto se realizó mediante la configuración contentHint de WebRTC, que permite indicar al navegador qué es más importante: la alta resolución o el movimiento fluido.

Mi objetivo era mantener la velocidad de fotogramas en 30 fps constantes, un valor ampliamente reconocido como el ideal para una visualización fluida y cómoda. Lograrlo de forma constante fue difícil (la transmisión adaptativa siempre implica cierta fluctuación), pero los resultados ofrecieron información valiosa sobre cómo cada códec gestiona esta compensación.

Para ayudar a analizar este comportamiento, introduje una nueva métrica:

Píxeles enviados por segundo = Velocidad de cuadros × Resolución

Esto ofrece una imagen más completa que simplemente analizar los FPS o la resolución. Muestra la cantidad de datos visuales que el códec entrega por segundo en diferentes condiciones.

En vídeo de alta velocidad, AV1 volvió a destacar , y por un margen considerable. Incluso con tasas de bits más bajas, logró transmitir significativamente más píxeles por segundo que cualquier otro códec. Esto demuestra claramente la eficacia de AV1 para gestionar el contenido dinámico cuando el sistema se ve obligado a mantener una alta velocidad de fotogramas. Consulte el siguiente gráfico :

Al cambiar a contenido con poco movimiento, como una página web con texto desplazable, la competencia se igualó un poco. El rendimiento de todos los códecs se volvió más uniforme, como se puede apreciar en la siguiente imagen . Sin embargo, AV1 mantuvo la ventaja , especialmente con tasas de bits más altas. Sus optimizaciones de compresión le permitieron mantener un alto rendimiento sin aumentar significativamente el consumo de recursos.

¿Qué significa todo esto en la práctica?

Bueno, si su caso de uso involucra imágenes dinámicas de alto movimiento (como tutoriales en video, animaciones en vivo o transmisión de juegos), priorizar la velocidad de cuadros puede marcar una gran diferencia , y AV1 demuestra ser particularmente capaz en ese entorno.

Incluso con contenido de baja velocidad, AV1 sigue demostrando su solidez. Si bien la diferencia puede ser menor, logra enviar consistentemente más datos visuales, lo que se traduce en mejor calidad con el mismo ancho de banda o incluso con uno menor, gracias a sus avanzadas estrategias de compresión.

En ambos casos, la métrica de "píxeles enviados por segundo" resultó útil para comprender cómo los códecs equilibran la resolución y la velocidad de fotogramas cuando el ancho de banda es limitado. El rendimiento de AV1 en estas condiciones lo consolida como la opción más eficaz, siempre que su sistema pueda gestionar las demandas adicionales de la CPU.

¿Qué tan nítida es la imagen? Hablemos de PSNR

Más allá de la velocidad de fotogramas, la resolución y el uso de la CPU, hay un factor más importante en el proceso de compartir pantalla: ¿qué tan parecida es la imagen recibida a la original? Aquí es donde entra en juego la relación señal-ruido máxima (PSNR) .

La PSNR es una métrica ampliamente utilizada para medir la calidad del vídeo comprimido. Indica cuánta distorsión (o "ruido") se ha introducido durante la codificación. Se mide en decibelios (dB) y la regla general es simple: cuanto más alta, mejor . Una PSNR alta significa que la imagen se ve casi exactamente igual a la original; una puntuación más baja significa que hay una degradación más visible.

Para contextualizar, probé los valores de PSNR en distintos códecs en dos escenarios diferentes: uno donde la resolución es la prioridad y otro donde la velocidad de fotogramas es la principal. Ambas pruebas utilizaron el mismo contenido de vídeo de alto movimiento para mantener la coherencia.

En esta configuración, donde la claridad es fundamental (aunque el vídeo quede algo entrecortado), el H.264 tuvo un rendimiento excepcional , ofreciendo imágenes nítidas con mínima distorsión. Es una excelente opción cuando la fluidez no es tan importante.

Cuando el objetivo es mantener un movimiento fluido, AV1 destaca , especialmente a velocidades de bits más altas. Consigue preservar la calidad de la imagen incluso con una compresión agresiva para alcanzar los objetivos de velocidad de fotogramas.

Si bien las diferencias de PSNR entre códecs no siempre son drásticas, sí resaltan las ventajas y desventajas que se deben tener en cuenta al elegir un códec. Algunos priorizan la nitidez; otros buscan un movimiento fluido; y, según el caso de uso, uno puede ser más adecuado que el otro.

Luego volví a ejecutar las mismas pruebas, esta vez utilizando contenido de texto desplazado , algo que realmente resalta la importancia de la resolución y la claridad.

Al priorizar el movimiento, los valores de PSNR en todos los códecs son bastante similares. El contenido no cambia mucho, por lo que las diferencias en la estrategia de compresión no afectan significativamente la calidad general de la imagen.

Aquí es donde la cosa se pone interesante. Con la resolución como prioridad, AV1 supera con creces a los demás códecs, especialmente a velocidades de bits más altas. Su rendimiento en este aspecto es excepcional.

¿Por qué? AV1 incluye optimizaciones específicas para gestionar contenido estático y repetitivo, como texto. Esto le permite mantener una mayor fidelidad de imagen , evitar artefactos y comprimir de forma más eficiente. Esto convierte a AV1 en una opción fantástica para casos de uso como compartir documentos o tutoriales de código, donde la nitidez y la legibilidad de los detalles son cruciales .

En resumen, PSNR ayuda a resaltar una dimensión sutil pero importante de la calidad de la pantalla compartida. Ya sea que priorice el movimiento o la nitidez, comprender cómo se comportan los códecs bajo diferentes restricciones le permite elegir el más adecuado.

¿Qué es QP? Comprensión vs. calidad

Otro factor importante en la calidad de la pantalla compartida es el parámetro de cuantificación ( QP) . Si alguna vez te has preguntado qué controla la pérdida de detalle durante la compresión, aquí lo tienes.

En términos simples, QP le dice al codificador qué tan agresivamente debe comprimir el video .

• Un QP bajo significa menos compresión y mejor calidad de imagen.
• Un QP alto significa más compresión, lo que ahorra ancho de banda, pero puede hacer que el video se vea peor.

Mientras que PSNR nos da un resultado (cuánta calidad de imagen se conservó) , QP nos indica el objetivo del codificador . Por lo tanto, analicé ambos.

En este estudio:

• Los valores QP se extrajeron de las métricas estándar de WebRTC.
• La PSNR se midió después del hecho comparando cada cuadro original con su versión recibida.

Aquí es donde la cosa se puso interesante. AV1 obtuvo las mejores puntuaciones de PSNR , lo que significa que conservó mejor la calidad de imagen, pero también tuvo valores de QP hasta cuatro veces superiores a los de los otros códecs. A primera vista, esto parece contradictorio.

Pero aquí está el truco: cada códec define y gestiona el QP de forma diferente , por lo que los valores no son directamente comparables. Un QP de 50 en un códec no implica necesariamente el mismo nivel de compresión que en otro.

Aun así, las tendencias de QP nos indican algo útil. En todos los códecs, observé que, a medida que aumenta el ancho de banda, el QP disminuye . Esto tiene sentido: con más ancho de banda disponible, los códecs pueden permitirse reducir la compresión y mejorar la calidad de la imagen.

Entonces, si bien no podemos alinear los números QP uno al lado del otro en todos los códecs, aún muestran cómo cada códec ajusta dinámicamente la compresión en función de las condiciones de red disponibles.

En resumen: QP no es una puntuación de calidad, sino un parámetro . Sin embargo, el seguimiento de su variación con el ancho de banda ofrece información útil sobre lo que hace el codificador en segundo plano. Y, combinado con PSNR, ofrece una visión más completa del comportamiento del códec.

Reflexiones finales: Qué significa todo esto para compartir pantalla con WebRTC

Después de analizar en profundidad cómo funciona WebRTC, una cosa está clara: no todos los códecs son iguales , y la mejor opción realmente depende de sus prioridades y su entorno.

Estas son las conclusiones clave de mis experimentos:

AV1: La mejor calidad, el mayor costo

AV1 siempre ofreció la mejor calidad visual , tanto al compartir videos rápidos como al desplazarse lentamente por el texto. Su compresión y optimizaciones avanzadas lo hacen increíblemente eficiente, pero eso tiene un precio. AV1 consume mucha CPU , y dado que la compatibilidad con hardware aún está en desarrollo, aún no es ideal para dispositivos móviles o de bajo consumo.

H.264: El todoterreno sólido

Si busca un equilibrio entre rendimiento y eficiencia , H.264 sigue siendo una excelente opción. Cuenta con amplia compatibilidad, está acelerado por hardware en la mayoría de las plataformas y ofrece un buen rendimiento en casi cualquier situación, especialmente cuando los recursos del sistema o la duración de la batería son un problema.

El contenido importa más de lo que crees

El tipo de contenido que compartes tiene un gran impacto en el rendimiento. El vídeo de alta velocidad consume mucho más de tu CPU y ancho de banda que el contenido estático, como documentos o texto. Elegir el códec y la configuración adecuados para tu contenido puede marcar una gran diferencia en la calidad y el uso de recursos.

El uso de la CPU no es sólo una nota al pie

Gracias a un plugin de Chrome personalizado que creé, pude medir con precisión el uso de la CPU al compartir la pantalla. Los resultados mostraron grandes diferencias en la exigencia de cada códec , lo cual es especialmente importante en dispositivos móviles o en entornos con consumo energético limitado.

¿Qué sigue? ¿Hacia dónde podría llegar esta investigación?

Este experimento abrió la puerta a nuevos y emocionantes pasos. Aquí es donde creo que el trabajo futuro podría tener un impacto aún mayor:

Pruebas en dispositivos móviles

Hasta ahora, todas las pruebas se realizaron en computadoras de escritorio, pero compartir pantalla es igual de común (o incluso más) en teléfonos y tabletas . Probar el rendimiento de estos códecs en dispositivos móviles ofrecería una visión más completa, especialmente en términos de capacidad de respuesta y consumo de energía.

Eficiencia energética

Hablando de energía, los códecs no solo consumen CPU, sino también batería . Investigaciones futuras deberían explorar qué códecs son más eficientes energéticamente , especialmente para largas sesiones de pantalla compartida en dispositivos portátiles.

Ajuste de códecs con tecnología de IA

Imagine si WebRTC pudiera ajustar automáticamente la configuración del códec según su contenido actual y la velocidad de la red. La IA podría hacerlo posible , encontrando dinámicamente el equilibrio perfecto entre calidad y rendimiento en tiempo real.

Envolviéndolo

La elección del códec es más que una simple decisión técnica: afecta directamente la calidad, la fluidez y el uso de recursos de tu experiencia al compartir pantalla. Ya sea que estés desarrollando una herramienta de videoconferencia, una plataforma de colaboración o simplemente optimizando tus propios flujos de trabajo, comprender cómo se comportan estos códecs en diferentes condiciones puede ayudarte a tomar decisiones más inteligentes y efectivas.

A medida que WebRTC evoluciona, también lo harán las herramientas y técnicas que lo rodean. Espero que este análisis profundo ayude a otros a comprender mejor qué sucede tras bambalinas y cómo sacar el máximo provecho de su plataforma de pantalla compartida.

¿Quieres explorar los datos tú mismo?

Si tiene curiosidad por profundizar en los resultados o realizar su propio análisis, he puesto a su disposición el conjunto de datos completo de este estudio aquí:

Descargue el conjunto de datos en Kaggle

Incluye métricas sin procesar de velocidad de fotogramas, resolución, PSNR, QP, uso de CPU y más, todo organizado por códec, tipo de contenido y ancho de banda. Úsalo para tus propios experimentos, benchmarking o simplemente para explorar el comportamiento de WebRTC en diferentes escenarios.