Omówienie interfejsu Meet Media API

Interfejs Google Meet Media API umożliwia dostęp do multimediów w czasie rzeczywistym z konferencji w Google Meet. Umożliwia to różne zastosowania, np. aplikacje, które dokumentują elementy działania, oferują w czasie rzeczywistym statystyki dotyczące bieżącego spotkania lub przesyłają strumieniowo dźwięk i obraz na nowe urządzenie.

Przypadki użycia

Aplikacje zarejestrowane w Google Cloud Console mogą korzystać z interfejsu Meet Media API, aby łączyć się z konferencjami w Meet. Dzięki temu mogą:

  • Oglądanie strumieni wideo Przykład:
    • Przesyłaj strumienie wideo z rozmów w Meet do własnych modeli AI.
    • Filtrowanie strumieni pod kątem nagrań niestandardowych.
  • Odtwarzanie strumieni audio Przykład:
    • Przesyłaj dźwięk bezpośrednio do Gemini i twórz własnego chatbota AI do spotkań.
    • przesyłać strumienie audio wygenerowane podczas konferencji w Meet do własnej usługi transkrypcji;
    • generować napisy w różnych językach;
    • Tworzenie wygenerowanych przez model kanałów z tłumaczeniem na język migowy na podstawie zarejestrowanego dźwięku.
    • Twórz własne modele redukcji szumów, aby usuwać z konferencji szumy i artefakty.
  • Korzystanie z metadanych uczestnika Przykład:
    • wykrywanie uczestników konferencji, co pozwala na lepsze analizy i statystyki;

Cykl życia interfejsu Meet Media API

Poniższe obrazy przedstawiają cykl życia interfejsu Meet Media API:

  • Bot interfejsu Meet Media API próbuje dołączyć do spotkania w witrynie innej firmy.
    Rysunek 1. Bot interfejsu Meet Media API próbuje dołączyć do spotkania na stronie internetowej innej firmy. Połączenie jest odrzucane, gdy występują konta osób niepełnoletnich.
  • zaszyfrowane spotkania i spotkania ze znakiem wodnym.
    Rysunek 2. Spotkania mogą być oznaczane jako zaszyfrowane i zawierać znak wodny. Nie można połączyć interfejsu Meet Media API, gdy spotkanie jest szyfrowane lub ma znak wodny.
  • Sprawdź, czy ustawienie administratora jest prawidłowe.
    Rysunek 3. Sprawdź, czy ustawienie administratora jest prawidłowe.
  • Skonfiguruj spotkanie w Kalendarzu.
    Rysunek 4. Skonfiguruj spotkanie w Kalendarzu. Gospodarz musi przyznać aplikacji innej firmy uprawnienia w ustawieniach Kalendarza, w przeciwnym razie połączenie zostanie odrzucone.
  • Zmiana ustawień w trakcie rozmowy.
    Rysunek 5. zmiana ustawienia podczas połączenia; Jeśli gospodarz zdecyduje się wyłączyć ustawienie interfejsu Meet Media API podczas połączenia, połączenie zostanie przerwane.
  • Podczas spotkań z klientami osoba inicjująca musi być obecna.
    Rysunek 6. Jeśli właściciel spotkania ma konto indywidualne (konto kończące się na @gmail.com), inicjator musi być obecny na spotkaniu, aby wyrazić zgodę. W przeciwnym razie połączenie zostanie odrzucone.
  • Połączenie zostało nawiązane.
    Rysunek 7. Po nawiązaniu połączenia gospodarz, współgospodarz lub uczestnicy z tej samej organizacji co gospodarz zobaczą okno dialogowe inicjowania.
  • Każda osoba może zatrzymać interfejs Meet Media API podczas połączenia.
    Rysunek 8. Każda osoba może zatrzymać interfejs Meet Media API podczas połączenia.

Często spotykane terminy

