Webcam Canlı Akış Testi — Karşı Taraf Gerçekte Ne Görür?

Webcam önizlemesinde gördüğünüz görüntü yerel bir yakalama manzarasıdır — kamera akışının [getUserMedia()](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia) üzerinden teslim edildiği hali — ve ham sensör çıktısı değildir. Görüntülü görüşme alıcınızın gördüğü görüntü tarayıcı tarafından kodlanmış bir akıştır; bu akış sessizce müzakere edilmiş sıkıştırılmış ve muhtemelen WebRTC tarafından aşağı düşürülmüştür. Bu rehber WebRTC kodek müzakeresinin nasıl çalıştığını RTCPeerConnection üzerinde getStats() kullanarak gerçek akış parametrelerini nasıl ölçeceğinizi ve kalite kaybının yaygın nedenlerini nasıl düzelteceğinizi açıklar. Not: Bu sitedeki webcam aracımız yalnızca yerel yakalama track'ini ve tarayıcı kare hızını kontrol eder; giden WebRTC kodlanmış akışı ölçmez.

Bir görüntülü görüşmeye oturursunuz ve kendi pencereniz net iyi aydınlatılmış bir 1080p görüntü gösterir. Keskin görünürsünüz arka plan temiz ve kare doğru. Sonra bir meslektaşı video sürekli donuyor ve bulanık göründüğünü söyler; ekranını paylaştığında kendini on yıl önceki bütçe bir webcam üreteceği blok şeklinde yumuşak kenarlı bir resim olarak görürsünüz. Aynı kamera aynı aydınlatma aynı makine. Farklı bir görüntü.

Çoğu görüşme rehberinin atladığı şey şudur: o boşluk genellikle donanım arızası veya sensör kusuru değildir — ancak bozuk çalışan bir sürücü de zaman zaman buna neden olabilir. Tipik olarak kameranızın ürettiği ile tarayıcınızın gerçekten gönderdiği arasındaki farktır. Önizlemeniz yerel yakalama yolundan beslenir — kamera tarafından üretilen ve getUserMedia() üzerinden teslim edilen çerçeve — WebRTC kodlamasından önce; bu onu diğer katılımcıların aldığının video için daha olumlu bir görünüm yapar. O görünüm aynı zamanda ölçeklendirme renk dönüştürme veya kısıtlama işleme gibi tarayıcı uygulaması içerebilir bu yüzden ham sensör çıktısı değildir. Diğer katılımcıların aldığı şey makinenizden ayrılmasından milisaniyeler önce WebRTC tarafından müzakere edilmiş yeniden kodlanmış hız sınırlı ve muhtemelen aşağı düşürülmüş bir sıkıştırılmış akıştır.

O kodlama katmanı kullanıcı arayüzünden görünmez ve normal çalışmada sessizdir. Görüşme penceresinde var olduğunu söyleyen hiçbir şey yoktur kararlarını rapor eden hiçbir şey yoktur ve önizlemenizde hiçbir şey onları yansıtmaz. Alışılmış bir sahnede: bir kullanıcı görüşmenin bulanık göstermesi nedeniyle saatler kamera sürücüsünü yeniden kurmaya harcar — ancak chrome://webrtc-internals aracılığıyla tarayıcının bant genişliği tahminine dayalı 480p15’e düştüğünü keşfeder; kamera veya sürücü değil. Bu sayfa kamera sensörü ile görüşme ortağınızın ekranı arasında neler olduğunu tarayıcının sessizce kaliteyi neden düşürdüğünü ve en önemlisi önizlemeye güvenmek yerine makinenizden çıkan gerçek akışı nasıl ölçeceğinizi açıklar.

Önizlemeniz size ne göstermez

Görüntülü görüşme bilginiz dışında tamamen işleyen bir hattın üzerine kuruludur. Gönderdiğiniz her çerçeve aşağıdaki aşamalardan geçer:

