Test Strumienia Webcam — Co Druga Strona Widzi

Obraz, który widzisz w podglądzie webcam, to widok lokalnego przechwytywania — feed kamery dostarczony przez getUserMedia() — nie wyjście surowego sensora. Obraz, który widzi odbiorca wideorozmowy, to strumień zakodowany przez przeglądarkę, który został po cichu negocjowany, skompresowany i potencjalnie zdegradowany przez WebRTC. Ten przewodnik wyjaśnia, jak działa negocjacja kodeków WebRTC, jak użyć getStats() na RTCPeerConnection, aby zmierzyć rzeczywiste parametry strumienia, i jak naprawić powszechne przyczyny utraty jakości. Narzędzie webcam na tej stronie sprawdza tylko lokalny capture track i frame rate przeglądarki; nie mierzy wychodzącego strumienia zakodowanego WebRTC.

Siedzisz w wideorozmowie, a twoje własne okno pokazuje ostry, dobrze oświetlony obraz 1080p. Wyglądasz sharp, tło jest czyste, a kadrowanie odpowiednie. Wtedy współpracownik mówi, że twoje wideo ciągle zamarza i jest rozmazane, a gdy dzieli się ekranem, widzisz siebie jako blocky, miękki obraz, jaki produkowałaby tania webcam sprzed dekady. Ta sama kamera. To samo oświetlenie. Ta sama maszyna. Inny obraz.

Oto, co pomijają większość przewodników po wideorozmowach: ta luka zazwyczaj nie jest winą sprzętu ani defektem sensora — choć źle działający driver czasem też może ją spowodować. Jest to zazwyczaj różnica między tym, co produkuje twoja kamera, a tym, co przeglądarka faktycznie wysyła. Twój podgląd jest zasilany ze ścieżki lokalnego przechwytywania — klatka wyprodukowana przez kamerę, dostarczona przez getUserMedia() — przed kodowaniem WebRTC, co czyni go korzystniejszym widokiem twojego wideo niż to, co otrzymują inni uczestnicy. W tym widoku mogą być zawarte skalowanie, konwersja kolorów lub constraint processing zastosowane przez przeglądarkę, więc to nie jest surowy output sensora. To, co otrzymują inni uczestnicy, to skompresowany strumień, który został znegocjowany, ponownie zakodowany, rate-limit i potencjalnie zdegradowany przez WebRTC w milisekundach, zanim opuści twój komputer.

Ta warstwa kodowania jest niewidoczna z interfejsu użytkownika i cicha podczas normalnego działania. Nic w oknie rozmowy nie mówi ci, że istnieje, nic nie raportuje jej decyzji, i nic w twoim podglądzie ich nie odzwierciedla. Znana scena: użytkownik spędza godziny na przeinstalowywaniu drivera kamery, bo rozmowa pokazuje rozmazany obraz — tylko po to, by odkryć przez chrome://webrtc-internals, że przeglądarka negocjowała spadek do 480p15 na podstawie estymacji bandwidth, a nie z powodu kamery lub drivera. Ta strona wyjaśnia, co dzieje się między sensorem kamery a ekranem partnera rozmowy, dlaczego przeglądarka po cichu obniża twoją jakość i — co najważniejsze — jak zmierzyć rzeczywisty strumień opuszczający twój komputer zamiast ufać podglądowi.

Czego twój podgląd ci nie pokazuje

Wideorozmowa opiera się na potoku, który działa całkowicie poza twoją świadomością. Każda klatka, którą wysyłasz, przechodzi przez następujące etapy:

1. Sensor kamery przechwytuje klatkę; przeglądarka dostarcza ją przez getUserMedia() przy żądanej rozdzielczości i frame rate, co może obejmować skalowanie, konwersję kolorów i constraint processing.
2. Przeglądarka odbiera tę klatkę przez API getUserMedia() i przekazuje ją do silnika WebRTC. Twój lokalny podgląd jest zasilany z tego etapu — dlatego zawsze wygląda perfect, niezależnie od tego, co dzieje się dalej.
3. Koder WebRTC kompresuje klatkę do bitstreamu przy użyciu wynegocjowanego kodeka, przy wynegocjowanej rozdzielczości, frame rate i bitrate.
4. Zakodowana klatka jest dzielona na pakiety RTP i wysyłana przez sieć, zwykle przez media server, który przekazuje ją do wszystkich innych.
5. Każdy odbiorca dekoduje pakiety z powrotem na obraz i renderuje go na swoim ekranie.

Twój podgląd tapuje w potok na etapie drugim. Wyświetla klatkę wyprodukowaną przez kamerę, dostarczoną przez getUserMedia(), przed kodowaniem WebRTC. Przeglądarka może zastosować skalowanie, konwersję kolorów lub constraint processing na tym etapie, ale żadna kompresja WebRTC nie jest stosowana. Strumień, który widzi twój partner rozmowy, to to, co wychodzi z etapu trzeciego. Między tymi dwoma punktami koder decyduje, co otrzymuje świat, i podejmuje tę decyzję na podstawie warunków, których nigdy nie widzisz.

Koder po cichu negocjuje trzy parametry, a każdy z nich może się zmienić w trakcie rozmowy bez powiadomienia:

• Rozdzielczość — szerokość i wysokość zakodowanych klatek, która może spaść z 1920×1080 do 1280×720 lub 640×480 sama z siebie.
• Frame rate — ile klatek na sekundę przetrwa kodowanie, który zazwyczaj spada jako pierwszy (z 30 do 15 lub niżej), ponieważ zmniejszenie frame rate o połowę tnie data rate o połowę bez zmiany rozdzielczości — choć niektóre implementacje mogą zmniejszać rozdzielczość zamiast tego, w zależności od kodeka i platformy.
• Bitrate — ile bitów na sekundę koder ma do dyspozycji, co ustawia ogólny poziom kompresji.

Te trzy wartości determinują wszystko, co widzi druga strona. Obraz 1080p skompresowany do niskiego bitrate wygląda miękko i rozmazanie. Strumień 30 fps nagle działający na 10 fps wygląda juddery i nienaturalnie. Gdy zrozumiesz, że podgląd nie raportuje żadnej z tych wartości, tajemnica fatalnej rozmowy z świetną kamerą znika.

SDP negocjuje zanim wyślesz klatkę

Negocjacja zaczyna się przed wysłaniem pierwszej klatki. Gdy dołączasz do rozmowy, platforma i twoja przeglądarka wymieniają ofertę i odpowiedź Session Description Protocol (SDP). SDP reklamuje kodeki i możliwości mediów, które każda strona wspiera; rzeczywista rozdzielczość i frame rate są następnie dalej negocjowane przez send i receive parametry i ograniczone przez estymację bandwidth. W nieformalnych testach na Chrome 125 na Windows 10 (maj 2024), odpowiedź SDP oferowała VP9 pierwszy, potem H.264, potem VP8; na Safari 17 na macOS 14 (ten sam okres), H.264 pojawił się pierwszy. Te obserwacje zostały wykonane na jednej maszynie na przeglądarkę bez kontrolowanych warunków sieciowych, więc ilustrują istniejącą różnorodność, a nie definiują uniwersalną kolejność. Rzeczywisty wybrany kodek zależy od przeglądarki, platformy, parametrów SDP i możliwości sprzętu. Typowe wybory to VP9, H.264, VP8 i AV1, ale nie ma jednej stałej kolejności preferencji na wszystkich platformach.

Wybór kodeka to dopiero początek. Gdy rozmowa jest aktywna, drugi mechanizm przejmuje: estymacja bandwidth. WebRTC stale monitoruje ścieżkę sieciową w obu kierunkach i uruchamia algorytm kontroli przeciążenia — najczęściej Google Congestion Control — który na bieżąco mierzy trzy rzeczy:

