WebRTC topology

MCU(다지점 제어 장치)

대규모 그룹 다자간 오디오 및 비디오 믹싱

오디오 및 비디오를 표준 또는 사용자 정의 비디오 템플릿을 기반으로 단일 스트림으로 혼합할 수 있다. 각 참가자에 대해 하나의 업로드 스트림과 하나의 다운로드 스트림만 있으면 레거시 및 리소스가 제한된 장치에 특히 유용하다. 서버는모든 믹싱을 자동으로 처리하고 각 출력 스트림은 장치에 필요한 형식으로 클라이언트에 전달된다. 

멀티포인트 제어장치 - 하나 이상의 비디오 스트림을 소비 단일 스트림으로 그들을 구성하는 많은 엔드 포인트에 전달하는 기술이다. 또한 비디오 프로세싱, 즉석에서 해상도 변경 또는 비디오 압축을 위한 키프레임 및 델타 생성과 같은 추가 작업을 제공할 수 있다. 

mcu 토폴로지는 webrtc 클라이언트가 인코딩 된 미디어 스트림을 보내는 중앙 미디어 서버와 함께 작동한다. 거기에서 mcu 미디어 서버는 비디오 스트림을 수신하고 디코딩하고, 다른 참가자의 스트림으로 디코딩 된 프레임을 타일링 한 다음 타일링 된 비디오를 인코딩하여 참가자에게 다시 전송한다. mcu 토폴리지 아키텍처를 사용하면 webrtc 클라이언트가 보내고 받는 스트림을 단순화하여 스트림수를 단 하나로 줄일수 있다. 하지만 각 비디오를 디코딩하고 크기를 조정하고 다시 포맷하고 모든 업데이트에 대해 새로운 프레임을 구성해야 하므로 매우 무겁고 비싼 하드웨어를 필요로 한다.

필요한 인코드/디코드를 하나로 줄이면 클라이언트 컴퓨팅 및 대역폭 소비가 모두 감소하므로 모바일 유형장치에 도움이 된다. 또한 mcu 미디어 서버에서 각 스트림이 디코딩 되고 코드 변환되므로 각 webrtc 클라이언트가 동일한 코덱, 프레임 속도 및 해상도 프로파일을 공유할 필요가 없다. 이제 다양한 클라이언트의 들어오는 미디어 스트림을 다른 코덱으로 코드 변환하고 다른 해상도로 트랜스 사이즈 할 수 있으며 다른 프레임 속도로 변환하여 각 클라이언트가 원하는 프로파일에 최적화 되도록 할 수 있다. 

mcu 미디어 서버가 피어로서 동작하기 때문에 하나이 열악한 연결이 다중 당사자 응용 프로그램의 모든 사용자의 품질을 결정할 수 없다.

클라이언트의 컴퓨팅 및 대역폭을 크게 낮추고 서버 성능과 유연성이 부족한 클라이언트 사용자 인터페이스의 단점을 고려하여 트랜스 코딩/트랜스 레이팅/트랜스 사이징을 통해 서로 다른 네트워크를 상호 연결 할 수 있다. 그러나 mcu의 중앙 집중식 계산 리소스는 비용에 민감하고 대규모의 일대 다 어플리케이션에서 제한 요소가 될 수 있다. 

여러 참가자가 보낸 비디오 및 음성 피드를 가져와 모든 참가자에게 보낼 수 있는 하나의 비디오/음성 피드로 결합된다. 이를 위해서는 mcu에서 스트림을 디코딩하고 다시 인코딩해야 한다.

결론

정의 - 여러 클라이언트가 보낸 비디오 및 음성 피드를 가져와 모든 참가자에게 보낼 수 있는 하나의 비디오/음성 피드로 결합된다. 

장점 - 필요한 인코드/디코드를 하나로 줄이면 클라이언트 컴퓨팅 및 대역폭 소비가 모두 감소하므로 모바일 유형장치에 도움이 된다. (클라이언트는 한개의 스트림만 받아서 처리하므로 무리를 주지 않는다. 배터리 수명 연장.)

단점 - 각 비디오를 디코딩하고 크기를 조정하고 다시 포맷하고 모든 업데이트에 대해 새로운 프레임을 구성해야 하므로 비싼 하드웨어가 필요하다. 비용에 민감하고 대규모의 일대 다 어플리케이션에서 제한 요소가 될 수 있다.