1. Kamera sensörü bir çerçeveyi yakalar; tarayıcı daha sonra getUserMedia() üzerinden istenen çözünürlük ve kare hızında teslim eder; bu ölçeklendirme renk dönüştürme ve kısıtlama işleme içerebilir.
2. Tarayıcı o çerçeveyi getUserMedia() API’si üzerinden alır ve WebRTC motoruna verir. Yerel önizlemeniz bu aşamadan beslenir — bu yüzden sonra ne olursa olsun her zaman mükemmel görünur.
3. WebRTC kodlayıcı müzakere edilmiş bir kodek kullanarak müzakere edilmiş çözünürlük kare hızı ve bit hızında çerçeveyi bir bit akışına sıkıştırır.
4. Kodlanmış çerçeve RTP paketlerine bölünür ve ağ üzerinden gönderilir; genellikle herkesine ileten bir medya sunucusu üzerinden.
5. Her alıcı paketleri bir resme geri çözer ve ekranında gösterir.

Önizlemeniz hattın ikinci aşamasına bağlanır. Kamera tarafından üretilen ve getUserMedia() üzerinden teslim edilen çerçeveyi WebRTC kodlamasından önce gösterir. Tarayıcı bu aşamada ölçeklendirme renk dönüştürme veya kısıtlama işleme uygulayabilir ancak WebRTC sıkıştırması uygulanmaz. Görüşme ortağınızın gördüğü akış üçüncü aşamadan çıkan şeydir. Bu iki nokta arasında kodlayıcı dünyanın ne göreceğini karar verir ve bu kararı asla görmediğiniz koşullara dayalı yapar.

Kodlayıcı sessizce üç parametre müzakere eder ve her biri görüşme sırasında hiçbir bildirim olmadan değişebilir:

• Çözünürlük — kodlanmış çerçevelerin genişliği ve yüksekliği; 1920x1080’den 1280x720 veya 640x480’e kendi kendine düşebilir.
• Kare hızı — saniyede kaç kare kodlandı; genellikle ilk düşen bu (30’dan 15’e veya daha aşağı) çünkü kare hızını yarıya indirmek çözünürlüğü değiştirmeden veri hızını yarıya indirir — ancak bazı uygulamalar kodeğe ve platforma bağlı olarak çözünürlüğü azaltabilir.
• Bit hızı — kodlayıcının saniyede harcamasına izin verilen bit sayısı; genel sıkıştırma seviyesini belirler.

Bu üç değer karşı tarafın gördüğü her şeyi belirler. Düşük bir bit hızına sıkıştırılmış 1080p görüntü yumuşak ve bulanık görünür. Ani 30 fps akış 10 fps çalışıyorsa takır takır ve yapay görünür. Önizlemenin bu değerlerden hiçbirini rapor etmediğini anlayınca harika bir kamera ile korkunç bir görüşme gizemi çözülür.

SDP Bir Çerçeve Göndermeden Önce Müzakere Eder

Müzakere ilk çerçeve gönderilmeden önce başlar. Bir görüşmeye katıldığınızda platform ve tarayıcınız Oturum Açıklama Protokolü (SDP) önerisi ve cevabı takas eder. SDP her iki tarafın desteklediği kodekleri ve medya kabiliyetlerini duyurur; gerçek çözünürlük ve kare hızı daha sonra gönderim ve alım parametreleri üzerinden müzakere edilir ve bant genişliği tahmini ile sınırlanır. Chrome 125 Windows 10 üzerinde (Mayıs 2024) gayri resmi testlerde SDP cevabı önce VP9 sonra H.264 sonra VP8 sunduğu gözlemlendi; Safari 17 macOS 14 üzerinde (aynı dönem) H.264 ilk geldi. Bu gözlemler her tarayıcı için tek bir makine üzerinde kontrollü ağ koşulları olmadan yapıldı; bu yüzden evrensel bir sırayı tanımlamak yerine mevcut değişimi gösterir. Seçilen gerçek kodek tarayıcı platform SDP parametreleri ve donanım kabiliyetlerine bağlıdır. Yaygın seçimler VP9 H.264 VP8 ve AV1 içerir ancak tüm platformlar arasında tek sabit bir tercih sırası yoktur.

Kodek seçimi yalnızca başlangıçtır. Görüşme canlı olunca ikinci bir mekanizma devreye girer: bant genişliği tahmini. WebRTC her iki yönde ağ yolunu sürekli izler ve çoğunlukla Google Congestion Control olan bir kalabalık kontrol algoritması çalıştırır; bu algoritma dönen bir bazda üç ölçüm yapar:

