วิธีปรับความละเอียดและอัตราบิตของ Jitsi Meet ให้เหมาะสมสำหรับแบนด์วิดท์ต่ำ

ในการใช้งาน Jitsi Meet ที่มีแบนด์วิดท์ต่ำ ควรเปลี่ยนอะไรเป็นอันดับแรก?

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

Jitsi ได้บันทึกการควบคุมวิดีโอฝั่งไคลเอ็นต์ไว้ในเอกสารอ้างอิงการกำหนดค่าปัจจุบันณ วันที่ 6 ตุลาคม 2026 เอกสารระบุว่าค่าconstraintsเริ่มต้นของออบเจ็กต์คือความสูงในการจับภาพที่เหมาะสมที่ 720p channelLastNค่าเริ่มต้นคือไม่จำกัด-1และstartLastNสามารถเริ่มการประชุมได้แม้จะมีวิดีโอที่ได้รับน้อยกว่าก่อนที่ผู้ใช้จะเปลี่ยนการตั้งค่าการจัดการคุณภาพวิดีโอ

สำหรับสำนักงานสาขาที่มีพื้นที่จำกัด ฮอตสปอตมือถือ การเชื่อมต่อในชนบท หรือเครือข่าย Wi-Fi ที่มีผู้ใช้งานมากเกินไป เป้าหมายเริ่มต้นที่เหมาะสมมักจะเป็น 360p มากกว่า 720p หน้าข้อมูลความต้องการโครงสร้างพื้นฐานของ Jitsi ให้ตัวเลขการวางแผนคร่าวๆ ประมาณ 200 kbit/s สำหรับ 180p, 500 kbit/s สำหรับ 360p และ 2.5 Mbit/s สำหรับ 720p พร้อมทั้งเตือนว่าความต้องการที่แท้จริงอาจแตกต่างกันไปตามหลายปัจจัย โปรดพิจารณาตัวเลขเหล่านั้นเป็นข้อมูลอ้างอิงสำหรับการวางแผนกำลังการผลิต ไม่ใช่ความเร็วต่อผู้ใช้ที่รับประกัน ดูคู่มือข้อกำหนด Jitsi Meet อย่างเป็นทางการ

ภาพแสดงมุมมองการประชุมตัวอย่างที่แสดงตัวเลือกคุณภาพ 360p สำหรับการเชื่อมต่อที่มีข้อจำกัด รูปแบบการควบคุมที่แน่นอนอาจแตกต่างกันไปตามเวอร์ชันของ Jitsi Meet

ควรจำกัดความละเอียดก่อนจำกัดบิตเรตหรือไม่?

โดยทั่วไปแล้วใช่ การลดความสูงในการจับภาพจะช่วยลดจำนวนพิกเซลที่ตัวเข้ารหัสต้องประมวลผลก่อนที่จะเริ่มการจัดสรรบิตเรต เอกสารอ้างอิงการกำหนดค่าปัจจุบันของ Jitsi แยกวิดีโอ W3C ออกconstraintsจากresolutionค่าที่แนะนำแบบเก่า และระบุว่าข้อจำกัดเริ่มต้นที่ความสูงในการจับภาพ 720p ที่เหมาะสม

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

constraints: {
    video: {
        height: {
            ideal: 360,
            max: 360,
            min: 180
        }
    }
},

นี่เป็นเพียงตัวอย่างโปรไฟล์ ไม่ใช่ค่าเริ่มต้นของ Jitsi โปรไฟล์นี้ขอให้เบราว์เซอร์เลือกใช้ความละเอียด 360p และไม่ควรเกินกว่านั้น ในขณะเดียวกันก็ยังอนุญาตให้ความละเอียดลดลงเหลือ 180p ได้หากจำเป็น โปรดอย่าคิดว่าการตั้งค่านี้จะmin: 180รับประกันความเสถียรของสตรีม 180p ภายใต้สภาวะการใช้งานที่หนาแน่น เพราะ WebRTC ยังคงตอบสนองต่อแบนด์วิดท์ที่มีอยู่ โหลด CPU การสูญเสียแพ็กเก็ต ความสามารถของอุปกรณ์ และพฤติกรรมของตัวแปลงสัญญาณได้

