ทดสอบสตรีมเว็บแคม — อีกฝั่งเห็นอะไร

ภาพในพรีวิวเว็บแคมเป็นวิวจับภาพในเครื่อง — ฟีดกล้องผ่าน getUserMedia() — ไม่ใช่เอาต์พุตเซนเซอร์ดิบ ภาพที่ผู้รับเห็นเป็นสตรีมที่เบราว์เซอร์เข้ารหัสผ่าน WebRTC ที่ถูกเจรจา บีบอัด และอาจลดระดับอย่างเงียบๆ คู่มือนี้อธิบายการเจรจา codec ของ WebRTC ทำงานอย่างไร วิธีใช้ getStats() บน RTCPeerConnection เพื่อวัดพารามิเตอร์สตรีมจริง และวิธีแก้สาเหตุความสูญเสียคุณภาพที่พบบ่อย ข้อสังเกต: เครื่องมือเว็บแคมของไซต์นี้ตรวจแทร็กจับในเครื่องและเฟรมเรตเบราว์เซอร์เท่านั้น ไม่วัดสตรีมที่เข้ารหัส WebRTC ขาออก

คุณนั่งในวิดีโอคอลและหน้าต่างของคุณแสดงภาพ 1080p คมชัด คุณดูคม พื้นหลังสะอาด และกรอบถูกต้อง แล้วเพื่อนร่วมงานบอกว่าวิดีโอของคุณค้างและมัว และเมื่อพวกเขาแชร์หน้าจอ คุณเห็นตัวเองเป็นภาพเป็นก้อน ขอบนุ่น ที่กล้องประหยัดจากสิบปีก่อนจะผลิตได้ กล้องเดียวกัน แสงเดียวกัน เครื่องเดียวกัน ภาพต่างกัน

นี่คือสิ่งที่คู่มือวิดีโอคอลส่วนใหญ่ข้าม: ช่องว่างนั้นมักไม่ใช่ข้อบกพร่องฮาร์ดแวร์หรือข้อบกพร่องเซนเซอร์ — แม้ไดรเวอร์ทำงานผิดปกติบางครั้งก็ทำให้เกิดได้ มักเป็นความแตกต่างระหว่างสิ่งที่กล้องผลิตและสิ่งที่เบราว์เซอร์ส่งจริง พรีวิวของคุณถูกป้อนจากเส้นทางจับในเครื่อง — เฟรมที่กล้องผลิตผ่าน getUserMedia() — ก่อนการเข้ารหัส WebRTC ซึ่งทำให้มันเป็นวิวที่เอื้ออำนวยกว่าของวิดีโอของคุณกว่าสิ่งที่ผู้เข้าร่วมคนอื่นได้รับ วิวนั้นอาจยังรวมการปรับสเกล การแปลงสี หรือการประมวลผลข้อจำกัดที่เบราว์เซอร์ใช้ จึงไม่ใช่เอาต์พุตเซนเซอร์ดิบ สิ่งที่ผู้เข้าร่วมคนอื่นได้รับคือสตรีมบีบอัดที่ถูกเจรจา เข้ารหัสใหม่ จำกัดอัตรา และอาจลดระดับโดย WebRTC ในมิลลิวินาทีก่อนออกจากเครื่องของคุณ

เลเยอร์การเข้ารหัสนั้นมองไม่เห็นจากส่วนต่อประสานผู้ใช้และเงียบระหว่างการทำงานปกติ ไม่มีสิ่งใดในหน้าต่างคอลบอกคุณว่ามันมีอยู่ ไม่มีสิ่งใดรายงานการตัดสินใจของมัน และไม่มีสิ่งใดในพรีวิวสะท้อนสิ่งเหล่านั้น ฉากที่คุ้นเคย: ผู้ใช้คนหนึ่งใช้เวลาหลายชั่วโมงติดตั้งไดรเวอร์กล้องใหม่เพราะคอลแสดงภาพมัว — แต่กลับค้นพบผ่าน chrome://webrtc-internals ว่าเบราว์เซอร์กำลังเจรจาลงไปที่ 480p15 ตามการประเมินแบนด์วิดท์ ไม่ใช่เพราะกล้องหรือไดรเวอร์ หน้านี้อธิบายว่าเกิดอะไรขึ้นระหว่างเซนเซอร์กล้องและหน้าจอของคู่สนทนา ทำไมเบราว์เซอร์ลดคุณภาพของคุณอย่างเงียบๆ และที่สำคัญที่สุด — วิธีวัดสตรีมจริงที่ออกจากเครื่องของคุณแทนที่จะเชื่อพรีวิว

