Tổng quan về Meet Media API

Google Meet Media API cho phép bạn truy cập vào nội dung nghe nhìn theo thời gian thực từ các hội nghị 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 việc cần làm, 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 phát 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 được đăng ký trong Google Cloud Console có thể sử dụng API nội dung nghe nhìn của Meet để kết nối với các hội nghị truyền hình trên Meet, cho phép các ứng dụng này:

  • Xem luồng video. Ví dụ:
    • Truyền các luồng video được tạo trong các hội nghị trên Meet vào các mô hình AI của riêng bạn.
    • Lọc luồng cho bản ghi hình tuỳ chỉnh.
  • Tiêu thụ nội dung phát trực tiếp dạ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.
    • Truyền các luồng âm thanh được tạo trong các hội nghị 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ý do mô hình tạo ra từ âm thanh đã ghi lại.
    • Tạo mô hình khử nhiễu của riêng bạn để loại bỏ nền và các hiện tượng nhiễu khỏi hội nghị.
  • 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 trong hội nghị, cho phép thu thập thông tin chi tiết và phân tích hiệu quả hơn.

Vòng đời của Meet Media API

Các hình ảnh sau đây minh hoạ vòng đời của Meet Media API:

  • Bot Meet Media API cố gắng tham gia tại trang web của bên thứ ba.
    Hình 1. Bot Meet Media API sẽ cố gắng tham gia vào trang web của bên thứ ba. Hệ thống sẽ từ chối yêu cầu kết nối nếu có tài khoản của trẻ vị thành niên.
  • Cuộc họp được mã hoá và cuộc họp có hình mờ.
    Hình 2. Cuộc họp có thể được đánh dấu là được mã hoá và có hình mờ. Không thể kết nối Meet Media API khi cuộc họp có tính năng mã hoá hoặc hình mờ.
  • Đảm bảo chế độ cài đặt quản trị viên là chính xác.
    Hình 3. Đảm bảo chế độ cài đặt quản trị viên là chính xác.
  • Thiết lập cuộc họp trong Lịch.
    Hình 4. Thiết lập cuộc họp trong Lịch. Người tổ chức cần cấp quyền cho ứng dụng bên thứ ba trong phần cài đặt Lịch, nếu không, yêu cầu kết nối sẽ bị từ chối.
  • Thay đổi chế độ cài đặt trong khi gọi.
    Hình 5. Thay đổi chế độ cài đặt trong cuộc gọi. Nếu người tổ chức quyết định tắt chế độ cài đặt Meet Media API trong cuộc gọi, thì kết nối sẽ dừng.
  • Người bắt đầu phải có mặt trong các cuộc họp với người tiêu dùng.
    Hình 6. Nếu chủ sở hữu cuộc họp có tài khoản người dùng thông thường (tài khoản có đuôi @gmail.com), thì người bắt đầu phải có mặt để đồng ý tham gia cuộc họp, nếu không yêu cầu kết nối sẽ bị từ chối.
  • Đã thiết lập kết nối.
    Hình 7. Sau khi kết nối được thiết lập, người tổ chức, người đồng tổ chức hoặc bất kỳ người tham gia nào trong cùng một tổ chức với người tổ chức sẽ thấy hộp thoại bắt đầu.
  • Bất kỳ ai cũng có thể dừng API nội dung nghe nhìn của Meet trong cuộc gọi.
    Hình 8. Bất kỳ ai cũng có thể dừng Meet Media API trong cuộc gọi.

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

Số dự án trên Cloud
Giá trị nhận dạng int64 bất biến được tạo cho một dự án trên Google Cloud. Google Cloud Console sẽ tạo các giá trị này cho từng ứng dụng đã đăng ký.
Hội nghị
Một phiên bản do máy chủ tạo của một cuộc gọi trong 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 duy nhất.
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 Google Meet REST API, các ứng dụng Meet Media API sẽ 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 từng 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 truyền trực tuyến nội dung nghe nhìn ảo, bạn không thể giả định rằng một luồng truyền trực tuyến 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 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 riêng biệt khi họ tham gia. Giá trị này vẫn không đổi cho đến khi họ rời đ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. Data Channel sử dụng cùng một kết nối như luồng nội dung nghe nhì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 kết nối tương tác (ICE)

Một giao thức để thiết lập kết nối, tìm tất cả các tuyến đường 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 nghe nhìn

Luồng nội dung nghe nhìn WebRTC biểu thị một luồng dữ liệu nội dung nghe nhìn (thường là âm thanh hoặc video) được ghi lại từ một thiết bị như camera hoặc micrô. Nó bao gồm một hoặc nhiều bản luồng nội dung nghe nhìn, mỗi bản đại diện cho một nguồn nội dung nghe nhìn duy nhất, chẳng hạn như bản video hoặc bản âm thanh).