• Paket kaybı alıcı tarafından RTCP geri bildirim mesajları aracılığıyla rapor edilir.
• Gidip dönüş zamanı bir paket gönderilmesinden varışının kabulü alınmasına kadar olan gecikme.
• Geçiş hızı verinin bağlantıyı gerçekten aştığı etkili hız.

Algoritma bu ölçümleri ağın şu anda taşıyabileceği bant genişliğini tahmin eden bir modele besler. O tahmin kodlayıcıya verilen bir hedef bit hızı olur ve kodlayıcı çıkışını buna uyarlar. Döngü süreklidir ve hızlıdır: tahmin düştüğünde kodlayıcı kırık saniyeler içinde daha düşük bir bit hızında yeniden kodlar.

Eşikler yaklaşık ve kullanılan spesifik kalabalık kontrol algoritmasına bağlıdır. Yaklaşık yüzde beşin üzerindeki sürekli paket kaybı hedef bit hızında azalmaya yol açabilir ancak kesin davranış — hızın ne kadar düşeceği çözünürlük veya kare hızının da değişip değişmeyeceği hangi kayıp seviyesinde — algoritmaya kodeğe ve platforma göre değişir. Kayıp yüzdesinden belirli bir çıktı çözünürlüğüne evrensel bir eşleme yoktur. Bu kararları yönlendiren geri bildirim döngüsü (Google: WebRTC Congestion Control Whitepaper 2019; RFC 8888: RTP için Kalabalık Kontrol Geri Bildirimi) ile tanımlanmıştır. 30 fps bir 1080p akışı temiz görünmek için tipik olarak dört ile altı megabit/saniye yükleme bant genişliği gerektirir; bu kodeğe kodlama ayarlarına ve sahne karmaşıklığına bağlıdır. Tahminci yalnızca bir megabit mevcut sonucuna ulaşırsa akışı zorlamaya çalışmaz — hedefi düşürür ve kodlayıcı 480p’ye çözünürlüğü ve 15 fps’e kare hızını düşürerek tepki verir. Tahmin daha da düşerse görüntü tekrar bozulur 320x240 bir konuşan kafaya kadar. Her adım deliberate’dir: amaç görüşmeyi ayakta tutmak ve sesi stabil tutmaktır; video kalitesi bu amaç için ilk feda edilen şeydir.

Akışınızın Gizlediği Üç Başarısızlık Deseni

Önizleme akışın gerçek durumunu üç tekrarlayan başarısızlık deseni arkasında saklar. Her birini belirtileriyle tanımayı öğrenin çünkü doğru düzeltme her vakada farklıdır. Üçü de ortak bir ip ucu paylaşır: önizleme tüm süre mükemmel kalır çünkü kodlayıcıdan önce örnekleme yapılır. Yalnızca kodlanmış akış — ve dolayısıyla diğer katılımcıların ekranları — hasarı gösterir.

Bit Hızı Tuzak

Belirtiler: Önizlemeniz mükemmel ve makinenizde boşta CPU var. Karşı taraf hiçbir zaman keskinleşmeyen bulanık düşük çözünürlükte bir görüntü görür; duraklama sırasında bile. Yerel kayıtlar mükemmel görünür; görüşme kötü görünür. Teşhis: Tarayıcı ağın tam akışı taşıyamadığını tahmin etmiş ve bit hızını tavanlamıştır; bu da kodlayıcıyı çözünürlüğü küçültmeye zorlar. Kısıtlayan yükleme bant genişliğinizdir veya medya sunucusunun iletim kapasitesidir kamera değil. Hız testini çalıştırın ve ölçülen yüklemenizi 1080p30’nin gerektirdiği dört ile altı megabit ile karşılaştırın. Başka cihazlarla akış indirme veya senkronize eden bir bağlantıyı paylaşıyorsanız aynı bütçe için rekabet ederler.

Kayıp Eşiği