สิ่งที่พรีวิวไม่แสดงให้คุณเห็น

การโทรวิดีโอพึ่งพานบนไปป์ไลน์ที่ทำงานนอกเหนือการรับรู้ของคุณโดยสมบูรณ์ ทุกเฟรมที่คุณส่งผ่านขั้นตอนต่อไปนี้:

1. เซนเซอร์กล้อง จับเฟรมหนึ่ง เบราว์เซอร์จากนั้นส่งมันผ่าน getUserMedia() ที่ความละเอียดและเฟรมเรตที่ร้องขอ ซึ่งอาจรวมถึงการปรับสเกล การแปลงสี และการประมวลผลข้อจำกัด
2. เบราว์เซอร์รับเฟรมนั้นผ่าน API getUserMedia() และส่งต่อให้เอนจิน WebRTC พรีวิวในเครื่องของคุณถูกป้อนจากขั้นตอนนี้ — นี่คือเหตุผลที่มันดูสมบูรณ์แบบเสมอ ไม่ว่าจะเกิดอะไรขึ้นต่อไป
3. ตัวเข้ารหัส WebRTC บีบอัดเฟรมเป็นบิตสตรีมโดยใช้ codec ที่เจรจาแล้ว ที่ความละเอียด เฟรมเรต และบิตเรตที่เจรจาแล้ว
4. เฟรมที่เข้ารหัสถูกแบ่งเป็น แพ็กเก็ต RTP และส่งผ่านเครือข่าย มักผ่านเซิร์ฟเวอร์สื่อกลางที่ถ่ายทอดไปยังทุกคนอื่น
5. แต่ละฝั่งรับ ถอดรหัส แพ็กเก็ตกลับเป็นภาพและเรนเดอร์บนหน้าจอของพวกเขา

พรีวิวของคุณแตะไปป์ไลน์ที่ขั้นตอนที่สอง มันแสดงเฟรมที่กล้องผลิตตามที่ส่งผ่าน getUserMedia() ก่อนการเข้ารหัส WebRTC เบราว์เซอร์อาจปรับสเกล แปลงสี หรือประมวลผลข้อจำกัดที่ขั้นตอนนี้ แต่ไม่มีการบีบอัด WebRTC สตรีมที่คู่สนทนาเห็นคือสิ่งที่ออกมาจากขั้นตอนที่สาม ระหว่างจุดสองจุดนั้น ตัวเข้ารหัสตัดสินใจว่าโลกจะได้รับอะไร และมันตัดสินใจนั้นจากเงื่อนไขที่คุณไม่เห็น

ตัวเข้ารหัสเจรจาพารามิเตอร์สามตัวอย่างเงียบๆ และแต่ละตัวสามารถเปลี่ยนกลางคอลได้โดยไม่มีการแจ้งเตือน:

• ความละเอียด — ความกว้างและความสูงของเฟรมที่เข้ารหัส ซึ่งสามารถลดจาก 1920×1080 เป็น 1280×720 หรือ 640×480 ได้เอง
• เฟรมเรต — กี่เฟรมต่อวินาทีรอดจากการเข้ารหัส มักลดลงเป็นอันดับแรก (จาก 30 เป็น 15 หรือต่ำกว่า) เพราะการลดเฟรมเรตครึ่งหนึ่งตัดอัตราข้อมูลครึ่งหนึ่งโดยไม่เปลี่ยนความละเอียด — แม้บางการใช้งานอาจลดความละเอียดแทน ขึ้นกับ codec และแพลตฟอร์ม
• บิตเรต — กี่บิตต่อวินาทีที่ตัวเข้ารหัสได้รับอนุญาตให้ใช้ ซึ่งกำหนดระดับการบีบอัดโดยรวม

ค่าทั้งสามนี้กำหนดทุกสิ่งที่อีกฝั่งเห็น ภาพ 1080p ที่บีบอัดเป็นบิตเรตต่ำดูนุ่มและเลอะ สตรีม 30 fps ที่ทำงานที่ 10 fps ทันใดดูกระตุกและไม่เป็นธรรมชาติ เมื่อคุณเข้าใจว่าพรีวิวไม่รายงานค่าใดเหล่านี้เลย ปริศนาของคอลที่แย่กับกล้องที่ดีก็คลาย

