Mengapa pratonton kamera saya kelihatan seperti 1080p tetapi orang lain melihat imej kabur?

Pratonton pelayar anda menunjukkan pandangan tangkapan tempatan — bingkai yang kamera hasilkan sebagaimana dihantar melalui getUserMedia() — sebelum enkod WebRTC. Apa yang orang lain terima ialah aliran selepas WebRTC telah menegosiasikan codec, bit rate, dan resolusi berdasarkan keadaan rangkaian persepsi. Jika lebar jalur upload anda terhad, kehilangan pakej tinggi, atau platform memilih konfigurasi codec konservatif, pelayar menurunkan aliran secara senyap untuk mengekalkan sambungan stabil. Pratonton tidak pernah mencerminkan degradasi ini kerana ia diberi makan dari laluan tangkapan tempatan, bukan dari output enkod, walaupun ia mungkin masih termasuk penskalaan, penukaran warna, atau pemprosesan kekangan yang diterapkan oleh pelayar.

Bagaimana pelayar memutuskan untuk menurunkan kualiti video saya?

WebRTC menganggarkan lebar jalur tersedia dari kehilangan pakej, masa pusingan bulat, dan kelancaran. Apabila kehilangan melebihi kira-kira lima peratus atau kelancaran jatuh di bawah bit rate semasa, kawalan kesesakan menurunkan bit rate sasaran dan penderiaan menyesuaikan resolusi dan kadar bingkai untuk muat. Sebagai contoh kasar, aliran 1080p pada tiga puluh bingkai sesaat biasanya memerlukan kira-kira empat hingga enam megabit sesaat; jika pelayar menganggarkan hanya satu megabit tersedia, respons biasa ialah turun ke 480p pada lima belas bingkai sesaat tanpa amaran. Ambang tepat bergantung kepada codec, platform, dan kawalan kesesakan — corak biasa, tidak dijamin. Ini menghalang beku penuh dengan kos kualiti.

Data apakah yang getStats() sebenarnya berikan?

Kaedah getStats() pada sambungan WebRTC mengembalikan statistik terperinci tentang laluan penyiara, rangkaian, dan penerimaan. Di sebelah hantar ia melaporkan kadar bingkai sebenar yang ditangkap, kadar bingkai enkod, resolusi output, bit rate dalam bit sesaat, kadar kehilangan pakej, dan masa pusingan bulat. Di sebelah terima ia melaporkan bit rate masuk, jitter, dan kegagalan decode. Metric utama ialah framesPerSecond pada outbound-rtp berbanding framesPerSecond pada media-source — jika ia berbeza ketara, penderiaan menjatuhkan bingkai untuk mengkekalkan kestabilan. Alat ini dapat dipanggil dari konsol pelayar atau laman web anda sendiri untuk melihat nilai sebenar aliran pada masa nyata.

Adakah penindasan bising membantu atau mencederakan kualiti video saya?

Penindasan bising audio — yang menapis bunyi latar belakang dari mikrofon — tidak memberi kesan langsung kepada kualiti video dan biasanya bermanfaat dalam bilik bising. Ia beroperasi pada aliran audio, bukan video. Sesetengah platform video, namun, menerapkan pengurangan bising video (kadangkala dipanggil denoising) dalam senario cahaya rendah atau variance tinggi, yang boleh melembutkan detil halus dalam aliran enkod. Jika anda dalam persekitaran terkawal dengan pencahayaan baik, melumpuhkan tetapan pengurangan bising video platform boleh mengekalkan lebih detil. Pertaruhan ialah clutter latar belakang atau pergerakan menjadi lebih kelihatan. Semak tetapan platform spesifik untuk mengesahkan apa yang ditindas — kawalan sering dilabel berbeza.

Adakah latar belakang maya menggunakan banyak lebar jalur?

