Inicio
» ADMINISTRADOR DE RED
»
Solucionar el alto consumo de CPU en Jitsi Meet en navegadores de clientes.
Solucionar el alto consumo de CPU en Jitsi Meet en navegadores de clientes.
Escenario ilustrativo: Morgan usa una computadora portátil antigua para una videollamada de Jitsi Meet. El ventilador hace mucho ruido y el uso de la CPU del navegador se mantiene alto cuando varias personas tienen sus cámaras encendidas. Este es un ejemplo ficticio, no el informe de un usuario real ni el resultado de una prueba. Nos brinda una forma práctica de diferenciar las posibles causas: decodificación de varias transmisiones de video entrantes, codificación de la cámara de Morgan, efectos de video o un problema con el navegador y los gráficos.
Comience por identificar qué parte de la llamada consume muchos recursos. Luego, modifique una configuración a la vez y compare los resultados en condiciones de reunión similares. Un cliente de Jitsi Meet puede consumir una cantidad considerable de CPU incluso cuando el servidor de Jitsi funciona correctamente; esta guía se centra en el navegador y el dispositivo, no en la capacidad de Videobridge del servidor.
Las ilustraciones de pantalla que se muestran a continuación presentan ejemplos de controles y comprobaciones. La apariencia y disponibilidad exactas de los controles pueden variar según la implementación de Jitsi, el navegador y la versión.
1. Compruebe si el navegador es el proceso que está utilizando la CPU.
Un ejemplo de monitor del sistema resalta el proceso del navegador que ejecuta Jitsi Meet para que pueda separar la carga de la reunión de otras aplicaciones.
Mientras se presenta el problema, abra el Administrador de tareas, el Monitor de actividad o el Monitor del sistema de su sistema operativo. Busque el proceso del navegador y, si la herramienta divide la actividad del navegador en pestañas o tareas, la pestaña de Jitsi Meet. Observe si el uso de la CPU es constante o si solo aumenta brevemente cuando alguien se une o cambia el video. Compruebe también si otra aplicación, como un grabador de pantalla, un juego o un editor de video, está utilizando más recursos del procesador.
Para Morgan, esta primera comprobación responde a una pregunta importante: ¿el navegador soporta la mayor parte de la carga o el ventilador responde a otra aplicación? Registre el número de participantes en la reunión, si la cámara local está encendida y si los efectos están activos. Estos detalles permiten realizar comparaciones posteriores con mayor precisión.
2. Averigüe si los mosaicos de video entrantes son el desencadenante.
Una vista en mosaico con varias personas ilustra por qué una llamada con muchas transmisiones de video visibles puede ser más exigente que un diseño más simple.
Si es posible, compare el mismo dispositivo en una llamada individual con una llamada grupal. En la reunión grupal, observe si el uso de la CPU aumenta al visualizarse más cámaras o al cambiar a una disposición con muchos mosaicos. La renderización y decodificación de múltiples transmisiones de video en movimiento puede sobrecargar el cliente en comparación con un solo video remoto. Esto es un indicio, no una prueba concluyente: el tamaño de la llamada, la resolución de video, los controladores del dispositivo y otras aplicaciones también influyen en la carga.
Si el uso de la CPU se mantiene alto incluso en una llamada individual con los efectos de vídeo desactivados, concéntrese en la cámara local, el navegador y la ruta gráfica. Si el aumento se produce principalmente con muchos mosaicos entrantes, priorice los controles de calidad de recepción y la configuración de diseño o del host.
3. Reduzca la calidad del vídeo entrante cuando el control esté disponible.
El menú de ejemplo muestra una selección de baja calidad de recepción en Gestionar calidad de vídeo; las opciones disponibles dependen de la configuración de la reunión.
Abre el menú «Más acciones» de la reunión y busca «Gestionar calidad de vídeo» . Si tu sistema incluye un control deslizante de calidad, selecciona un valor inferior y observa si las imágenes entrantes se ven menos detalladas y el navegador responde con mayor fluidez. Este control afecta al vídeo que recibes; no necesariamente reduce la resolución de la transmisión de tu cámara.
La guía de configuración actual de Jitsi describe startLastNcómo controlar la cantidad de videos de los participantes que se reciben, e indica que el control deslizante de calidad se usa cuando channelLastNestá configurado. Por lo tanto, no asuma que todas las salas de Jitsi tienen este control ni que se comporta de la misma manera en todas partes. Si no está presente, continúe con los demás pasos o pregunte al administrador de la reunión si la implementación admite la gestión de la calidad de recepción.
4. Pruebe la cámara local por separado.
Desactivar la cámara local es una forma rápida de comprobar si la captura y codificación de tu propio vídeo contribuye a la carga del sistema.
Apaga brevemente la cámara, manteniendo el resto de la llamada lo más similar posible. Si notas una diferencia evidente, es posible que la carga esté relacionada con la captura o codificación de vídeo en tu dispositivo. Esto no elimina el trabajo de decodificación de los vídeos de los demás participantes, por lo que una galería con muchos vídeos podría seguir siendo exigente.
Si el vídeo no es esencial, deje la cámara apagada. Si necesita enviar vídeo, mejore la iluminación y mantenga la cámara estable para que la imagen siga siendo útil incluso con una resolución menor; evite modificar varios controles de calidad simultáneamente, ya que esto dificulta la interpretación del resultado.
5. Desactivar fondos virtuales y otros efectos de vídeo.
El ejemplo de configuración de vídeo muestra el fondo virtual desactivado, una función de diagnóstico útil cuando los efectos de fondo están habilitados.
Si el desenfoque o el fondo virtual están activados, desactívelos para una breve comparación. Los efectos añaden procesamiento a la ruta de vídeo local y pueden no ser adecuados para dispositivos antiguos. La documentación de configuración de Jitsi incluye una opción para desactivar los fondos virtuales en una implementación, pero la posibilidad de que un participante active o desactive esta función depende de la configuración del sitio.
Morgan debería probar esto después de comparar las cámaras: primero con la cámara apagada y luego con la cámara encendida y los efectos desactivados. Si la segunda configuración resulta menos exigente para el portátil que la configuración original, se puede optar por dejar el efecto desactivado. No se debe inferir que el efecto es la causa si la diferencia no es reproducible.
6. Compruebe metódicamente la configuración del navegador y de los gráficos.
El ejemplo de configuración del sistema del navegador muestra la opción de aceleración gráfica; para cambiarla es necesario reiniciar el navegador.
Cierra las pestañas y aplicaciones que consuman muchos recursos y que no estén relacionadas con el problema. Asegúrate de usar un navegador compatible con tu implementación de Jitsi. La página de compatibilidad de navegadores de Jitsi muestra los navegadores de escritorio compatibles, pero esta lista puede cambiar; consulta la versión que utilizas. Si el problema persiste, prueba temporalmente sin extensiones de navegador en un perfil limpio, siempre que la política de tu organización lo permita.
La aceleración de hardware es una variable de diagnóstico, no una solución universal. En Chrome, las instrucciones de soporte de Google describen desactivar la aceleración gráfica y reiniciar el navegador como un paso para solucionar problemas. Si sospecha que hay un problema con la GPU o el controlador, anote la configuración original, cámbiela, reinicie el navegador y compare el resultado. La renderización por software puede transferir la carga de trabajo a la CPU, así que restaure la configuración si el rendimiento empeora. Actualice el navegador y el controlador de gráficos mediante el proceso de actualización compatible habitual; evite instalar controladores de fuentes no confiables.
7. Para un sitio web autoalojado, considere una resolución de captura de cámara más baja.
Un ejemplo de fragmento de código config.js establece una altura de vídeo preferida y máxima de 360 píxeles para la captura local.
Los administradores de una implementación de Jitsi autohospedada pueden revisar la configuración de video después de probar las opciones del participante. La referencia de configuración documenta resolutionla altura de video local preferida y la captura constraintspor separado. Por ejemplo, un administrador podría probar un objetivo de captura más bajo como este en el objeto de configuración válido:
Este es un ejemplo, no un parche universal: confirme la sintaxis y las opciones compatibles con la versión y configuración de Jitsi que utilice en su implementación. Un objetivo de captura inferior sacrifica detalle de la imagen a cambio de menos datos de vídeo para procesar y enviar. Pruebe la calidad de la imagen, el comportamiento de la cámara y el uso de la CPU del cliente en dispositivos representativos antes de aplicar el cambio de forma generalizada. La documentación de referencia indica que las restricciones de captura son independientes de la resolutionconfiguración.
8. Reduzca la cantidad de videos remotos que se mantienen en resolución completa.
La entrada de configuración de ejemplo limita la cantidad de participantes que permanecen con resolución de recepción completa en la vista de mosaico; el valor elegido es ilustrativo.
Para los administradores cuyos usuarios reportan un alto consumo de CPU, principalmente en vistas de mosaico grandes, revisen maxFullResolutionParticipantsesta opción. Jitsi documenta esta opción como el número de participantes que se muestran a resolución completa antes de que el video recibido se reduzca de HD a SD en la vista de mosaico. Una configuración como esta maxFullResolutionParticipants: 4es solo un valor de ejemplo, no una configuración recomendada para todas las organizaciones.
Esta configuración afecta la calidad del video para los participantes y debe evaluarse como una política para todo el sitio. Consulte la documentación de configuración actual para conocer la semántica exacta en su versión, implemente el cambio y pida a los usuarios que comparen el mismo tamaño y distribución de sala. No confunda esta configuración con un aumento en la capacidad del servidor; simplemente modifica lo que reciben los clientes.
¿Cómo se puede saber si la solución funcionó?
Repita la comparación en condiciones similares: mismo dispositivo, navegador, tamaño de la reunión, diseño y estado de la cámara. Compruebe si el uso de la CPU del navegador se estabiliza, si el audio se mantiene nítido, si el vídeo remoto es utilizable y si su propio vídeo sigue satisfaciendo las necesidades de la reunión. Modifique una configuración a la vez y anote el resultado. Si el uso de la CPU sigue siendo alto con la cámara apagada, los efectos desactivados y solo unos pocos vídeos remotos, pruebe con un perfil de navegador compatible y compruebe los límites de gráficos o térmicos del sistema; este patrón indica que va más allá de una opción de vídeo de Jitsi y puede requerir un diagnóstico del dispositivo o del navegador.