SDP เจรจาก่อนที่คุณส่งเฟรม

การเจรจาเริ่มก่อนที่เฟรมแรกจะถูกส่ง เมื่อคุณเข้าร่วมคอล แพลตฟอร์มและเบราว์เซอร์ของคุณแลกเปลี่ยนข้อเสนอและคำตอบ Session Description Protocol (SDP) SDP โฆษณา codec และความสามารถสื่อสารที่แต่ละฝั่งสนับสนุน ความละเอียดและเฟรมเรตจริงจากนั้นถูกเจรจาเพิ่มเติมผ่านพารามิเตอร์ส่งและรับ และจำกัดโดยการประเมินแบนด์วิดท์ ในการทดสอบอย่างไม่เป็นทางการบน Chrome 125 บน Windows 10 (พฤษภาคม 2024) พบว่า SDP answer เสนอ VP9 ก่อน แล้ว H.264 แล้ว VP8 บน Safari 17 บน macOS 14 (ช่วงเดียวกัน) H.264 ปรากฏก่อน การสังเกตเหล่านี้ทำบนเครื่องเดียวต่อเบราว์เซอร์โดยไม่มีเงื่อนไขเครือข่ายที่ควบคุม จึงแสดงการแปรผันที่มีอยู่แทนที่จะกำหนดลำดับสากล codec จริงที่ถูกเลือกขึ้นกับเบราว์เซอร์ แพลตฟอร์ม พารามิเตอร์ SDP และความสามารถฮาร์ดแวร์ ตัวเลือกทั่วไปรวม VP9, H.264, VP8 และ AV1 แต่ไม่มีลำดับความชอบคงที่เดียวข้ามแพลตฟอร์มทั้งหมด

การเลือก codec เป็นเพียงจุดเริ่มต้น เมื่อคอลดำเนินไป กลไกที่สองเข้าควบคุม: การประเมินแบนด์วิดท์ WebRTC ตรวจสอบเส้นทางเครือข่ายอย่างต่อเนื่องทั้งสองทิศทางและทำงานอัลกอริทึมควบคุมการคั่วคับ — มากที่สุดคือ Google Congestion Control — ที่ทำการวัดสามอย่างบนพื้นฐานต่อเนื่อง:

• การสูญเสียแพ็กเก็ต รายงานโดยฝั่งรับผ่านข้อความตอบกลับ RTCP
• รอบไปกลับ ความหน่วงระหว่างส่งแพ็กเก็ตและรับการยืนยันว่ามาถึง
• Throughput อัตราที่ข้อมูลข้ามการเชื่อมต่อจริงๆ

อัลกอริทึมป้อนการวัดเหล่านี้เข้าสู่โมเดลที่ประเมินว่าเครือข่ายสามารถรับส่งข้อมูลได้กี่แบนด์วิดท์ การประเมินนั้นกลายเป็น บิตเรตเป้าหมาย ที่ส่งให้ตัวเข้ารหัส และตัวเข้ารหัสปรับเอาต์พุตให้พอดี วงจรนี้ต่อเนื่องและรวดเร็ว: เมื่อการประเมินลด ตัวเข้ารหัสเข้ารหัสใหม่ที่บิตเรตต่ำกว่าภายในเสี้ยววินาที