Numer projektu Cloud
Niezmienny wygenerowany int64 identyfikator projektu Google Cloud. Te wartości są generowane przez konsolę Google Cloud dla każdej zarejestrowanej aplikacji.
Konferencja
Instancja połączenia wygenerowana przez serwer w przestrzeni spotkania. Użytkownicy zwykle traktują ten scenariusz jako jedno spotkanie.
Kanał danych o zasobach konferencji

W przeciwieństwie do interfejsu Google Meet REST API, w którym zasoby są wysyłane przez HTTP, klienci interfejsu Meet Media API wysyłają żądania zasobów z serwera przez kanały danych.

Dla każdego typu zasobu można otworzyć osobny kanał danych. Po otwarciu klient może wysyłać żądania przez kanał. Aktualizacje zasobów będą przesyłane tym samym kanałem.

Źródło danych (CSRC)

W przypadku wirtualnych strumieni multimediów nie można zakładać, że strumień multimediów zawsze wskazuje tego samego uczestnika. Wartość CSRC w nagłówku każdego pakietu RTP identyfikuje prawdziwe źródło pakietu.

Meet przypisuje każdemu uczestnikowi konferencji unikalną wartość CSRC, gdy dołącza on do spotkania. Ta wartość pozostaje stała, dopóki użytkownik nie opuści strony.

Kanały danych

Kanały danych WebRTC umożliwiają wymianę dowolnych danych (tekstu, plików itp.) niezależnie od strumieni audio i wideo. Kanały danych korzystają z tego samego połączenia co strumienie multimediów, co zapewnia skuteczny sposób dodawania wymiany danych do aplikacji WebRTC.

Interactive Connectivity Establishment (ICE)

Protokół służący do nawiązywania połączenia, wyszukiwania wszystkich możliwych tras, którymi dwa komputery mogą się ze sobą komunikować w sieci peer-to-peer (P2P), a następnie zapewnia utrzymanie połączenia.

Strumień multimediów

Strumień multimediów WebRTC reprezentuje przepływ danych multimedialnych, zwykle audio lub wideo, przechwytywanych z urządzenia, takiego jak kamera lub mikrofon. Składa się z co najmniej 1 ścieżki strumienia multimediów, z których każda reprezentuje pojedyncze źródło multimediów, np. ścieżkę wideo lub ścieżkę audio.

Ścieżka strumienia multimediów

Składa się z pojedynczego, jednokierunkowego przepływu pakietów RTP. Ścieżka strumienia multimediów może być audio lub wideo, ale nie może być jednocześnie audio i wideo. Dwukierunkowe połączenie Secure Real-time Transport Protocol (SRTP) zwykle składa się z 2 ścieżek strumienia multimediów: wychodzącej z lokalnego do zdalnego urządzenia równorzędnego i przychodzącej ze zdalnego do lokalnego urządzenia równorzędnego.

Miejsce spotkań

Wirtualne miejsce lub trwały obiekt (np. sala spotkań), w którym odbywa się konferencja. W danej przestrzeni może się odbywać tylko 1 aktywna rozmowa wideo naraz. Przestrzeń do spotkań pomaga też użytkownikom spotykać się i znajdować wspólne zasoby.

Uczestnik

Osoba, która dołączyła do konferencji lub korzysta z trybu towarzyszącego, ogląda spotkanie jako widz lub urządzenie w sali jest połączone z rozmową. Gdy uczestnik dołącza do konferencji, przypisywany jest mu unikalny identyfikator.

Trafne strumienie

Istnieje limit liczby wirtualnych strumieni audio i wirtualnych strumieni wideo, które klient może otworzyć.

Liczba uczestników konferencji może przekroczyć tę liczbę. W takich sytuacjach serwery Meet przesyłają strumienie audio i wideo uczestników uznanych za „najbardziej istotnych”. Trafność jest określana na podstawie różnych cech, takich jak udostępnianie ekranu i to, jak niedawno uczestnik mówił.