• Packet loss, zgłaszane przez odbiorcę przez komunikaty RTCP feedback.
• Round-trip time, opóźnienie między wysłaniem pakietu a otrzymaniem potwierdzenia jego przybycia.
• Throughput, efektywna prędkość, z jaką dane faktycznie przekraczają połączenie.

Algorytm wrzuca te pomiary w model, który estymuje, ile bandwidth sieć może obecnie przenieść. Ta estymacja staje się target bitrate przekazywana koderowi, a koder adaptuje swoje wyjście. Pętla jest ciągła i szybka: gdy estymacja spada, koder ponownie koduje przy niższym bitrate w ułamku sekundy.

Progi są przybliżone i zależą od konkretnego algorytmu kontroli przeciążenia. Utrata pakietów powyżej około pięciu procent może wywołać redukcję target bitrate, ale dokładne zachowanie — ile rate spada, czy rozdzielczość lub frame rate też się zmienia, i przy jakim poziomie utraty — różni się w zależności od algorytmu, kodeka i platformy. Nie ma uniwersalnego mapowania od procentu utraty do konkretnej rozdzielczości wyjściowej. Pętla feedback sterująca tymi decyzjami jest zdefiniowana w (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP). Strumień 1080p przy 30 fps potrzebuje zazwyczaj około czterech do sześciu megabitów na sekundę upload bandwidth, aby wyglądać czysto, choć zależy to od kodeka, ustawień kodowania i złożoności sceny. Jeśli estimator wnioskuje, że dostępny jest tylko jeden megabit, nie próbuje przepchnąć strumienia przez — obniża target, a koder reaguje, zmniejszając rozdzielczość do 480p i frame rate do 15 fps. Jeśli estymacja spada dalej, obraz degraduje się ponownie, aż do 320×240 talking head. Każdy krok jest celowy: celem jest utrzymanie rozmowy przy życiu i stabilnego audio, a jakość wideo jest pierwszą rzeczą ofiarowaną, aby to osiągnąć.

Trzy wzorce awarii, które ukrywa twój strumień

Podgląd ukrywa rzeczywisty stan strumienia za trzema powracającymi wzorcami awarii. Naucz się rozpoznawać każdy po jego objawach, bo poprawna naprawa różni się w każdym przypadku. Wszystkie trzy mają jedną wspólną cechę: podgląd pozostaje idealny przez cały czas, ponieważ jest próbkowany przed koderem. Tylko zakodowany strumień — a więc ekrany innych uczestników — pokazuje uszkodzenie.

Bit Rate Trap

Objawy: Twój podgląd jest idealny, a twój komputer ma bezczynny CPU. Druga strona widzi rozmazany, niskorozdzielczy obraz, który nigdy nie wyostrza się, nawet podczas pauzy. Lokalne nagrania wyglądają świetnie; rozmowa wygląda słabo.

Diagnoza: Przeglądarka oszacowała, że sieć nie przeniesie pełnego strumienia i capowała bitrate, zmuszając koder do zmniejszenia rozdzielczości. Ograniczeniem jest twój upload bandwidth lub przepustowość relay media server, nie twoja kamera. Uruchom speed test i porównaj zmierzony upload z czterema do sześciu megabitami, których wymaga 1080p30. Jeśli dzielisz połączenie z innymi urządzeniami streaming, downloading lub syncing, konkurują o ten sam budżet.

Loss Threshold

Objawy: Statyczne obrazy z rozmowy wyglądają dobrze, ale każdy ruch jest juddery i robotic. Audio pozostaje płynne, podczas gdy wideo się zacina, i krótkie zamarznięcia występują co kilka sekund, zanim obraz wznowi się przy niższym frame rate.

