Pourquoi mon aperçu de caméra semble en 1080p mais l'autre personne voit une image floue ?

Votre aperçu de navigateur montre une vue de capture locale — l'image produite par la caméra telle que livrée par getUserMedia() — avant l'encodage WebRTC. Ce que reçoit l'autre personne est le flux après que WebRTC a négocié un codec, un débit et une résolution basés sur les conditions réseau perçues. Si votre bande passante montante est limitée, la perte de paquets élevée ou la plateforme a choisi une configuration de codec prudente, le navigateur dégrade le flux en silence pour maintenir une connexion stable. L'aperçu ne reflète jamais cette dégradation parce qu'il est alimenté par la capture locale, pas par la sortie encodée, bien qu'il puisse inclure une mise à l'échelle ou une conversion de couleur du navigateur.

Comment le navigateur décide-t-il de baisser la qualité de ma vidéo ?

WebRTC estime la bande passante disponible à partir de la perte de paquets, du temps aller-retour et du débit. Quand la perte dépasse environ cinq pour cent ou que le débit tombe sous le débit actuel, le contrôle de congestion baisse le débit cible et l'encodeur ajuste résolution et fps. Comme exemple, un 1080p à trente fps nécessite environ quatre à six mégabits par seconde ; si le navigateur estime un seul mégabit, une réponse courante est 480p à quinze fps sans avertissement. Les seuils exacts dépendent du codec, de la plateforme et du contrôle de congestion — un schéma typique, pas garanti. C'est le prix d'un gel complet évité.

Quelles données fournit réellement getStats() ?

La méthode getStats() sur une connexion WebRTC renvoie des statistiques détaillées sur les chemins d'encodage, de réseau et de réception. Côté envoi, elle rapporte la fréquence d'images réelle capturée, la fréquence d'images encodée, la résolution de sortie, le débit en bits par seconde, le taux de perte de paquets et le temps aller-retour. Côté réception, elle rapporte le débit entrant, la gigue et les échecs de décodage. La métrique clé est framesPerSecond sur outbound-rtp par rapport à framesPerSecond sur media-source — s'ils diffèrent significativement, l'encodeur abandonne des images pour maintenir la stabilité.

La suppression de bruit aide-t-elle ou nuit-elle à ma qualité vidéo ?

La suppression de bruit audio — qui filtre le son de fond du micro — n'affecte pas directement la qualité vidéo et est généralement bénéfique dans les pièces bruyantes. Elle opère sur le flux audio, pas la vidéo. Certaines plateformes vidéo appliquent cependant une réduction de bruit vidéo (parfois appelée débruiteur) dans les scènes à faible lumière ou à forte variance, ce qui peut adoucir les détails fins du flux encodé. Dans un environnement contrôlé bien éclairé, désactiver la réduction de bruit vidéo peut préserver plus de détails. Le compromis : le désordre ou le mouvement de fond deviennent plus visibles. Vérifiez les réglages de la plateforme — les contrôles sont souvent étiquetés différemment.

L'arrière-plan virtuel consomme-t-il beaucoup de bande passante ?

Oui, cela peut. L'arrière-plan virtuel exige que le navigateur sépare la personne du fond en temps réel, ce qui demande un traitement GPU supplémentaire et peut augmenter le débit effectif par rapport à un fond réel. Cette demande supplémentaire peut amener le navigateur à réduire la résolution ou les fps pour compenser. Pour la meilleure qualité vidéo, utilisez un fond réel propre avec un éclairage uniforme plutôt qu'un fond virtuel. La segmentation ajoute aussi de la latence au pipeline d'encodage, ce qui peut rendre la vidéo moins réactive sur du matériel d'entrée de gamme.

Ma caméra fonctionne bien sur mon ordinateur mais paraît terrible en appel vidéo — qu'est-ce qui a changé ?

La plateforme d'appel applique son propre pipeline d'encodage par-dessus l'implémentation WebRTC du navigateur. Certaines plateformes appliquent une compression supplémentaire, des limites de résolution ou des plafonds de fps indépendamment de vos conditions réelles. D'autres priorisent l'audio sur la vidéo et peuvent réduire la qualité vidéo pour garder l'audio stable. La même caméra qui paraît excellente en aperçu local peut paraître médiocre en appel parce que la plateforme a choisi un débit bas pour garantir que tous les participants reçoivent un flux stable. C'est une décision de politique de la plateforme, pas une limitation matérielle.

