Cómo optimizar la resolución y la tasa de bits de Jitsi Meet para ancho de banda bajo

¿Qué deberías cambiar primero en una implementación de Jitsi Meet con ancho de banda bajo?

Comience con tres controles, en este orden: reduzca la resolución de captura de la cámara, disminuya la cantidad de videos remotos que recibe cada cliente y, solo entonces, ajuste los límites de tasa de bits específicos del códec. Esta secuencia es importante porque la resolución y la cantidad de transmisiones recibidas suelen tener el efecto más evidente en el consumo de ancho de banda, mientras que los límites de tasa de bits excesivos pueden hacer que el movimiento se vea borroso sin solucionar la pérdida de paquetes o la inestabilidad de la conexión Wi-Fi.

Jitsi documenta los controles de vídeo del lado del cliente en su referencia de configuración actual . A fecha de 6 de octubre de 2026, la documentación indica que el constraintsobjeto tiene por defecto una altura de captura ideal de 720p, channelLastNpor defecto es ilimitado con -1y startLastNpuede iniciar una conferencia con menos vídeos recibidos antes de que el usuario cambie la configuración de Gestionar calidad de vídeo.

Para una sucursal con recursos limitados, un punto de acceso móvil, un enlace rural o una red Wi-Fi sobrecargada, un objetivo inicial práctico suele ser 360p en lugar de 720p. La página de requisitos de infraestructura de Jitsi proporciona cifras aproximadas de planificación de unos 200 kbit/s para 180p, 500 kbit/s para 360p y 2,5 Mbit/s para 720p, aunque advierte que los requisitos reales varían según muchos factores. Considere estas cifras como referencias para la planificación de capacidad, no como velocidades garantizadas por usuario. Consulte la guía oficial de requisitos de Jitsi Meet .

Vista ilustrativa de la reunión que muestra una opción de calidad 360p para una conexión limitada; la disposición exacta de los controles puede variar según la versión de Jitsi Meet.

¿Deberías limitar la resolución antes que la tasa de bits?

Por lo general, sí. Reducir la altura de captura disminuye la cantidad de píxeles que el codificador debe procesar antes de que comience la asignación de la tasa de bits. La referencia de configuración actual de Jitsi separa el vídeo W3C constraintsdel resolutionvalor preferido anterior e indica que las restricciones se establecen por defecto en una altura de captura ideal de 720p.

Para un sitio donde la estabilidad del video importa más que los detalles faciales finos, prueba un límite de captura de 360p como este:

constraints: {
    video: {
        height: {
            ideal: 360,
            max: 360,
            min: 180
        }
    }
},

Este es un perfil de ejemplo, no la configuración predeterminada de Jitsi. Indica al navegador que priorice 360p y no lo exceda, permitiendo a la vez que la captura se reduzca a 180p si es necesario. No asuma que esto min: 180garantiza una transmisión estable de 180p en condiciones de alta congestión; WebRTC puede responder al ancho de banda disponible, la carga de la CPU, la pérdida de paquetes, las capacidades del dispositivo y el comportamiento del códec.

Ejemplo de configuración de Jitsi autoalojada con un límite de captura de 360p y valores LastN conservadores.

¿Cuántas transmisiones de vídeo remotas debería recibir cada participante?

Si un participante recibe ocho vídeos remotos a la vez, reducir únicamente la resolución de la cámara local no soluciona el problema de la descarga completa. Jitsi ofrece controles LastN específicos para la cantidad de transmisiones de vídeo remoto que se envían a un participante.

El valor predeterminado documentado channelLastNes -1, lo que significa ilimitado. La startLastNopción documentada permite que una conferencia comience con un valor LastN más pequeño, y Jitsi señala que channelLastNse utiliza cuando el usuario cambia el nivel de calidad con el control deslizante Administrar calidad de video.

Un punto de partida prudente para un entorno con ancho de banda limitado es:

channelLastN: 2,
startLastN: 1,

En este ejemplo, un participante comienza recibiendo un video remoto y puede pasar a recibir hasta dos videos remotos, según el comportamiento de calidad de la aplicación. No considere estas 2recomendaciones 1como universales. En un aula donde los estudiantes ven principalmente a un presentador, se puede usar un LastN menor que en una revisión de diseño con cuatro personas donde todos deben permanecer visibles.

