Test Webcam Flusso Reale — Cosa Vede Davvero l'Altra Parte

L'immagine che vedi nell'anteprima della webcam è una vista di cattura locale — il feed della camera consegnato tramite getUserMedia() — non l'output del sensore grezzo. L'immagine che il destinatario della videochiamata vede è uno stream codificato dal browser, silenziosamente negoziato, compresso e potenzialmente degradato da WebRTC. Questa guida spiega come funziona la negoziazione dei codec WebRTC, come usare getStats() su una RTCPeerConnection per misurare i parametri reali dello stream, e come risolvere le cause comuni di perdita di qualità. Lo strumento webcam di questo sito controlla solo la traccia di cattura locale e il frame rate del browser; non misura lo stream codificato WebRTC in uscita.

Sei in videochiamata e la tua finestra mostra un’immagine 1080p nitida, ben illuminata. Appari sharp, lo sfondo è pulito, l’inquadratura è corretta. Poi un collega dice che il tuo video continua a congelarsi e apparire sfocato, e quando condivide lo schermo ti vedi come un’immagine blocky, dai contorni morbidi che perfino una webcam economica di un decennio fa avrebbe prodotto. Stessa camera. Stessa illuminazione. Stessa macchina. Un’immagine diversa.

Ecco cosa la maggior parte delle guide alle videochiamate tralascia: quel divario solitamente non è un difetto hardware o un difetto del sensore — sebbene un driver malfunzionante a volte possa causarlo. È tipicamente la differenza tra ciò che la tua camera produce e ciò che il browser effettivamente invia. La tua anteprima è alimentata dal percorso di cattura locale — il fotogramma prodotto dalla camera, consegnato tramite getUserMedia() — prima della codifica WebRTC, il che la rende una vista più favorevole del tuo video rispetto a quello che gli altri partecipanti ricevono. Quella vista può includere ridimensionamento, conversione colore o constraint processing applicati dal browser, quindi non è l’output grezzo del sensore. Quello che gli altri partecipanti ricevono è uno stream compresso che è stato negoziato, ri-codificato, rate-limitato e potenzialmente degradato da WebRTC nei millisecondi prima di lasciare la tua macchina.

Quello strato di codifica è invisibile dall’interfaccia utente e silenzioso durante il funzionamento normale. Nulla nella finestra di chiamata ti dice che esiste, nulla riporta le sue decisioni, e nulla nella tua anteprima le riflette. Una scena familiare: un utente trascorre ore a reinstallare il driver della camera perché una chiamata mostra un’immagine sfocata — solo per scoprire tramite chrome://webrtc-internals che il browser stava negoziando un downgrade a 480p15 basato sulla stima della banda, non a causa della camera o del driver. Questa pagina spiega cosa accade tra il sensore della camera e lo schermo del partner di chiamata, perché il browser abbassa silenziosamente la tua qualità e — soprattutto — come misurare lo stream reale che lascia la tua macchina invece di affidarti all’anteprima.

Cosa la tua anteprima non ti mostra

Le videochiamate si basano su una pipeline che gira interamente al di fuori della tua consapevolezza. Ogni fotogramma che invii passa attraverso questi stadi:

1. Il sensore della camera cattura un fotogramma; il browser lo consegna tramite getUserMedia() alla risoluzione e al frame rate richiesti, il che può comportare ridimensionamento, conversione colore e constraint processing.
2. Il browser riceve quel fotogramma attraverso l’API getUserMedia() e lo passa al motore WebRTC. La tua anteprima locale è alimentata da questo stadio — ecco perché appare sempre perfetta, indipendentemente da cosa accade dopo.
3. L’encoder WebRTC comprime il fotogramma in un bitstream usando un codec negoziato, a una risoluzione, frame rate e bitrate negoziati.
4. Il fotogramma codificato è diviso in pacchetti RTP e inviato sulla rete, solitamente attraverso un media server che lo inoltra a tutti gli altri.
5. Ogni destinatario decodifica i pacchetti nuovamente in un’immagine e la renderizza sul suo schermo.

La tua anteprima tappa nella pipeline allo stadio due. Mostra il fotogramma prodotto dalla camera, consegnato tramite getUserMedia(), prima della codifica WebRTC. Il browser può applicare ridimensionamento, conversione colore o constraint processing a questo stadio, ma nessuna compressione WebRTC viene applicata. Lo stream che il tuo partner di chiamata vede è ciò che esce dallo stadio tre. Tra quei due punti, l’encoder decide cosa riceve il mondo, e prende quella decisione in base a condizioni che non vedi mai.