ตัวอย่างการตั้งค่า Jitsi แบบโฮสต์เอง โดยกำหนดขีดจำกัดการจับภาพ 360p และใช้ค่า LastN ที่เหมาะสม

ผู้เข้าร่วมแต่ละคนควรได้รับสตรีมวิดีโอทางไกลกี่รายการ?

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

ค่าเริ่มต้น ที่ระบุไว้channelLastNคือ-1ซึ่งหมายถึงไม่จำกัดstartLastNตัวเลือกที่ระบุไว้จะอนุญาตให้การประชุมเริ่มต้นด้วยค่า LastN ที่เล็กกว่า และ Jitsi ระบุว่าค่านี้channelLastNจะถูกใช้เมื่อผู้ใช้เปลี่ยนระดับคุณภาพด้วยแถบเลื่อนจัดการคุณภาพวิดีโอ

จุดเริ่มต้นที่ระมัดระวังสำหรับสภาพแวดล้อมที่มีแบนด์วิดท์จำกัดคือ:

channelLastN: 2,
startLastN: 1,

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

ปัจจุบัน Jitsi ใช้ค่าบิตเรตเท่าใด?

config.jsเทมเพลตและเอกสารอ้างอิงการกำหนดค่าปัจจุบันของ Jitsi แสดง maxBitratesVideoระดับเฉพาะของแต่ละโคเดก ในการกำหนดค่าหลักของโครงการที่ดูเมื่อวันที่ 6 ตุลาคม 2026 นั้น AV1 ใช้ 100,000 บิต/วินาทีสำหรับระดับต่ำ 300,000 สำหรับระดับมาตรฐาน และ 1,000,000 สำหรับระดับสูง; VP9 ใช้ 100,000, 300,000 และ 1,200,000; VP8 และ H.264 ใช้ 200,000, 500,000 และ 1,500,000 สำหรับระดับเดียวกัน คุณสามารถตรวจสอบเทมเพลตสดได้ใน ที่เก็บ GitHub อย่างเป็นทางการของ Jitsi Meet

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

เมื่อไหร่จึงจะเหมาะสมที่จะลดเพดานอัตราดอกเบี้ย?

ลดข้อจำกัดลงเมื่อทราบงบประมาณเครือข่ายของคุณ และความเสถียรของวิดีโอมีความสำคัญมากกว่ารายละเอียด ตัวอย่างเช่น คุณอาจทดสอบโปรไฟล์ VP8 ดังนี้:

videoQuality: {
    vp8: {
        maxBitratesVideo: {
            low: 150000,
            standard: 300000,
            high: 800000
        }
    }
},

ตัวเลขเหล่านี้ถูกระบุไว้เพื่อเป็นตัวอย่างสำหรับการทดสอบเท่านั้น ไม่ใช่ค่าเริ่มต้นของ Jitsi ตัวเลขเหล่านี้จะมีความหมายก็ต่อเมื่อมีการเจรจา VP8 บนอุปกรณ์ปลายทางที่คุณต้องการใช้งานเท่านั้น หากไคลเอนต์เดสก์ท็อปของคุณต้องการ AV1 หรือ VP9 การปรับเฉพาะออบเจ็กต์ VP8 จะไม่ให้ผลลัพธ์ที่คุณคาดหวัง

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

คุณควรบังคับใช้ตัวแปลงสัญญาณเฉพาะเพื่อประหยัดแบนด์วิดท์หรือไม่?

ไม่ใช่โดยอัตโนมัติ Jitsi รุ่นใหม่ๆ จะแสดงลำดับความสำคัญของตัวแปลงสัญญาณและอัตราบิตเริ่มต้นที่แตกต่างกันสำหรับ AV1, VP9, ​​VP8 และ H.264 AV1 และ VP9 อาจมีประสิทธิภาพ แต่การเลือกตัวแปลงสัญญาณก็ส่งผลต่อต้นทุน CPU การรองรับอุปกรณ์ การรองรับเบราว์เซอร์ และคุณสมบัติการปรับขนาดด้วย แล็ปท็อปที่มีประสิทธิภาพต่ำซึ่งมีปัญหาในการเข้ารหัสตัวแปลงสัญญาณที่ซับซ้อนกว่า อาจทำให้การประชุมมีคุณภาพแย่ลง แม้ว่าตัวแปลงสัญญาณนั้นจะมีประสิทธิภาพในทางทฤษฎีก็ตาม

