Mengapa pratinjau kamera saya terlihat 1080p namun orang lain melihat gambar buram?

Pratinjau browser Anda menampilkan tampilan tangkapan lokal — frame yang diproduksi kamera sebagaimana dikirimkan melalui getUserMedia() — sebelum enkoding WebRTC. Apa yang diterima orang lain adalah aliran setelah WebRTC menegosiasikan codec, bit rate, dan resolusi berdasarkan kondisi jaringan yang dipersepsikan. Jika bandwidth upload Anda terbatas, packet loss tinggi, atau platform memilih konfigurasi codec yang konservatif, browser secara diam-diam menurunkan kualitas aliran untuk menjaga koneksi stabil. Pratinjau tidak pernah mencerminkan degradasi ini karena ia diberi makan dari jalur tangkapan lokal, bukan dari output terenkod, meskipun ia mungkin tetap mencakup scaling, konversi warna, atau pemrosesan constraint yang diterapkan browser.

Bagaimana browser memutuskan menurunkan kualitas video saya?

WebRTC memperkirakan bandwidth yang tersedia dari packet loss, round-trip time, dan throughput. Ketika loss melebihi sekitar lima persen atau throughput turun di bawah bit rate saat ini, kongesti control menurunkan target bit rate dan encoder menyesuaikan resolusi dan frame rate agar muat. Sebagai contoh kasar, aliran 1080p pada tiga puluh frame per detik umumnya membutuhkan empat hingga enam megabit per detik; jika browser memperkirakan hanya satu megabit tersedia, respons umum adalah turun ke 480p pada lima belas frame per detik tanpa peringatan. Ambang pastinya bergantung pada codec, platform, dan kongesti control — pola tipikal, bukan dijamin. Ini mencegah freeze total dengan mengorbankan kualitas.

Data apa yang sebenarnya disediakan oleh getStats()?

Metode getStats() pada koneksi WebRTC mengembalikan statistik rinci tentang jalur enkoding, jaringan, dan penerimaan. Di sisi kirim, ia melaporkan frame rate aktual yang ditangkap, frame rate terenkod, resolusi output, bit rate dalam bit per detik, tingkat packet loss, dan round-trip time. Di sisi terima, ia melaporkan bit rate masuk, jitter, dan kegagalan decode. Metrik kuncinya adalah framesPerSecond pada outbound-rtp dibandingkan framesPerSecond pada media-source — jika keduanya berbeda signifikan, encoder membuang frame untuk menjaga stabilitas. Data ini membantu Anda membedakan apakah masalah berasal dari enkoding, jaringan, atau kombinasi keduanya.

Apakah noise suppression membantu atau merusak kualitas video saya?

Noise suppression audio — yang menyaring suara latar dari mikrofon — tidak secara langsung memengaruhi kualitas video dan umumnya bermanfaat di ruangan bising. Ia beroperasi pada aliran audio, bukan video. Beberapa platform video, bagaimanapun, menerapkan video noise reduction (kadang disebut denoising) pada adegan pencahayaan rendah atau variansi tinggi, yang dapat melembutkan detail halus dalam aliran terenkod. Jika Anda berada di lingkungan terkontrol dengan pencahayaan baik, menonaktifkan pengaturan video noise reduction platform dapat mempertahankan lebih banyak detail. Trade-offnya adalah kekacauan latar atau gerakan menjadi lebih terlihat. Periksa pengaturan platform spesifik untuk mengonfirmasi apa yang diredam — kontrolnya sering diberi label berbeda.

Apakah virtual background menggunakan bandwidth banyak?

