WebRTC 회의의 맥락에서 가상 미디어 스트림은 여러 참여자의 미디어를 집계하고 배포하기 위해 선택적 전달 단위 (SFU)에 의해 생성된 미디어 스트림입니다. 대규모 회의에서 복잡한 연결 메시를 만드는 직접 P2P 미디어 스트림과 달리 가상 미디어 스트림은 토폴로지를 간소화합니다. SFU는 각 참여자로부터 개별 미디어 스트림을 수신하고 활성 또는 관련 스트림을 다른 참여자에게 선택적으로 전달하여 더 작고 고정된 아웃바운드 가상 미디어 스트림 세트로 멀티플렉싱합니다.
이 접근 방식을 사용하면 각 참여자가 처리해야 하는 동시 수신 스트림 수가 줄어들어 처리 및 대역폭 요구사항이 낮아집니다. 각 가상 스트림에는 한 번에 한 참여자의 미디어가 포함될 수 있으며, SFU가 발표자 활동이나 동영상 할당과 같은 요소를 기반으로 동적으로 조정합니다. 참여자는 이러한 가상 스트림을 수신하므로 다른 모든 참여자의 개별 스트림을 관리하지 않아도 회의의 구성된 뷰를 효과적으로 볼 수 있습니다. 가상 미디어 스트림에서 제공하는 이 추상화는 WebRTC 회의를 많은 수의 참여자로 확장하는 데 매우 중요합니다.
오디오를 수신하려면 클라이언트가 정확히 세 개의 오디오 미디어 설명을 제공하여 세 개의 로컬 오디오 트랜시버를 생성해야 합니다. 동영상을 수신하려면 클라이언트가 1~3개의 동영상 미디어 설명을 제공하여 해당 수의 동영상 트랜시버를 설정해야 합니다.
수신자
각 클라이언트 소유 트랜시버에는 전용 RtpReceiver와 Meet 서버에서 오디오 RTP 스트림을 수신하는 전용 '미디어 트랙'이 있습니다.
각 트랙에는 고유 ID가 있으며 특정 미디어 소스에서 고유한 RTP 패킷 스트림을 수신합니다. 예를 들어 트랙 A는 production-1에서 오디오를 수신하고 트랙 B는 production-2에서 오디오를 수신할 수 있습니다.
SSRC
각 RTP 패킷에는 특정 트랙에 연결하는 동기화 소스(SSRC) 헤더 값이 있습니다.
Meet Media API를 통한 오디오 세션은 각각 고유한 정적 SSRC를 갖는 세 개의 개별 미디어 스트림을 사용합니다. 설정되면 이러한 SSRC 값은 세션이 종료될 때까지 변경되지 않습니다.
가상 스트림
Meet Media API는 가상 미디어 스트림을 사용합니다. 이러한 값은 세션 전체에서 정적이지만 패킷의 소스는 가장 관련성 높은 피드를 반영하도록 변경될 수 있습니다. 가상 미디어 스트림은 오디오와 동영상에서 동일하게 작동합니다.
RTP 패킷 헤더의 기여 소스(CSRC)는 RTP 패킷의 실제 소스를 식별합니다. Meet에서는 참여자가 회의에 참여할 때 각 참여자에게 고유한 CSRC를 할당합니다. 이 값은 사용자가 나갈 때까지 일정하게 유지됩니다.
SSRC 수는 Meet Media API 세션 전체에서 일정하므로 가능한 시나리오 3가지가 있습니다.
사용 가능한 SSRC보다 많은 참여자:
Meet은 세 개의 SSRC에서 가장 큰 소리를 내는 세 명의 사용자를 전송합니다. 각 RTP 스트림은 자체 전용 SSRC에 있으므로 스트림 간에 혼합이 없습니다.
그림 1. Meet은 세 개의 SSRC에서 가장 큰 소리를 내는 세 명의 사용자를 전송합니다. 회의의 원래 스트림 중 가장 큰 스트림이 더 이상 없는 경우 Meet은 SSRC를 구성하는 RTP 패킷을 가장 큰 스트림으로 전환합니다.
그림 2. Meet은 RTP 패킷을 가장 큰 소리를 내는 새로운 사람으로 전환합니다. 활성 참여자 수가 오디오 SSRC 3개 미만:
회의에 스트림보다 더 많은 SSRC가 있는 시나리오의 경우 Meet은 사용 가능한 오디오 패킷을 자체 고유 SSRC에 매핑합니다. 사용되지 않는 SSRC는 계속 준비되어 있고 사용할 수 있지만 RTP 패킷은 전송되지 않습니다.
그림 3. Meet은 사용 가능한 오디오 패킷을 자체 고유 SSRC에 매핑합니다. 활성 참여자 수가 오디오 SSRC 3개와 같음:
참여자가 동일하고 사용 가능한 SSRC가 있는 시나리오의 경우 각 참여자의 미디어가 전용 SSRC에 매핑됩니다. 이러한 매핑은 이 특정 시나리오가 지속되는 한 유지됩니다.
그림 4. Meet은 각 참여자의 미디어를 전용 SSRC에 매핑합니다.