ขีดจำกัดนั้นประมาณและขึ้นกับอัลกอริทึมควบคุมการคั่วคับที่ใช้ การสูญเสียแพ็กเก็ตต่อเนื่องเกินประมาณห้าเปอร์เซ็นต์สามารถกระตุ้นการลดบิตเรตเป้าหมาย แต่พฤติกรรมที่แน่นอน — ลดเท่าใด จะลดความละเอียดหรือเฟรมเรตหรือไม่ และที่ระดับการสูญเสียใด — แตกต่างกันไปตามอัลกอริทึม codec และแพลตฟอร์ม ไม่มีการแม็ปสากลจากเปอร์เซ็นต์การสูญเสียไปสู่ความละเอียดเอาต์พุตที่เฉพาะเจาะจง วงจรตอบสนองที่ขับเคลื่อนการตัดสินใจเหล่านี้ถูกกำหนดใน (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP) สตรีม 1080p ที่ 30 fps มักต้องการประมาณสี่ถึงหกเมกะบิตต่อวินาทีของแบนด์วิดท์อัปโหลดเพื่อให้ดูสะอาด แม้นี้ขึ้นกับ codec การตั้งค่าการเข้ารหัส และความซับซ้อนของฉาก ถ้าตัวประเมินสรุปว่ามีเพียงหนึ่งเมกะบิตที่ใช้ได้ มันจะไม่พยายามบังคับสตรีมผ่าน — มันลดเป้าหมาย และตัวเข้ารหัสตอบสนองโดยลดความละเอียดเป็น 480p และเฟรมเรตเป็น 15 fps ถ้าการประเมินลดลงอีก ภาพเสื่อมอีก ลดไปถึง 320×240 ที่เป็นเพียงหัวพูด ทุกขั้นตอนเป็นการตั้งใจ: เป้าหมายคือรักษาคอลให้มีชีวิตและเสียงให้เสถียร และคุณภาพวิดีโอเป็นสิ่งแรกที่สละเพื่อบรรลุเป้าหมายนั้น

รูปแบบความล้มเหลวสามแบบที่สตรีมของคุณซ่อน

พรีวิวซ่อนสถานะจริงของสตรีมเบื้องหลังรูปแบบความล้มเหลวสามแบบที่เกิดซ้ำ เรียนรู้ที่จะจดจำแต่ละแบบจากอาการ เพราะวิธีแก้ที่ถูกต้องแตกต่างกันในแต่ละกรณี ทั้งสามแบบมีสัญญาณบ่งชี้ร่วมกันหนึ่งอย่าง: พรีวิวยังสมบูรณ์ตลอดเวลา เพราะมันถูกสุ่มก่อนตัวเข้ารหัส เฉพาะสตรีมที่เข้ารหัส — และดังนั้นหน้าจอของผู้เข้าร่วมคนอื่น — แสดงความเสียหาย

กับดักบิตเรต

อาการ: พรีวิวของคุณสมบูรณ์และ CPU ของเครื่องว่าง อีกฝั่งเห็นภาพมัว ความละเอียดต่ำที่ไม่เคยคมเลย แม้ตอนหยุดนิ่ง การบันทึกในเครื่องดูดีมาก คอลดูแย่

วินิจฉัย: เบราว์เซอร์ประเมินว่าเครือข่ายไม่สามารถรับส่งสตรีมเต็มได้และจำกัดบิตเรต บังคับให้ตัวเข้ารหัสลดความละเอียด ข้อจำกัดคือ แบนด์วิดท์อัปโหลด หรือความสามารถรีเลย์ของเซิร์ฟเวอร์สื่อสาร ไม่ใช่กล้องของคุณ ทดสอบความเร็วและเปรียบเทียบอัปโหลดที่วัดได้กับสี่ถึงหกเมกะบิตที่ 1080p30 ต้องการ ถ้าคุณแชร์การเชื่อมต่อกับอุปกรณ์อื่นที่สตรีมมิ่ง ดาวน์โหลด หรือซิงค์ พวกมันแข่งขันกันบนงบประมาณเดียวกัน

ขีดจำกัดการสูญเสีย

อาการ: ภาพนิ่งจากคอลดูดี แต่การเคลื่อนไหวใดๆ กระตุกและเป็นกลไก เสียงยังราบรื่นขณะที่วิดีโอกระตุก และการค้างสั้นๆ เกิดขึ้นทุกๆ ไม่กี่วินาทีก่อนที่ภาพจะกลับมาที่เฟรมเรตต่ำกว่า

วินิจฉัย: การสูญเสียแพ็กเก็ตข้ามขีดห้าเปอร์เซ็นต์อย่างไม่ต่อเนื่อง ทำให้ตัวควบคุมการคั่วคับตัดบิตเรตเป้าหมายซ้ำแล้วซ้ำเล่า และตัวเข้ารหัสกำลัง ดรอปเฟรมเพื่อให้พอดี เฟรมเรตลดก่อนเพราะเป็นกลไกที่ถูกที่สุด — ลดจาก 30 เป็น 15 fps ตัดอัตราข้อมูลครึ่งหนึ่งโดยไม่เปลี่ยนความละเอียด ตรวจหาการรบกวน Wi-Fi สายเคเบิลอีเทอร์เน็ตที่ไม่ดี หรือ VPN ที่เพิ่มการสูญเสียและเลเทนซี วิดีโอจะยังเสื่อมจนกว่าเส้นทางเครือข่ายจะได้รับการซ่อมแซม

