如何針對低頻寬優化 Jitsi Meet 的解析度和位元率

在低頻寬 Jitsi Meet 部署中，首先應該更改哪些內容？

首先按以下順序進行三項控制：降低攝影機拍攝分辨率，減少每個客戶端接收的遠端視訊數量，最後才收緊特定編解碼器的比特率上限。這個順序很重要，因為解析度和接收的視訊串流數量通常對頻寬消耗的影響最為顯著，而過高的位元率上限可能會導致畫面模糊，卻無法解決丟包或Wi-Fi不穩定的問題。

Jitsi 在其最新的配置參考文件中記錄了客戶端視訊控制。截至 2026 年 10 月 6 日，該文件指出，constraints預設情況下，視訊物件會以理想的 720p 解析度進行捕獲，channelLastN預設情況下視訊數量不限-1，並且startLastN在用戶更改「管理視訊品質」設定之前，即使接收到的視訊數量較少，也可以開始會議。

對於資源受限的分支機構、行動熱點、鄉村鏈路或過載的 Wi-Fi 網絡，實際的初始目標通常是 360p 而不是 720p。 Jitsi 的基礎設施需求頁面給出了粗略的規劃數據：180p 大約需要 200 kbit/s，360p 大約需要 500 kbit/s，720p 大約需要 2.5 Mbit/s，同時也提醒實際需求會受到多種因素的影響。請將這些數據視為容量規劃參考，而非保證的每用戶速率。請參閱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目前使用的位元率是多少？

Jitsi 目前的config.js範本和配置參考文件公開了特定於編解碼器的maxBitratesVideo等級。在 2026 年 10 月 6 日查看的項目主配置中，AV1 的低電平使用 100,000 比特/秒，標準電平使用 300,000 比特/秒，高電平使用 1,000,000 比特/秒；VP9 的低電平、標準電平和高電平1,200,000 位元/秒；VP8 和 H.264 的低電平、標準電平和高電平分別使用 200,000、500,000 和 1,500,000 位元/秒。您可以在Jitsi Meet 的官方 GitHub 程式碼庫中驗證即時範本。

這些值是上游預設值或範本值，並非保證每次呼叫都會以完全相同的速率傳輸。 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 fps 左右，既能保證清晰度，又不會因為不必要的動畫而浪費頻寬。

如果使用者分享動畫、CAD旋轉檔案或影片片段，5幀/秒的幀率可能感覺太慢。在這種情況下，請謹慎提高幀率，並觀察解析度或丟包率是否下降。官方Jitsi配置文件是了解目前支援的選項名稱的正確參考。

你怎麼知道這些改變是否真的有效？

不要只根據畫面「看起來是否正常」來判斷。還要驗證網路行為。 Jitsi 的 IFrame API 提供了 `IFrame_Skype` 函數getConnectionStats()，可以傳回本機連線品質、可用頻寬、上傳和下載位元率、音訊和視訊位元速率、丟包速率、編解碼器資訊、幀速率、已解碼幀數、解析度和傳輸詳情。請參閱官方的 IFrame API 函數參考文件。

對於嵌入式部署，一個簡單的檢查可以如下所示：

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

在更改前後分別運行相同的會議模式。一個有效的測試至少包含三個條件：正常的辦公室頻寬、故意限制頻寬以及真實的多人通話。錄製音訊是否仍然清晰、視訊是否卡頓、丟包率是否上升、參與者是否降低解析度或CPU使用率是否過高。

連接統計資訊範例視圖，顯示驗證期間要比較的解析度、幀率、位元率和丟包率值。

應該從哪種低頻寬設定檔開始？

這些是初始配置方案，並非保證最優值。正確的配置取決於上行鏈路和下行鏈路的不對稱性、參與者數量、相機內容、所選編解碼器、終端CPU以及用戶期望的品質。

在自託管伺服器上，應該在哪裡編輯配置？

在 Debian 軟體包安裝中，Jitsi 通常會將虛擬主機 Web 設定保存在 `/etc/jitsi.conf` 目錄中/etc/jitsi/meet/<your-hostname>-config.js。 Jitsi 本身的身份驗證文件範例中也使用了該路徑。在 Docker 部署中，官方 Docker 指南指出config.js容器內產生的檔案會在啟動時重新創建，因此自訂設定應該放在主機端的 `/etc/ jitsi.conf`CONFIG/web/custom-config.js檔案中。請參閱官方 Docker 自託管指南。

編輯前，請複製現有配置，每次變更一組參數，並驗證 JavaScript 語法。避免將整個範例貼config.js到正在運行的部署環境中，因為上游範本會不斷更新，並且可能包含特定於部署環境的值。

最安全的調校順序是？

1. 首先進行測量。使用實際的參與者數量重現低頻寬問題，並記錄丟包率、位元率、解析度和 CPU 負載。
2. 將相機拍攝解析度限制在 360p。使用constraints.video.height並測試視訊穩定性是否有所改善。
3. 減少接收的資料流。降低startLastN接收量，必要時channelLastN避免每位參與者下載不必要的縮圖。
4. 保持螢幕分享內容的清晰度。除非使用場景需要動態顯示，否則請將投影片和文件的螢幕共用幀速率保持在較低水平。
5. 最後再調整編解碼器比特率上限。只更改客戶端實際協商的編解碼器配置文件，並比較更改前後的畫質。
6. 在網路擁堵的情況下重新測試。在區域網路內看起來不錯的配置，在飯店 Wi-Fi 或行動熱點網路下可能無法正常運作。

應該避免什麼？

不要因為想要降低頻寬就停用同步廣播或重傳功能；這些設定會影響 Jitsi 的自適應和丟包恢復機制，而更改這些設定可能會導致新的故障模式。除非實際應用場景確實允許，否則不要強制所有使用者使用 180p 解析度。不要將比特率上限視為頻寬預留。也不要只優化伺服器連結而忽略每個端點的最後一公里連線。

因此，最佳的低頻寬 Jitsi 配置並非參數值最小的配置，而是能夠確保音訊穩定可靠、發言者清晰可辨、限制不必要的視訊輸入，並為編碼器留出足夠的自適應空間的配置。建議先從 360p 解析度、保守的 LastN 值以及 Jitsi 目前的預設編解碼器開始；然後，只有當測量結果表明提高位元率限制能夠改善會議體驗而非僅僅降低畫面品質時，才考慮收緊位元率限制。