Faut-il utiliser VP8, VP9 ou H.264 pour la meilleure qualité vidéo ?

VP9 offre une bonne efficacité de compression et des résolutions plus élevées à débit égal, mais nécessite plus de CPU pour l'encodage (WebM Project: VP9 Bitstream Specification (https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.7-20170222-draft.pdf)). H.264 est le plus largement compatible et encode plus vite (ITU-T: H.264/AVC Standard (https://www.itu.int/rec/T-REC-H.264)), bien qu'il puisse nécessurer environ vingt à trente pour cent de débit supplémentaire pour égaler la qualité de VP9 sur de nombreuses plateformes. VP8 est un codec plus ancien et moins efficace que VP9 et H.264 dans la plupart des scénarios ; si VP9 ou H.264 est disponible, il est généralement préférable. La négociation de codecs du navigateur sélectionne automatiquement, mais certaines plateformes permettent un remplacement manuel. Il n'y a pas de codec universellement supérieur.

Comment corriger un appel vidéo qui paraît systématiquement pire que l'aperçu de ma caméra ?

Commencez par mesurer le flux réel avec getStats() pour confirmer si le navigateur réduit la résolution ou les fps. Si la résolution baisse, vérifiez votre bande passante montante — les appels vidéo nécessitent au moins un mégabit par seconde pour 720p et quatre pour 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 perte de paquets dépasse cinq pour cent, la connexion est instable. Corrigez d'abord l'éclairage : un sujet bien éclairé nécessite moins de débit. Désactivez ensuite la suppression de bruit et l'arrière-plan virtuel. Si la qualité reste médiocre sur une plateforme mais bonne sur une autre, la politique d'encodage est la contrainte, pas votre matériel.

Test de flux réel : ce que l'autre côté voit de votre webcam

L'aperçu de votre webcam montre la capture locale livrée par [getUserMedia()](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia), pas la vidéo réellement envoyée. Avant d'atteindre les autres participants, l'image est négociée, encodée, compressée et parfois dégradée par WebRTC. Ce guide explique comment comparer media-source et outbound-rtp avec getStats(), lire la résolution, les images par seconde, le débit et les pertes, puis isoler une limite de réseau, de processeur, de codec ou de plateforme. L'outil webcam du site reste utile comme référence locale, mais il ne mesure pas à lui seul le flux WebRTC sortant.

Vous êtes en appel vidéo. La fenêtre de votre navigateur montre un aperçu de vous qui semble net et vivant — 1080p, dit le réglage de la caméra. Puis le collègue dit : « Tu peux te rapprocher de la lumière ? L’image est toute floue ». Vous basculez sur l’aperçu de la caméra et tout semble parfait. Ce n’est pas un défaut technique — c’est une séparation de vues intégrée à WebRTC.

Votre aperçu de caméra est la vue locale. Il montre l’image que produit votre caméra, telle que getUserMedia() la livre au navigateur, avant tout encodage réseau. Ce que voit votre collègue est le flux — la vidéo après que le navigateur l’a encodée et que WebRTC a négocié la qualité en fonction des conditions réseau perçues. Ces deux vidéos du même sujet peuvent être dramatiquement différentes.

L’aperçu n’est pas la sortie brute du capteur. Le capteur produit une image ; le navigateur applique ensuite une chaîne de traitement — mise à l’échelle, conversion de couleur, éventuellement recadrage et les contraintes que vous avez configurées — avant de libérer une image pour l’encodage. Ce traitement fait partie du modèle de capture du navigateur, qui peut retarder ou modifier l’arrivée réelle des images. C’est normal ; l’image que vous voyez est déjà une image traitée. La vraie différence se situe entre le chemin local et ce que l’encodage réseau en fait.

Ce guide explique pourquoi cette séparation existe, comment mesurer la qualité réelle du flux et comment corriger les causes courantes de perte de qualité. Notez que l’outil webcam de ce site vérifie la piste de capture locale : il affiche les fps et les images que le navigateur reçoit de votre caméra, pas la qualité que vous envoyez dans un appel WebRTC. Le côté encodage est le travail de ce guide.

Webcam avec fenêtre d'appel vidéo WebRTC montrant l'aperçu local et le flux envoyé

Pourquoi l’aperçu ment

L’aperçu montre la vue de capture locale : une image produite par votre caméra, livrée via getUserMedia() et traitée par le navigateur avant d’atteindre votre fenêtre. Il montre les capacités de votre appareil, pas la livraison à l’autre personne.

