저대역폭 환경에서 Jitsi Meet 해상도 및 비트 전송률을 최적화하는 방법

대역폭이 낮은 Jitsi Meet 환경에서 가장 먼저 변경해야 할 사항은 무엇입니까?

먼저 다음 세 가지 설정을 순서대로 시도해 보세요. 카메라 캡처 해상도를 낮추고, 각 클라이언트가 수신하는 원격 비디오 스트림 수를 줄인 다음, 코덱별 비트 전송률 제한을 강화하세요. 이 순서가 중요한 이유는 해상도와 수신 스트림 수가 대역폭 사용량에 가장 큰 영향을 미치는 반면, 비트 전송률을 지나치게 제한하면 패킷 손실이나 Wi-Fi 불안정 문제를 해결하지 못하고 움직임이 흐릿해질 수 있기 때문입니다.

Jitsi는 현재 구성 참조 문서 에서 클라이언트 측 비디오 제어 기능을 설명합니다 . 2026년 10월 6일 기준으로, 해당 문서에 따르면 비디오 constraints객체는 기본적으로 이상적인 720p 캡처 높이를 사용하고, channelLastN기본적으로 무제한으로 설정되어 있으며 -1, startLastN사용자가 비디오 품질 관리 설정을 변경하기 전에 수신된 비디오 수가 적은 상태에서도 회의를 시작할 수 있습니다.

제한된 지사, 모바일 핫스팟, 농촌 지역 연결 또는 과부하된 Wi-Fi 네트워크의 경우, 실제 목표 해상도는 720p보다는 360p인 경우가 많습니다. Jitsi의 인프라 요구 사항 페이지에서는 180p의 경우 약 200kbit/s, 360p의 경우 500kbit/s, 720p의 경우 2.5Mbit/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 부하, 패킷 손실, 장치 성능 및 코덱 동작에 따라 달라질 수 있습니다.

캡처 상한을 360p로 설정하고 LastN 값을 보수적으로 설정한 자체 호스팅 Jitsi 구성 예시입니다.

각 참가자는 몇 개의 원격 비디오 스트림을 받아야 합니까?

참가자가 한 번에 8개의 원격 비디오를 수신하는 경우, 로컬 카메라 해상도만 낮추는 것으로는 다운로드 문제를 완전히 해결할 수 없습니다. Jitsi는 참가자에게 전달되는 원격 비디오 스트림의 수를 구체적으로 제어할 수 있는 LastN 기능을 제공합니다.

문서에 명시된 channelLastN기본값은 -1무제한입니다. 문서에 나와 있는 startLastN옵션을 사용하면 더 작은 LastN 값으로 회의를 시작할 수 있으며, Jitsi는 channelLastN사용자가 비디오 품질 관리 슬라이더를 사용하여 품질 수준을 변경할 때 이 값이 사용된다고 설명합니다.

대역폭이 제한된 환경에서 신중하게 시작할 수 있는 출발점은 다음과 같습니다.

channelLastN: 2,
startLastN: 1,

이 예시에서 참가자는 처음에는 원격 비디오 하나를 수신하는 것으로 시작하여 애플리케이션의 품질 동작에 따라 최대 두 개의 원격 비디오를 수신하는 상태로 전환할 수 있습니다. 하지만 이를 2보편적 1인 권장 사항으로 간주해서는 안 됩니다. 학생들이 주로 한 명의 발표자만 시청하는 강의실에서는 모든 참가자가 화면에 보여야 하는 4인 디자인 검토 회의보다 더 작은 LastN 값을 사용할 수 있습니다.

Jitsi는 현재 어떤 비트레이트 값을 사용하고 있나요?

Jitsi의 현재 config.js템플릿 및 구성 참조에는 코덱별 레벨이 명시되어 있습니다 . 2026년 10월 6일 기준으로 프로젝트 마스터 구성에서 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비트/초를 사용합니다. 공식 Jitsi Meet GitHub 저장소maxBitratesVideo 에서 실제 템플릿을 확인할 수 있습니다 .