Belirtiler: Görüşmeden alınmış hareketsiz görüntüler iyi görünür ancak herhangi bir hareket takır takır ve robotik görünür. Ses akıcı kalırken video takılır ve birkaç saniyede bir kısa donmalar olur; resim daha düşük bir kare hızında devam eder. Teşhis: Paket kaybı yüzde beş eşiğini aralıklı olarak aşar; bu yüzden kalabalık kontrolör tekrarlayan hedef bit hızını keser ve kodlayıcı kareleri eşitlemek için atar. Kare hızı en ucuz kaldıraç olduğu için ilk düşer — 30’dan 15’e düşmek çözünürlüğü değiştirmeden veri hızını yarıya indirir. Wi-Fi paraziti sınırlı bir Ethernet kablosu veya gecikme ve kayıp ekleyen bir VPN için kontrol edin. Ağ yolu onarılana kadar видео bozulmaya devam eder.

Ana Kare Donması

Belirtiler: Katıldıktan veya ekran paylaştıktan sonra ilk iki ila beş saniyede karşı taraf donmuş veya ağır bulanık bir görüntü görür. Sonra resim odaklanır ve bir sonraki büyük sahne değişimine kadar normal davranır. Teşhis: Video kodekleri iki çerçeve türü gönderir. Ana kareler tüm resmi kodlar ve sabit aralıklarla görünür — genellikle platforma ve yapılandırmaya bağlı olarak bir ile on saniyede bir. Delta kareleri yalnızca önceki kareden bu yana değişenleri kodlar; bu yüzden çok küçüktür. Bir delta kare paketinden biri kaybedilirse alıcı o kareyi yeniden yapılandıramaz — yeniden iletim isteyebilir (NACK) göndericiden taze ana kare isteyebilir (PLI veya FIR) veya beklerken hatayı gizleyebilir. İstek başarılı olduğunda kurtarma hızlıdır; başarısız olduğunda resim bir sonraki planlanan ana karenin gelmesine kadar donuk kalır. Bu bekleme gördüğünüz donmadır. Kısa ana kare aralıkları daha hızlı kurtarır ama bant gerektirir; uzun aralıklar verimli ama her kaybı daha görünür yapar. Bu arıza değil — kodeğin tasarım gereği çalışmasıdır.

getStats() ile Gerçek Akışı Ölçmek

Tahmin yürütmeyi bırakın. Sayılar flörtöz değil ama doğru. WebRTC API istatistik arayüzü sunar; kodlayıcının ne yaptığını tam olarak raporlar ve kontrol ettiğiniz herhangi bir web sayfası kendi peer bağlantısını okuyabilir. RTCPeerConnection nesnesinde getStats() çağırın ardından dönen raporu kind değeri video olan outbound-rtp girdisi için filtreleyin. media-source ve outbound-rtp girdilerinde önemli olan değerleri bulacaksınız:

• framesPerSecond (media-source girdisinde) — kameranın kodlayıcıya teslim ettiği kare hızı. 30 fps kamerada 30’un altındaysa sorun yakalama yolunun kendisidir — bu çoğu zaman bir USB bus rekabeti sorunudur; nasıl teşhis edileceğini USB bus rekabeti rehberimiz açıklar.
• framesPerSecond (outbound-rtp girdisinde) — kodlayıcının aslında ürettiği kare hızı. Bu giriş hızından düşükse kodlayıcı kareleri atar.
• frameWidth ve frameHeight (outbound-rtp girdisinde) — kodlanmış çözünürlük. Görüşme ayarlarınıza karşılaştırın; her farklılık sessiz bir aşağı düşürmedir.
• bytesSent (outbound-rtp girdisinde) — toplam kodlanmış veri. Bir saniye arayla iki kez örnekle ve farkı sekiz ile çarpın; gerçek bit hızını elde edersiniz.
• packetsSent ve packetsLost — outbound-rtp’deki packetsLost her zaman doldurulmaz; kayıp oranı remote-inbound-rtp girdisinden daha güvenilir okunur çünkü alıcı perspektifini raporlar.
• currentRoundTripTime (candidate-pair girdisinde) — ağ gecikmesi. Yüksek RTT ile kayıp birlikte kalabalığı işaret eder.

Farklı tarayıcılar biraz farklı alan adları raporlayabilir veya bazı istatistikleri tamamen atlayabilir; bu yüzden mümkün olduğunda tarayıcının WebRTC iç sayfaları ile karşılaştırın.