Bản phụ đề của luồng nội dung nghe nhìn

Bao gồm một luồng gói RTP một chiều. Một bản ghi luồng nội dung nghe nhì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 2 bản nhạc luồng nội dung nghe nhìn, đường truyền ra từ thiết bị ngang hàng cục bộ đến thiết bị ngang hàng từ xa và đường truyền vào từ thiết bị ngang hàng từ xa đến thiết bị ngang hàng cục bộ.

Không gian của cuộc họp

Một địa điểm ảo hoặc đối tượng cố định (chẳng hạn như phòng họp) nơi diễn ra một hội nghị. Tại một thời điểm bất kỳ, bạn chỉ có thể tổ chức một hội nghị truyền hình đang hoạt động trong một không gian. Không gian tổ chức cuộc 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 ở chế độ người xem hoặc một thiết bị phòng kết nối với cuộc gọi. Khi một người tham gia vào hội nghị, họ sẽ được chỉ định một mã nhận dạng duy nhất.

Luồng phát có liên quan

Có giới hạn về số lượng Luồng âm thanh ảo và Luồng video ảo mà một ứ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 các luồng âm thanh và video của những người tham gia được coi là "phù hợp 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ư hoạt động chia sẻ màn hình và thời gian gần đây nhất mà người tham gia đã nói.

Đơn vị chuyển tiếp có chọn lọc (SFU)

Đơn vị chuyển tiếp có chọn lọc (SFU) là một thành phần phía máy chủ trong hội nghị truyền hình WebRTC, giúp quản lý việc phân phối luồng nội dung nghe nhìn. Người tham gia chỉ kết nối với SFU, SFU này sẽ chọn lọc và chuyển tiếp các luồng liên quan đến những 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 các hội nghị có thể mở rộng.

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

Cơ chế báo hiệu mà WebRTC dùng để thương lượng một kết nối P2P. RFC 8866 chi phối việc này.

Câu trả lời SDP

Phản hồi đối với một lời đề nghị SDP. Câu trả lời này từ chối hoặc chấp nhận mọi luồng nhận được từ thiết bị ngang hàng từ xa. Ngoài ra, nó còn thương lượng những luồng mà nó dự định truyền ngược lại cho thiết bị 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 các luồng được báo hiệu từ đề nghị ban đầu. Theo kinh nghiệm, nếu một thiết bị ngang hàng đề nghị báo hiệu rằng thiết bị đó chấp nhận tối đa 3 luồng âm thanh từ thiết bị ngang hàng từ xa, thì thiết bị ngang hàng từ xa này không thể báo hiệu 4 luồng âm thanh để truyền.

Đề nghị SDP

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

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

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

SSRC là 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 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 nghe nhìn khác nhau có nguồn gốc từ những người tham gia khác nhau hoặc thậm chí là các bản nhạc khác nhau của cùng một người tham gia (chẳng hạn như các camera khác nhau).

RtpTransceiver

Như đã trình bày chi tiết trong RFC 8829, bộ thu phát là một thành phần 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 duy nhất được liên kết và mô tả bằng một nội dung mô tả nội dung nghe nhìn duy nhất trong SDP. Một bộ thu phát bao gồm một RtpSender và một RtpReceiver.

Vì RTP là giao thức hai chiều, nên mỗi thành phần ngang hàng đều có phiên bản 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 thiết bị ngang hàng cục bộ được liên kết với RtpReceiver của một bộ thu phát cụ thể trong thiết bị ngang hàng từ xa. Điều ngược lại cũng đúng. RtpSender của cùng một bộ thu phát của thiết bị ngang hàng từ xa được ánh xạ đến RtpReceiver của thiết bị ngang hàng cục bộ.

Mỗi nội dung mô tả về 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 người dùng ngang hàng.

Virtual Media Streams

Luồng nội dung nghe nhìn ảo là luồng nội dung nghe nhìn tổng hợp do Đơn vị chuyển tiếp có chọn lọc (SFU) tạo ra trong các hội nghị WebRTC. Thay vì mỗi người tham gia gửi các luồng riêng lẻ cho mọi người khác, SFU sẽ ghép các luồng của người tham gia được 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 kết nối và giảm tải cho người tham gia, cho phép các hội nghị có thể mở rộng. Mỗi luồng ảo có thể chứa nội dung nghe nhìn của nhiều người tham gia, do SFU quản lý linh hoạt.