Meet Media API 개요

Google Meet Media API를 사용하면 Google Meet 회의의 실시간 미디어에 액세스할 수 있습니다. 이를 통해 작업 항목을 문서화하거나, 현재 회의에 관한 실시간 통계를 제공하거나, 오디오 및 동영상을 새 표시 경로로 스트리밍하는 앱과 같은 다양한 사용 사례를 지원할 수 있습니다.

사용 사례

Google Cloud 콘솔에 등록된 앱은 Meet Media API를 사용하여 Meet 회의에 연결하여 다음 작업을 할 수 있습니다.

  • 동영상 스트림 소비 예:
    • Meet 회의에서 생성된 동영상 스트림을 자체 AI 모델에 제공합니다.
    • 맞춤 녹화 파일의 스트림을 필터링합니다.
  • 오디오 스트림 사용 예:
    • 오디오를 Gemini에 직접 제공하고 나만의 회의 AI 챗봇을 만드세요.
    • Meet 회의에서 생성된 오디오 스트림을 자체 스크립트 작성 서비스로 피드
    • 다양한 언어로 자막을 생성합니다.
    • 캡처된 오디오에서 모델 생성 수화 피드를 만듭니다.
    • 자체 노이즈 제거 모델을 만들어 회의에서 배경과 노이즈가 있는 아티팩트를 제거합니다.
  • 참여자 메타데이터 사용 예:
    • 회의에 참여 중인 참석자를 감지하여 더 나은 정보 및 분석을 제공합니다.

일반적인 용어

Cloud 프로젝트 번호
Google Cloud 프로젝트의 변경 불가능한 생성된 int64 식별자입니다. 이러한 값은 등록된 각 앱에 대해 Google Cloud 콘솔에서 생성합니다.
회의
회의 공간 내에서 서버에서 생성한 통화 인스턴스입니다. 사용자는 일반적으로 이 시나리오를 단일 회의로 간주합니다.
회의 리소스 데이터 채널

Meet Media API 클라이언트는 Google Meet REST API와 같이 HTTP를 통해 리소스를 요청하는 대신 데이터 채널을 통해 서버에서 리소스를 요청합니다.

리소스 유형별로 전용 데이터 채널이 열릴 수 있습니다. 열리면 클라이언트는 채널을 통해 요청을 보낼 수 있습니다. 리소스 업데이트는 동일한 채널을 통해 전송됩니다.

참여 소스 (CSRC)

가상 미디어 스트림을 사용하면 미디어 스트림이 항상 동일한 참여자를 가리킨다고 가정할 수 없습니다. 각 RTP 패킷 헤더의 CSRC 값은 패킷의 실제 소스를 식별합니다.

Meet에서는 참여자가 회의에 참여할 때 각 참여자에게 고유한 CSRC 값을 할당합니다. 이 값은 사용자가 나가기 전까지 일정하게 유지됩니다.

데이터 채널

WebRTC 데이터 채널을 사용하면 오디오 및 동영상 스트림과 별개로 임의 데이터 (텍스트, 파일 등)를 교환할 수 있습니다. 데이터 채널은 미디어 스트림과 동일한 연결을 사용하므로 WebRTC 애플리케이션에 데이터 교환을 추가하는 효율적인 방법을 제공합니다.

대화형 연결 설정 (ICE)

연결을 설정하기 위한 프로토콜로, 두 대의 컴퓨터가 P2P (Peer-to-Peer) 네트워킹을 통해 서로 통신할 수 있는 모든 경로를 찾은 후 연결 상태를 유지합니다.

미디어 스트림

WebRTC 미디어 스트림은 카메라나 마이크와 같은 기기에서 캡처된 미디어 데이터(일반적으로 오디오 또는 동영상)의 흐름을 나타냅니다. 하나 이상의 미디어 스트림 트랙으로 구성되며, 각각은 동영상 트랙이나 오디오 트랙과 같은 단일 미디어 소스를 나타냅니다.

미디어 스트림 트랙

단일 단방향 RTP 패킷 흐름으로 구성됩니다. 미디어 스트림 트랙은 오디오 또는 동영상일 수 있지만 둘 다일 수는 없습니다. 양방향 보안 실시간 전송 프로토콜 (SRTP) 연결은 일반적으로 두 개의 미디어 스트림 트랙, 즉 로컬에서 원격 피어로의 이그레스와 원격 피어에서 로컬 피어로의 인그레스로 구성됩니다.

회의 공간

회의가 열리는 가상 장소 또는 영구 객체 (예: 회의실)입니다. 한 공간에서 한 번에 하나의 회의만 진행할 수 있습니다. 회의 공간은 사용자가 공유 리소스를 찾고 만나는 데도 도움이 됩니다.