หลักการใช้งานที่ปลอดภัยกว่าคือ การคงค่าการตั้งค่าโคเดกปัจจุบันของ Jitsi ไว้ เว้นแต่ว่าคุณจะมีผลการวัดที่แสดงให้เห็นถึงปัญหา หากคุณเปลี่ยนลำดับโคเดก ให้ทดสอบกับเบราว์เซอร์ Chrome, Firefox, Safari, Android และ iOS ที่องค์กรของคุณใช้งานจริง อย่าสรุปประสิทธิภาพของโคเดกจากเบราว์เซอร์บนเดสก์ท็อปเพียงเบราว์เซอร์เดียว

แล้วถ้าใช้การเชื่อมต่อที่ช้า การแชร์หน้าจอจะเป็นอย่างไร?

การแชร์หน้าจอมีการแลกเปลี่ยนคุณภาพที่แตกต่างจากการแชร์วิดีโอด้วยกล้อง ข้อความและสไลด์จะได้รับประโยชน์จากความละเอียดที่อ่านได้ ในขณะที่การเคลื่อนไหวที่ราบรื่นต้องการเฟรมต่อวินาทีที่สูงกว่า เอกสารของ Jitsi ระบุdesktopSharingFrameRateและแสดงค่าเริ่มต้น{ min: 5, max: 5 }ไว้ที่ 5 เฟรมต่อวินาที สำหรับการประชุมที่มีการนำเสนอจำนวนมาก การตั้งค่าการแชร์หน้าจอไว้ที่ประมาณ 5 เฟรมต่อวินาทีจะช่วยรักษาความชัดเจนโดยไม่สิ้นเปลืองแบนด์วิดท์ไปกับการเคลื่อนไหวที่ไม่จำเป็น

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

คุณจะรู้ได้อย่างไรว่าการเปลี่ยนแปลงเหล่านั้นได้ผลจริง?

อย่าตัดสินเพียงแค่ว่าภาพ “ดูโอเค” หรือไม่ ตรวจสอบพฤติกรรมของเครือข่ายด้วย API IFrame ของ Jitsi มีฟังก์ชันต่างๆgetConnectionStats()ที่สามารถส่งคืนคุณภาพการเชื่อมต่อในพื้นที่ แบนด์วิดท์ที่ใช้งานได้ อัตราบิตในการอัปโหลดและดาวน์โหลด อัตราบิตของเสียงและวิดีโอ การสูญเสียแพ็กเก็ต ข้อมูลตัวแปลงสัญญาณ อัตราเฟรม เฟรมที่ถอดรหัส ความละเอียด และรายละเอียดการขนส่ง ดูข้อมูลอ้างอิงฟังก์ชัน API IFrame อย่างเป็นทางการ

สำหรับการใช้งานแบบฝังตัว การตรวจสอบอย่างง่ายอาจมีลักษณะดังนี้:

api.getConnectionStats().then(stats => {
    console.log(stats.bitrate);
    console.log(stats.packetLoss);
    console.log(stats.resolution);
    console.log(stats.connectionQuality);
});

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

ภาพแสดงสถิติการเชื่อมต่อตัวอย่าง ซึ่งแสดงค่าความละเอียด อัตราเฟรม อัตราบิต และค่าความคลาดเคลื่อนต่างๆ ที่ใช้ในการเปรียบเทียบระหว่างการตรวจสอบความถูกต้อง

คุณควรเริ่มต้นด้วยโปรไฟล์แบนด์วิดท์ต่ำแบบใด?

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

คุณควรแก้ไขการตั้งค่าบนเซิร์ฟเวอร์ที่โฮสต์เองที่ใด