Diagnoza: Packet loss przekracza próg pięciu procent przerywanie, więc kontroler przeciążenia ciągle obniża target bitrate, a koder odrzuca klatki. Frame rate spada jako pierwszy, ponieważ jest najtańszą dźwignią — zmniejszenie z 30 do 15 fps tnie data rate o połowę bez zmiany rozdzielczości. Sprawdź interference Wi-Fi, marginalny kabel Ethernet lub VPN dodający loss i latency. Wideo będzie się stale degradować, dopóki ścieżka sieciowa nie zostanie naprawiona.

Keyframe Freeze

Objawy: Przez pierwsze dwie do pięciu sekund po dołączeniu lub po udostępnieniu ekranu, druga strona widzi zamrożony lub mocno rozmazany obraz. Potem obraz wyostrza się i zachowuje normalnie do następnej dużej zmiany sceny.

Diagnoza: Kodeki wideo wysyłają dwa typy klatek. Keyframe koduje cały obraz i pojawia się w stałym interwale — zazwyczaj co jedną do dziesięciu sekund, w zależności od platformy i konfiguracji. Delta frame koduje tylko zmiany od poprzedniej klatki, co czyni je malutkimi. Jeśli pakiet z delta frame zostanie utracony, odbiorca nie może zrekonstruować tej klatki — może zażądać retransmisji (NACK), poprosić o nowy keyframe (PLI lub FIR) lub ukryć błąd w trakcie czekania. Gdy żądanie się powiedzie, odzyskiwanie jest szybkie; gdy nie, obraz pozostaje zamrożony do następnego zaplanowanego keyframe. To oczekiwanie to freeze, który widzisz. Krótkie interwały keyframe odzyskują szybciej, ale kosztują bandwidth; długie są wydajne, ale każda utrata jest bardziej widoczna. To nie jest malfunction — to kodek działający zgodnie z projektem.

Mierzenie rzeczywistego strumienia przez getStats()

Przestań zgadywać. Liczby nie są flaterring, ale są prawdziwe. API WebRTC wystawia statistics interface, która raportuje dokładnie, co robi koder, i każda strona, którą kontrolujesz, może odczytać własne peer connection. Wywołaj getStats() na obiekcie RTCPeerConnection, a następnie przefiltruj zwrócony raport dla wpisu outbound-rtp, którego kind to video. Na wpisach media-source i outbound-rtp znajdziesz wartości, które mają znaczenie:

• framesPerSecond (na wpisie media-source) — frame rate, jaki kamera dostarcza do kodera. Jeśli jest poniżej 30 na kamerze 30 fps, ścieżka przechwytywania sama jest problemem — często to kwestia konfliktu o przepustowość USB; jak go zdiagnozować, wyjaśnia nasz przewodnik po konflikcie o przepustowość USB.
• framesPerSecond (na wpisie outbound-rtp) — frame rate, jaki koder faktycznie produkuje. Gdy jest niższy od input rate, koder odrzuca klatki.
• frameWidth i frameHeight (na wpisie outbound-rtp) — zakodowana rozdzielczość. Porównaj z ustawieniami rozmowy; każda różnica to silent downgrade.
• bytesSent (na wpisie outbound-rtp) — całkowite zakodowane dane. Próbkuj dwa razy w odstępie sekundy i oblicz różnicę × 8, aby uzyskać real bitrate.
• packetsSent i packetsLost — zauważ, że packetsLost na wpisie outbound-rtp nie zawsze jest wypełniony; loss ratio jest bardziej niezawodnie odczytywane z wpisu remote-inbound-rtp, który raportuje perspektywę odbiorcy.
• currentRoundTripTime (na wpisie candidate-pair) — opóźnienie sieci. Wysoki RTT połączony z loss wskazuje na congestion.

Różne przeglądarki mogą raportować nieco inne nazwy pól lub całkowicie pominąć niektóre statystyki, więc cross-check ze stroną WebRTC internals przeglądarki, gdy jest dostępna.

