Meet Media API 개요

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

사용 사례

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

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

Meet Media API 수명 주기

다음 이미지는 Meet Media API 수명 주기를 보여줍니다.

동의자 요구사항

Meet Media API 앱은 회의를 대신하여 동의를 제공할 수 있는 통화 참여자가 있는 경우에만 회의에 참여할 수 있습니다.

Google Workspace 회의

Google Workspace 회의에서 동의를 제공하려면 회의를 소유한 조직에 속해 있어야 합니다. 대부분의 경우 회의 소유자는 주최자와 동일합니다. 호스트 또는 시작자가 회의에 참석 하고 회의를 소유한 조직에 속해 있는 경우 시작 대화상자가 우선적으로 표시됩니다.

일반 회의

Gmail 계정으로 주최된 회의의 경우 시작자가 회의에 참석하여 동의를 제공해야 합니다.

일반적인 용어

클라우드 프로젝트 번호

Google Cloud 프로젝트의 변경 불가능한 생성된 int64 식별자입니다. 이러한 값은 등록된 각 앱에 대해 Google Cloud 콘솔에서 생성됩니다.

회의

회의 공간 내에서 서버에서 생성된 통화 인스턴스입니다. 사용자는 일반적으로 이 시나리오를 단일 회의로 간주합니다.

회의 리소스 데이터 채널

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

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

기여 소스 (CSRC)

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

Meet는 회의에 참여할 때 각 참여자에게 고유한 CSRC 값을 할당합니다. 이 값은 참여자가 회의를 종료할 때까지 일정하게 유지됩니다.

데이터 채널

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

대화형 연결 설정 (ICE)

연결을 설정하고, 두 컴퓨터가 P2P (피어 투 피어) 네트워킹을 통해 서로 통신할 수 있는 모든 가능한 경로를 찾은 다음, 연결을 유지하는 프로토콜입니다.

미디어 스트림

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에 자세히 설명된 대로 트랜시버는 피어 투 피어 세션의 RTP 스트림을 추상화한 것입니다.

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

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

모든 미디어 설명에는 자체 전용 트랜시버가 있습니다. 따라서 RTP 스트림이 여러 개 있는 피어 투 피어 세션에는 각 피어에 대해 RtpSenders와 RtpReceivers가 여러 개 있는 트랜시버가 여러 개 있습니다.

가상 미디어 스트림

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

관련 주제

• Meet Media API 클라이언트 개발을 시작하는 방법을 알아보려면 시작하기의 단계를 따르세요.

• 샘플 Meet Media API 참조 클라이언트를 설정하고 실행하는 방법을 알아보려면 C++ 참조 클라이언트 빠른 시작을 참고하세요.

• 개념 개요를 보려면 Meet Media API 개념을 참고하세요.

• WebRTC에 대해 자세히 알아보려면 WebRTC For The Curious를 참고하세요.

• 인증 및 승인 처리를 비롯한 Google Workspace API를 사용하여 개발하는 방법을 알아보려면 Google Workspace에서 개발을 참고하세요.