Le flux est une autre chaîne. Le navigateur encode les images locales avec un codec — typiquement VP8 ou H.264, AV1 sur les appareils plus récents — et WebRTC décide quel débit, quelle résolution et quels fps sont envoyés en fonction des conditions réseau. Ce que vous voyez dans l’aperçu et ce qui traverse le réseau après l’encodage sont deux vidéos différentes : une avant, une après l’encodage.

Cette séparation existe parce que l’encodage est le seul endroit où la qualité s’échange contre la bande passante. Sans dégradation, un appel vidéo gèlerait sous de mauvaises conditions réseau. Le prix est que la perte de qualité reste invisible dans l’aperçu — l’aperçu est alimenté par la capture locale, pas par la sortie encodée, donc vous ne pouvez pas lire la qualité que voit l’autre personne depuis la fenêtre d’aperçu. Si la résolution de votre appel est inférieure à vos réglages de caméra, la cause est typiquement liée à la bande passante — combien votre navigateur peut dépenser et si votre connexion peut transporter le flux que vous croyez envoyer — mais la charge CPU, la sélection de l’encodeur, les politiques de la plateforme et la configuration des contraintes peuvent aussi contribuer ou dominer.

L’aperçu est la promesse ; le flux est la livraison. Ils sont différents parce qu’ils sont alimentés par des chemins différents. L’encodeur négocie silencieusement trois paramètres, et chacun peut changer en cours d’appel sans notification :

Résolution — la largeur et la hauteur des images encodées, qui peuvent tomber de 1920×1080 à 1280×720 ou 640×480 d’elles-mêmes.
Fréquence d’images — combien d’images par seconde survivent à l’encodage ; elle baisse souvent en premier (de 30 à 15 ou moins) car diviser par deux la fréquence divise le débit de données sans changer la résolution — certaines implémentations réduisent cependant la résolution, selon le codec et la plateforme.
Débit binaire — combien de bits par seconde l’encodeur est autorisé à dépenser, ce qui détermine le niveau de compression global. Ces trois valeurs déterminent tout ce que l’autre côté voit. Une image 1080p compressée à un faible débit binaire paraît floue et baveuse. Un flux de 30 fps qui tourne soudainement à 10 fps paraît saccadé et contre nature. Quand vous comprenez que l’aperçu ne rapporte aucune de ces valeurs, le mystère du mauvais appel avec une bonne caméra se dissout.

SDP négocie avant d’envoyer une image

La négociation commence avant l’envoi de la première image. Quand vous rejoignez un appel, la plateforme et votre navigateur échangent une offre et une réponse Session Description Protocol (SDP). Le SDP annonce les codecs et les capacités multimédias que chaque côté prend en charge ; la résolution et la fréquence d’images réelles sont ensuite négociées via des paramètres d’envoi et de réception et limitées par l’estimation de bande passante. La sélection réelle du codec dépend du navigateur, de la plateforme, des paramètres SDP et des capacités matérielles. Les choix courants incluent VP9, H.264, VP8 et AV1, mais il n’y a pas d’ordre de préférence fixe entre toutes les plateformes. La sélection du codec n’est que le début. Une fois l’appel en cours, un deuxième mécanisme prend le relais : l’estimation de bande passante. WebRTC surveille en continu le chemin réseau dans les deux sens et exécute un algorithme de contrôle de congestion — généralement Google Congestion Control — qui effectue trois mesures en continu :

Perte de paquets, signalée par le récepteur via les messages de rétroaction RTCP.
Temps aller-retour, le délai entre l’envoi d’un paquet et la réception d’un accusé de réception.
Débit utile, la vitesse effective à laquelle les données traversent réellement la connexion. L’algorithme alimente ces mesures dans un modèle qui estime la bande passante que le réseau peut actuellement supporter. Cette estimation devient un débit binaire cible transmis à l’encodeur, qui adapte sa sortie pour s’y ajuster. La boucle est continue et rapide : quand l’estimation baisse, l’encodeur recode à un débit inférieur en une fraction de seconde. Les seuils sont approximatifs et dépendent de l’algorithme de contrôle de congestion. Une perte de paquets soutenue au-dessus d’environ cinq pour cent peut déclencher une réduction du débit cible, mais le comportement exact — de combien le débit baisse, si la résolution ou la fréquence changent aussi, et à quel niveau de perte — varie selon l’algorithme, le codec et la plateforme. Un flux 1080p à 30 fps nécessite généralement environ quatre à six mégabits par seconde de bande passante montante pour paraître net. Si l’estimateur conclut qu’un seul mégabit est disponible, il ne tente pas de forcer le flux : il baisse la cible, et l’encodeur répond en abaissant la résolution à 480p et la fréquence à 15 fps (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP).