Zasady interpretacji są proste. Jeśli outbound-rtp framesPerSecond jest widocznie niższy niż media-source framesPerSecond, koder zrzuca klatki pod presją. Jeśli frameWidth i frameHeight są poniżej rozdzielczości, którą skonfigurowałeś, budżet połączenia nie mógł jej przenieść. Jeśli bytesSent przekłada się na bitrate dalece poniżej wymagań kodeka dla tej rozdzielczości, obraz jest crushowany — a podgląd, który nigdy nie widzi kodera, będzie wyglądał dobrze przez cały czas.

Nie musisz pisać kodu, aby odczytać te wartości. Chrome i Edge mają wbudowany statistics viewer pod chrome://webrtc-internals, który przechwytuje każde połączenie WebRTC w przeglądarce, w tym to, które utworzyła platforma rozmowy. Otwórz go przed dołączeniem do meeting, pozwól mu nagrywać, a następnie inspect wpisy outbound-rtp dla video sender. Te same frame rate, rozdzielczość, bitrate i loss są tam, wraz z wykresem timeline pokazującym dokładnie, kiedy koder zmienił swoje wyjście. To najszybszy sposób, aby złapać downgrade na żywo na realnej rozmowie platformowej.

Uruchom to pomiar, gdy twoja rozmowa jest bezczynna w tle, a potem ponownie w trakcie zajętego meeting i porównaj oba zestawy liczb. Typowe porównanie: bezczynnie, outbound-rtp framesPerSecond odczytuje 30; podczas zajętego meeting może spaść do 18, podczas gdy lokalny podgląd nadal pokazuje 30. To porównanie ujawnia, czy twój baseline sieci jest adekwatny i czy contention podczas rozmowy wyzwala downgrade. Nasze narzędzie webcam test pokazuje rozdzielczość i frame rate lokalnego capture track, negocjowane przez getUserMedia() — użyteczny baseline dla tego, co kamera może dostarczyć do przeglądarki, ale nie pomiar wychodzącego strumienia zakodowanego WebRTC, który wymaga peer connection lub strony WebRTC internals przeglądarki.

Zoom, Meet, Teams: trzy różne kamery

Ta sama kamera, ten sam laptop i ta sama sieć mogą dać widocznie różne wyniki w różnych aplikacjach, ponieważ każda platforma stosuje własną politykę kodowania na wierzchu implementacji WebRTC przeglądarki.

• Zoom zazwyczaj priorytetyzuje stabilność. W zależności od wersji, typu konta i ustawień meeting, może capować wychodzącą rozdzielczość i poświęcić jakość wideo, aby utrzymać audio i screen share stabilne. Kamera 1080p-capable może transmitować 720p lub niżej na Zoom.
• Google Meet ma tendencję do adaptacji do zmierzonego bandwidth, wcześnie obniżając rozdzielczość i szybko ją przywracając, gdy warunki się poprawiają. Jego zachowanie śledzi rzeczywisty stan sieci, na lepsze i gorsze.
• Microsoft Teams stosuje własny potok kodowania i post-processing. W zależności od wersji i ustawień meeting, obraz może być dodatkowo skompresowany poza raw negocjacją WebRTC.
• Browser-native WebRTC, rodzaj, który dostajesz na czystej stronie web, wysyła wynegocjowany strumień bez polityki platformy na wierzchu. Jest to najbliższe ground truth dla tego, co twój sprzęt i sieć mogą dostarczyć pod zwykłym WebRTC. Polityki platform różnią się w zależności od wersji, typu konta i konfiguracji meeting, więc traktuj je jako ogólne tendencje, a nie stałe reguły.

Praktyczny wniosek: porównanie rozmowy Zoom z rozmową Meet nie jest testem kamery. Jest testem decyzji kodowania każdej platformy. Zmierz najpierw raw strumień plain WebRTC page lub narzędziem webcam test. Jeśli raw strumień jest czysty, a jedna platforma nadal wygląda słabo, polityka platformy jest ograniczeniem i żaden upgrade sprzętu tego nie zmieni. Gdy trwa rozmowa platformowa, chrome://webrtc-internals pozwala oglądać decyzje kodera na żywo, abyś mógł zobaczyć, czy downgrade to polityka platformy czy zachowanie sieci, bez ufania self-report którejkolwiek ze stron.