이러한 값들은 업스트림 기본값 또는 템플릿 값일 뿐이며, 모든 호출이 정확히 해당 속도로 전송된다는 보장은 아닙니다. 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현재 기본 프레임 수를 약 5fps로 설정하고 있습니다 { min: 5, max: 5 }. 프레젠테이션이 많은 회의에서는 화면 공유 프레임 수를 약 5fps로 유지하면 불필요한 움직임에 대역폭을 낭비하지 않고도 가독성을 확보할 수 있습니다.

사용자가 애니메이션, CAD 회전 또는 비디오 클립을 공유하는 경우 5fps는 너무 느리게 느껴질 수 있습니다. 이 경우 프레임 속도를 조심스럽게 높여 해상도나 패킷 손실이 발생하는지 확인하십시오. 현재 지원되는 옵션 이름에 대한 자세한 내용은 Jitsi 공식 구성 문서를 참조하십시오.

그 변화가 실제로 도움이 되었는지 어떻게 알 수 있나요?

단순히 사진이 "괜찮아 보이는지"만으로 판단하지 마세요. 네트워크 동작을 검증해야 합니다. Jitsi의 IFrame API는 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 /etc/jitsi/meet/<your-hostname>-config.js는 일반적으로 가상 호스트 웹 구성 파일 config.js을 `/etc/jitsi.config/web CONFIG/web/custom-config.js...

편집하기 전에 기존 구성을 복사하고, 한 번에 하나의 매개변수 그룹만 변경하고, JavaScript 구문의 유효성을 검사하십시오. config.js상위 템플릿은 지속적으로 업데이트되며 배포별 값이 포함될 수 있으므로, 정상적으로 작동하는 배포 환경에 전체 샘플을 붙여넣지 마십시오.

가장 안전한 튜닝 순서는 무엇인가요?

1. 먼저 측정하십시오. 실제 참여자 수를 설정하여 저대역폭 문제를 재현하고 패킷 손실률, 비트 전송률, 해상도 및 CPU 부하를 기록하십시오.
2. 카메라 촬영 해상도를 360p로 제한합니다. 이를 사용하여 constraints.video.height영상 안정성이 향상되는지 테스트해 보세요.
3. 수신 스트림 수 를 줄이세요.startLastN 필요한 경우, channelLastN각 참여자가 불필요한 썸네일을 다운로드하지 않도록 하세요.
4. 화면 공유 시 가독성을 유지하세요. 슬라이드와 문서의 경우, 움직임이 필요한 경우가 아니라면 화면 공유 프레임 속도를 낮게 유지하세요.
5. 코덱 비트레이트 제한은 마지막에 조정하세요. 클라이언트가 실제로 협상하는 코덱 프로필만 변경하고, 변경 전후의 품질을 비교하세요.
6. 네트워크 혼잡 상황에서 재테스트하십시오. LAN 환경에서 정상적으로 작동하는 구성도 호텔 Wi-Fi나 모바일 핫스팟 환경에서는 제대로 작동하지 않을 수 있습니다.

무엇을 피해야 할까요?

대역폭을 줄이려는 목적으로 동시 방송 또는 재전송 기능을 비활성화하지 마십시오. 이러한 기능은 Jitsi가 손실 발생 시 적응하고 복구하는 방식에 영향을 미치며, 설정을 변경하면 새로운 오류 모드가 발생할 수 있습니다. 사용 사례에서 180p 해상도를 실제로 허용하지 않는 한 모든 사용자에게 180p를 강제 적용하지 마십시오. 비트 전송률 제한을 대역폭 예약으로 간주하지 마십시오. 또한 각 엔드포인트의 마지막 구간 연결을 무시하고 서버 링크만 최적화하지 마십시오.

따라서 최적의 저대역폭 Jitsi 설정은 가장 작은 수치를 사용하는 것이 아닙니다. 오디오의 안정성을 유지하고, 발언자의 얼굴을 선명하게 보여주며, 불필요한 영상 입력을 제한하면서도 인코더가 적응할 수 있는 충분한 여유를 확보하는 설정입니다. 360p 해상도, 보수적인 LastN 값, 그리고 Jitsi의 기본 코덱 설정을 사용하다가, 측정 결과 회의 품질이 향상되는 경우에만 비트레이트 제한을 강화하십시오.