¿Por qué mi vista previa de cámara parece 1080p pero la otra persona ve una imagen borrosa?

Tu vista previa del navegador muestra una vista de captura local — el fotograma que la cámara produjo tal como lo entrega getUserMedia() — antes de la codificación WebRTC. Lo que el otro recibe es la transmisión después de que WebRTC haya negociado un códec, una tasa de bits y una resolución basados en las condiciones de red percibidas. Si tu subida es limitada, la pérdida de paquetes alta o la plataforma eligió un códec conservador, el navegador degrada la transmisión en silencio para mantener la conexión estable. La vista previa nunca refleja esta degradación porque se alimenta de la captura local, no de la salida codificada, aunque puede incluir escalado o conversión de color del navegador.

¿Cómo decide el navegador bajar la calidad de mi vídeo?

WebRTC estima el ancho de banda disponible a partir de la pérdida de paquetes, el tiempo de ida y vuelta y el rendimiento. Cuando la pérdida supera aproximadamente el cinco por ciento o el rendimiento cae bajo la tasa actual, el control de congestión baja la tasa objetivo y el codificador ajusta resolución y fps. Como ejemplo, un 1080p a treinta fps necesita unos cuatro a seis megabits por segundo; si el navegador estima solo un megabit, una respuesta común es bajar a 480p a quince fps sin aviso. Los umbrales exactos dependen del códec, la plataforma y el control de congestión — un patrón típico, no garantizado. Es el precio de evitar una congelación total.

¿Qué datos proporciona realmente getStats()?

El método getStats() en una conexión WebRTC devuelve estadísticas detalladas sobre las rutas de codificación, red y recepción. En el lado de envío informa la tasa de fotogramas real capturada, la tasa de fotogramas codificada, la resolución de salida, la tasa de bits en bits por segundo, la tasa de pérdida de paquetes y el tiempo de ida y vuelta. En el lado de recepción informa la tasa de bits entrante, el jitter y los fallos de decodificación. La métrica clave es framesPerSecond en outbound-rtp frente a framesPerSecond en media-source — si difieren significativamente, el codificador está descartando fotogramas para mantener la estabilidad.

¿La supresión de ruido ayuda o perjudica a mi calidad de vídeo?

La supresión de ruido de audio — que filtra el sonido de fondo del micrófono — no afecta directamente a la calidad de vídeo y es generalmente beneficiosa en habitaciones ruidosas. Opera sobre la transmisión de audio, no sobre el vídeo. Algunas plataformas de vídeo, sin embargo, aplican reducción de ruido de vídeo (a veces llamada denoising) en escenas con poca luz o alta varianza, lo que puede suavizar los detalles finos en la transmisión codificada. En un entorno controlado con buena luz, desactivar la reducción de ruido de vídeo puede preservar más detalle. El intercambio: el desorden o movimiento de fondo se vuelven más visibles. Comprueba los ajustes de la plataforma — los controles suelen tener etiquetas distintas.

¿El fondo virtual consume mucha banda ancha?

Sí, puede. El fondo virtual requiere que el navegador separe a la persona del fondo en tiempo real, lo que exige procesamiento GPU adicional y puede aumentar la tasa de bits efectiva en comparación con un fondo real. Esta demanda extra puede llevar al navegador a reducir la resolución o los fps para compensar. Para la mejor calidad de vídeo, usa un fondo real limpio con iluminación consistente en lugar de uno virtual. La segmentación también añade latencia al proceso de codificación, lo que puede hacer que el vídeo se sienta menos responsivo en hardware de gama baja.

Mi cámara funciona bien en mi ordenador pero se ve terrible en la videollamada — ¿qué cambió?

La plataforma de llamadas aplica su propio proceso de codificación sobre la implementación WebRTC del navegador. Algunas plataformas aplican compresión adicional, límites de resolución o topes de fps independientemente de tus condiciones reales. Otras priorizan el audio sobre el vídeo y pueden reducir la calidad de vídeo para mantener el audio estable. La misma cámara que se ve excelente en una vista previa local puede verse pobre en una llamada porque la plataforma eligió una tasa de bits baja para garantizar que todos los participantes reciban un stream estable. Es una decisión de política de la plataforma, no una limitación de hardware.

¿Debería usar VP8, VP9 o H.264 para la mejor calidad de vídeo?