ในการติดตั้ง Jitsi ผ่านแพ็กเกจ Debian นั้น โดยทั่วไปแล้ว Jitsi จะเก็บการตั้งค่าเว็บโฮสต์เสมือนไว้ใน/etc/jitsi/meet/<your-hostname>-config.js. เอกสารการตรวจสอบสิทธิ์ของ Jitsi เองก็ใช้เส้นทางนี้ในตัวอย่าง ส่วนในการใช้งาน Docker นั้น คู่มืออย่างเป็นทางการของ Docker ระบุว่าconfig.jsไฟล์ที่สร้างขึ้นภายในคอนเทนเนอร์จะถูกสร้างขึ้นใหม่เมื่อเริ่มต้นระบบ ดังนั้นการตั้งค่าแบบกำหนดเองควรอยู่ในไฟล์ฝั่งโฮสต์CONFIG/web/custom-config.jsแทน ดูคู่มือการโฮสต์ด้วยตนเองของ Docker อย่างเป็นทางการได้ที่นี่

ก่อนทำการแก้ไข ให้คัดลอกการตั้งค่าที่มีอยู่ เปลี่ยนพารามิเตอร์ทีละกลุ่ม และตรวจสอบความถูกต้องของไวยากรณ์ JavaScript หลีกเลี่ยงการวางตัวอย่างทั้งหมดทับลงconfig.jsบนระบบที่ใช้งานได้อยู่แล้ว เนื่องจากเทมเพลตต้นทางมีการพัฒนาและอาจมีค่าเฉพาะสำหรับการใช้งานนั้นๆ

ลำดับการปรับแต่งที่ปลอดภัยที่สุดคืออะไร?

1. วัดผลก่อนจำลองปัญหาแบนด์วิดท์ต่ำด้วยจำนวนผู้เข้าร่วมที่สมจริง และบันทึกการสูญเสียแพ็กเก็ต อัตราบิต ความละเอียด และภาระการทำงานของ CPU
2. จำกัดการบันทึกวิดีโอไว้ที่ 360p แล้วconstraints.video.heightทดสอบดูว่าความเสถียรของวิดีโอดีขึ้นหรือไม่
3. ลดจำนวนสตรีมที่ได้รับลดลงstartLastNและหากจำเป็น ให้ ลดขนาดลง channelLastNเพื่อไม่ให้ผู้เข้าร่วมแต่ละคนดาวน์โหลดภาพขนาดย่อที่ไม่จำเป็น
4. รักษาความชัดเจนในการอ่านขณะแชร์หน้าจอลดอัตราเฟรมขณะแชร์หน้าจอสำหรับสไลด์และเอกสาร เว้นแต่กรณีการใช้งานนั้นต้องการการเคลื่อนไหว
5. ปรับค่าจำกัดบิตเรตของโคเดกเป็นลำดับสุดท้ายเปลี่ยนเฉพาะโปรไฟล์โคเดกที่ลูกค้าของคุณตกลงกันไว้เท่านั้น และเปรียบเทียบคุณภาพก่อนและหลังการเปลี่ยนแปลง
6. ทดสอบซ้ำในสภาวะที่มีการใช้งานหนาแน่นการตั้งค่าที่ดูเหมือนจะใช้งานได้ดีบนเครือข่าย LAN อาจใช้งานไม่ได้ผลบน Wi-Fi ของโรงแรมหรือฮอตสปอตมือถือ

คุณควรหลีกเลี่ยงอะไรบ้าง?

อย่าปิดใช้งานคุณสมบัติการส่งสัญญาณพร้อมกันหรือการส่งซ้ำเพียงเพราะคุณพยายามลดแบนด์วิดท์ การควบคุมเหล่านั้นส่งผลต่อวิธีที่ Jitsi ปรับตัวและกู้คืนจากการสูญเสีย และการเปลี่ยนแปลงอาจทำให้เกิดโหมดความล้มเหลวใหม่ได้ อย่าบังคับใช้ 180p สำหรับผู้ใช้ทุกคน เว้นแต่กรณีการใช้งานจะยอมรับได้จริง ๆ อย่าถือว่าการจำกัดบิตเรตเป็นการสำรองแบนด์วิดท์นั้นไว้ และอย่าปรับแต่งเฉพาะลิงก์เซิร์ฟเวอร์โดยไม่สนใจการเชื่อมต่อช่วงสุดท้ายที่ปลายทางแต่ละแห่ง

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