Ya, ia boleh. Latar belakang maya memerlukan pelayar memisah orang dari latar belakang dalam masa nyata, yang memerlukan pemprosesan GPU tambahan dan boleh meningkatkan bit rate berkesan berbanding latar belakang polos. Penceraian imej secara real-time membebani pemproses grafik dengan ketara. Demand tambahan ini mungkin mencetuskan pelayar menurunkan resolusi atau kadar bingkai untuk menebus. Untuk kualiti video terbaik, gunakan latar belakang sebenar bersih dengan pencahayaan konsisten daripada satu maya. Segmentasi juga menambah latensi kepada paip penyiara, yang boleh menjadikan video terasa kurang responsif pada perkakasan bawah.

Kamera saya berfungsi baik pada komputer saya tetapi kelihatan teruk pada panggilan video — apa berubah?

Platform panggilan menerapkan paip penyiara sendiri di atas pelaksanaan WebRTC pelayar. Sesetengah platform menerapkan pemampatan tambahan, had resolusi, atau had kadar bingkai tanpa mengira keadaan sebenar anda. Platform ini menambah lapisan pemprosesan di antara kamera dan rangkaian. Yang lain mengutamakan audio atas video dan mungkin mengurangkan kualiti video untuk mengekalkan audio stabil. Kamera yang sama yang kelihatan cemerlang dalam pratonton tempatan boleh kelihatan teruk pada panggilan kerana platform memilih bit rate rendah untuk memastikan semua orang dalam mesyuarat menerima aliran stabil. Ini keputusan dasar platform, bukan had perkakasan.

Patutkah saya menggunakan VP8, VP9, atau H.264 untuk kualiti video terbaik?