L’encoder negozia silenziosamente tre parametri, e ciascuno può cambiare durante la chiamata senza alcuna notifica:

• Risoluzione — la larghezza e l’altezza dei fotogrammi codificati, che può scendere da 1920×1080 a 1280×720 o 640×480 da sola.
• Frame rate — quanti fotogrammi al secondo sopravvivono alla codifica, che tipicamente scende per primo (da 30 a 15 o meno) perché dimezzare il frame rate taglia il data rate a metà senza cambiare risoluzione — sebbene alcune implementazioni possano ridurre la risoluzione invece, a seconda del codec e della piattaforma.
• Bitrate — quanti bit al secondo l’encoder può spendere, che imposta il livello di compressione generale.

Questi tre valori determinano tutto ciò che l’altra parte vede. Un’immagine 1080p compressa a un bitrate basso appare morbida e impastata. Uno stream 30 fps improvvisamente a 10 fps appare juddery e innaturale. Quando capisci che l’anteprima non riporta nessuno di questi valori, il mistero della chiamata terribile con un’ottima camera si dissolve.

SDP negozia prima che tu invii un fotogramma

La negoziazione inizia prima che il primo fotogramma sia inviato. Quando ti unisci a una chiamata, la piattaforma e il tuo browser scambiano un’offerta e una risposta Session Description Protocol (SDP). L’SDP pubblicizza i codec e le capacità multimediali che ciascuna parte supporta; la risoluzione e il frame rate reali sono poi ulteriormente negoziati tramite parametri di send e receive e vincolati dalla stima della banda. In test informali su Chrome 125 su Windows 10 (maggio 2024), la risposta SDP offriva VP9 per primo, poi H.264, poi VP8; su Safari 17 su macOS 14 (stesso periodo), H.264 appariva per primo. Queste osservazioni sono state fatte su una singola macchina per browser senza condizioni di rete controllate, quindi illustrano la variazione esistente piuttosto che definire un ordine universale. Il codec effettivamente selezionato dipende dal browser, piattaforma, parametri SDP e capacità hardware. Scelte comuni includono VP9, H.264, VP8 e AV1, ma non c’è un singolo ordine di preferenza fisso su tutte le piattaforme.

La selezione del codec è solo l’inizio. Una volta che la chiamata è live, un secondo meccanismo prende il sopravvento: stima della banda. WebRTC monitora continuamente il percorso di rete in entrambe le direzioni ed esegue un algoritmo di congestion control — più comunemente Google Congestion Control — che misura tre cose su base continuativa:

• Perdita di pacchetti, riportata dal destinatario tramite messaggi RTCP feedback.
• Round-trip time, il ritardo tra l’invio di un pacchetto e la ricezione del riconoscimento del suo arrivo.
• Throughput, il rate effettivo a cui i dati attraversano la connessione.

L’algoritmo alimenta queste misurazioni in un modello che stima quanta banda la rete può attualmente trasportare. Quella stima diventa un target bitrate consegnato all’encoder, e l’encoder adatta il proprio output. Il ciclo è continuo e veloce: quando la stima scende, l’encoder ri-codifica a un bitrate più basso in una frazione di secondo.

Le soglie sono approssimative e dipendono dallo specifico algoritmo di congestion control in uso. Una perdita di pacchetti sostenuta sopra circa il cinque percento può innescare una riduzione del target bitrate, ma il comportamento esatto — di quanto scende il rate, se risoluzione o frame rate cambiano anch’essi, e a quale livello di perdita — varia per algoritmo, codec e piattaforma. Non c’è una mappatura universale da percentuale di perdita a risoluzione di output specifica. Il ciclo di feedback che guida queste decisioni è definito in (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP). Uno stream 1080p a 30 fps richiede tipicamente circa quattro-sei megabit al secondo di upload bandwidth per apparire pulito, sebbene dipenda da codec, impostazioni di codifica e complessità della scena. Se lo stimatore conclude che solo un megabit è disponibile, non cerca di forzare lo stream attraverso — abbassa il target, e l’encoder risponde riducendo la risoluzione a 480p e il frame rate a 15 fps. Se la stima scende ulteriormente, l’immagine degrada ancora, fino a un 320×240 talking head. Ogni passo è deliberato: l’obiettivo è mantenere la chiamata viva e l’audio stabile, e la qualità video è la prima cosa sacrificata per conseguirlo.