Ya, bisa. Virtual background mengharuskan browser memisahkan orang dari latar belakang secara real time, yang memerlukan pemrosesan GPU tambahan dan dapat meningkatkan bit rate efektif dibandingkan latar belakang polos. Tuntutan ekstra ini dapat memicu browser menurunkan resolusi atau frame rate untuk mengimbangi. Segmentasi background juga menambah latensi ke pipeline enkoding karena browser harus memproses setiap frame sebelum mengirimkannya. Pada hardware kelas bawah, tambahan latensi ini dapat membuat video terasa tertunda bahkan jika kualitas visual tetap terlihat cukup baik. Untuk kualitas video terbaik, gunakan latar belakang nyata bersih dengan pencahayaan konsisten daripada yang virtual.

Kamera saya bekerja baik di komputer tapi terlihat buruk di panggilan video — apa yang berubah?

Platform panggilan menerapkan pipeline enkodingnya sendiri di atas implementasi WebRTC browser. Beberapa platform menerapkan kompresi tambahan, batasan resolusi, atau batas frame rate terlepas dari kondisi aktual Anda. Platform lain memprioritaskan audio di atas video dan mungkin mengurangi kualitas video untuk menjaga audio stabil. Kamera yang sama yang terlihat luar biasa di pratinjau lokal dapat terlihat buruk di panggilan karena platform memilih bit rate rendah untuk memastikan setiap orang di meeting menerima aliran stabil. Ini adalah keputusan kebijakan platform, bukan keterbatasan hardware.

Haruskah saya menggunakan VP8, VP9, atau H.264 untuk kualitas video terbaik?

VP9 menawarkan efisiensi kompresi baik dan resolusi lebih tinggi pada bit rate yang sama, namun memerlukan lebih banyak CPU untuk enkode (WebM Project: VP9 Bitstream Specification (https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.7-20170222-draft.pdf)). H.264 paling luas kompatibilitas dan mengenkod lebih cepat (ITU-T: H.264/AVC Standard (https://www.itu.int/rec/T-REC-H.264)), meskipun mungkin memerlukan sekitar dua puluh hingga tiga puluh persen lebih banyak bit rate untuk menyamai kualitas VP9 pada banyak platform. VP8 sudah legacy dan sebaiknya dihindari jika VP9 atau H.264 tersedia. Negosiasi codec browser memilih secara otomatis, namun beberapa platform mengizinkan override manual. Tidak ada codec terbaik universal.

Bagaimana memperbaiki panggilan video yang konsisten terlihat lebih buruk dari pratinjau kamera?

Mulai dengan mengukur aliran sesungguhnya menggunakan getStats() untuk mengonfirmasi apakah browser menurunkan resolusi atau frame rate. Jika resolusi turun, periksa bandwidth upload — panggilan video membutuhkan setidaknya satu megabit per detik untuk 720p dan empat megabit untuk 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)). Jika packet loss di atas lima persen, koneksi tidak stabil terlepas dari bandwidth mentah. Perbaiki pencahayaan terlebih dahulu: subjek yang terang membutuhkan lebih sedikit bit rate untuk terlihat baik. Lalu nonaktifkan noise suppression dan virtual background. Jika kualitas masih buruk di satu platform tapi baik di platform lain, kebijakan enkoding platform adalah pembatasnya, bukan hardware atau koneksi Anda.

Uji Siaran Langsung Webcam — Apa yang Sisi Lain Melihat

Gambar yang Anda lihat di pratinjau webcam adalah tampilan tangkapan lokal — feed kamera sebagaimana dikirimkan melalui getUserMedia() — bukan output sensor mentah. Gambar yang dilihat penerima panggilan video Anda adalah aliran yang dienkod browser yang telah dinegosiasikan, dikompres, dan mungkin diturunkan kualitasnya secara diam-diam oleh WebRTC. Panduan ini menjelaskan cara negosiasi codec WebRTC bekerja, cara menggunakan getStats() pada RTCPeerConnection untuk mengukur parameter aliran sungguhan, dan cara memperbaiki penyebab umum kehilangan kualitas. Perhatikan bahwa alat webcam di situs ini hanya memeriksa track tangkapan lokal dan frame rate browser; ia tidak mengukur aliran WebRTC terenkod yang keluar.