การค้างของคีย์เฟรม

อาการ: ในช่วงสองถึงห้าวินาทีแรกหลังคุณเข้าร่วม หรือหลังคุณแชร์หน้าจอ อีกฝั่งเห็นภาพค้างหรือเลอะอย่างรุนแรง จากนั้นภาพกระโดดเข้าสู่โฟกัสและทำงานปกติจนถึงการเปลี่ยนฉากใหญ่ครั้งถัดไป

วินิจฉัย: codec วิดีโอส่งเฟรมสองประเภท คีย์เฟรม เข้ารหัสทั้งภาพและปรากฏในช่วงเวลาคงที่ — มักทุกหนึ่งถึงสิบวินาทีขึ้นกับแพลตฟอร์มและการกำหนดค่า เดลต้าเฟรม เข้ารหัสเฉพาะการเปลี่ยนแปลงตั้งแต่เฟรมก่อนหน้า ทำให้มันเล็กมาก ถ้าแพ็กเก็ตจากเดลต้าเฟรมสูญ ฝั่งรับไม่สามารถสร้างเฟรมนั้นใหม่ได้ — มันสามารถขอส่งใหม่ (NACK) ขอคีย์เฟรมใหม่จากผู้ส่ง (PLI หรือ FIR) หรือปกปิดข้อผิดพลาดขณะรอ เมื่อคำขอสำเร็จ การกู้คืนเร็ว เมื่อไม่สำเร็จ ภาพค้างจนกว่าคีย์เฟรมตามกำหนดเวลาถัดไปจะมาถึง การรอนั้นคือการค้างที่คุณเห็น ช่วงคีย์เฟรมสั้นกู้คืนเร็วกว่าแต่เสียแบนด์วิดท์ ช่วงยาวมีประสิทธิภาพแต่ทำให้ทุกการสูญเสียเห็นได้ชัดขึ้น นี่ไม่ใช่การทำงานผิดปกติ — เป็น codec ทำงานตามออกแบบ

วัดสตรีมจริงด้วย getStats()

เลิกเดาเดา ตัวเลขไม่สวย แต่เป็นความจริง WebRTC API เปิดเผย ส่วนต่อประสานสถิติ ที่รายงานสิ่งที่ตัวเข้ารหัสทำอยู่ และหน้าเว็บใดที่คุณควบคุมสามารถอ่านการเชื่อมต่อเพียร์ของตัวเองได้ เรียก getStats() บนออบเจกต์ RTCPeerConnection แล้วกรองรายงานที่ส่งกลับมาหารายการ outbound-rtp ที่ kind เป็น video บนรายการ media-source และ outbound-rtp คุณจะพบค่าที่สำคัญ:

• framesPerSecond (บนรายการ media-source) — เฟรมเรตที่กล้องส่งให้ตัวเข้ารหัส ถ้าค่านี้ต่ำกว่า 30 บนกล้อง 30 fps เส้นทางจับภาพเองเป็นปัญหา
• framesPerSecond (บนรายการ outbound-rtp) — เฟรมเรตที่ตัวเข้ารหัสผลิตจริง เมื่อค่านี้ต่ำกว่าอัตราอินพุต ตัวเข้ารหัสกำลังดรอปเฟรม
• frameWidth และ frameHeight (บนรายการ outbound-rtp) — ความละเอียดที่เข้ารหัส เปรียบเทียบกับการตั้งค่าคอลของคุณ ความแตกต่างใดๆ คือการลดระดับเงียบ
• bytesSent (บนรายการ outbound-rtp) — ข้อมูลที่เข้ารหัสทั้งหมด สุ่มสองครั้งห่างกันหนึ่งวินาทีและคำนวณผลต่างคูณ 8 เพื่อให้ได้บิตเรตจริง
• packetsSent และ packetsLost — สังเกตว่า packetsLost บนรายการ outbound-rtp ไม่ได้ถูกเติมเสมอ อัตราการสูญเสียอ่านได้น่าเชื่อถือกว่าจากรายการ remote-inbound-rtp ที่รายงานมุมมองฝั่งรับ
• currentRoundTripTime (บนรายการ candidate-pair) — ความหน่วงเครือข่าย RTT สูงร่วมกับการสูญเสียบ่งชี้การคั่วคับ