Tre pattern di guasto che il tuo stream nasconde

L’anteprima nasconde lo stato reale dello stream dietro tre pattern di guasto ricorrenti. Impara a riconoscere ciascuno dai suoi sintomi, perché la correzione corretta differisce per ogni caso. Tutti e tre condividono un segnale rivelatore: l’anteprima rimane perfetta per tutto il tempo, perché è campionata prima dell’encoder. Solo lo stream codificato — e quindi gli schermi degli altri partecipanti — mostra il danno.

La trappola del bitrate

Sintomi: La tua anteprima è perfetta e la tua macchina ha CPU inattiva. L’altra parte vede un’immagine sfocata, a bassa risoluzione che non si mette mai a fuoco, anche durante una pausa. Le registrazioni locali appariono eccellenti; la chiamata appare scadente.

Diagnosi: Il browser ha stimato che la rete non può trasportare lo stream completo e ha limitato il bitrate, forzando l’encoder a ridurre la risoluzione. Il vincolo è il tuo upload bandwidth o la capacità di relay del media server, non la tua camera. Esegui uno speed test e confronta il tuo upload misurato con i quattro-sei megabit richiesti da 1080p30. Se condividi una connessione con altri dispositivi in streaming, downloading o syncing, stanno competendo per lo stesso budget.

La soglia di perdita

Sintomi: Le immagini statiche della chiamata sembrano a posto, ma qualsiasi movimento è juddery e robotico. L’audio rimane fluido mentre il video scatta, e brevi congelamenti si verificano ogni pochi secondi prima che l’immagine riprenda a un frame rate più basso.

Diagnosi: La perdita di pacchetti supera intermittentemente la soglia del cinque percento, quindi il congestion controller taglia ripetutamente il target bitrate e l’encoder scarta fotogrammi. Il frame rate scende per primo perché è la leva meno costosa — ridurre da 30 a 15 fps taglia il data rate a metà senza cambiare risoluzione. Controlla interferenza Wi-Fi, un cavo Ethernet marginale, o una VPN che aggiunge perdita e latenza. Il video continuerà a degradarsi finché il percorso di rete non viene riparato.

Il blocco sul keyframe

Sintomi: Per i primi due-cinque secondi dopo che ti sei unito, o dopo aver condiviso lo schermo, l’altra parte vede un’immagine congelata o fortemente impastata. Poi l’immagine va a fuoco e si comporta normalmente fino al prossimo grande cambio di scena.

Diagnosi: I codec video inviano due tipi di fotogramma. I Keyframe codificano l’intera immagine e appaiono a intervalli fissi — tipicamente ogni uno-dieci secondi a seconda della piattaforma e configurazione. I Delta frame codificano solo i cambiamenti dal fotogramma precedente, rendendoli piccolissimi. Se un pacchetto di un delta frame viene perso, il destinatario non può ricostruire quel fotogramma — può richiedere una ritrasmissione (NACK), chiedere un nuovo keyframe (PLI o FIR), o nascondere l’errore in attesa. Quando la richiesta ha successo, il recupero è veloce; quando non ha successo, l’immagine rimane congelata fino al prossimo keyframe programmato. Quell’attesa è il freeze che vedi. Intervalli keyframe brevi recuperano più velocemente ma costano banda; intervalli lunghi sono efficienti ma rendono ogni perdita più visibile. Non è un malfunzionamento — è il codec che funziona come progettato.

Misurare lo stream reale con getStats()

Smetti di indovinare. I numeri non sono lusinghieri, ma sono veri. L’API WebRTC espone una statistics interface che riporta esattamente cosa sta facendo l’encoder, e qualsiasi pagina web che controlli può leggere la propria peer connection. Chiama getStats() sull’oggetto RTCPeerConnection, poi filtra il report restituito per la voce outbound-rtp il cui kind è video. Sulle voci media-source e outbound-rtp troverai i valori che contano:

• framesPerSecond (sulla voce media-source) — il frame rate che la camera consegna all’encoder. Se è sotto 30 su una camera 30 fps, il percorso di cattura stesso è il problema — spesso si tratta di una contesa della larghezza di banda USB, che la nostra guida alla contesa della larghezza di banda USB spiega come diagnosticare.
• framesPerSecond (sulla voce outbound-rtp) — il frame rate che l’encoder sta effettivamente producendo. Quando è inferiore al rate di input, l’encoder sta scartando fotogrammi.
• frameWidth e frameHeight (sulla voce outbound-rtp) — la risoluzione codificata. Confronta con le impostazioni di chiamata; qualsiasi differenza è un silent downgrade.
• bytesSent (sulla voce outbound-rtp) — dati codificati totali. Campiona due volte a un secondo di distanza e calcola la differenza × 8 per ottenere il bitrate reale.
• packetsSent e packetsLost — nota che packetsLost sulla voce outbound-rtp non è sempre popolato; il loss ratio è letta più affidabilmente dalla voce remote-inbound-rtp, che riporta la prospettiva del destinatario.
• currentRoundTripTime (sulla voce candidate-pair) — il ritardo di rete. Un RTT alto combinato con perdita indica congestione.

Browser diversi possono riportare nomi di campo leggermente diversi o omettere alcune statistiche, quindi cross-check con la pagina WebRTC internals del browser quando disponibile.

Le regole di interpretazione sono semplici. Se outbound-rtp framesPerSecond è visibilmente inferiore a media-source framesPerSecond, l’encoder sta scartando fotogrammi sotto pressione. Se frameWidth e frameHeight sono inferiori alla risoluzione che hai configurato, il budget di connessione non poteva trasportarla. Se bytesSent si traduce in un bitrate di gran lunga inferiore ai requisiti del codec per quella risoluzione, l’immagine sta sendo schiacciata — e l’anteprima, che non vede mai l’encoder, apparirà bene per tutto il tempo.

Non devi scrivere codice per leggere questi valori. Chrome ed Edge includono un visualizzatore di statistiche integrato su chrome://webrtc-internals che cattura ogni connessione WebRTC nel browser, inclusa quella creata dalla piattaforma di chiamata. Aprilo prima di unirti a un meeting, lascialo registrare, e ispeziona le voci outbound-rtp per il video sender successivamente. Gli stessi frame rate, risoluzione, bitrate e figure di perdita sono lì, insieme a un grafico timeline che mostra esattamente quando l’encoder ha cambiato il proprio output. Questo è il modo più veloce per cogliere un downgrade sul fatto su una chiamata reale di piattaforma.

Esegui questa misurazione mentre la tua chiamata è inattiva nel background, poi di nuovo durante un meeting intenso, e confronta i due set di numeri. Un confronto tipico: inattivo, outbound-rtp framesPerSecond legge 30; durante un meeting intenso può scendere a 18 mentre l’anteprima locale mostra ancora 30. Quel confronto rivela se il tuo baseline di rete è adeguato e se il contention durante la chiamata è ciò che innesca il downgrade. Il nostro strumento test webcam mostra la risoluzione e il frame rate della traccia di cattura locale negoziata tramite getUserMedia() — un utile baseline per ciò che la tua camera può consegnare al browser, ma non una misurazione dello stream WebRTC codificato in uscita, che richiede una peer connection o la pagina WebRTC internals del browser.

Zoom, Meet, Teams: tre camere diverse

La stessa camera, lo stesso laptop, e la stessa rete possono produrre risultati visibilmente diversi in applicazioni diverse, perché ogni piattaforma applica la propria policy di codifica sopra l’implementazione WebRTC del browser.

• Zoom comunemente dà priorità alla stabilità. A seconda di versione, tipo di account e impostazioni meeting, può limitare la risoluzione in uscita e sacrificare la qualità video per mantenere audio e screen share stabili. Una camera 1080p-capable può trasmettere a 720p o inferiore su Zoom.
• Google Meet tende ad adattarsi alla banda misurata, riducendo la risoluzione presto e ripristinandola rapidamente quando le condizioni migliorano. Il suo comportamento traccia lo stato reale della rete, per il meglio e per il peggio.
• Microsoft Teams applica la propria pipeline di codifica e post-processing. A seconda di versione e impostazioni meeting, l’immagine può essere ulteriormente compressa oltre la negoziazione WebRTC grezza.
• Browser-native WebRTC, il tipo che ottieni in una pagina web nuda, invia lo stream negoziato senza policy di piattaforma sopra. È la cosa più vicina al ground truth per ciò che il tuo hardware e la tua rete possono consegnare sotto WebRTC puro. Le policy di piattaforma variano per versione, tipo di account e configurazione meeting, quindi trattale come tendenze generali piuttosto che regole fisse.

