Tổng quan về Meet Media API

Google Meet Media API cho phép bạn truy cập nội dung nghe nhìn theo thời gian thực từ các cuộc họp trên Google Meet. Điều này cho phép nhiều trường hợp sử dụng, chẳng hạn như các ứng dụng ghi lại các mục hành động, cung cấp thông tin chi tiết theo thời gian thực về cuộc họp hiện tại hoặc truyền trực tuyến âm thanh và video đến một nền tảng mới.

Trường hợp sử dụng

Các ứng dụng đã đăng ký trong Google Cloud Console có thể sử dụng Meet Media API để kết nối với các cuộc họp trên Meet, cho phép các ứng dụng đó:

  • Tiêu thụ luồng video. Ví dụ:
    • Cung cấp luồng video được tạo trong các cuộc họp trên Meet vào mô hình AI của riêng bạn.
    • Lọc luồng cho bản ghi tuỳ chỉnh.
  • Tiêu thụ luồng âm thanh. Ví dụ:
    • Truyền trực tiếp âm thanh vào Gemini và tạo chatbot AI cho cuộc họp của riêng bạn.
    • Cung cấp luồng âm thanh được tạo trong các cuộc họp trên Meet vào dịch vụ chép lời của riêng bạn
    • Tạo phụ đề bằng nhiều ngôn ngữ.
    • Tạo nguồn cấp dữ liệu ngôn ngữ ký hiệu do mô hình tạo từ âm thanh đã ghi lại.
    • Tạo mô hình khử nhiễu của riêng bạn để loại bỏ tạp âm và phông nền khỏi cuộc họp.
  • Sử dụng siêu dữ liệu của người tham gia. Ví dụ:
    • Phát hiện những người tham gia đang có mặt trong hội nghị, cho phép cung cấp thông tin và số liệu phân tích hiệu quả hơn.

Thuật ngữ thường gặp

Số dự án trên Cloud
Mã nhận dạng int64 được tạo không thể thay đổi cho một dự án trên Google Cloud. Các giá trị này là do Google Cloud Console tạo ra cho từng ứng dụng đã đăng ký.
Hội nghị
Một thực thể cuộc gọi do máy chủ tạo trong một không gian họp. Người dùng thường coi trường hợp này là một cuộc họp.
Kênh dữ liệu tài nguyên hội nghị

Thay vì yêu cầu tài nguyên qua HTTP, như với API Google Meet REST, ứng dụng Meet Media API yêu cầu tài nguyên từ máy chủ qua các kênh dữ liệu.

Bạn có thể mở một kênh dữ liệu chuyên dụng cho mỗi loại tài nguyên. Sau khi mở, ứng dụng có thể gửi yêu cầu qua kênh. Nội dung cập nhật tài nguyên sẽ được truyền qua cùng một kênh.

Nguồn đóng góp (CSRC)

Với luồng nội dung nghe nhìn ảo, bạn không thể giả định rằng luồng nội dung nghe nhìn luôn trỏ đến cùng một người tham gia. Giá trị CSRC trong tiêu đề của mỗi gói RTP xác định nguồn thực sự của gói.

Meet chỉ định cho mỗi người tham gia trong một hội nghị một giá trị CSRC duy nhất khi họ tham gia. Giá trị này không đổi cho đến khi người dùng rời khỏi.

Kênh dữ liệu

Kênh dữ liệu WebRTC cho phép trao đổi dữ liệu tuỳ ý (văn bản, tệp, v.v.) độc lập với luồng âm thanh và video. Kênh dữ liệu sử dụng cùng một kết nối với luồng nội dung đa phương tiện, cung cấp một cách hiệu quả để thêm tính năng trao đổi dữ liệu vào các ứng dụng WebRTC.

Thiết lập khả năng kết nối tương tác (ICE)

Giao thức thiết lập kết nối, tìm tất cả các tuyến có thể để hai máy tính giao tiếp với nhau thông qua mạng ngang hàng (P2P), sau đó đảm bảo bạn luôn kết nối.

Luồng nội dung đa phương tiện

Luồng nội dung đa phương tiện WebRTC đại diện cho luồng dữ liệu đa phương tiện, thường là âm thanh hoặc video, được ghi lại từ một thiết bị như camera hoặc micrô. Luồng này bao gồm một hoặc nhiều luồng nội dung nghe nhìn, mỗi luồng đại diện cho một nguồn nội dung nghe nhìn như luồng video hoặc luồng âm thanh).

Đường dẫn luồng nội dung đa phương tiện

Bao gồm một luồng đơn, một chiều của các gói RTP. Một kênh phát trực tuyến nội dung đa phương tiện có thể là âm thanh hoặc video, nhưng không thể là cả hai. Kết nối Giao thức truyền tải bảo mật theo thời gian thực (SRTP) hai chiều thường bao gồm hai kênh luồng nội dung nghe nhìn, luồng đầu ra từ máy tính cục bộ đến máy tính từ xa và luồng đầu vào từ máy tính từ xa đến máy tính cục bộ.

Không gian họp

Một địa điểm ảo hoặc đối tượng ổn định (chẳng hạn như phòng họp) nơi diễn ra hội nghị. Tại một thời điểm, bạn chỉ có thể tổ chức một hội nghị đang hoạt động trong một không gian. Không gian họp cũng giúp người dùng gặp gỡ và tìm thấy các tài nguyên dùng chung.

Người tham gia