Siedem kroków do czystego strumienia

Te kroki izolują odrębne przyczyny. Możesz przestać, gdy tylko strumień wygląda dobrze — ale mierz przed i po każdej zmianie, aby potwierdzić, że fix faktycznie przesunął liczby.

1. Zmierz najpierw. Otwórz chrome://webrtc-internals lub użyj getStats() na własnym peer connection i zapisz rozdzielczość, frame rate i bitrate. Jeśli raw strumień jest już zdegradowany, twoja kamera i połączenie są problemem. Jeśli jest czysty, platforma jest.
2. Sprawdź bandwidth. Wideorozmowy potrzebują co najmniej 1 Mbps upload dla 720p i około 4 Mbps dla 1080p. Testuj z maszyny, z której dzwonisz, nie z innego urządzenia, i retestuj z innym traffic w sieci. Przejdź na połączenie przewodowe, jeśli możesz; Wi-Fi loss to najczęstsza pojedyncza przyczyna niewidocznych downgrade.
3. Napraw oświetlenie. Dobrze oświetlony obiekt kompresuje się drastycznie lepiej niż ciemny, bo koder wydaje bitrate na widoczne detale, a nie na noise. Stoi twarzą do okna lub użyj soft light. To nic nie kosztuje i często daje większą poprawę niż jakiekolwiek ustawienie.
4. Wyłącz video noise reduction, gdy twoje środowisko jest już ciche i dobrze oświetlone. Niektóre platformy stosują aggressive denoising w scenach o słabym oświetleniu, co może zauważalnie zmiękczyć drobne detale w zakodowanym strumieniu. Lokalny podgląd nie pokaże tej różnicy; tylko zakodowany strumień. Sprawdź konkretne ustawienia platformy.
5. Wyłącz wirtualne tło. Segmentacja tła dodaje overhead do efektywnego bitrate i zużywa GPU cycle z kodera. Czyste, rzeczywiste tło ze spójnym oświetleniem jest lepsze od każdego wirtualnego.
6. Sprawdź kodek. Jeśli twój CPU daje radę, VP9 dostarcza najlepszą jakość na bit; jeśli widzisz frame drop lub CPU spike, H.264 koduje szybciej. Niektóre platformy udostępniają preferencję kodeka w ustawieniach.
7. Przetestuj inną platformę. Jeśli jakość jest dobra na jednej usłudze i słaba na innej, polityka kodowania platformy jest ograniczeniem. Dostosuj swoje oczekiwania lub meeting tool — twój sprzęt nie jest winny.

Podsumowanie

Podgląd to lokalny self-image twojej kamery: korzystny widok tego, co kamera może dostarczyć do przeglądarki. Strumień to to, co świat faktycznie widzi — negocjowane, skompresowane i kształtowane przez warunki sieciowe i politykę platformy. To dwa różne wideo tego samego tematu, i tylko jedno z nich ma znaczenie dla tego, jak się prezentujesz. Jeśli kiedykolwiek zastanawiałeś się, dlaczego twoja kamera wygląda świetnie na ekranie, ale fatalnie w rozmowie, masz teraz odpowiedź i narzędzie do jej zmierzenia.

Otwórz chrome://webrtc-internals. Dołącz do następnej rozmowy. Obserwuj wpisy outbound-rtp. Jeśli frameWidth lub framesPerSecond są poniżej tego, co ustawiłeś w ustawieniach kamery, downgrade ma miejsce. Przyczyna jest zazwyczaj związana z bandwidth — ile twój komputer ma dozwolone wydać i czy twoje połączenie faktycznie może przenieść strumień, który myślisz, że wysyłasz — ale CPU load, wybór kodera, polityki platformy i konfiguracja constraint również mogą przyczynić się do lub zdominować degradację.