Google Meet Media API ช่วยให้คุณเข้าถึงสื่อแบบเรียลไทม์จากการประชุมผ่าน Google Meet ได้ ซึ่งจะช่วยให้มีกรณีการใช้งานที่หลากหลาย เช่น แอปที่บันทึกรายการดำเนินการ ให้ข้อมูลเชิงลึกแบบเรียลไทม์เกี่ยวกับการประชุมปัจจุบัน หรือสตรีมเสียงและวิดีโอไปยังแพลตฟอร์มใหม่
กรณีการใช้งาน
แอปที่ลงทะเบียนใน Google Cloud Console สามารถใช้ Meet Media API เพื่อ เชื่อมต่อกับการประชุม Meet ซึ่งจะช่วยให้แอปทำสิ่งต่อไปนี้ได้
- ดูสตรีมวิดีโอ ตัวอย่าง
- ป้อนสตรีมวิดีโอฟีดที่สร้างในการประชุม Meet ลงใน โมเดล AI ของคุณเอง
- กรองสตรีมสำหรับการบันทึกที่กำหนดเอง
- ฟังไลฟ์สด ตัวอย่าง
- ป้อนเสียงลงใน Gemini โดยตรงและสร้างแชทบอท AI สำหรับการประชุมของคุณเอง
- ส่งสตรีมเสียงของฟีดที่สร้างขึ้นในการประชุม Meet ไปยัง บริการถอดเสียงของคุณเอง
- สร้างคำบรรยายแทนเสียงในภาษาต่างๆ
- สร้างฟีดภาษามือที่โมเดลสร้างขึ้นจากเสียงที่บันทึกไว้
- สร้างโมเดลลดสัญญาณรบกวนของคุณเองเพื่อนำพื้นหลังและอาร์ติแฟกต์ที่มีสัญญาณรบกวน ออกจากการประชุม
- ใช้ข้อมูลเมตาของผู้เข้าร่วม เช่น
- ตรวจหาผู้เข้าร่วมในการประชุมทางวิดีโอ ซึ่งช่วยให้มี ข้อมูลเชิงลึกและการวิเคราะห์ที่ดีขึ้น
วงจรของ Meet Media API
รูปภาพต่อไปนี้แสดงวงจรของ Meet Media API
-
รูปที่ 1 บ็อต Meet Media API พยายามเข้าร่วมในเว็บไซต์ของบุคคลที่สาม ระบบจะปฏิเสธการเชื่อมต่อเมื่อมีบัญชีของผู้ที่มีอายุต่ำกว่าเกณฑ์ -
รูปที่ 2 การประชุมสามารถทำเครื่องหมายเป็น เข้ารหัสและมีลายน้ำได้ Meet Media API จะเชื่อมต่อไม่ได้ เมื่อการประชุมมีการเข้ารหัสหรือลายน้ำ -
รูปที่ 3 ตรวจสอบว่าการตั้งค่าผู้ดูแลระบบถูกต้อง -
รูปที่ 4 สร้างการประชุมใน ปฏิทิน โฮสต์ต้องให้สิทธิ์แก่ แอปของบุคคลที่สามในการตั้งค่าปฏิทิน มิเช่นนั้นระบบจะปฏิเสธ การเชื่อมต่อ -
รูปที่ 5 การเปลี่ยนแปลงการตั้งค่าระหว่าง การโทร หากผู้จัดการประชุมตัดสินใจปิดการตั้งค่า Meet Media API ระหว่างการโทร การเชื่อมต่อจะหยุดลง -
รูปที่ 6 หากเจ้าของการประชุมมี บัญชีผู้ใช้ทั่วไป (บัญชีที่ลงท้ายด้วย @gmail.com) ผู้เริ่ม ต้องเข้าร่วมการประชุมเพื่อยินยอม มิเช่นนั้นระบบจะปฏิเสธการเชื่อมต่อ -
รูปที่ 7 เมื่อสร้างการเชื่อมต่อแล้ว ผู้จัดการประชุม ผู้ร่วมจัดการประชุม หรือผู้เข้าร่วมทุกคนที่อยู่ในองค์กรเดียวกับผู้จัดการประชุมจะเห็นกล่องโต้ตอบการเริ่มต้น -
รูปที่ 8 ทุกคนสามารถหยุด Meet Media API ระหว่างการโทรได้
ข้อกำหนดของผู้ให้ความยินยอม
แอป Meet Media API จะได้รับอนุญาตให้เข้าร่วมการประชุมก็ต่อเมื่อมีบุคคลในการโทรที่ได้รับอนุญาตให้ให้ความยินยอมในนามของการประชุม
สำหรับการประชุมใน Google Workspace
หากต้องการให้ความยินยอมในการประชุม Google Workspace คุณต้องอยู่ในองค์กรที่เป็นเจ้าของการประชุม ในกรณีส่วนใหญ่ เจ้าของการประชุมจะ เป็นคนเดียวกับผู้จัดการประชุม หากผู้จัดการประชุมหรือผู้เริ่มการประชุมอยู่ในการประชุมและ อยู่ในองค์กรที่เป็นเจ้าของการประชุม ระบบจะแสดงกล่องโต้ตอบเริ่มต้นให้ผู้จัดการประชุมหรือผู้เริ่มการประชุม ก่อน
สำหรับการประชุมกับลูกค้า
สำหรับการประชุมที่จัดโดยบัญชี Gmail ผู้เริ่มการประชุมต้องอยู่ในการประชุมเพื่อยินยอม
คำทั่วไป
- หมายเลขโปรเจ็กต์ที่อยู่ในระบบคลาวด์
- ตัวระบุที่สร้างขึ้นซึ่งเปลี่ยนแปลงไม่ได้
int64สำหรับโปรเจ็กต์ Google Cloud ค่าเหล่านี้ สร้างขึ้นโดย Google Cloud Console สำหรับแอปที่ลงทะเบียนแต่ละแอป - การประชุม
- อินสแตนซ์ที่เซิร์ฟเวอร์สร้างขึ้นของการโทรภายในพื้นที่ การประชุม โดยปกติแล้ว ผู้ใช้จะถือว่าสถานการณ์นี้เป็นการประชุมเดียว
- ช่องข้อมูลทรัพยากรการประชุม
ไคลเอ็นต์ Meet Media API จะขอทรัพยากรจากเซิร์ฟเวอร์ผ่านช่องข้อมูลแทนที่จะขอทรัพยากรผ่าน HTTP เหมือนกับ REST API ของ Google Meet
ระบบอาจเปิดช่องข้อมูลเฉพาะสำหรับทรัพยากรแต่ละประเภท เมื่อเปิดแล้ว ไคลเอ็นต์จะส่งคำขอผ่านแชแนลได้ ระบบจะส่งการอัปเดตทรัพยากรผ่านช่องทางเดียวกัน
- แหล่งที่มาของการมีส่วนร่วม (CSRC)
สตรีมสื่อเสมือนทำให้คุณไม่สามารถสันนิษฐานได้ว่าสตรีมสื่อจะชี้ไปยังผู้เข้าร่วมคนเดียวกันเสมอ ค่า CSRC ในส่วนหัวของแต่ละแพ็กเก็ต RTP จะระบุแหล่งที่มาจริงของแพ็กเก็ต
Meet จะกำหนดค่า CSRC ที่ไม่ซ้ำกันให้ผู้เข้าร่วมแต่ละคนในการประชุม เมื่อเข้าร่วม ค่านี้จะคงที่จนกว่าผู้ใช้จะออกจากกลุ่ม
- แชแนลข้อมูล
ช่องข้อมูล WebRTC ช่วยให้แลกเปลี่ยนข้อมูลที่กำหนดเอง (ข้อความ ไฟล์ ฯลฯ) ได้โดยไม่ขึ้นกับ สตรีมเสียงและวิดีโอ DataChannel ใช้การเชื่อมต่อเดียวกับ MediaStream ซึ่งเป็นวิธีที่มีประสิทธิภาพในการเพิ่มการแลกเปลี่ยนข้อมูลลงในแอปพลิเคชัน WebRTC
- การสร้างการเชื่อมต่อแบบอินเทอร์แอกทีฟ (ICE)
โปรโตคอลสำหรับการสร้างการเชื่อมต่อ การค้นหาเส้นทางที่เป็นไปได้ทั้งหมดสำหรับคอมพิวเตอร์ 2 เครื่องเพื่อสื่อสารกันผ่านเครือข่ายแบบเพียร์ทูเพียร์ (P2P) และตรวจสอบว่าคุณยังคงเชื่อมต่ออยู่
- สตรีมสื่อ
สตรีมสื่อ WebRTC แสดงถึงการไหลของข้อมูลสื่อ ซึ่งโดยปกติคือเสียงหรือวิดีโอที่บันทึกจาก อุปกรณ์ เช่น กล้องหรือไมโครโฟน โดยประกอบด้วยแทร็กสตรีมสื่ออย่างน้อย 1 รายการ ซึ่งแต่ละรายการแสดงถึงแหล่งที่มาของสื่อเพียงแหล่งเดียว เช่น แทร็กวิดีโอหรือแทร็กเสียง)
- แทร็กสตรีมสื่อ
ประกอบด้วยการไหลของแพ็กเก็ต RTP แบบทิศทางเดียว แทร็กสตรีมสื่อ อาจเป็นเสียงหรือวิดีโอก็ได้ แต่ไม่ใช่ทั้งสองอย่าง การเชื่อมต่อ Secure Real-time Transport Protocol (SRTP) แบบ 2 ทางมักประกอบด้วยแทร็กสตรีมสื่อ 2 แทร็ก ได้แก่ ขาออกจากเพียร์ในเครื่องไปยังเพียร์ระยะไกล และขาเข้าจากเพียร์ระยะไกลไปยังเพียร์ในเครื่อง
- พื้นที่การประชุม
สถานที่เสมือนหรือออบเจ็กต์ถาวร (เช่น ห้องประชุม) ที่ใช้จัดการประชุม คุณจัดการประชุมที่ใช้งานอยู่ได้เพียงครั้งละ 1 รายการใน พื้นที่เดียว นอกจากนี้ พื้นที่การประชุมยังช่วยให้ผู้ใช้ได้พบปะและค้นหาแหล่งข้อมูลที่แชร์
- ผู้เข้าร่วม
บุคคลที่เข้าร่วมการประชุมหรือใช้โหมดแยกหน้าจอประชุม ดูในฐานะผู้ชม หรืออุปกรณ์ในห้องที่เชื่อมต่อกับการโทร เมื่อผู้เข้าร่วมเข้าร่วมการประชุม ระบบจะกำหนดรหัสที่ไม่ซ้ำกันให้
- สตรีมที่เกี่ยวข้อง
มีการจำกัดจำนวนสตรีมเสียงเสมือนและสตรีมวิดีโอเสมือน ที่ไคลเอ็นต์เปิดได้
จำนวนผู้เข้าร่วมการประชุมอาจเกินจำนวนนี้ได้ ในสถานการณ์เหล่านี้ เซิร์ฟเวอร์ Meet จะส่งสตรีมเสียงและวิดีโอของผู้เข้าร่วมที่ระบบพิจารณาว่า "เกี่ยวข้องมากที่สุด" ความเกี่ยวข้องจะพิจารณาจากลักษณะต่างๆ เช่น การแชร์หน้าจอและระยะเวลาล่าสุดที่ผู้เข้าร่วมพูด
- หน่วยส่งต่อแบบเลือก (SFU)
หน่วยส่งต่อแบบเลือก (SFU) เป็นคอมโพเนนต์ฝั่งเซิร์ฟเวอร์ในการประชุมผ่าน WebRTC ที่จัดการการกระจายสตรีมสื่อ ผู้เข้าร่วมจะเชื่อมต่อกับ SFU เท่านั้น ซึ่งจะส่งต่อสตรีมที่เกี่ยวข้องไปยังผู้เข้าร่วมรายอื่นๆ อย่างเลือกสรร ซึ่งจะช่วยลดความต้องการในการประมวลผลของไคลเอ็นต์และแบนด์วิดท์ ทำให้การประชุม ปรับขนาดได้
- Session Description Protocol (SDP)
กลไกการส่งสัญญาณที่ WebRTC ใช้เพื่อเจรจาการเชื่อมต่อ P2P
RFC 8866- คำตอบ SDP
การตอบกลับข้อเสนอ SDP คำตอบจะปฏิเสธหรือยอมรับสตรีมที่ได้รับจากเพียร์ระยะไกล นอกจากนี้ยังเจรจาต่อรองสตรีมที่ วางแผนจะส่งกลับไปยังเพียร์ที่เสนอ โปรดทราบว่าคำตอบ SDP จะเพิ่มสตรีมที่ส่งสัญญาณจากข้อเสนอเริ่มต้นไม่ได้ ตัวอย่างเช่น หากเพียร์ที่เสนอส่งสัญญาณว่ายอมรับสตรีมเสียงได้สูงสุด 3 รายการจากเพียร์ระยะไกล เพียร์ระยะไกลนี้จะส่งสัญญาณสตรีมเสียง 4 รายการเพื่อ ส่งไม่ได้
- ข้อเสนอ SDP
SDP เริ่มต้นในขั้นตอนการเจรจาแบบเพียร์ทูเพียร์ของข้อเสนอและคำตอบ ข้อเสนอ สร้างขึ้นโดยเพียร์ที่เริ่มต้นและกำหนดข้อกำหนดของเซสชันแบบเพียร์ทูเพียร์ ไคลเอ็นต์ Meet Media API จะสร้างข้อเสนอเสมอ และส่งไปยังเซิร์ฟเวอร์ Meet
เช่น ข้อเสนออาจระบุจำนวนสตรีมเสียงหรือวิดีโอที่ผู้เสนอส่ง (หรือรับได้) และระบุว่าจะเปิดช่องข้อมูลหรือไม่
- แหล่งที่มาของการซิงโครไนซ์ (SSRC)
SSRC คือตัวระบุขนาด 32 บิตที่ระบุแหล่งที่มาเดียวของ สตรีมสื่อภายในเซสชัน RTP (Real-time Transport Protocol) แบบไม่ซ้ำกัน ใน WebRTC จะใช้ SSRC เพื่อแยกความแตกต่างระหว่างสตรีมสื่อต่างๆ ที่มาจากผู้เข้าร่วมที่แตกต่างกัน หรือแม้แต่แทร็กที่แตกต่างกันจาก ผู้เข้าร่วมคนเดียวกัน (เช่น กล้องที่แตกต่างกัน)
- RtpTransceiver
ดังที่ระบุไว้ใน
RFC 8829ตัวรับส่งเป็นนามธรรมเกี่ยวกับสตรีม RTP ในเซสชันแบบเพียร์ทูเพียร์โดยจะมีการแมปทรานซีฟเวอร์เดียวกับคำอธิบายสื่อเดียวใน SDP ทรานซีฟเวอร์ประกอบด้วย
RtpSenderและRtpReceiverเนื่องจาก RTP เป็นแบบ 2 ทิศทาง พีเจียร์แต่ละรายการจึงมีอินสแตนซ์ตัวรับส่งของตัวเอง สำหรับการเชื่อมต่อ RTP เดียวกัน
RtpSenderของทรานซีฟเวอร์ที่กำหนดสำหรับ เพียร์ในเครื่องจะแมปกับRtpReceiverของทรานซีฟเวอร์ที่เฉพาะเจาะจงใน เพียร์ระยะไกล ในทางกลับกัน การลบข้อมูลออกจากโปรไฟล์ Play Games ก็จะไม่ลบข้อมูลจากประวัติการใช้งาน Google Play เช่นกัน ระบบจะแมปRtpSenderของ ทรานซีฟเวอร์เดียวกันของเพียร์ระยะไกลกับRtpReceiverของเพียร์ ในเครื่องคำอธิบายสื่อทุกรายการจะมีตัวรับส่งเฉพาะของตัวเอง ดังนั้น เซสชันแบบเพียร์ทูเพียร์ที่มีสตรีม RTP หลายรายการจึงมีตัวรับส่งหลายตัว พร้อมด้วย
RtpSendersและRtpReceiverหลายรายการสำหรับแต่ละเพียร์- Virtual Media Streams
สตรีมสื่อเสมือนคือสตรีมสื่อที่รวบรวมซึ่งสร้างโดยหน่วยส่งต่อแบบเลือก (SFU) ในการประชุม WebRTC SFU จะมัลติเพล็กซ์สตรีมของผู้เข้าร่วมที่เลือกไปยังสตรีมเสมือนขาออกจำนวนน้อยลงแทนที่ผู้เข้าร่วมแต่ละคนจะส่งสตรีมของตนเองไปยังผู้เข้าร่วมคนอื่นๆ ซึ่งจะช่วย ลดความซับซ้อนของโทโพโลยีการเชื่อมต่อและลดภาระของผู้เข้าร่วม ทำให้การประชุมสามารถปรับขนาดได้ สตรีมเสมือนแต่ละรายการสามารถมีสื่อจาก ผู้เข้าร่วมหลายคน ซึ่ง SFU จะจัดการแบบไดนามิก
หัวข้อที่เกี่ยวข้อง
หากต้องการดูวิธีเริ่มพัฒนาไคลเอ็นต์ Meet Media API ให้ทำตาม ขั้นตอนในเริ่มต้นใช้งาน
ดูวิธีตั้งค่าและเรียกใช้ไคลเอ็นต์อ้างอิง Meet Media API ตัวอย่างได้ที่คู่มือเริ่มต้นใช้งานไคลเอ็นต์อ้างอิง C++
ดูภาพรวมเชิงแนวคิดได้ที่แนวคิดเกี่ยวกับ Meet Media API
ดูข้อมูลเพิ่มเติมเกี่ยวกับ WebRTC ได้ที่ WebRTC สำหรับผู้ที่สนใจ
ดูข้อมูลเกี่ยวกับการพัฒนาด้วย Google Workspace API รวมถึงการจัดการการตรวจสอบสิทธิ์และการให้สิทธิ์ได้ที่พัฒนาบน Google Workspace