Một người đã tham gia hội nghị hoặc sử dụng Chế độ đồng hành, xem với tư cách là người xem hoặc một thiết bị trong phòng được kết nối với cuộc gọi. Khi một người tham gia tham gia cuộc họp, hệ thống sẽ chỉ định một mã nhận dạng duy nhất.

Luồng có liên quan

Có giới hạn về số lượng Luồng âm thanh ảo và Luồng video ảo mà ứng dụng có thể mở.

Số lượng người tham gia trong một hội nghị có thể vượt quá con số này. Trong những trường hợp này, máy chủ Meet sẽ truyền luồng âm thanh và video của những người tham gia được coi là "liên quan nhất". Mức độ liên quan được xác định dựa trên nhiều đặc điểm, chẳng hạn như tính năng chia sẻ màn hình và thời điểm gần đây nhất mà người tham gia đã nói.

Bộ chuyển tiếp chọn lọc (SFU)

Bộ chuyển tiếp có chọn lọc (SFU) là một thành phần phía máy chủ trong cuộc họp WebRTC, có chức năng quản lý việc phân phối luồng nội dung đa phương tiện. Người tham gia chỉ kết nối với SFU. SFU sẽ chuyển tiếp có chọn lọc các luồng liên quan đến người tham gia khác. Điều này giúp giảm nhu cầu xử lý và băng thông của máy khách, cho phép tổ chức các cuộc họp có thể mở rộng quy mô.

Giao thức mô tả phiên (SDP)

Cơ chế báo hiệu mà WebRTC sử dụng để đàm phán kết nối P2P. RFC 8866 quản lý lớp này.

Câu trả lời SDP

Phản hồi đối với lời đề nghị SDP. Câu trả lời từ chối hoặc chấp nhận mọi luồng đã nhận từ máy ngang hàng từ xa. Lớp này cũng thương lượng về những luồng mà nó dự định truyền lại cho máy ngang hàng cung cấp. Điều quan trọng cần lưu ý là câu trả lời SDP không thể thêm luồng được báo hiệu từ ưu đãi ban đầu. Theo kinh nghiệm, nếu một máy chủ đồng cấp cung cấp tín hiệu chấp nhận tối đa 3 luồng âm thanh từ máy chủ đồng cấp từ xa, thì máy chủ đồng cấp từ xa này không thể báo hiệu 4 luồng âm thanh để truyền.

Ưu đãi SDP

SDP ban đầu trong quy trình thương lượng ngang hàng offer-answer. Ưu đãi do máy chủ đồng cấp khởi tạo tạo ra và đưa ra các điều khoản của phiên đồng cấp. Ưu đãi luôn do ứng dụng Meet Media API tạo và gửi đến máy chủ Meet.

Ví dụ: một ưu đãi có thể cho biết số lượng luồng âm thanh hoặc video mà bên đưa ra ưu đãi đang gửi (hoặc có thể nhận) và liệu có mở kênh dữ liệu hay không.

Nguồn đồng bộ hoá (SSRC)

SSRC là một giá trị nhận dạng 32 bit giúp xác định duy nhất một nguồn của luồng nội dung nghe nhìn trong một phiên RTP (Giao thức truyền tải theo thời gian thực). Trong WebRTC, SSRC được dùng để phân biệt giữa các luồng nội dung đa phương tiện bắt nguồn từ nhiều người tham gia hoặc thậm chí là nhiều kênh của cùng một người tham gia (chẳng hạn như nhiều máy ảnh).

RtpTransceiver

Như đã trình bày chi tiết trong RFC 8829, bộ thu phát là một khái niệm trừu tượng xung quanh các luồng RTP trong một phiên ngang hàng.

Một bộ thu phát được liên kết và mô tả bằng một nội dung mô tả nội dung đa phương tiện trong SDP. Bộ thu phát bao gồm RtpSender và RtpReceiver.

Vì RTP là giao thức hai chiều, nên mỗi máy ngang hàng đều có thực thể bộ thu phát riêng cho cùng một kết nối RTP. RtpSender của một bộ thu phát nhất định cho máy tính cục bộ được liên kết với RtpReceiver của một bộ thu phát cụ thể trong máy tính từ xa. Điều ngược lại cũng đúng. RtpSender của cùng một bộ thu phát của máy ngang hàng từ xa được liên kết với RtpReceiver của máy ngang hàng cục bộ.

Mỗi nội dung mô tả nội dung nghe nhìn đều có bộ thu phát chuyên dụng riêng. Do đó, một phiên ngang hàng có nhiều luồng RTP sẽ có nhiều bộ thu phát với nhiều RtpSenders và RtpReceiver cho mỗi máy ngang hàng.

Luồng nội dung nghe nhìn ảo

Luồng nội dung nghe nhìn ảo là các luồng nội dung nghe nhìn tổng hợp do Bộ chuyển tiếp chọn lọc (SFU) tạo ra trong các cuộc họp WebRTC. Thay vì mỗi người tham gia gửi luồng riêng lẻ cho những người khác, SFU sẽ đaплекс các luồng người tham gia đã chọn vào ít luồng ảo đi ra hơn. Điều này giúp đơn giản hoá cấu trúc liên kết và giảm tải cho người tham gia, cho phép tổ chức các cuộc họp có thể mở rộng quy mô. Mỗi luồng ảo có thể chứa nội dung đa phương tiện của nhiều người tham gia, do SFU quản lý linh động.