Jednostka selektywnego przekazywania (SFU)

Jednostka selektywnego przekazywania (SFU) to komponent po stronie serwera w konferencjach WebRTC, który zarządza dystrybucją strumieni multimediów. Uczestnicy łączą się tylko z SFU, który selektywnie przekazuje odpowiednie strumienie do innych uczestników. Zmniejsza to obciążenie klienta i zapotrzebowanie na przepustowość, umożliwiając skalowanie konferencji.

Session Description Protocol (SDP)

Mechanizm sygnalizacji używany przez WebRTC do negocjowania połączenia P2P. RFC 8866.

Odpowiedź SDP

Odpowiedź na ofertę SDP. Odpowiedź odrzuca lub akceptuje wszystkie strumienie otrzymane od zdalnego klienta. Negocjuje też strumienie, które zamierza przesłać z powrotem do peera oferującego. Pamiętaj, że odpowiedź SDP nie może dodawać strumieni sygnalizowanych z początkowej oferty. Nieoficjalnie: jeśli oferujący uczestnik sygnalizuje, że akceptuje maksymalnie 3 strumienie audio od zdalnego uczestnika, ten zdalny uczestnik nie może sygnalizować 4 strumieni audio do transmisji.

Oferta SDP

Początkowy SDP w procesie negocjacji peer-to-peer typu oferta-odpowiedź. Oferta jest tworzona przez inicjującego użytkownika i określa warunki sesji peer-to-peer. Oferta jest zawsze tworzona przez klienta Meet Media API i przesyłana na serwery Meet.

Na przykład oferta może wskazywać liczbę strumieni audio lub wideo, które oferujący wysyła (lub może odbierać), oraz czy należy otworzyć kanały danych.

Źródło synchronizacji (SSRC)

SSRC to 32-bitowy identyfikator, który jednoznacznie identyfikuje pojedyncze źródło strumienia multimediów w sesji RTP (Real-time Transport Protocol). W WebRTC identyfikatory SSRC służą do rozróżniania różnych strumieni multimediów pochodzących od różnych uczestników lub nawet różnych ścieżek od tego samego uczestnika (np. z różnych kamer).

RtpTransceiver

Zgodnie z opisem w RFC 8829, transceiver to abstrakcja strumieni RTP w sesji peer-to-peer.

Pojedynczy nadajnik-odbiornik jest mapowany na pojedynczy opis multimediów w SDP i przez niego opisywany. Transceiver składa się z RtpSender i RtpReceiver.

Protokół RTP jest dwukierunkowy, więc każdy węzeł ma własną instancję nadajnika-odbiornika dla tego samego połączenia RTP. RtpSender danego nadajnika-odbiornika w przypadku lokalnego urządzenia równorzędnego jest mapowany na RtpReceiver konkretnego nadajnika-odbiornika w przypadku zdalnego urządzenia równorzędnego. Prawdziwe jest też stwierdzenie odwrotne. RtpSender tego samego transceivera zdalnego węzła jest mapowany na RtpReceiver węzła lokalnego.

Każdy opis multimediów ma własny dedykowany nadajnik-odbiornik. Dlatego sesja peer-to-peer z wieloma strumieniami RTP ma wiele nadajników-odbiorników z wieloma RtpSenders i RtpReceiver dla każdego uczestnika.

Virtual Media Streams

Wirtualne strumienie multimediów to zagregowane strumienie multimediów generowane przez jednostkę selektywnego przekazywania (SFU) podczas konferencji WebRTC. Zamiast wysyłać indywidualne strumienie do wszystkich pozostałych uczestników, SFU multipleksuje wybrane strumienie uczestników na mniejszą liczbę wychodzących strumieni wirtualnych. Upraszcza to topologię połączeń i zmniejsza obciążenie uczestników, umożliwiając skalowanie konferencji. Każdy strumień wirtualny może zawierać multimedia od wielu uczestników, którymi dynamicznie zarządza SFU.