Anda duduk di panggilan video dan jendela Anda sendiri menunjukkan gambar 1080p yang tajam dan terang. Anda terlihat jelas, latar belakang bersih, dan framing tepat. Lalu seorang kolega bilang video Anda terus membeku dan terlihat buram, dan ketika mereka berbagi layar Anda melihat diri Anda sebagai gambar berblok dan tepi lembut yang akan dihasilkan webcam murah dari satu dekade lalu. Kamera yang sama. Pencahayaan yang sama. Mesin yang sama. Gambar yang berbeda.

Inilah yang dilewatkan kebanyakan panduan panggilan video: kesenjangan itu biasanya bukan kesalahan hardware atau cacat sensor — meskipun driver yang bermasalah terkadang bisa menyebabkannya juga. Ini tipikal perbedaan antara apa yang dihasilkan kamera dan apa yang benar-benar dikirim browser. Pratinjau Anda diberi makan dari jalur tangkapan lokal — frame yang dihasilkan kamera sebagaimana dikirimkan melalui getUserMedia() — sebelum enkoding WebRTC, yang membuatnya tampilan yang lebih menguntungkan dari video Anda daripada yang diterima peserta lain. Tampilan itu mungkin tetap mencakup scaling, konversi warna, atau pemrosesan constraint yang diterapkan browser, jadi bukan output sensor mentah. Apa yang diterima peserta lain adalah aliran terkompres yang telah dinegosiasikan, dienkod ulang, dibatasi laju, dan mungkin diturunkan oleh WebRTC dalam milidetik sebelum meninggalkan mesin Anda.

Lapisan enkoding itu tidak terlihat dari antarmuka pengguna dan senyap selama operasi normal. Tidak ada di jendela panggilan yang memberi tahu Anda keberadaannya, tidak ada yang melaporkan keputusannya, dan tidak ada di pratinjau Anda yang mencerminkannya. Pemandangan familiar: pengguna menghabiskan jam-jam memasang ulang driver kamera karena panggilan menunjukkan gambar buram — hanya untuk menemukan melalui chrome://webrtc-internals bahwa browser menegosiasikan turun ke 480p15 berdasarkan estimasi bandwidth, bukan karena kamera atau driver. Halaman ini menjelaskan apa yang terjadi antara sensor kamera dan layar mitra panggilan Anda, mengapa browser diam-diam menurunkan kualitas Anda, dan — yang paling penting — cara mengukur aliran sungguhan yang meninggalkan mesin Anda alih-alih mempercayai pratinjau. Laptop dengan webcam menampilkan visualisasi kualitas stream dengan indikator resolusi dan bit rate

Apa yang pratinjau Anda tidak tunjukkan

Panggilan video bertumpu pada pipeline yang berjalan sepenuhnya di luar kesadaran Anda. Setiap frame yang Anda kirim melewati tahapan berikut:

Sensor kamera menangkap frame; browser kemudian mengirimkannya melalui getUserMedia() pada resolusi dan frame rate yang diminta, yang mungkin melibatkan scaling, konversi warna, dan pemrosesan constraint.
Browser menerima frame itu melalui API getUserMedia() dan menyerahkannya ke mesin WebRTC. Pratinjau lokal Anda diberi makan dari tahap ini — itulah mengapa selalu terlihat sempurna, terlepas dari apa yang terjadi berikutnya.
Encoder WebRTC mengompresi frame menjadi bitstream menggunakan codec yang dinegosiasikan, pada resolusi, frame rate, dan bit rate yang dinegosiasikan.
Frame terenkod dipecah menjadi paket RTP dan dikirim melalui jaringan, biasanya melalui server media yang menyampaikannya ke semua orang lain.
Setiap penerima mendekode paket kembali menjadi gambar dan merendernya di layar mereka. Pratinjau Anda mengetuk pipeline di tahap dua. Ia menampilkan frame yang dihasilkan kamera sebagaimana dikirimkan melalui getUserMedia(), sebelum enkoding WebRTC. Browser mungkin menerapkan scaling, konversi warna, atau pemrosesan constraint di tahap ini, tapi tidak ada kompresi WebRTC yang diterapkan. Aliran yang dilihat mitra panggilan Anda adalah apa yang keluar dari tahap tiga. Di antara dua titik itu, encoder memutuskan apa yang diterima dunia, dan ia membuat keputusan itu berdasarkan kondisi yang tidak pernah Anda lihat.