Personne ne choisit consciemment une qualité plus basse. La dégradation se produit à travers une série de décisions de négociation et d’encodage qui se déroulent en arrière-plan. Les principaux décideurs : le codec détermine combien de compression l’encodeur peut appliquer, à quels débits il peut travailler et quelles résolutions et fps il supporte ; le débit, que WebRTC estime à partir de la perte de paquets, du temps aller-retour et du débit ; la politique de la plateforme, qui impose souvent ses propres limites de qualité ; et l’appareil, dont le CPU encode en temps réel et peut baisser les fps ou la résolution lorsque la charge est élevée. Aucune de ces décisions n’affiche de message. L’aperçu continue de sembler superbe.

Une fois que WebRTC a négocié les paramètres, le navigateur encode en continu. Le processus est constant :

La piste de capture livre des images de la caméra.
L’encodeur compresse chaque image selon les paramètres négociés.
Le multiplexeur emballe les images encodées en paquets RTP.
Les paquets traversent la connexion réseau.
Le côté récepteur décode les paquets en vidéo.

Chaque étape peut coûter de la qualité. L’encodeur peut abandonner des images pour maintenir le débit. Le réseau peut perdre des paquets. Le récepteur peut souffrir de problèmes de décodage. La qualité n’est pas une étape — c’est le maillon le plus faible de la chaîne. L’encodage n’est pas déterministe. Avec une bande passante limitée, l’encodeur doit prendre des décisions : résolution plus basse avec fps plus élevés, ou fps plus bas avec résolution plus haute, ou plus de compression avec plus d’artefacts. Ces décisions sont prises par les heuristiques de l’encodeur, pas par la plateforme, et peuvent changer à mesure que les conditions changent. Une mesure est un instantané, pas une garantie.

Trois schémas de panne invisibles

L’aperçu reste impeccable parce qu’il est prélevé avant l’encodeur. Seul le flux envoyé révèle le problème, et chaque symptôme demande une vérification différente.

Le piège du débit

Symptômes : l’aperçu est net, le CPU est peu chargé, mais le destinataire voit une image floue qui ne s’améliore pas. Les enregistrements locaux restent bons. Diagnostic : l’estimation réseau plafonne le débit et l’encodeur réduit la résolution. Mesurez la montante et comparez-la aux 4–6 Mbit/s généralement nécessaires au 1080p30. Les autres vidéos, téléchargements et synchronisations partagent cette capacité.

Le seuil de perte

Symptômes : les images fixes sont correctes, mais le mouvement devient saccadé ; l’audio reste fluide alors que la vidéo gèle brièvement puis revient avec moins de fps. Diagnostic : la perte de paquets dépasse par moments environ cinq pour cent. Le contrôle de congestion réduit le débit cible et l’encodeur abandonne des images. Vérifiez les interférences Wi-Fi, le câble Ethernet et le VPN. Le seuil exact varie selon l’algorithme, le codec et la plateforme.

Le gel sur image clé

Symptômes : pendant les deux à cinq premières secondes ou après un partage d’écran, l’autre côté voit une image figée ou très brouillée, puis la netteté revient. Diagnostic : une image clé contient toute l’image ; une image delta ne contient que les changements. Après la perte d’un paquet delta, le récepteur peut demander une retransmission (NACK) ou une nouvelle image clé (PLI/FIR). Sans réponse rapide, il attend l’image clé suivante. Des intervalles courts récupèrent plus vite mais consomment du débit ; des intervalles longs sont efficaces mais rendent chaque perte plus visible. Ce comportement vient du codec et n’indique pas forcément une panne. Comparaison entre un aperçu webcam net en 1080p et un flux réel dégradé et pixelisé en 480p

Mesurer le flux réel avec getStats()

L’API WebRTC getStats() expose le travail réel de l’encodeur. Dans le rapport de la RTCPeerConnection active, filtrez outbound-rtp avec kind: video et comparez-le à media-source :