¿Qué valores de tasa de bits utiliza Jitsi actualmente?

config.jsLa plantilla y la referencia de configuración actuales de Jitsi muestran maxBitratesVideoniveles específicos para cada códec. En la configuración maestra del proyecto, consultada el 6 de octubre de 2026, AV1 utiliza 100 000 bits/s para el nivel bajo, 300 000 para el estándar y 1 000 000 para el alto; VP9 utiliza 100 000, 300 000 y 1 200 000; VP8 y H.264 utilizan 200 000, 500 000 y 1 500 000 para esos mismos niveles. Puede verificar la plantilla en vivo en el repositorio oficial de Jitsi Meet en GitHub .

Esos valores son valores predeterminados o plantillas, no una garantía de que cada llamada se transmita exactamente a esas velocidades. La estimación del ancho de banda de WebRTC, el control de congestión, el códec seleccionado, la transmisión simultánea o el comportamiento de codificación escalable, la complejidad de la escena, la velocidad de fotogramas y las limitaciones del receptor influyen en lo que se envía realmente.

¿Cuándo tiene sentido bajar los límites?

Reduce los límites cuando conozcas el presupuesto de tu red y la estabilidad del vídeo sea más importante que el nivel de detalle. Por ejemplo, podrías probar un perfil VP8 como este:

videoQuality: {
    vp8: {
        maxBitratesVideo: {
            low: 150000,
            standard: 300000,
            high: 800000
        }
    }
},

Estos números se han etiquetado deliberadamente como un ejemplo para pruebas, no como valores predeterminados de Jitsi. Solo tienen sentido si se negocia VP8 en los puntos finales que le interesan. Si sus clientes de escritorio prefieren AV1 o VP9, ​​ajustar únicamente el objeto VP8 no producirá el efecto esperado.

Ejemplos de límites de velocidad de bits VP8 para una red con recursos limitados; pruébelos con sus propios dispositivos y patrones de llamadas antes de su implementación.

¿Deberías forzar un códec en particular para ahorrar ancho de banda?

No automáticamente. Las versiones modernas de Jitsi muestran el orden de preferencia de códecs y diferentes niveles de tasa de bits predeterminados para AV1, VP9, ​​VP8 y H.264. AV1 y VP9 pueden ser eficientes, pero la elección del códec también afecta el costo de la CPU, la compatibilidad con dispositivos y navegadores, y las funciones de escalabilidad. Una computadora portátil de baja potencia que tenga dificultades para codificar un códec más complejo puede ofrecer una peor calidad de video, incluso si el códec es eficiente en teoría.

Una regla operativa más segura es mantener la configuración actual de Jitsi en cuanto a preferencias de códecs, a menos que las mediciones muestren algún problema. Si cambia el orden de los códecs, realice pruebas en las combinaciones reales de Chrome, Firefox, Safari, Android e iOS que utiliza su organización. No infiera el rendimiento de los códecs a partir de un único navegador de escritorio.

¿Qué ocurre al compartir la pantalla con una conexión lenta?

Compartir pantalla implica una compensación de calidad diferente a la del vídeo de la cámara. El texto y las diapositivas se benefician de una resolución legible, mientras que el movimiento fluido requiere más fotogramas por segundo. Jitsi documenta desktopSharingFrameRatey actualmente indica un valor predeterminado de { min: 5, max: 5 }. Para una reunión con muchas presentaciones, mantener la pantalla compartida a unos 5 fps puede preservar la legibilidad sin consumir ancho de banda en movimientos innecesarios.

Si los usuarios comparten animaciones, rotaciones CAD o videoclips, 5 fps puede resultar demasiado lento. En ese caso, aumente la velocidad de fotogramas con cuidado y observe si se degrada la resolución o la pérdida de paquetes. La documentación oficial de configuración de Jitsi es la referencia correcta para conocer los nombres de las opciones compatibles actualmente.

¿Cómo saber si los cambios realmente ayudaron?

No juzgue solo por si la imagen “se ve bien”. Valide el comportamiento de la red. La API IFrame de Jitsi expone getConnectionStats(), que puede devolver la calidad de la conexión local, el ancho de banda disponible, la tasa de bits de carga y descarga, la tasa de bits de audio y video, la pérdida de paquetes, la información del códec, la velocidad de fotogramas, los fotogramas decodificados, la resolución y los detalles de transporte. Consulte la referencia oficial de funciones de la API IFrame .