Encoder diam-diam menegosiasikan tiga parameter, dan masing-masing dapat berubah di tengah panggilan tanpa notifikasi:

Resolusi — lebar dan tinggi frame terenkod, yang bisa turun dari 1920x1080 ke 1280x720 atau 640x480 sendirian.
Frame rate — berapa frame per detik yang bertahan enkoding, yang umumnya jatuh pertama (dari 30 ke 15 atau lebih rendah) karena memotong frame rate menjadi setengahnya memotong data rate menjadi setengah tanpa mengubah resolusi — meskipun beberapa implementasi mungkin mengurangi resolusi sebagai gantinya, tergantung codec dan platform.
Bit rate — berapa bit per detik yang diizinkan untuk encoder dibelanjakan, yang menetapkan tingkat kompresi keseluruhan. Ketiga nilai ini menentukan semua yang dilihat sisi lain. Gambar 1080p yang dikompres ke bit rate rendah terlihat lembut dan kabur. Aliran 30 fps yang tiba-tiba berjalan di 10 fps terlihat bergoyang dan tidak natural. Ketika Anda memahami bahwa pratinjau tidak melaporkan salah satu nilai ini, misteri panggilan buruk dengan kamera hebat pun terurai.

SDP menegosiasikan sebelum Anda mengirim frame

Negosiasi dimulai sebelum frame pertama dikirim. Saat Anda bergabung panggilan, platform dan browser Anda bertukar penawaran dan jawaban Session Description Protocol (SDP). SDP mengiklankan codec dan kemampuan media yang didukung setiap sisi; resolusi dan frame rate aktual kemudian dinegosiasikan lebih lanjut melalui parameter kirim dan terima dan dibatasi oleh estimasi bandwidth. Dalam pengujian informal di Chrome 125 pada Windows 10 (Mei 2024), jawaban SDP teramati menawarkan VP9 pertama, lalu H.264, lalu VP8; di Safari 17 pada macOS 14 (periode yang sama), H.264 muncul pertama. Pengamatan ini dibuat pada satu mesin per browser tanpa kondisi jaringan terkontrol, jadi menggambarkan variasi yang ada daripada mendefinisikan urutan universal. Codec aktual yang dipilih bergantung pada browser, platform, parameter SDP, dan kemampuan hardware. Pilihan umum termasuk VP9, H.264, VP8, dan AV1, namun tidak ada urutan preferensi tunggal yang tetap di semua platform.

Pemilihan codec hanya permulaan. Setelah panggilan berjalan, mekanisme kedua mengambil alih: estimasi bandwidth. WebRTC terus-menerus memantau jalur jaringan ke dua arah dan menjalankan algoritma congestion control — paling umum Google Congestion Control — yang membuat tiga pengukuran secara bergulir:

Packet loss, dilaporkan oleh penerima melalui pesan feedback RTCP.
Round-trip time, jeda antara mengirim paket dan menerima konfirmasi kedatangannya.
Throughput, laju efektif di mana data benar-benar melewati koneksi. Algoritma memasukkan pengukuran ini ke dalam model yang memperkirakan berapa bandwidth yang bisa dibawa jaringan saat ini. Perkiraan itu menjadi target bit rate yang diserahkan ke encoder, dan encoder menyesuaikan outputnya agar muat. Loop ini berkelanjutan dan cepat: ketika estimasi turun, encoder mengenkod ulang pada bit rate lebih rendah dalam sepersekian detik.