framesPerSecond (sur l’entrée media-source) — la fréquence d’images que la caméra livre à l’encodeur. Si elle est inférieure à 30 sur une caméra de 30 fps, le chemin de capture lui-même est en cause — souvent un problème de contention de bande passante USB, que notre guide sur la contention de bande passante USB explique comment diagnostiquer.
framesPerSecond (sur l’entrée outbound-rtp) — la fréquence d’images que l’encodeur produit réellement. Quand elle est inférieure à la fréquence d’entrée, l’encodeur abandonne des images.
frameWidth et frameHeight (sur l’entrée outbound-rtp) — la résolution encodée. Comparez-la avec vos réglages d’appel ; tout écart est une dégradation silencieuse.
bytesSent (sur l’entrée outbound-rtp) — le total des données encodées. Échantillonnez deux fois à une seconde d’intervalle et multipliez la différence par huit pour obtenir le débit réel.
packetsSent et packetsLost — notez que packetsLost sur l’entrée outbound-rtp n’est pas toujours renseigné ; le taux de perte se lit de manière plus fiable sur l’entrée remote-inbound-rtp, qui rapporte la perspective du récepteur.
currentRoundTripTime (sur l’entrée candidate-pair) — le délai réseau. Un RTT élevé combiné à des pertes indique une congestion.

Les navigateurs peuvent omettre certains champs ou les nommer légèrement différemment. Chrome et Edge enregistrent les valeurs et leur évolution dans chrome://webrtc-internals. Comparez un appel au repos avec une réunion chargée : si outbound-rtp passe de 30 à 18 fps alors que media-source reste à 30, la limitation intervient après la capture locale. Le test webcam fournit une référence de capture, pas la mesure du flux WebRTC sortant.

Zoom, Meet et Teams sont trois caméras différentes

La même caméra peut produire une image différente selon le service, car chaque plateforme ajoute sa propre politique à WebRTC :

Zoom privilégie souvent la stabilité et peut plafonner la résolution selon la version, le compte et les réglages de réunion.
Google Meet suit la bande passante mesurée, baisse souvent tôt la résolution et la rétablit lorsque le réseau s’améliore.
Microsoft Teams applique sa propre chaîne d’encodage et de post-traitement, avec une compression supplémentaire possible.
WebRTC direct dans le navigateur n’ajoute pas de politique de plateforme et fournit la référence la plus proche des capacités du matériel et du réseau.

Comparer Zoom et Meet ne teste donc pas la caméra : cela compare leurs décisions d’encodage. Si le flux WebRTC direct est bon et qu’une seule plateforme est mauvaise, sa politique est probablement la contrainte. Ces tendances varient selon la version, le compte et le nombre de participants.

Sept étapes vers un flux propre

Mesurez d’abord : notez résolution, fps et débit dans chrome://webrtc-internals ou getStats().
Vérifiez la montante : prévoyez au moins 1 Mbit/s pour 720p et environ 4 Mbit/s pour 1080p ; préférez l’Ethernet si possible.
Améliorez la lumière : un visage bien éclairé se compresse mieux qu’une scène sombre et bruitée.
Désactivez la réduction de bruit vidéo lorsque la pièce est calme et bien éclairée ; le réglage dépend du service.
Désactivez l’arrière-plan virtuel : la segmentation consomme du GPU et peut augmenter le débit nécessaire.
Vérifiez le codec : VP9 est souvent plus efficace par bit ; H.264 encode plus vite lorsque le CPU est limité.
Essayez un autre service : si un seul service dégrade l’image, sa politique est plus probable qu’un défaut matériel.

Conclusion

L’aperçu est l’auto-image locale de votre caméra : une vue favorable de ce que votre caméra peut livrer au navigateur. Le flux est ce que le monde voit réellement — négocié, compressé et façonné par les conditions réseau et la politique de la plateforme. Ce sont deux vidéos différentes du même sujet, et une seule compte pour l’image que vous projetez. Si vous vous êtes déjà demandé pourquoi votre caméra semble superbe sur votre écran mais terrible dans l’appel, vous avez maintenant la réponse et l’outil pour la mesurer.

Ouvrez chrome://webrtc-internals. Rejoignez votre prochain appel. Observez les entrées outbound-rtp. Si frameWidth ou framesPerSecond sont inférieurs à ce que vous avez configuré dans les réglages de votre caméra, la dégradation a lieu. La cause est typiquement liée à la bande passante — combien votre navigateur peut dépenser et si votre connexion peut transporter le flux que vous croyez envoyer — mais la charge CPU, la sélection de l’encodeur, les politiques de la plateforme et la configuration des contraintes peuvent aussi contribuer ou dominer.