Para implementaciones integradas, una comprobación sencilla puede tener este aspecto:

api.getConnectionStats().then(stats => {
    console.log(stats.bitrate);
    console.log(stats.packetLoss);
    console.log(stats.resolution);
    console.log(stats.connectionQuality);
});

Ejecuta el mismo patrón de reunión antes y después de realizar los cambios. Una prueba útil debe tener al menos tres condiciones: ancho de banda normal de oficina, ancho de banda deliberadamente limitado y una llamada realista con varios participantes. Registra si el audio se mantiene inteligible, si el video se congela, si aumenta la pérdida de paquetes, si la resolución de los participantes disminuye o si el uso de la CPU se vuelve excesivo.

Vista ilustrativa de las estadísticas de conexión que muestra el tipo de resolución, velocidad de fotogramas, tasa de bits y valores de pérdida que se deben comparar durante la validación.

¿Con qué perfil de bajo ancho de banda debería empezar?

Estos son perfiles iniciales, no valores óptimos garantizados. La configuración correcta depende de la asimetría entre el enlace ascendente y descendente, el número de participantes, el contenido de la cámara, el códec elegido, la CPU del dispositivo y la calidad que esperan los usuarios.

¿Dónde se debe editar la configuración en un servidor autohospedado?

En una instalación de paquete Debian, Jitsi suele guardar la configuración web del host virtual en /etc/jitsi/meet/<your-hostname>-config.js. La propia documentación de autenticación de Jitsi utiliza esa ruta en sus ejemplos. En implementaciones de Docker, la guía oficial de Docker indica que config.jslos archivos generados dentro del contenedor se recrean al iniciar, por lo que la configuración personalizada debe ir en el CONFIG/web/custom-config.jsarchivo del lado del host. Consulte la guía oficial de Docker para el autoalojamiento .

Antes de editar, copie la configuración existente, modifique un grupo de parámetros a la vez y valide la sintaxis de JavaScript. Evite pegar un ejemplo completo config.jssobre una implementación en funcionamiento, ya que las plantillas originales evolucionan y pueden incluir valores específicos de cada implementación.

¿Cuál es el orden de ajuste más seguro?

1. Primero, mida. Reproduzca el problema de ancho de banda bajo con un número realista de participantes y anote la pérdida de paquetes, la tasa de bits, la resolución y la carga de la CPU.
2. Captura la imagen de la cámara a 360p. Úsala constraints.video.heighty comprueba si mejora la estabilidad del vídeo.
3. Reduzca las transmisiones recibidas. Disminuya startLastNy, si es necesario, channelLastNpara que cada participante no descargue miniaturas innecesarias.
4. Conserva la legibilidad de la pantalla compartida. Mantén baja la velocidad de fotogramas de la pantalla compartida para diapositivas y documentos, a menos que el caso de uso requiera movimiento.
5. Ajusta los límites de tasa de bits del códec al final. Modifica solo los perfiles de códec que tus clientes hayan negociado y compara la calidad antes y después.
6. Vuelva a realizar la prueba en condiciones de congestión. Una configuración que funciona bien en una red LAN puede fallar en la red Wi-Fi de un hotel o en un punto de acceso móvil.

¿Qué debes evitar?

No desactive las funciones de transmisión simultánea o retransmisión solo para reducir el ancho de banda; estos controles afectan la forma en que Jitsi se adapta y se recupera de las pérdidas, y modificarlos puede generar nuevos modos de fallo. No fuerce la transmisión a 180p para todos los usuarios a menos que el caso de uso lo permita. No considere un límite de velocidad de bits como una reserva de ese ancho de banda. Y no optimice únicamente el enlace del servidor ignorando la conexión de última milla en cada extremo.

Por lo tanto, la mejor configuración de Jitsi para ancho de banda bajo no es la que tiene los valores más bajos. Es la que mantiene un audio fiable, permite que el orador activo sea legible, limita el vídeo entrante innecesario y, además, le da al codificador suficiente margen de adaptación. Empiece con 360p, valores LastN conservadores y la configuración predeterminada actual del códec de Jitsi; luego, ajuste los límites de la tasa de bits solo cuando sus mediciones demuestren que hacerlo mejora la reunión en lugar de simplemente disminuir la calidad de la imagen.