(너무 많으면 믹싱하기 힘들다)

SFU(선택형 전달 장치)

비디오 컨퍼런싱을 위한 선택적 전달

참가자가 선택적으로 서버에 한 번 자신의 미디어를 보낼 수 있는 한 최대, 많은 다운 아키텍처를 사용하여 트랜스 코딩 및 분산 연결된 다운 스트림 클라이언트에 아웃.

이러한 업로드는 대역폭 및 클라이언트 cpu 사용량의 감소로 인해 각 클라이언트는 대규모 다자간 회의로 쉽게 확장 할 수 있다. 

참가자가 서버에 자신의 미디어 스트림을 보내면 서버는 참가자 만큼의 프로세스 스트림을 얻을 수 있다. 클라이언트에게 무리를 줄 수있다. 하지만 클라이언트(브라우저 조차도) 상당히 많은 계산을 처리 할만큼 충분히 빨라졌다. 충분하다. 

회의 컨트롤러는 대역폭 조건의 따라 각 수신기에 가장적합한 스트림을 동적으로 전달한다. 컨트롤러는 송신자의 인코딩 비트 레이트를 동적으로 다시 계산하고 수신기의 단기적인 대역폭 변화를 줄이고 전달되는 비디오 품질을 높일 수 있다. 

webrtc 클라이언트가 인코딩 된 비디오 스트림을 중앙 집중식 미디어 서버로 전송할 수 있는 토폴로지로 중앙의 미디어 서버에서 다른 클라이언트로 전달/라우팅 된다. 서버에서 인코딩/디코딩을 하지 않기 때문에 컴퓨팅 비용을 포함하지 않아 서버 성능 문제를 해결할 수 있고 서버의 대기시간은 최소화된다.  미디어 서버와 완벽하게 통신하는 클라이언트는 수신 스트림을 완벽하게 제어할 수 있으며 클라이언트는 원하는 스트림을 수신하기 때문에 사용자 인터페이스 유연성을 완전히 제어 할 수 있다.

클라이언트로 라우팅/포워딩 되는 다중 스트림은 다운링크 대역폭을 증가시켜 디코드 처리를 증가시킬수 있다. 클라이언트에게 전달되는 스트림의 수를 제한함으로써 완화 할 수 있다. 

결론

회의 컨트롤러는 대역폭 조건의 따라 각 수신기에 가장 적합한 스트림을 동적으로 전달한다. 컨트롤러는 송신자의 인코딩 비트 레이트를 동적으로 다시 계산하고 수신기의 단기적인 대역폭 변화를 줄이고 전달되는 비디오 품질을 높일 수 있다. 

미디어 서버와 완벽하게 통신하는 클라이언트는 수신 스트림을 완벽하게 제어할 수 있으며 클라이언트는 원하는 스트림을 수신하기 때문에 사용자 인터페이스 유연성을 완전히 제어 할 수 있다.

 

정의 - 클라이언트가 인코딩 된 비디오 스트림을 서버에 보내면 서버는 다른 클라이언트로 전달한다. 

장점 - 대역폭 조건에 따라 각 수신기에 가장 적합한 스트림을 동적으로 전달한다. (컨트롤러는 송신자의 인코딩 비트레이트를 동적으로 다시 계산하고, 수신기의 단기적인 대역폭 변화를 줄이고 전달되는 비디오 품질을 높일 수 있다.) 

서버에서 인코딩/디코딩을 하지 않아 서버대기 시간이 최소화된다.

단점 - 클라이언트 컴퓨팅/대역폭을 요구하는 단점이 있다.(다른 클라이언트의 비디오 스트림을 받아서 디코딩 해야된다. 하지만 요즘 클라이언트가 상당히 많은 계산을 처리 할 만큼 충분히 빨라졌다. 클라이언트에게 전달되는 스트림의 수를 제한함으로써 완화 할 수 있다.)

MESH

클라이언트간에 직접 미디어를 전송한다.

결론

정의 - 클라이언트 간에 직접 미디어를 전송한다. 전송하는 동시에 미디어 스트림을 수신하고 해독해야 한다. 

장점 - 미디어가 수신 클라이언트에게 직접 전달되기 때문에 대기시간은 문제가 되지 않는다. 1대1일때 품질이 우수하고 대기시간이 짧으므로 적합 하다.

단점 - 클라이언트가 늘어날수록 CPU와 대역폭 이 증가한다.