Yorum kuralları basittir. outbound-rtp framesPerSecond, media-source framesPerSecond’un belirgin şekilde altında ise kodlayıcı baskı altında kare atar. frameWidth ve frameHeight, konfigüre ettiğiniz çözünürlüğün altında ise bağlantı bütçesi onu taşıyamamıştır. bytesSent, o çözünürlük için kodek gereksiniminden çok daha düşük bir bit hızına dönüştürüyorsa görüntü ezilir — ve kodlayıcıyı hiç gören önizleme tüm süre iyi görünecektir.

Bu değerleri okumak için kod yazmana gerek yok. Chrome ve Edge chrome://webrtc-internals adresinde dahili bir istatistik görüntüleyicisi ile gelir; tarayıcıdaki her WebRTC bağlantısını yakalar, bir görüşme platformunun oluşturduğu bağlantı da dahil. Bir toplantıya katılmadan önce açın kayıt yapmasına izin verin ve sonrasında video göndericisinin outbound-rtp girdilerini inceleyin. Aynı kare hızı çözünürlük bit hızı ve kayıp değerleri oradadır; ayrıca kodlayıcının ne zaman çıktıyı değiştirdiğini gösteren bir zaman çizelgesi grafiği vardır. Gerçek bir platform görüşmesinde bir aşağı düşürmeyi işlemde yakalamak için en hızlı yoldur.

Bu ölçümü kendi görüşmeniz arka planda boşta çalışırken bir kez sonra yoğun bir toplantı sırasında bir kez daha çalıştırın ve iki sayı setini karşılaştırın. Tipik bir karşılaştırma: boşta outbound-rtp framesPerSecond 30 okur; yoğun toplantıda yerel önizleme hâlâ 30 gösterirken 18’e düşebilir. O karşılaştırma temel ağınızın yeterli olup olmadığını ve görüşme sırasındaki rekabetin aşağı düşürmeyi tetikleyen şey olup olmadığını ortaya çıkarır. Webcam testimiz getUserMedia() üzerinden müzakere edilen yerel yakalama track’inin çözünürlüğünü ve kare hızını gösterir — kameranızın tarayıcıya sağlayabileceği için kullanışlı bir temel; ancak giden WebRTC kodlanmış akışın ölçümü değil ki bu bir peer bağlantısı veya tarayıcının WebRTC iç sayfaları gerektirir.

Zoom Meet Teams: Üç Farklı Kamera

Aynı kamera aynı dizüstü ve aynı ağ farklı uygulamalarda belirgin farklı sonuçlar üretebilir; çünkü her platform tarayıcının WebRTC uygulaması üzerine kendi kodlama politikasını uygular.

• Zoom genellikle stabiliteye öncelik verir. Versiyona hesap türüne ve toplantı ayarlarına bağlı olarak giden çözünürlüğü tavanlayabilir ve ses ile ekran paylaşımının stabil kalması için video kalitesinden feda edebilir. 1080p destekli bir kamera Zoom’da 720p veya daha düşük iletebilir.
• Google Meet ölçülen bant genişliğine adapte olmaya eğilimlidir; çözünürlüğü erken düşürür ve koşullar iyileştiğinde hızla geri getirir. Davranışı gerçek ağ durumunu izler iyiye ve kötüye.
• Microsoft Teams kendi kodlama ve son işleme hattını uygular. Versiyona ve toplantı ayarlarına bağlı olarak resim ham WebRTC müzakeresinin ötesine sıkıştırılabilir.
• Tarayıcı yerel WebRTC çıplak bir web sayfasında aldığınız tür; üzerinde platform politikası olmadan müzakere edilmiş akışı gönderir. Donanımınızın ve ağınızın düz WebRTC altında sağlayabileceği için gerçekliğe en yakın şeydir. Platform politikaları versiyona hesap türüne ve toplantı yapılandırmasına göre değişir; bunları sabit kurallar yerine genel eğilimler olarak ele alın.

Pratik sonuç: Zoom’u Meet ile kıyaslamak bir kamera testi değildir. Her platformun kodlama kararlarının bir testidir. Önce düz bir WebRTC sayfası veya webcam testi ile ham akışı ölçün. Ham akış temizse ve bir platform hâlâ kötü görünüyorsa platformun politikası kısıtlayıcıdır ve hiçbir donanım yükseltmesi onu değiştiremez. Bir platform görüşmesi devam ettiğinde chrome://webrtc-internals kodlayıcı kararlarını canlı izlemenizi sağlar; böylece aşağı düşürmenin platformun politikası mı yoksa ağın davranışı mı olduğunu iki tarafın kendi raporuna güvenmeden görebilirsiniz.