VP9 menawarkan kecekapan pemampatan baik dan resolusi lebih tinggi pada bit rate yang sama, tetapi memerlukan lebih CPU untuk enkod (WebM Project: VP9 Bitstream Specification (https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.7-20170222-draft.pdf)). H.264 ialah paling luas serasi dan enkod lebih pantas (ITU-T: H.264/AVC Standard (https://www.itu.int/rec/T-REC-H.264)), walaupun ia mungkin memerlukan kira-kira dua puluh hingga tiga puluh peratus lebih bit rate untuk memadani kualiti VP9 pada ramai platform. VP8 warisan dan paling baik dielakkan jika VP9 atau H.264 tersedia. Negosiasi codec pelayar memilih secara automatik, tetapi sesetengah platform membenarkan override manual. Tiada codec terbaik universal.

Bagaimana saya membetulkan panggilan video yang konsisten kelihatan lebih teruk daripada pratonton kamera saya?

Mula dengan mengukur aliran sebenar menggunakan getStats() untuk mengesahkan sama ada pelayar menurunkan resolusi atau kadar bingkai. Jika resolusi jatuh, semak lebar jalur upload anda — panggilan video memerlukan setidaknya satu megabit sesaat 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 kehilangan pakej di atas lima peratus, sambungan tidak stabil tanpa mengira lebar jalur mentah. Betulkan pencahayaan dahulu: subjek terang memerlukan kurang bit rate untuk kelihatan baik. Kemudian lumpuhkan penindasan bising dan latar belakang maya. Jika kualiti masih teruk pada satu platform tetapi baik pada yang lain, dasar penyiara platform ialah kekangan, bukan perkakasan atau sambungan anda.

Ujian Aliran Webcam Sebenar: Apa Penerima Pandang Benar

Imej yang anda lihat dalam pratonton webcam ialah pandangan tangkapan tempatan — aliran kamera sebagaimana dihantar melalui getUserMedia() — bukan output sensor kasar. Imej penerima panggilan video anda ialah aliran enkod oleh pelayar yang telah dirundingkan secara senyap, dimampatkan, dan mungkin diturunkan oleh WebRTC. Panduan ini menerangkan bagaimana negosiasi codec WebRTC berfungsi, bagaimana menggunakan getStats() pada RTCPeerConnection untuk mengukur parameter aliran sebenar, dan bagaimana membetulkan punca kehilangan kualiti biasa. Harap maklum bahawa alat webcam tapak ini hanya menyemak trek tangkapan tempatan dan kadar bingkai pelayar sahaja; ia tidak mengukur aliran WebRTC enkod keluar.

Anda duduk dalam panggilan video dan tingkap anda sendiri menunjukkan imej 1080p tajam, terang. Anda kelihatan tajam, latar belakang bersih, dan bingkai tepat. Kemudian rakan sekerja mengatakan video anda kerap beku dan kelihatan kabur, dan apabila mereka kongsi skrin mereka anda melihat diri anda sebagai gambar berblok, tepi lembut yang webcam bajet dari dekad lalu mungkin hasilkan. Kamera sama. Pencahayaan sama. Mesin sama. Imej berbeza.

Inilah yang kebanyakan panduan panggilan video langkau: jurang itu biasanya bukan kecacatan perkakasan atau kecacatan sensor — walaupun pemacu yang berkelakuan salah kadangkala boleh menyebabkannya juga. Ia biasanya perbezaan antara apa yang kamera anda hasilkan dan apa yang pelayar anda sebenarnya hantar. Pratonton anda diberi makan dari laluan tangkapan tempatan — bingkai yang kamera hasilkan sebagaimana dihantar melalui getUserMedia() — sebelum enkod WebRTC, yang menjadikannya pandangan lebih menyenangkan video anda daripada apa yang peserta lain terima. Pandangan itu mungkin masih termasuk penskalaan, penukaran warna, atau pemprosesan kekangan yang diterapkan oleh pelayar, jadi ia bukan output sensor kasar. Apa yang peserta lain terima ialah aliran mampat that telah dirundingkan, enkod semula, had kadar, dan mungkin diturunkan oleh WebRTC dalam milisaat sebelum ia meninggalkan mesin anda.

Lapisan penyiara itu tidak ketara dari antara muka pengguna dan senyap semasa operasi normal. Tiada apa-apa dalam tingkap panggilan memberitahu anda ia wujud, tiada apa-apa melaporkan keputusannya, dan tiada apa-apa dalam pratonton anda mencerminkannya. Adegan biasa: pengguna menghabiskan jam memuat semula pemacu kamera kerana panggilan menunjukkan imej kabur — hanya untuk mengetahui melalui chrome://webrtc-internals bahawa pelayar menegosiasikan turun ke 480p15 berdasarkan anggaran lebar jalur, bukan kerana kamera atau pemacu. Halaman ini menerangkan apa yang berlaku antara sensor kamera dan skrin rakan panggilan anda, mengapa pelayar secara senyap menurunkan kualiti anda, dan — yang paling penting — bagaimana mengukur aliran sebenar yang meninggalkan mesin anda daripada mempercayai pratonton. Komputer riba dengan webcam menunjukkan visualisasi kualiti aliran video dengan penunjuk resolusi dan bit rate ditindihkan

Apa pratonton anda tidak tunjukkan

Panggilan video bertumpu pada paip yang berjalan sepenuhnya di luar kesedaran anda. Setiap bingkai yang anda hantar melalui peringkat berikut:

Sensor kamera menangkap bingkai; pelayar kemudian menghantarinya melalui getUserMedia() pada resolusi dan kadar bingkai diminta, yang mungkin melibatkan penskalaan, penukaran warna, dan pemprosesan kekangan.
Pelayar menerima bingkai itu melalui API getUserMedia() dan menyerahkannya kepada enjin WebRTC. Pratonton tempatan anda diberi makan dari peringkat ini — itulah sebabnya ia sentiasa kelihatan sempurna, tanpa mengira apa yang berlaku seterusnya.
Penderiaan WebRTC memampatkan bingkai ke dalam bitstream menggunakan codec dirundingkan, pada resolusi, kadar bingkai, dan bit rate dirundingkan.
Bingkai enkod dipisah kepada pakej RTP dan dihantar melalui rangkaian, biasanya melalui pelayan media yang meneruskannya kepada semua orang lain.
Setiap penerima decode pakej kembali menjadi gambar dan memaparkannya pada skrin mereka. Pratonton anda menyambung ke paip pada peringkat dua. Ia memaparkan bingkai yang kamera hasilkan sebagaimana dihantar melalui getUserMedia(), sebelum enkod WebRTC. Pelayar mungkin menerapkan penskalaan, penukaran warna, atau pemprosesankekangan pada peringkat ini, tetapi tiada pemampatan WebRTC diterapkan. Aliran rakan panggilan anda lihat ialah apa yang keluar dari peringkat tiga. Antara dua titik itu, penderiaan memutuskan apa yang dunia terima, dan ia membuat keputusan itu berdasarkan keadaan yang anda tidak pernah lihat.

Penderiaan secara senyap menegosiasikan tiga parameter, dan setiap satu boleh berubah tengah panggilan tanpa sebarang notifikasi:

Resolusi — lebar dan tinggi bingkai enkod, yang boleh jatuh dari 1920 x 1080 ke 1280 x 720 atau 640 x 480 dengan sendiri.
Kadar bingkai — berapa banyak bingkai sesaat bertahan penyiara, yang biasa jatuh dahulu (dari 30 ke 15 atau lebih rendah) kerana memotong kadar bingkai separuh memotong kadar data separuh tanpa mengubah resolusi — walaupun sesetengah pelaksanaan mungkin mengurangkan resolusi sebaliknya, bergantung kepada codec dan platform.
Bit rate — berapa banyak bit sesaat penderiaan dibenarkan menghabiskan, yang menetapkan tahap pemampatan keseluruhan. Tiga nilai ini menentukan segala-galanya pihak lain lihat. Imej 1080p dimampatkan pada bit rate rendah kelihatan lembut dan berlorek. Aliran 30 fps tiba-tiba berjalan pada 10 fps kelihatan juddery dan tidak semula jadi. Apabila anda memahami pratonton tidak melaporkan mana-mana nilai ini, misteri panggilan teruk dengan kamera hebat hilang.

SDP Menegosiasikan Sebelum Anda Menghantar Bingkai

Negosiasi bermula sebelum bingkai pertama dihantar. Apabila anda menyertai panggilan, platform dan pelayar anda bertukar Session Description Protocol (SDP) tawaran dan jawapan. SDP mengumumkan codec dan keupayaan media setiap sisi menyokong; resolusi dan kadar bingkai sebenar kemudian dirundingkan lanjut melalui parameter hantar dan terima dan dikawal oleh anggaran lebar jalur. Dalam ujian tidak rasmi pada Chrome 125 pada Windows 10 (Mei 2024), jawapan SDP diperhatikan menawarkan VP9 dahulu, kemudian H.264, kemudian VP8; pada Safari 17 pada macOS 14 (tempoh sama), H.264 muncul dahulu. Pemerhatian ini dibuat pada satu mesin setiap pelayar tanpa keadaan rangkaian terkawal, jadi ia menggambarkan variasi yang wujud daripada mentakrifkan tertib universal. Codec sebenar yang dipilih bergantung kepada pelayar, platform, parameter SDP, dan keupayaan perkakasan. Pilihan biasa termasuk VP9, H.264, VP8, dan AV1, tetapi tiada tertib keutamaan tetap tunggal merentas semua platform.

Pemilihan codec hanyalah permulaan. Selepas panggilan langsung, mekanisme kedua mengambil alih: anggaran lebar jalur. WebRTC memantau laluan rangkaian secara berterusan dalam kedua-dua arah dan menjalankan algoritma kawalan kesesakan — paling kerap Google Congestion Control — yang membuat tiga ukuran secara berterusan:

Kehilangan pakej, dilaporkan oleh penerima melalui mesej maklum balas RTCP.
Masa pusingan bulat, kelewatan antara menghantar pakej dan menerima pengiktirafan ketibaannya.
Kelancaran, kadar berkesan di mana data sebenarnya melintasi sambungan. Algoritma memaka ukuran ini ke dalam model yang menganggarkan berapa banyak lebar jalur rangkaian boleh bawa semasa. Anggaran itu menjadi bit rate sasaran diserah kepada penderiaan, dan penderiaan menyesuaikan outputnya untuk muat. Gelung itu berterusan dan pantas: apabila anggaran jatuh, penderiaan enkod semula pada bit rate lebih rendah dalam pecahan saat.

Ambang adalah anggaran dan bergantung kepada algoritma kawalan kesesakan spesifik yang digunakan. Kehilangan pakej berterusan di atas kira-kira lima peratus boleh mencetuskan pengurangan bit rate sasaran, tetapi kelakuan tepat — berapa banyak kadar jatuh, sama ada resolusi atau kadar bingkai juga berubah, dan pada tahap kehilangan apa — berbeza mengikut algoritma, codec, dan platform. Tiada pemetaan universal dari peratus kehilangan ke resolusi output khusus. Gelung maklum balas yang memacu keputusan ini ditakrifkan dalam (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP). Aliran 1080p pada 30 fps biasanya memerlukan kira-kira empat hingga enam megabit sesaat lebar jalur upload untuk kelihatan bersih, walaupun ini bergantung kepada codec, tetapan penyiara, dan kompleksiti adegan. Jika pemerikir menimpulkan hanya satu megabit tersedia, ia tidak cuba memaksa aliran — ia menjatuhkan sasaran, dan penderiaan bertindak balas dengan menurunkan resolusi ke 480p dan kadar bingkai ke 15 fps. Jika anggaran jatuh lebih jauh, gambar merosot lagi, terus ke bawah kepada kepala bercakap 320 x 240. Setiap langkah berkesedaran: matlamat ialah mengekalkan panggilan hidup dan audio stabil, dan kualiti video ialah perkara pertama dikorbankan untuk mencapainya. Rajah yang menunjukkan aliran penyiara video WebRTC dari sensor kamera melalui penderiaan pelayar ke rangkaian dan penonton

Tiga corak kegagalan yang aliran anda sembunyikan

Pratonton menyembunyikan keadaan sebenar aliran di sebalik tiga corak kegagalan berulang. Belajar mengenali setiap satu oleh gejalanya, kerana pembetulan betul berbeza untuk setiap kes. Ketiga-tiganya kongsi satu petunjuk: pratonton kekal sempurna sepanjang masa, kerana ia disampel sebelum penderiaan. Hanya aliran enkod — dan oleh itu skrin peserta lain — menunjukkan kerosakan.

Perangkap Bit Rate

Gejala: Pratonton anda sempurna dan mesin anda mempunyai CPU lengang. Pihak lain melihat imej kabur, resolusi rendah yang tidak pernah menajamkan, bahkan semasa jeda. Rakaman tempatan kelihatan cemerlang; panggilan kelihatan teruk.

Diagnosis: Pelayar telah menganggarkan bahawa rangkaian tidak mampu bawa aliran penuh dan telah mengehadkan bit rate, memaksa penderiaan mengecilkan resolusi. Kekangan ialah lebar jalur upload anda atau kebolehan terusan pelayan media, bukan kamera anda. Jalankan ujian kelajuan dan bandingkan upload diukur anda terhadap empat hingga enam megabit yang 1080p30 memerlukan. Jika anda berkongsi sambungan dengan peranti lain streaming, memuat turun, atau menyelaraskan, mereka bersaing untuk bajet yang sama.

Ambang Kehilangan

Gejala: Gambar tetap dari panggilan kelihatan baik, tetapi sebarang pergerakan terasa juddery dan robotik. Audio kekal lancar sementara video tersendat, dan beku pendek berlaku setiap beberapa saat sebelum gambar kembali pada kadar bingkai lebih rendah.

Diagnosis: Kehilangan pakej melintasi ambang lima peratus secara berintermitt, jadi pengawal kesesakan berulang kali memotong bit rate sasaran dan penderiaan menjatuhkan bingkai untuk memadani. Kadar bingkai jatuh dahulu kerana ia tuas termurah — mengurangkan dari 30 ke 15 fps memotong kadar data separuh tanpa mengubah resolusi. Semak gangguan Wi-Fi, kabel Ethernet sempit, atau VPN menambah kehilangan dan latensi. Video akan terus merosot sehingga laluan rangkaian diperbaiki.

Beku Keyframe

Gejala: Untuk dua hingga lima saat pertama selepas anda menyertai, atau selepas anda kongsi skrin, pihak lain melihat gambar beku atau berlorek teruk. Kemudian gambar snap fokus dan berkelakuan normal sehingga perubahan adegan besar seterusnya.

Diagnosis: Codec video menghantar dua jenis bingkai. Keyframe menyandikan keseluruhan gambar dan muncul pada interval tetap — biasa setiap satu hingga sepuluh saat bergantung kepada platform dan konfigurasi. Bingkai delta hanya menyandikan perubahan sejak bingkai sebelumnya, yang menjadikannya kecil. Jika pakej dari bingkai delta hilang, penerima tidak mampu membina semula bingkai itu — ia boleh meminta penghantaran semula (NACK), meminta pemancar untuk keyframe segar (PLI atau FIR), atau menyembunyikan ralat sambil menunggu. Apabila permintaan berjaya, pemulihan pantas; apabila tidak, gambar kekal beku sehingga keyframe jadual seterusnya tiba. Tunggu itu ialah beku yang anda lihat. Interval keyframe pendek pulih lebih cepat tetapi kos lebar jalur; interval panjang cekap tetapi menjadikan setiap kehilangan lebih kelihatan. Ini bukan kecacatan — ini codec bekerja seperti direka. Perbandingan bersebelahan pratonton webcam 1080p tajam berbanding aliran 480p diturunkan berblok

Mengukur aliran sebenar dengan getStats()

Berhenti meneka. Angka tidak flattering, tetapi ia benar. API WebRTC mendedahkan antaramuka statistik yang melaporkan tepat apa yang penderiaan lakukan, dan mana-mana halaman web yang anda kawal boleh baca peer connection sendiri. Panggil getStats() pada objek RTCPeerConnection, kemudian tapis laporan yang dikembalikan untuk entri outbound-rtp yang kind ialah video. Pada entri media-source dan outbound-rtp anda akan jumpa nilai yang penting:

framesPerSecond (pada entri media-source) — kadar bingkai kamera menghantar kepada penderiaan. Jika ini di bawah 30 pada kamera 30 fps, laluan tangkapan sendiri ialah masalah — selalunya ini isu perebutan lebar jalur USB; cara mendiagnosisnya dijelaskan dalam panduan perebutan lebar jalur USB kami.
framesPerSecond (pada entri outbound-rtp) — kadar bingkai penderiaan sebenarnya menghasilkan. Apabila ini lebih rendah daripada kadar input, penderiaan menjatuhkan bingkai.
frameWidth dan frameHeight (pada entri outbound-rtp) — resolusi enkod. Bandingkan dengan tetapan panggilan anda; setiap perbezaan ialah penurunan senyap.
bytesSent (pada entri outbound-rtp) — jumlah data enkod. Sampel dua kali satu saat terpisah dan kira perbezaan darab 8 untuk mendapatkan bit rate sebenar.
packetsSent dan packetsLost — perhatikan bahawa packetsLost pada entri outbound-rtp tidak sentiasa dipenuhi; nisbah kehilangan lebih boleh dipercayai dibaca dari entri remote-inbound-rtp, yang melaporkan perspektif penerima.
currentRoundTripTime (pada entri candidate-pair) — kelewatan rangkaian. RTT tinggi bersama kehilangan menunjukkan kesesakan. Pelayar berbeza mungkin melaporkan nama medan sedikit berbeza atau menghilangkan sesetengah statistik sepenuhnya, jadi semak silang dengan halaman WebRTC internals pelayar apabila tersedia.

Peraturan tafsiran mudah. Jika outbound-rtp framesPerSecond jelas di bawah media-source framesPerSecond, penderiaan menanggalkan bingkai bawah tekanan. Jika frameWidth dan frameHeight di bawah resolusi yang anda konfigurasi, bajet sambungan tidak mampu bawa. Jika bytesSent diterjemahkan ke bit rate jauh di bawah keperluan codec untuk resolusi itu, imej sedang dipukul — dan pratonton, yang tidak pernah melihat penderiaan, akan kelihatan baik sepanjang masa.

Anda tidak perlu menulis kod untuk membaca nilai ini. Chrome dan Edge membekalkan pemapar statistik terbina dalam di chrome://webrtc-internals yang menangkap setiap sambungan WebRTC dalam pelayar, termasuk satu yang platform panggilan ciptakan. Buka ia sebelum menyertai mesyuarat, biar ia rakam, dan periksa entri outbound-rtp untuk penghantar video selepas itu. Angka kadar bingkai, resolusi, bit rate, dan kehilangan yang sama ada di sana, bersama graf garis masa menunjukkan tepat bila penderiaan mengubah outputnya. Ini cara terpantas untuk menangkap penurunan dalam tindakan pada panggilan platform sebenar.

Jalankan ukuran ini sementara panggilan anda sendiri lengang di latar belakang, kemudian lagi semasa mesyuarat sibuk, dan bandingkan dua set angka. Perbandingan biasa: lengang, outbound-rtp framesPerSecond baca 30; semasa mesyuarat sibuk ia boleh jatuh ke 18 sementara pratonton tempatan masih menunjukkan 30. Perbandingan itu mendedahkan sama ada rangkaian asas anda mencukupi dan sama ada perebutan semasa panggilan ialah yang mencetuskan penurunan. Ujian webcam kami menunjukkanresolusi dan kadar bingkai trek tangkapan tempatan sebagaimana dirundingkan melalui getUserMedia() — garis asas berguna untuk apa yang kamera anda mampu hantar ke pelayar, tetapi bukan ukuran aliran WebRTC enkod keluar, yang memerlukan peer connection atau halaman WebRTC internals pelayar.

Zoom, Meet, Teams: Tiga Kamera Berbeza

Kamera sama, komputer riba sama, dan rangkaian sama boleh menghasilkan keputusan kelihatan berbeza dalam aplikasi berbeza, kerana setiap platform menerapkan dasar penyiara sendiri di atas pelaksanaan WebRTC pelayar.

Zoom biasa mengutamakan kestabilan. Bergantung kepada versi, jenis akaun, dan tetapan mesyuarat, ia mungkin had resolusi keluaran dan mengorbankan kualiti video untuk mengekalkan audio dan kongsi skrin stabil. Kamera keupayaan 1080p mungkin menghantar 720p atau lebih rendah pada Zoom.
Google Meet cenderung menyesuaikan kepada lebar jalur diukur, menurunkan resolusi awal dan memulihkannya pantas apabila keadaan bertambah baik. Kelakuannya mengikuti keadaan rangkaian sebenar anda, untuk baik dan buruk.
Microsoft Teams menerapkan paip penyiara dan post-processing sendiri. Bergantung kepada versi dan tetapan mesyuarat, imej mungkin dimampatkan lebih jauh melebihi negosiasi WebRTC kasar.
WebRTC asli pelayar, jenis yang anda dapat pada halaman web kosong, menghantar aliran dirundingkan tanpa dasar platform di atas. Ia perkara terdekat dengan kebenaran asas untuk apa yang perkakasan dan rangkaian anda mampu hantar bawah WebRTC polos. Dasar platform berbeza mengikut versi, jenis akaun, dan konfigurasi mesyuarat, jadi anggap sebagai kecenderungan umum daripada peraturan tetap. Akibat praktikal: membandingkan panggilan Zoom dengan panggilan Meet bukan ujian kamera. Ia ujian keputusan penyiara setiap platform. Ukur aliran kasar dahulu dengan halaman WebRTC polos atau alat ujian webcam. Jika aliran kasar bersih dan satu platform masih kelihatan teruk, dasar platform ialah kekangan, dan tiada penambahbaikan perkakasan akan mengubahnya. Apabila panggilan platform sedang berlangsung, chrome://webrtc-internals membolehkan anda melihat keputusan penderiaannya langsung, supaya anda boleh lihat sama ada penurunan itu dasar platform atau kelakuan rangkaian tanpa mempercayai laporan sendiri mana-mana pihak.

Tujuh Langkah untuk Aliran Bersih

Langkah-langkah ini mengasingkan punca berbeza. Anda boleh berhenti begitu aliran kelihatan betul — tetapi ukur sebelum dan selepas setiap perubahan untuk mengesahkan pembetulan sebenarnya menggerakkan angka.

Ukur dahulu. Buka chrome://webrtc-internals atau gunakan getStats() pada peer connection anda sendiri dan rekod resolusi, kadar bingkai, dan bit rate. Jika aliran kasar sudah diturunkan, kamera dan sambungan anda ialah masalah. Jika bersih, platform ialah.
Semak lebar jalur. Panggilan video memerlukan setidaknya 1 Mbps upload untuk 720p dan kira-kira 4 Mbps untuk 1080p. Ujian dari mesin anda panggil dari, bukan peranti lain, dan uji semula dengan trafik lain pada rangkaian. Pindah ke sambungan berwayar jika anda boleh; kehilangan Wi-Fi ialah punca paling biasa untuk penurunan tidak ketara.
Betulkan pencahayaan. Subjek terang memampatkan jauh lebih baik daripada yang gelap, kerana penderiaan membelanjakan bit rate pada detil kelihatan daripada bising. Hadapi tingkap atau gunakan sumber cahaya lembut. Ini kos sifar dan sering menghasilkan penambahbaikan lebih besar daripada mana-mana tetapan.
Lumpuhkan pengurangan bising video apabila persekitaran anda sudah senyap dan terang. Sesetengah platform menerapkan denoising agresif dalam senario cahaya rendah, yang boleh melembutkan detil halus ketara dalam aliran enkod. Pratonton tempatan tidak akan menunjukkan perbezaan ini; hanya aliran enkod akan. Semak tetapan platform spesifik untuk mengesahkan kawalan apa yang tersedia.
Lumpuhkan latar belakang maya. Segmentasi latar belakang menambah overhead kepada bit rate berkesan dan memakan kitaran GPU dari penderiaan. Latar belakang sebenar bersih dengan pencahayaan konsisten mengalahkan mana-mana maya.
Semak codec. Jika CPU anda mampu mengendalikannya, VP9 memberikan kualiti terbaik per bit; jika anda lihat bingkai jatuh atau lonjakan CPU, H.264 enkod lebih pantas. Sesetengah platform mendedahkan keutamaan codec dalam tetapan.
Uji platform berbeza. Jika kualiti baik pada satu perkhidmatan dan teruk pada yang lain, dasar penyiara platform ialah kekangan. Laraskan jangkaan anda atau alat mesyuarat anda ikut itu — perkakasan anda tidak salah.

Intipati

Pratonton ialah imej sendiri kamera anda: pandangan menyenangkan untuk apa yang kamera anda mampu hantar ke pelayar. Aliran ialah apa yang dunia sebenarnya lihat — dirundingkan, dimampatkan, dan dibentuk oleh keadaan rangkaian dan dasar platform. Mereka dua video berbeza subjek yang sama, dan hanya satu daripadanya penting untuk bagaimana anda muncul. Jika anda pernahhairan mengapa kamera anda kelihatan hebat pada skrin anda tetapi teruk dalam panggilan, anda kini ada jawapan dan alat untuk mengukurnya.

Buka chrome://webrtc-internals. Sertai panggilan seterusnya. Perhatikan entri outbound-rtp. Jika frameWidth atau framesPerSecond di bawah apa yang anda set dalam tetapan kamera anda, penurunan berlaku. Punca biasanya berkaitan lebar jalur — apa yang pelayar anda dibenarkan membelanjakan, dan sama ada sambungan anda sebenarnya mampu bawa aliran yang anda fikir anda sedang hantar — tetapi beban CPU, pemilihan penderiaan, dasar platform, dan konfigurasi kekangan juga boleh menyumbang atau mendominasi degradasi.