เบราว์เซอร์ต่างกันอาจรายงานชื่อฟิลด์ที่แตกต่างเล็กน้อยหรือละเว้นสถิติบางอย่างทั้งหมด ดังนั้นตรวจสอบข้ามกับหน้า internals ของเบราว์เซอร์เมื่อมี

กฎการตีความนั้นง่าย ถ้า outbound-rtp framesPerSecond ต่ำกว่า media-source framesPerSecond อย่างเห็นได้ ตัวเข้ารหัสกำลังทิ้งเฟรมภายใต้แรงกดดัน ถ้า frameWidth และ frameHeight ต่ำกว่าความละเอียดที่คุณตั้งค่าไว้ งบประมาณการเชื่อมต่อไม่สามารถรับส่งได้ ถ้า bytesSent แปลงเป็นบิตเรตที่ต่ำกว่าข้อกำหนดของ codec สำหรับความละเอียดนั้นๆ อย่างมาก ภาพกำลังถูกบีบอัด — และพรีวิวที่ไม่เคยเห็นตัวเข้ารหัส จะดูดีตลอดเวลา

คุณไม่ต้องเขียนโค้ดเพื่ออ่านค่าเหล่านี้ Chrome และ Edge มีโปรแกรมดูสถิติในตัวที่ chrome://webrtc-internals ที่จับทุกการเชื่อมต่อ WebRTC ในเบราว์เซอร์ รวมถึงที่แพลตฟอร์มคอลสร้างขึ้น เปิดมันก่อนเข้าร่วมประชุม ปล่อยให้มันบันทึก และตรวจสอบรายการ outbound-rtp สำหรับตัวส่งวิดีโอภายหลัง เฟรมเรต ความละเอียด บิตเรต และการสูญเสียเดียวกันอยู่ที่นั่น พร้อมกราฟไทม์ไลน์ที่แสดงว่าตัวเข้ารหัสเปลี่ยนเอาต์พุตเมื่อใดอย่างชัดเจน นี่คือวิธีเร็วที่สุดในการจับการลดระดับในแอคชันบนคอลแพลตฟอร์มจริง

ทำการวัดนี้ขณะคอลของคุณเองว่างอยู่เบื้องหลัง แล้วอีกครั้งระหว่างการประชุมที่ยุ่ง และเปรียบเทียบชุดตัวเลขทั้งสอง การเปรียบเทียบทั่วไป: ขณะว่าง outbound-rtp framesPerSecond อ่านได้ 30 ระหว่างการประชุมที่ยุ่งอาจลดเหลือ 18 ขณะที่พรีวิวในเครื่องยังแสดง 30 การเปรียบเทียบนั้นเผยว่าเครือข่ายพื้นฐานของคุณเพียงพอหรือไม่ และการแข่งขันระหว่างคอลคือสิ่งที่กระตุ้นการลดระดับหรือไม่ เครื่องมือ ทดสอบเว็บแคม แสดงความละเอียดและเฟรมเรตของแทร็กจับในเครื่องตามที่เจรจาผ่าน getUserMedia() — เป็นค่าอ้างอิงที่มีประโยชน์สำหรับสิ่งที่กล้องของคุณส่งให้เบราว์เซอร์ได้ แต่ไม่ใช่การวัดสตรีมที่เข้ารหัส WebRTC ขาออก ซึ่งต้องการการเชื่อมต่อเพียร์หรือหน้า WebRTC internals ของเบราว์เซอร์

Zoom, Meet, Teams: กล้องสามตัวที่แตกต่าง

กล้องเดียวกัน แล็ปท็อปเดียวกัน และเครือข่ายเดียวกันสามารถให้ผลลัพธ์ที่แตกต่างกันอย่างเห็นได้ในแอปพลิเคชันต่างกัน เพราะทุกแพลตฟอร์มใช้นโยบายการเข้ารหัสของตัวเองบนการใช้งาน WebRTC ของเบราว์เซอร์