Ambangnya perkiraan dan bergantung pada algoritma congestion control spesifik yang digunakan. Packet loss berkelanjutan di atas kira-kira lima persen dapat memicu pengurangan target bit rate, namun perilaku eksaknya — berapa banyak rate turun, apakah resolusi atau frame rate juga berubah, dan pada level loss berapa — bervariasi per algoritma, codec, dan platform. Tidak ada pemetaan universal dari persentase loss ke resolusi output spesifik. Loop feedback yang mendorong keputusan ini didefinisikan dalam (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP). Aliran 1080p pada 30 fps tipikalnya membutuhkan sekitar empat hingga enam megabit per detik bandwidth upload agar terlihat bersih, meskipun ini bergantung pada codec, pengaturan enkoding, dan kompleksitas adegan. Jika estimator menyimpulkan hanya satu megabit tersedia, ia tidak mencoba memaksa aliran melewati — ia menjatuhkan target, dan encoder merespons dengan menurunkan resolusi ke 480p dan frame rate ke 15 fps. Jika estimasi turun lebih jauh, gambar terdegradasi lagi, sampai ke talking head 320x240. Setiap langkah disengaja: tujuannya menjaga panggilan tetap hidup dan audio stabil, dan kualitas video adalah hal pertama yang dikorbankan untuk mencapainya. Diagram aliran enkoding WebRTC dari sensor kamera melalui encoder browser ke jaringan dan penonton

Tiga pola kegagalan yang disembunyikan aliran Anda

Pratinjau menyembunyikan keadaan asli aliran di balik tiga pola kegagalan berulang. Belajar mengenali masing-masing dari gejalanya, karena perbaikan yang benar berbeda untuk setiap kasus. Ketiganya berbagi satu tanda: pratinjau tetap sempurna sepanjang waktu, karena ia diambil sebelum encoder. Hanya aliran terenkod — dan oleh karena itu layar peserta lain — yang menunjukkan kerusakan.

Jebakan Bit Rate

Gejala: Pratinjau Anda sempurna dan mesin Anda punya CPU idle. Sisi lain melihat gambar buram dan resolusi rendah yang tidak pernah tajam, bahkan saat jeda. Rekaman lokal terlihat luar biasa; panggilan terlihat buruk. Diagnosis: Browser telah memperkirakan bahwa jaringan tidak bisa membawa aliran penuh dan telah membat bit rate, memaksa encoder mengecilkan resolusi. Kendalanya adalah upload bandwidth atau kapasitas relay server media Anda, bukan kamera Anda. Jalankan speed test dan bandingkan upload terukur Anda terhadap empat hingga enam megabit yang dibutuhkan 1080p30. Jika Anda berbagi koneksi dengan perangkat lain yang streaming, mengunduh, atau sinkronisasi, mereka bersaing untuk anggaran yang sama.

Ambang Kehilangan Paket

Gejala: Gambar diam dari panggilan terlihat baik, tapi gerakan apa pun bergoyang dan robotik. Audio tetap mulus sementara video stutter, dan freeze pendek terjadi setiap beberapa detik sebelum gambar kembali pada frame rate lebih rendah. Diagnosis: Packet loss melewati ambang lima persen secara intermiten, jadi congestion controller berulang kali memotong target bit rate dan encoder membuang frame agar sesuai. Frame rate jatuh pertama karena ini tuas termurah — mengurangi dari 30 ke 15 fps memotong data rate setengahnya tanpa mengubah resolusi. Periksa interferensi Wi-Fi, kabel Ethernet marginal, atau VPN yang menambah loss dan latensi. Video akan terus terdegradasi sampai jalur jaringan diperbaiki.

Freeze Keyframe