Temiz Bir Akış İçin Yedi Adım

Bu adımlar farklı nedenleri izole eder. Akış doğru göründüğünde durabilirsiniz — ancak her değişiklikton önce ve sonra ölçün; düzeltmenin gerçekten sayıları move ettiğini onaylamak için.

1. Önce ölçün. chrome://webrtc-internals’ı açın veya kendi peer bağlantınızda getStats() kullanın ve çözünürlük kare hızı ve bit hızını kaydedin. Ham akış zaten aşağı düşürülmüşse sorun kamera ve bağlantınızdır. Temizse sorun platformdur.
2. Bant genişliğini kontrol edin. Görüntülü görüşmeler 720p için en az 1 Mbps yükleme ve 1080p için kabaca 4 Mbps gerektirir. Aradığınız makineden değil başka bir cihazdan test edin ve ağdaki diğer trafik ile tekrar test edin. Mümkünse kabloluya geçin; Wi-Fi kaybı görünmez aşağı düşürmelerin en yaygın tek nedenidir.
3. Aydınlatmayı düzeltin. İyi aydınlatılmış bir konu karanlık birine kıyasla çok daha iyi sıkıştırır; çünkü kodlayıcı bit hızını gürültü yerine görünür detay için harcar. Bir pencereye veya yumuşak bir ışık kaynağına yüzünüzü çevirin. Bu hiçbir şeyi maliyet etmez ve genellikle herhangi bir ayardan daha büyük bir iyileşme üretir.
4. Video gürültü azaltmayı devre dışı bırakın ortamınız zaten sessiz ve iyi aydınlatılmışsa. Bazı platformlar düşük ışık sahnelerinde agresif gürültü azaltma uygular; bu kodlanmış akışta ince detayı belirgin şekilde yumuşatabilir. Yerel önizleme bu farkı göstermez; yalnızca kodlanmış akış gösterir. Mevcut kontrolleri onaylamak için belirli平台 ayarlarını kontrol edin.
5. Sanal arka planı devre dışı bırakın. Arka plan segmentasyonu etkili bit hızına yük ekler ve kodlayıcıdan GPU döngüleri tüketir. Tutarlı aydınlatma ile temiz gerçek bir arka plan her sanal arka plandan üstündür.
6. Kodeği kontrol edin. CPU’nuz kaldırabiliyorsa VP9 bittir başına en iyi kaliteyi verir; kare düşürmeleri veya CPU sıçramaları görüyorsanız H.264 daha hızlı kodlar. Bazı platformlar ayarlarda bir kodek tercihi gösterir.
7. Farklı bir platform deneyin. Bir hizmette iyi diğerinde kötü kalite varsa platformun kodlama politikası kısıtlayıcıdır. Beklentilerinizi veya toplantı aracınızı buna göre ayarlayın — donanımınız suçlu değil.

Sonuç

Önizleme kameranızın yerel kendi portresidir: kameranızın tarayıcıya sağlayabileceği şeyin olumlu bir görünümü. Akış dünyanın aslında gördüğü şeydir — ağ koşulları ve platform politikası tarafından müzakere edilmiş sıkıştırılmış ve şekillendirilmiş. Aynı konunun iki farklı videosudur ve yalnızca bir tanesi sizin nasıl göründüğünüz için önemlidir. Kameranızın ekranınızda harika ama görüşmede kötü görünme nedenini hiç merak ettiyseniz artık cevabı ve onu ölçme aracını sahipsiniz.

chrome://webrtc-internals’ı açın. Sonraki görüşmenize katılın. outbound-rtp girdilerini izleyin. frameWidth veya framesPerSecond kamera ayarlarınızdakinden düşükse aşağı düşürme gerçekleşiyor. Neden genellikle bant genişliği ile ilgilidir — tarayıcınıza harcamaya izin verilen şey ve bağlantınızın gerçekten sandığınız akışı taşıyıp taşıyamayacağı — ancak CPU yükü kodek seçimi platform politikaları ve kısıtlama yapılandırması da bozulmaya katkıda bulunabilir veya onu domine edebilir.