• Zoom มักให้ความสำคัญกับความเสถียร ขึ้นกับเวอร์ชัน ประเภทบัญชี และการตั้งค่าการประชุม มันอาจจำกัดความละเอียดขาออกและสละคุณภาพวิดีโอเพื่อรักษาเสียงและการแชร์หน้าจอให้เสถียร กล้องที่รองรับ 1080p อาจส่ง 720p หรือต่ำกว่าบน Zoom
• Google Meet มักปรับตามแบนด์วิดท์ที่วัดได้ ลดความละเอียดเร็วและกู้คืนเร็วเมื่อสภาพดีขึ้น พฤติกรรมของมันติดตามสถานะเครือข่ายจริงของคุณ ทั้งในแง่ดีและแง่ร้าย
• Microsoft Teams ใช้ไปป์ไลน์การเข้ารหัสและการประมวลผลหลังของตัวเอง ขึ้นกับเวอร์ชันและการตั้งค่าการประชุม ภาพอาจถูกบีบอัดเพิ่มเติมจากการเจรจา WebRTC ดิบ
• WebRTC ในเบราว์เซอร์โดยตรง ประเภทที่คุณได้จากหน้าเว็บเปล่าๆ ส่งสตรีมที่เจรจาแล้วโดยไม่มีนโยบายแพลตฟอร์มเพิ่ม มันเป็นสิ่งที่ใกล้เคียงที่สุดกับความจริงพื้นฐานว่าฮาร์ดแวร์และเครือข่ายของคุณสามารถส่งได้ภายใต้ WebRTC ธรรมดา นโยบายแพลตฟอร์มแตกต่างกันไปตามเวอร์ชัน ประเภทบัญชี และการกำหนดค่าการประชุม ดังนั้นถือว่าเป็นแนวโน้มทั่วไปแทนที่จะเป็นกฎคงที่

ผลลัพธ์ในทางปฏิบัติ: การเปรียบเทียบคอล Zoom กับคอล Meet ไม่ใช่การทดสอบกล้อง มันเป็นการทดสอบการตัดสินใจเข้ารหัสของแต่ละแพลตฟอร์ม วัดสตรีมดิบก่อนด้วยหน้า WebRTC ธรรมดาหรือเครื่องมือ ทดสอบเว็บแคม ถ้าสตรีมดิบสะอาดและแพลตฟอร์มหนึ่งยังดูแย่ นโยบายของแพลตฟอร์มคือข้อจำกัด และการอัปเกรดฮาร์ดแวร์จะไม่เปลี่ยนแปลงอะไร เมื่อคอลแพลตฟอร์มกำลังดำเนินไป chrome://webrtc-internals ให้คุณดูการตัดสินใจของตัวเข้ารหัสแบบสด ดังนั้นคุณสามารถเห็นว่าการลดระดับเป็นนโยบายของแพลตฟอร์มหรือพฤติกรรมของเครือข่ายโดยไม่ต้องเชื่อรายงานตัวเองของทั้งสองฝั่ง

เจ็ดขั้นตอนสู่สตรีมที่สะอาด

ขั้นตอนเหล่านี้แยกสาเหตุที่แตกต่างกัน คุณสามารถหยุดทันทีที่สตรีมดูถูกต้อง — แต่วัดก่อนและหลังการเปลี่ยนแปลงแต่ละครั้งเพื่อยืนยันว่าการแก้ไขย้ายตัวเลขจริงๆ