VP9 ofrece buena eficiencia de compresión y resoluciones más altas a la misma tasa de bits, pero requiere más CPU para codificar (WebM Project: VP9 Bitstream Specification (https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.7-20170222-draft.pdf)). H.264 es el más compatible y codifica más rápido (ITU-T: H.264/AVC Standard (https://www.itu.int/rec/T-REC-H.264)), aunque puede necesitar alrededor de un veinte a treinta por ciento más de tasa de bits para igualar la calidad de VP9 en muchas plataformas. VP8 es un códec más antiguo y menos eficiente que VP9 y H.264 en la mayoría de escenarios; si VP9 o H.264 están disponibles, suelen ser preferibles. La negociación de códecs del navegador selecciona automáticamente, pero algunas plataformas permiten anulación manual. No hay un único códec universalmente mejor.

¿Cómo arreglo una videollamada que consistentemente se ve peor que la vista previa de mi cámara?

Empieza midiendo la transmisión real con getStats() para confirmar si el navegador reduce resolución o fps. Si la resolución baja, comprueba tu ancho de banda de subida — las videollamadas necesitan al menos un megabit por segundo para 720p y cuatro para 1080p (Google WebRTC Blog: Bandwidth Estimation, 2016 (https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc); YouTube Help: Recommended Upload Speeds (https://support.google.com/youtube/answer/2853702)). Si la pérdida de paquetes supera el cinco por ciento, la conexión es inestable. Arregla primero la iluminación: un sujeto bien iluminado necesita menos tasa de bits. Luego desactiva la supresión de ruido y el fondo virtual. Si la calidad sigue siendo mala en una plataforma pero buena en otra, la política de codificación es la limitación, no tu hardware.

Test de transmisión real de webcam: lo que el otro lado ve

La imagen en tu vista previa de webcam es una vista de captura local — el feed de la cámara vía [getUserMedia()](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia) — no la salida cruda del sensor. Lo que ve el receptor de tu videollamada es una transmisión codificada que WebRTC ha negociado, comprimido y posiblemente degradado. Esta guía explica la negociación de códecs, cómo usar getStats() en una RTCPeerConnection para medir los parámetros reales y cómo arreglar causas comunes de pérdida de calidad. La herramienta de webcam de este sitio comprueba solo la pista local y los fps; no mide la transmisión WebRTC saliente.

Estás en la videollamada. La ventana de tu navegador muestra una vista previa tuya que se ve nítida y viva — 1080p, dice el ajuste de la cámara. Entonces el colega dice: «¿Puedes acercarte más a la luz? La imagen se ve muy borrosa». Cambias a la vista previa de la cámara y todo se ve perfecto. Eso no es un fallo técnico — es una separación de vistas integrada en WebRTC.

Tu vista previa de cámara es la vista local. Muestra el fotograma que produce tu cámara, tal como getUserMedia() lo entrega al navegador, antes de cualquier codificación de red. Lo que tu colega ve es la transmisión — el vídeo después de que el navegador lo haya codificado y WebRTC haya negociado la calidad basándose en las condiciones de red percibidas. Estos dos vídeos del mismo sujeto pueden ser dramáticamente distintos.

La vista previa no es la salida cruda del sensor. El sensor produce una imagen; el navegador aplica entonces una cadena de procesamiento — escalado, conversión de color, posiblemente recorte y las restricciones que hayas configurado — antes de liberar un fotograma para codificación. Ese procesamiento es parte del modelo de captura del navegador, que puede retrasar o alterar la llegada real de fotogramas. Eso es normal; la imagen que ves ya es una imagen procesada. La diferencia real está entre la ruta local y lo que la codificación de red hace de ella.

Esta guía explica por qué existe esta separación, cómo medir la calidad real de la transmisión y cómo arreglar las causas más comunes de pérdida de calidad. Ten en cuenta que la herramienta de webcam de este sitio comprueba la pista de captura local: muestra los fps y los fotogramas que el navegador recibe de tu cámara, no la calidad que envías a una llamada WebRTC. El lado de la codificación es el trabajo de esta guía.

Webcam con ventana de videollamada WebRTC mostrando la vista previa local y la transmisión enviada

Por qué la vista previa miente

La vista previa muestra la vista de captura local: un fotograma producido por tu cámara, entregado a través de getUserMedia() y procesado por el navegador antes de llegar a tu ventana. Muestra las capacidades de tu dispositivo, no la entrega a la otra persona.

La transmisión es otra tubería. El navegador codifica los fotogramas locales con un códec — típicamente VP8 o H.264, AV1 en dispositivos más nuevos — y WebRTC decide qué tasa de bits, resolución y fps se envían según las condiciones de red. Lo que ves en la vista previa y lo que atraviesa la red después de la codificación son dos vídeos distintos: uno antes, otro después de la codificación.

Esta separación existe porque la codificación es el único lugar donde se intercambia calidad por ancho de banda. Sin degradación, una videollamada se congelaría bajo malas condiciones de red. El precio es que la pérdida de calidad permanece invisible en la vista previa — la vista previa se alimenta de la captura local, no de la salida codificada, por lo que no puedes leer la calidad que ve la otra persona desde el cuadro de vista previa. Si la resolución de tu llamada es más baja que los ajustes de tu cámara, la causa suele estar relacionada con el ancho de banda — cuánto puede gastar tu navegador y si tu conexión puede transportar la transmisión que crees enviar — pero la carga de CPU, la selección del codificador, las políticas de la plataforma y la configuración de restricciones también pueden contribuir o dominar.

La vista previa es la promesa; la transmisión es la entrega. Son distintas porque se alimentan de rutas distintas. El codificador negocia silenciosamente tres parámetros, y cada uno puede cambiar durante la llamada sin notificación:

Resolución — el ancho y alto de los fotogramas codificados, que pueden caer de 1920×1080 a 1280×720 o 640×480 por sí solos.
Fps — cuántos fotogramas por segundo sobreviven a la codificación; suele caer primero (de 30 a 15 o menos) porque reducir a la mitad los fps reduce la tasa de datos a la mitad sin cambiar la resolución — aunque algunas implementaciones reducen la resolución, dependiendo del códec y la plataforma.
Tasa de bits — cuántos bits por segundo el codificador puede gastar, lo que fija el nivel de compresión general. Estos tres valores determinan todo lo que ve la otra parte. Una imagen 1080p comprimida a una tasa de bits baja luce suave y borrosa. Un stream de 30 fps que de repente corre a 10 fps luce entrecortado y antinatural. Cuando entiendes que la vista previa no reporta ninguno de estos valores, el misterio de la mala llamada con una gran cámara se disuelve.

SDP negocia antes de enviar un fotograma

La negociación comienza antes de enviar el primer fotograma. Cuando te unes a una llamada, la plataforma y tu navegador intercambian un Offer y Answer de Session Description Protocol (SDP). El SDP anuncia los códecs y capacidades multimedia que cada lado soporta; la resolución y los fps reales se negocian luego a través de parámetros de envío y recepción y se limitan por la estimación de ancho de banda. La selección real del códec depende del navegador, la plataforma, los parámetros SDP y las capacidades del hardware. Las opciones comunes incluyen VP9, H.264, VP8 y AV1, pero no hay un orden de preferencia fijo entre todas las plataformas. La selección de códec es solo el principio. Una vez que la llamada está activa, un segundo mecanismo toma el control: estimación de ancho de banda. WebRTC monitorea continuamente la ruta de red en ambas direcciones y ejecuta un algoritmo de control de congestión — generalmente Google Congestion Control — que realiza tres mediciones continuas:

Pérdida de paquetes, reportada por el receptor mediante mensajes de retroalimentación RTCP.
Tiempo de ida y vuelta, el retraso entre enviar un paquete y recibir confirmación de su llegada.
Throughput, la tasa efectiva a la que los datos cruzan realmente la conexión. El algoritmo alimenta estas mediciones a un modelo que estima cuánto ancho de banda puede soportar la red actualmente. Esa estimación se convierte en una tasa de bits objetivo que se entrega al codificador, y este adapta su salida para ajustarse. El bucle es continuo y rápido: cuando la estimación cae, el codificador recodifica a una tasa de bits menor en una fracción de segundo. Los umbrales son aproximados y dependen del algoritmo de control de congestión. Una pérdida de paquetes sostenida por encima de aproximadamente cinco por ciento puede activar una reducción de la tasa de bits objetivo, pero el comportamiento exacto —cuánto cae la tasa, si la resolución o los fps también cambian, y en qué nivel de pérdida— varía según el algoritmo, el códec y la plataforma. Un stream de 1080p a 30 fps necesita típicamente alrededor de cuatro a seis megabits por segundo de ancho de banda de subida para verse limpio. Si el estimador concluye que solo hay un megabit disponible, no intenta forzar el stream: reduce el objetivo y el codificador responde bajando la resolución a 480p y los fps a 15 (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP).

Nadie elige conscientemente una calidad más baja. La degradación ocurre a través de una serie de decisiones de negociación y codificación que suceden en segundo plano. Los principales tomadores de decisiones: el códec determina cuánta compresión puede aplicar el codificador, a qué tasas de bits puede trabajar y qué resoluciones y fps soporta; la tasa de bits, que WebRTC estima a partir de la pérdida de paquetes, el tiempo de ida y vuelta y el rendimiento; la política de la plataforma, que a menudo impone sus propios límites de calidad; y el dispositivo, cuya CPU codifica en tiempo real y puede bajar los fps o la resolución cuando la carga es alta. Ninguna de estas decisiones muestra un mensaje. La vista previa sigue viéndose genial.

Una vez que WebRTC negocia los parámetros, el navegador codifica continuamente. El proceso es constante:

La pista de captura entrega fotogramas de la cámara.
El codificador comprime cada fotograma según los parámetros negociados.
El empaquetador envuelve los fotogramas codificados en paquetes RTP.
Los paquetes cruzan la conexión de red.
El lado receptor decodifica los paquetes de vuelta a vídeo.

Cada etapa puede costar calidad. El codificador puede descartar fotogramas para mantener la tasa de bits. La red puede perder paquetes. El receptor puede sufrir problemas de decodificación. La calidad no es un paso — es el paso más débil de la cadena. La codificación no es determinista. Con ancho de banda limitado, el codificador debe tomar decisiones: resolución más baja con fps más altos, o fps más bajos con resolución más alta, o más compresión con más artefactos. Estas decisiones las toman las heurísticas del codificador, no la plataforma, y pueden cambiar a medida que cambian las condiciones. Una medición es una instantánea, no una garantía.

Tres patrones de fallo ocultos

La vista previa permanece perfecta porque se toma antes del codificador. Solo la transmisión muestra el daño, y cada síntoma apunta a una causa distinta.

La trampa de la tasa de bits

Síntomas: La vista previa es nítida y la CPU está libre, pero el receptor ve una imagen borrosa que no mejora. Las grabaciones locales se ven bien. Diagnóstico: La estimación de red ha limitado la tasa de bits y el codificador ha reducido la resolución. Comprueba tu subida y compárala con los 4–6 Mbps que suele necesitar 1080p30. Otros vídeos, descargas y sincronizaciones comparten ese presupuesto.

El umbral de pérdida

Síntomas: Las imágenes fijas parecen correctas, pero el movimiento se vuelve robótico; el audio continúa estable mientras el vídeo se congela y vuelve con menos fps. Diagnóstico: La pérdida de paquetes supera aproximadamente el cinco por ciento de forma intermitente. El control de congestión recorta la tasa objetivo y el codificador descarta fotogramas. Revisa interferencias Wi-Fi, el cable Ethernet y cualquier VPN. El umbral exacto depende del algoritmo, el códec y la plataforma.

El congelamiento del fotograma clave

Síntomas: Durante los primeros dos a cinco segundos de la llamada o después de compartir pantalla, el receptor ve una imagen congelada o muy borrosa; luego recupera la nitidez. Diagnóstico: Los fotogramas clave contienen la imagen completa; los fotogramas delta solo los cambios. Si se pierde un paquete delta, el receptor puede pedir una retransmisión (NACK) o un fotograma clave nuevo (PLI/FIR). Si no llega a tiempo, espera al siguiente fotograma clave. Intervalos cortos recuperan antes pero consumen más ancho de banda; intervalos largos son eficientes pero hacen más visibles las pérdidas. Es un comportamiento del códec, no necesariamente una avería. Comparación entre una vista previa de webcam nítida en 1080p y una transmisión degradada y pixelada en 480p

Medir la transmisión real con getStats()

La API WebRTC getStats() expone lo que hace el codificador. En el informe de la RTCPeerConnection activa filtra outbound-rtp con kind: video y compáralo con media-source:

framesPerSecond (en la entrada media-source) — la tasa de fotogramas que la cámara entrega al codificador. Si está por debajo de 30 en una cámara de 30 fps, el problema está en la propia ruta de captura — a menudo, un problema de contención de ancho de banda USB que nuestra guía sobre contención de ancho de banda USB explica cómo diagnosticar.
framesPerSecond (en la entrada outbound-rtp) — la tasa de fotogramas que el codificador produce realmente. Cuando es inferior a la tasa de entrada, el codificador está descartando fotogramas.
frameWidth y frameHeight (en la entrada outbound-rtp) — la resolución codificada. Compárala con los ajustes de tu llamada; cualquier diferencia es una degradación silenciosa.
bytesSent (en la entrada outbound-rtp) — el total de datos codificados. Muestrea dos veces con un segundo de separación y multiplica la diferencia por ocho para obtener la tasa de bits real.
packetsSent y packetsLost — ten en cuenta que packetsLost en la entrada outbound-rtp puede faltar; la tasa de pérdida se lee de forma más fiable en la entrada remote-inbound-rtp, que informa desde la perspectiva del receptor.
currentRoundTripTime (en la entrada candidate-pair) — la demora de red. Un RTT alto combinado con pérdida indica congestión.

Los navegadores pueden omitir campos o nombrarlos de forma ligeramente distinta. Chrome y Edge registran los valores y sus cambios en chrome://webrtc-internals. Compara una llamada en reposo con otra reunión cargada: si outbound-rtp cae de 30 a 18 fps mientras media-source sigue en 30, el problema aparece después de la captura local. La prueba de webcam sirve como referencia de captura, no como medición del stream WebRTC saliente.

Zoom, Meet y Teams no usan la misma cámara

La misma cámara puede verse diferente en cada servicio porque cada uno aplica su propia política sobre WebRTC:

Zoom suele priorizar la estabilidad y puede limitar la resolución según la versión, la cuenta y la configuración de la reunión.
Google Meet se adapta al ancho de banda medido; normalmente baja pronto la resolución y la recupera cuando mejoran las condiciones.
Microsoft Teams añade su propia cadena de codificación y posprocesado, con compresión adicional en algunos casos.
WebRTC directo en el navegador no añade una política de plataforma y es la referencia más cercana a lo que pueden entregar tu hardware y tu red.

Comparar Zoom con Meet no es probar la cámara: es comparar decisiones de codificación. Si el stream directo es limpio y una plataforma se ve mal, esa política es el límite. Estas tendencias cambian con la versión, el tipo de cuenta y el número de participantes.

Siete pasos para limpiar el stream

Mide primero: registra resolución, fps y tasa de bits en chrome://webrtc-internals o getStats().
Comprueba la subida: reserva al menos 1 Mbps para 720p y unos 4 Mbps para 1080p; usa Ethernet si es posible.
Mejora la iluminación: una cara bien iluminada se comprime mejor que una escena oscura y ruidosa.
Desactiva la reducción de ruido de vídeo si el entorno ya está bien iluminado; el nombre y el control dependen de la plataforma.
Desactiva el fondo virtual: la segmentación consume GPU y puede elevar la tasa de bits efectiva.
Revisa el códec: VP9 suele ofrecer más calidad por bit; H.264 puede codificar más rápido cuando la CPU está al límite.
Prueba otro servicio: si solo falla una plataforma, su política es más probable que un defecto de la cámara.

Conclusión

La vista previa es la autoimagen local de tu cámara: una visión favorable de lo que tu cámara puede entregar al navegador. La transmisión es lo que el mundo ve realmente — negociada, comprimida y moldeada por las condiciones de red y la política de la plataforma. Son dos vídeos distintos del mismo sujeto, y solo uno importa para cómo te ven. Si alguna vez te has preguntado por qué tu cámara se ve genial en tu pantalla pero terrible en la llamada, ahora tienes la respuesta y la herramienta para medirla.

Abre chrome://webrtc-internals. Únete a tu próxima llamada. Observa las entradas outbound-rtp. Si frameWidth o framesPerSecond están por debajo de lo que configuraste en los ajustes de tu cámara, la degradación está ocurriendo. La causa suele estar relacionada con el ancho de banda — cuánto puede gastar tu navegador y si tu conexión puede transportar la transmisión que crees enviar — pero la carga de CPU, la selección del codificador, las políticas de la plataforma y la configuración de restricciones también pueden contribuir o dominar.