Gejala: Selama dua hingga lima detik pertama setelah Anda bergabung, atau setelah Anda berbagi layar, sisi lain melihat gambar yang membeku atau sangat kabur. Lalu gambar menajam dan berperilaku normal sampai perubahan adegan besar berikutnya. Diagnosis: Codec video mengirim dua tipe frame. Keyframe mengenkod keseluruhan gambar dan muncul pada interval tetap — biasanya setiap satu hingga sepuluh detik tergantung platform dan konfigurasi. Delta frame hanya mengenkod perubahan sejak frame sebelumnya, yang membuatnya kecil. Jika paket dari delta frame hilang, penerima tidak bisa merekonstruksi frame itu — ia bisa meminta pengiriman ulang (NACK), meminta pengirim keyframe baru (PLI atau FIR), atau menyembunyikan error sambil menunggu. Ketika permintaan berhasil, pemulihan cepat; ketika tidak, gambar tetap membeku sampai keyframe terjadwal berikutnya tiba. Itulah freeze yang Anda lihat. Interval keyframe pendek pulih lebih cepat tapi menghabiskan bandwidth; interval panjang efisien tapi membuat setiap loss lebih terlihat. Ini bukan malfungsi — ini codec bekerja sebagaimana dirancang. Perbandingan pratinjau webcam 1080p tajam versus aliran 480p berblok yang diturunkan

Mengukur aliran sungguhan dengan getStats()

Berhenti menebak. Angkanya tidak menyanjung, tapi mereka benar. API WebRTC mengekspos antarmuka statistik yang melaporkan persis apa yang dilakukan encoder, dan halaman web apa pun yang Anda kendalikan bisa membaca koneksi peer-nya sendiri. Panggil getStats() pada objek RTCPeerConnection, lalu saring laporan yang dikembalikan untuk entri outbound-rtp yang kind-nya video. Pada entri media-source dan outbound-rtp Anda akan menemukan nilai yang penting:

framesPerSecond (pada entri media-source) — frame rate yang dikirim kamera ke encoder. Jika ini di bawah 30 pada kamera 30 fps, jalur tangkapan itu sendiri masalahnya — sering kali ini masalah sengketa bandwidth USB; cara mendiagnosisnya dijelaskan dalam panduan sengketa bandwidth USB kami.
framesPerSecond (pada entri outbound-rtp) — frame rate yang sebenarnya dihasilkan encoder. Ketika ini lebih rendah dari laju input, encoder sedang membuang frame.
frameWidth dan frameHeight (pada entri outbound-rtp) — resolusi terenkod. Bandingkan dengan pengaturan panggilan Anda; setiap perbedaan adalah penurunan diam-diam.
bytesSent (pada entri outbound-rtp) — total data terenkod. Sampel dua kali berjarak satu detik dan hitung selisih kali 8 untuk mendapatkan bit rate asli.
packetsSent dan packetsLost — perhatikan bahwa packetsLost pada entri outbound-rtp tidak selalu terisi; rasio loss lebih andal dibaca dari entri remote-inbound-rtp, yang melaporkan perspektif penerima.
currentRoundTripTime (pada entri candidate-pair) — jeda jaringan. RTT tinggi dikombinasikan dengan loss mengindikasikan kongesti.

Browser berbeda mungkin melaporkan nama field yang sedikit berbeda atau menghilangkan beberapa statistik sepenuhnya, jadi silang-cek terhadap halaman internal WebRTC browser jika tersedia.

Aturan interpretasinya sederhana. Jika outbound-rtp framesPerSecond terlihat di bawah media-source framesPerSecond, encoder sedang membuang frame di bawah tekanan. Jika frameWidth dan frameHeight di bawah resolusi yang Anda konfigurasi, anggaran koneksi tidak bisa membawanya. Jika bytesSent diterjemahkan ke bit rate jauh di bawah kebutuhan codec untuk resolusi itu, gambar sedang digiling — dan pratinjau, yang tidak pernah melihat encoder, akan terlihat baik sepanjang waktu.