참여자

회의에 참여했거나 컴패니언 모드를 사용하며 시청자로 시청 중이거나 통화에 연결된 회의실 기기입니다. 참여자가 회의에 참여하면 고유 ID가 할당됩니다.

관련 스트림

클라이언트가 열 수 있는 가상 오디오 스트림 및 가상 동영상 스트림 수에 한도가 있습니다.

회의의 참여자 수가 이 숫자를 초과할 수 있습니다. 이 경우 Meet 서버는 '가장 관련성이 높다고' 간주되는 참여자의 오디오 및 동영상 스트림을 전송합니다. 관련성은 화면 공유, 참여자가 말한 최근 시간 등 다양한 특성에서 결정됩니다.

선택적 전달 장치 (SFU)

선택적 전달 단위 (SFU)는 미디어 스트림 배포를 관리하는 WebRTC 회의의 서버 측 구성요소입니다. 참여자는 SFU에만 연결되며 SFU는 관련 스트림을 다른 참여자에게 선택적으로 전달합니다. 이렇게 하면 클라이언트 처리 및 대역폭 요구사항이 줄어 확장 가능한 회의를 진행할 수 있습니다.

세션 설명 프로토콜 (SDP)

WebRTC에서 P2P 연결을 협상하는 데 사용하는 신호 메커니즘입니다. RFC 8866가 이를 관리합니다.

SDP 응답

SDP 오퍼에 대한 응답입니다. 응답은 원격 피어로부터 수신된 스트림을 거부하거나 수락합니다. 또한 오퍼링 피어에 다시 전송할 스트림을 협상합니다. SDP 응답은 초기 오퍼의 신호 스트림을 추가할 수 없다는 점에 유의해야 합니다. 예를 들어 제공 피어가 원격 피어의 오디오 스트림을 최대 3개까지 수신한다고 신호를 보내면 이 원격 피어는 전송을 위해 4개의 오디오 스트림을 신호로 보낼 수 없습니다.

SDP 오퍼

오퍼-응답 피어 투 피어 협상 흐름의 초기 SDP입니다. 오퍼는 시작하는 피어에 의해 생성되며 피어 투 피어 세션의 약관을 지정합니다. 오퍼는 항상 Meet Media API 클라이언트에서 생성하여 Meet 서버에 제출합니다.

예를 들어 오퍼는 오퍼 제공자가 전송 중인 (또는 수신할 수 있는) 오디오 또는 동영상 스트림의 수와 데이터 채널을 열지 여부를 나타낼 수 있습니다.

동기화 소스 (SSRC)

SSRC는 RTP (실시간 전송 프로토콜) 세션 내에서 미디어 스트림의 단일 소스를 고유하게 식별하는 32비트 식별자입니다. WebRTC에서 SSRC는 서로 다른 참여자로부터 발생한 서로 다른 미디어 스트림 또는 동일한 참여자의 서로 다른 트랙 (예: 서로 다른 카메라)을 구별하는 데 사용됩니다.

RtpTransceiver

RFC 8829에 설명된 대로, transceiver는 피어 투 피어 세션의 RTP 스트림을 추상화한 것입니다.

단일 트랜시버는 SDP의 단일 미디어 설명에 매핑되고 설명됩니다. 트랜시버는 RtpSender와 RtpReceiver로 구성됩니다.

RTP는 양방향이므로 각 피어에는 동일한 RTP 연결에 관한 자체 트랜시버 인스턴스가 있습니다. 로컬 피어의 지정된 트랜시버의 RtpSender는 원격 피어의 특정 트랜시버의 RtpReceiver에 매핑됩니다. 반대의 경우도 마찬가지입니다. 원격 피어의 동일한 트랜시버의 RtpSender는 로컬 피어의 RtpReceiver에 매핑됩니다.

모든 미디어 설명에는 자체 전용 트랜시버가 있습니다. 따라서 RTP 스트림이 여러 개인 P2P 세션에는 각 피어에 여러 개의 RtpSenders 및 RtpReceiver가 있는 여러 개의 트랜시버가 있습니다.

가상 미디어 스트림

가상 미디어 스트림은 WebRTC 회의에서 선택적 전달 장치 (SFU)에 의해 생성된 집계된 미디어 스트림입니다. 각 참여자가 개별 스트림을 다른 모든 참여자에게 전송하는 대신 SFU는 선택한 참여자 스트림을 더 적은 수의 발신 가상 스트림으로 다중화합니다. 이렇게 하면 연결 토폴로지가 단순화되고 참여자의 부하가 줄어들어 확장 가능한 회의를 진행할 수 있습니다. 각 가상 스트림은 SFU에서 동적으로 관리하는 여러 참여자의 미디어를 포함할 수 있습니다.