1. วัดก่อน เปิด chrome://webrtc-internals หรือใช้ getStats() บนการเชื่อมต่อเพียร์ของคุณเองและบันทึกความละเอียด เฟรมเรต และบิตเรต ถ้าสตรีมดิบถูกลดระดับอยู่แล้ว กล้องและการเชื่อมต่อของคุณคือปัญหา ถ้าสะอาด แพลตฟอร์มคือปัญหา
2. ตรวจแบนด์วิดท์ การโทรวิดีโอต้องการอย่างน้อย 1 Mbps ของอัปโหลดสำหรับ 720p และประมาณ 4 Mbps สำหรับ 1080p ทดสอบจากเครื่องที่คุณโทร ไม่ใช่อุปกรณ์อื่น และทดสอบใหม่เมื่อมีการจราจรอื่นบนเครือข่าย ย้ายไปใช้การเชื่อมต่อแบบมีสายถ้าทำได้ การสูญเสีย Wi-Fi เป็นสาเหตุที่พบบ่อยที่สุดของการลดระดับที่มองไม่เห็น
3. แก้ไฟ้ง วัตถุที่สว่างสดใสอัดแบบได้ดีกว่าวัตถุที่มืดมาก เพราะตัวเข้ารหัสใช้บิตเรตกับรายละเอียดที่มองเห็นแทนที่จะเป็นสัญญาณรบกวน หันหน้าไปทางหน้าต่างหรือใช้แหล่งแสงนุ่มๆ นี่ไม่ต้องเสียอะไรเลยและมักให้ผลลัพธ์ที่ดีกว่าการตั้งค่าใดๆ
4. ปิดการกำจัดสัญญาณรบกวนวิดีโอ เมื่อสภาพแวดล้อมของคุณเงียบและสว่างเพียงพอแล้ว บางแพลตฟอร์มใช้การกำจัดสัญญาณรบกวนอย่างก้าวร้าวในฉากแสงน้อย ซึ่งสามารถทำให้รายละเอียดละเอียดนุ่มลงอย่างชัดเจนในสตรีมที่เข้ารหัส พรีวิวในเครื่องจะไม่แสดงความแตกต่างนี้ เฉพาะสตรีมที่เข้ารหัสเท่านั้นที่จะแสดง ตรวจการตั้งค่าแพลตฟอร์มเฉพาะเพื่อยืนยันว่ามีการควบคุมอะไรบ้าง
5. ปิดพื้นหลังเสมือน การแยกพื้นหลังเพิ่มภาระให้บิตเรตที่มีประสิทธิภาพและใช้ GPU จากตัวเข้ารหัส พื้นหลังจริงที่สะอาดพร้อมแสงสม่ำเสมอดีกว่าพื้นหลังเสมือนใดๆ
6. ตรวจ codec ถ้า CPU ของคุณรับมือได้ VP9 ให้คุณภาพต่อบิตที่ดีที่สุด ถ้าคุณเห็นการทิ้งเฟรมหรือ CPU พุ่ง H.264 เข้ารหัสเร็วกว่า บางแพลตฟอร์มเปิดเผยความชอบ codec ในการตั้งค่า
7. ทดสอบแพลตฟอร์มอื่น ถ้าคุณภาพดีบนบริการหนึ่งแต่แย่บนอีกบริการหนึ่ง นโยบายการเข้ารหัสของแพลตฟอร์มคือข้อจำกัด ปรับความคาดหวังหรือเครื่องมือประชุมของคุณให้เหมาะสม — ฮาร์ดแวร์ของคุณไม่ใช่สาเหตุ

บทสรุป

พรีวิวคือภาพตนเองในเครื่องของกล้องของคุณ: มุมมองที่เอื้ออำนวยของสิ่งที่กล้องของคุณสามารถส่งให้เบราว์เซอร์ได้ สตรีมคือสิ่งที่โลกเห็นจริงๆ — เจรจา บีบอัด และหล่อหลอมโดยสภาพเครือข่ายและนโยบายแพลตฟอร์ม มันเป็นวิดีโอสองรายการของหัวข้อเดียวกัน และมีเพียงรายการเดียวเท่านั้นที่สำคัญต่อการที่คุณปรากฏ ถ้าคุณเคยสงสัยว่าทำไมกล้องของคุณดูดีบนหน้าจอของคุณแต่แย่ในคอล ตอนนี้คุณมีคำตอบและเครื่องมือที่จะวัดมัน

เปิด chrome://webrtc-internals เข้าร่วมคอลถัดไปของคุณ ดูรายการ outbound-rtp ถ้า frameWidth หรือ framesPerSecond ต่ำกว่าที่คุณตั้งค่าในการตั้งค่ากล้อง การลดระดับกำลังเกิดขึ้น สาเหตุมักเกี่ยวข้องกับแบนด์วิดท์ — สิ่งที่เบราว์เซอร์ของคุณได้รับอนุญาตให้ใช้ และการเชื่อมต่อของคุณสามารถรับส่งสตรีมที่คุณคิดว่ากำลังส่งได้จริงหรือไม่ — แต่โหลด CPU การเลือกตัวเข้ารหัส นโยบายแพลตฟอร์ม และการกำหนดค่าข้อจำกัดก็สามารถมีส่วนร่วมหรือเป็นปัจจัยหลักของการเสื่อมได้