Anda tidak perlu menulis kode untuk membaca nilai ini. Chrome dan Edge menyertakan penampil statistik bawaan di chrome://webrtc-internals yang menangkap setiap koneksi WebRTC di browser, termasuk yang dibuat platform panggilan. Buka sebelum bergabung meeting, biarkan merekam, dan inspeksi entri outbound-rtp untuk pengirim video setelahnya. Angka frame rate, resolusi, bit rate, dan loss yang sama ada di sana, bersama grafik timeline yang menunjukkan persis kapan encoder mengubah outputnya. Ini cara tercepat untuk menangkap penurunan dalam aksi pada panggilan platform nyata.

Jalankan pengukuran ini saat panggilan Anda sendiri idle di latar belakang, lalu lagi selama meeting sibuk, dan bandingkan dua set angka. Perbandingan tipikal: idle, outbound-rtp framesPerSecond terbaca 30; selama meeting sibuk bisa turun ke 18 sementara pratinjau lokal masih menunjukkan 30. Perbandingan itu mengungkap apakah jaringan baseline Anda memadai dan apakah kontensi selama panggilan yang memicu penurunan. Uji webcam kami menunjukkan resolusi dan frame rate track tangkapan lokal sebagaimana dinegosiasikan melalui getUserMedia() — baseline berguna untuk apa yang bisa dikirim kamera Anda ke browser, tapi bukan pengukuran aliran WebRTC terenkod keluar, yang memerlukan peer connection atau halaman internal WebRTC browser.

Zoom, Meet, Teams: Tiga Kamera Berbeda

Kamera yang sama, laptop yang sama, dan jaringan yang sama bisa menghasilkan hasil yang berbeda terlihat di aplikasi berbeda, karena setiap platform menerapkan kebijakan enkodingnya sendiri di atas implementasi WebRTC browser.

Zoom umumnya memprioritaskan stabilitas. Tergantung versi, tipe akun, dan pengaturan meeting, mungkin membat resolusi keluar dan mengorbankan kualitas video untuk menjaga audio dan berbagi layar stabil. Kamera berkemampuan 1080p mungkin mengirim 720p atau lebih rendah di Zoom.
Google Meet cenderung beradaptasi dengan bandwidth terukur, menurunkan resolusi lebih awal dan memulihkannya cepat saat kondisi membaik. Perilakunya melacak kondisi jaringan aktual Anda, untuk lebih baik dan lebih buruk.
Microsoft Teams menerapkan pipeline enkoding dan post-processing sendiri. Tergantung versi dan pengaturan meeting, gambar mungkin dikompres lebih lanjut di luar negosiasi WebRTC mentah.
WebRTC native browser, jenis yang Anda dapatkan di halaman web polos, mengirim aliran yang dinegosiasikan tanpa kebijakan platform di atasnya. Ini adalah yang terdekat dengan ground truth untuk apa yang bisa dikirim hardware dan jaringan Anda di bawah WebRTC polos. Kebijakan platform bervariasi per versi, tipe akun, dan konfigurasi meeting, jadi perlakukan ini sebagai kecenderungan umum bukan aturan tetap. Konsekuensi praktisnya: membandingkan panggilan Zoom dengan panggilan Meet bukan tes kamera. Ini adalah tes keputusan enkoding setiap platform. Ukur aliran mentah dulu dengan halaman WebRTC polos atau alat uji webcam. Jika aliran mentah bersih dan satu platform masih terlihat buruk, kebijakan platform itulah kendalanya, dan tidak ada upgrade hardware yang akan mengubahnya. Saat panggilan platform berlangsung, chrome://webrtc-internals memungkinkan Anda menonton keputusan encodernya secara langsung, jadi Anda bisa melihat apakah penurunan adalah kebijakan platform atau perilaku jaringan tanpa mempercayai laporan mandiri salah satu sisi.