La conseguenza pratica: confrontare una chiamata Zoom con una chiamata Meet non è un test della camera. È un test delle decisioni di codifica di ciascuna piattaforma. Misura prima lo stream grezzo con una pagina WebRTC nuda o lo strumento test webcam. Se lo stream grezzo è pulito e una piattaforma appare ancora scadente, la policy della piattaforma è il vincolo, e nessun upgrade hardware lo cambierà. Quando una chiamata di piattaforma è in corso, chrome://webrtc-internals ti permette di guardare le decisioni dell’encoder dal vivo, così puoi vedere se il downgrade è la policy della piattaforma o il comportamento della rete senza fidarti del self-report di nessuna delle due parti.

Sette passi per uno stream pulito

Questi passi isolano cause distinte. Puoi fermarti non appena lo stream appare giusto — ma misura prima e dopo ogni cambiamento per confermare che la correzione ha effettivamente mosso i numeri.

1. Misura prima. Apri chrome://webrtc-internals o usa getStats() sulla tua peer connection e registra risoluzione, frame rate e bitrate. Se lo stream grezzo è già degradato, la tua camera e connessione sono il problema. Se è pulito, la piattaforma lo è.
2. Controlla la banda. Le videochiamate richiedono almeno 1 Mbps di upload per 720p e circa 4 Mbps per 1080p. Testa dalla macchina da cui chiami, non da un altro dispositivo, e ritesta con altro traffico sulla rete. Passa a una connessione cablata se puoi; la perdita Wi-Fi è la singola causa più comune di downgrade invisibili.
3. Correggi l’illuminazione. Un soggetto ben illuminato comprime drasticamente meglio di uno scuro, perché l’encoder spende bitrate su dettagli visibili piuttosto che su rumore. Guarda verso una finestra o usa una luce soffusa. Questo non costa nulla e spesso produce un miglioramento maggiore di qualsiasi impostazione.
4. Disabilita la video noise reduction quando il tuo ambiente è già silenzioso e ben illuminato. Alcune piattaforme applicano un denoising aggressivo in scene scure, che può ammorbidire visibilmente i dettagli fini nello stream codificato. L’anteprima locale non mostrerà questa differenza; solo lo stream codificato la mostrerà. Controlla le impostazioni specifiche della piattaforma.
5. Disabilita lo sfondo virtuale. La segmentazione dello sfondo aggiunge overhead al bitrate effettivo e consuma cicli GPU dall’encoder. Uno sfondo reale pulito con illuminazione costante batte qualsiasi sfondo virtuale.
6. Controlla il codec. Se la tua CPU può gestirlo, VP9 consegna la migliore qualità per bit; se vedi frame drop o picchi CPU, H.264 codifica più velocemente. Alcune piattaforme espongono una preferenza codec nelle impostazioni.
7. Prova una piattaforma diversa. Se la qualità è buona su un servizio e scadente su un altro, la policy di codifica della piattaforma è il vincolo. Regola le tue aspettative o il tuo meeting tool di conseguenza — il tuo hardware non è in colpa.

In sintesi

L’anteprima è la self-image locale della tua camera: una vista favorevole di ciò che la camera può consegnare al browser. Lo stream è ciò che il mondo vede realmente — negoziato, compresso, e plasmato dalle condizioni di rete e dalla policy della piattaforma. Sono due video diversi dello stesso soggetto, e solo uno dei due conta per come appari. Se ti sei mai chiesto perché la tua camera appare ottima sullo schermo ma terribile in chiamata, ora hai la risposta e lo strumento per misurarla.

Apri chrome://webrtc-internals. Unisciti alla prossima chiamata. Osserva le voci outbound-rtp. Se frameWidth o framesPerSecond sono inferiori a ciò che hai impostato nelle impostazioni della camera, il downgrade sta avvenendo. La causa è tipicamente correlata alla banda — quanto il tuo browser può spendere e se la tua connessione può effettivamente trasportare lo stream che pensi di inviare — ma anche il carico CPU, la selezione dell’encoder, le policy della piattaforma e la configurazione dei constraint possono contribuire o dominare il degrado.