Tujuh langkah menuju aliran bersih

Langkah-langkah ini mengisolasi penyebab berbeda. Anda bisa berhenti begitu aliran terlihat benar — tapi ukur sebelum dan sesudah setiap perubahan untuk mengonfirmasi perbaikan benar-benar menggerakkan angkanya.

Ukur dulu. Buka chrome://webrtc-internals atau gunakan getStats() pada peer connection Anda sendiri dan catat resolusi, frame rate, dan bit rate. Jika aliran mentah sudah diturunkan, kamera dan koneksi Anda masalahnya. Jika bersih, platformnya.
Periksa bandwidth. Panggilan video butuh setidaknya 1 Mbps upload untuk 720p dan kira-kira 4 Mbps untuk 1080p. Tes dari mesin yang Anda panggil, bukan perangkat lain, dan tes ulang dengan lalu lintas lain di jaringan. Pindah ke koneksi kabel jika bisa; loss Wi-Fi adalah penyebab paling umum dari penurunan tak terlihat.
Perbaiki pencahayaan. Subjek yang terang mengompresi jauh lebih baik daripada yang gelap, karena encoder membelanjakan bit rate pada detail terlihat daripada noise. Hadap jendela atau gunakan sumber cahaya lembut. Ini gratis dan sering menghasilkan perbaikan lebih besar daripada pengaturan apa pun.
Nonaktifkan video noise reduction saat lingkungan Anda sudah senyap dan terang. Beberapa platform menerapkan denoising agresif di adegan cahaya rendah, yang bisa melembutkan detail halus terlihat dalam aliran terenkod. Pratinjau lokal tidak akan menunjukkan perbedaan ini; hanya aliran terenkod yang akan. Periksa pengaturan platform spesifik untuk mengonfirmasi kontrol apa yang tersedia.
Nonaktifkan virtual background. Segmentasi background menambah overhead ke bit rate efektif dan mengonsumsi siklus GPU dari encoder. Latar belakang nyata bersih dengan pencahayaan konsisten mengalahkan yang virtual.
Periksa codec. Jika CPU Anda mampu, VP9 memberikan kualitas terbaik per bit; jika Anda melihat frame drop atau lonjakan CPU, H.264 mengenkod lebih cepat. Beberapa platform mengekspos preferensi codec di pengaturan.
Tes platform berbeda. Jika kualitas baik di satu layanan dan buruk di lain, kebijakan enkoding platform adalah kendalanya. Sesuaikan ekspektasi atau alat meeting Anda — hardware Anda tidak bersalah.

Garis bawah

Pratinjau adalah citra diri lokal kamera Anda: tampilan yang menguntungkan dari apa yang bisa dikirim kamera ke browser. Aliran adalah apa yang benar-benar dilihat dunia — dinegosiasikan, dikompres, dan dibentuk oleh kondisi jaringan dan kebijakan platform. Mereka adalah dua video berbeda dari subjek yang sama, dan hanya satu yang penting untuk bagaimana Anda terlihat. Jika Anda pernah bertanya-tanya mengapa kamera Anda terlihat hebat di layar Anda tapi buruk di panggilan, Anda kini punya jawaban dan alat untuk mengukurnya.

Buka chrome://webrtc-internals. Bergabung panggilan Anda berikutnya. Awasi entri outbound-rtp. Jika frameWidth atau framesPerSecond di bawah yang Anda atur di pengaturan kamera, penurunan sedang terjadi. Penyebabnya tipikalnya terkait bandwidth — apa yang diizinkan browser belanjakan, dan apakah koneksi Anda benar-benar bisa membawa aliran yang Anda pikir Anda kirim — tapi beban CPU, pemilihan encoder, kebijakan platform, dan konfigurasi constraint juga bisa berkontribusi atau mendominasi degradasi.