סקירה כללית על Meet Media API

‫Google Meet Media API מאפשר לכם לגשת למדיה בזמן אמת משיחות ועידה ב-Google Meet. התכונה הזו מאפשרת מגוון תרחישי שימוש, כמו אפליקציות שמתעדות פעולות שצריך לבצע, מספקות תובנות בזמן אמת לגבי הפגישה הנוכחית או מעבירות אודיו ווידאו בסטרימינג לממשק חדש.

תרחישים לדוגמה

אפליקציות שרשומות ב-Google Cloud Console יכולות להשתמש ב-Meet Media API כדי להתחבר לוועידות ב-Meet, וכך:

  • צפייה בשידורי וידאו. לדוגמה:
    • הזנת סטרימינג של וידאו שנוצר בשיחות ועידה ב-Meet למודלים של AI משלכם.
    • סינון של הסטרימינג להקלטות בהתאמה אישית.
  • צפייה בשידורי אודיו. לדוגמה:
    • אפשר להזין אודיו ישירות ל-Gemini וליצור צ'אטבוט מבוסס-AI לפגישות.
    • העברת שידורי אודיו משיחות ועידה ב-Meet לשירות תמלול משלכם
    • ליצור כתוביות בשפות שונות.
    • ליצור פידים של שפת סימנים שנוצרו על ידי מודל מהאודיו שתועד.
    • ליצור מודלים משלכם לסינון רעשים כדי להסיר רעשי רקע וארטיפקטים רועשים מהשיחה.
  • צריכת מטא-נתונים של משתתפים. לדוגמה:
    • לזהות אילו משתתפים נמצאים בוועידה, כדי לשפר את הניתוח והתובנות.

מחזור החיים של Media API

בתמונות הבאות מוצג מחזור החיים של Meet Media API:

  • בוט של Meet Media API מנסה להצטרף לפגישה באתר של צד שלישי.
    איור 1. הבוט של Meet Media API מנסה להצטרף לאתר של הצד השלישי. החיבור נדחה אם יש חשבונות של משתמשים מתחת לגיל 18.
  • פגישות מוצפנות ופגישות עם סימן מים.
    איור 2. אפשר לסמן פגישות כמוצפנות ולהוסיף להן סימן מים. אי אפשר להתחבר אל Meet Media API כשיש בפגישה הצפנה או סימן מים.
  • מוודאים שהגדרת האדמין נכונה.
    איור 3. מוודאים שההגדרה של האדמין נכונה.
  • מגדירים את הפגישה ביומן.
    איור 4. מגדירים את הפגישה ביומן. המארח צריך לתת הרשאה לאפליקציית הצד השלישי בהגדרות היומן, אחרת החיבור יידחה.
  • שינוי ההגדרה במהלך השיחה.
    איור 5. שינוי בהגדרה במהלך השיחה. אם המארח מחליט להשבית את ההגדרה Meet Media API במהלך השיחה, החיבור נפסק.
  • היוזם חייב להיות נוכח בפגישות עם צרכנים.
    איור 6. אם הבעלים של הפגישה משתמש בחשבון פרטי (חשבון שמסתיים ב-‎ @gmail.com), יוזם השיחה חייב להיות נוכח בפגישה כדי לתת הסכמה, אחרת החיבור יידחה.
  • החיבור נוצר.
    איור 7. אחרי שהחיבור נוצר, המארח, המארחים הנוספים או כל משתתף שנמצא באותו ארגון כמו המארח רואים את תיבת הדו-שיח של ההתחלה.
  • כל המשתתפים בשיחה יכולים להפסיק את השימוש בממשקי Meet Media API במהלך השיחה.
    איור 8. כל המשתתפים בשיחה יכולים להפסיק את השימוש ב-Meet Media API במהלך השיחה.

מונחים נפוצים

מספר הפרויקט ב-Cloud
מזהה קבוע שנוצר int64 לפרויקט ב-Google Cloud. הערכים האלה נוצרים על ידי Google Cloud Console לכל אפליקציה רשומה.
ועידה
מופע של שיחה שנוצר על ידי השרת במרחב לפגישה. בדרך כלל, המשתמשים מתייחסים לתרחיש הזה כאל פגישה אחת.
ערוץ נתונים של משאבים לשיחות ועידה

במקום לבקש משאבים באמצעות HTTP, כמו ב-Google Meet REST API, לקוחות של Meet Media API מבקשים משאבים מהשרת באמצעות ערוצי נתונים.

יכול להיות שייפתח ערוץ נתונים ייעודי לכל סוג משאב. אחרי הפתיחה, הלקוח יכול לשלוח בקשות בערוץ. עדכוני משאבים יועברו באותו ערוץ.

מקור התנועה שתרם להמרה (CSRC)

בזרמי מדיה וירטואליים, אי אפשר להניח שזרם מדיה תמיד מצביע על אותו משתתף. ערך ה-CSRC בכותרת של כל חבילת RTP מזהה את המקור האמיתי של החבילה.

מערכת Meet מקצה לכל משתתף בשיחת ועידה ערך CSRC ייחודי כשהוא מצטרף. הערך הזה נשאר קבוע עד שהם עוזבים.

ערוצי נתונים

ערוצי נתונים של WebRTC מאפשרים להחליף נתונים שרירותיים (טקסט, קבצים וכו') בנפרד מזרמי אודיו ווידאו. ערוצי נתונים משתמשים באותו חיבור כמו זרמי מדיה, ומספקים דרך יעילה להוסיף חילופי נתונים לאפליקציות WebRTC.

Interactive Connectivity Establishment (ICE)

פרוטוקול ליצירת קישוריות, למציאת כל המסלולים האפשריים לשני מחשבים כדי לתקשר זה עם זה דרך רשתות עמית לעמית (P2P), ואז לוודא שהחיבור נשמר.

סטרימינג של מדיה

מקור מדיה של WebRTC מייצג זרם של נתוני מדיה, בדרך כלל אודיו או וידאו, שצולמו ממכשיר כמו מצלמה או מיקרופון. הוא מורכב מטראקים של שידורי מדיה אחד או יותר, שכל אחד מהם מייצג מקור מדיה יחיד, כמו טראק וידאו או טראק אודיו).

Media stream track

מורכב מזרם יחיד של מנות RTP בכיוון אחד. רכיב MediaStreamTrack יכול להיות אודיו או וידאו, אבל לא שניהם. חיבור פרוטוקול להעברה בטוחה בזמן אמת (SRTP) דו-כיווני מורכב בדרך כלל משני רכיבי מדיה: יציאה מעמית מקומי לעמית מרוחק וכניסה מעמית מרוחק לעמית מקומי.

מקום הפגישה

מקום וירטואלי או אובייקט קבוע (כמו חדר ישיבות) שבו מתקיימת ועידה. בכל רגע נתון אפשר לקיים במרחב רק שיחת ועידה פעילה אחת. בנוסף, מרחב הפגישות מאפשר למשתמשים להיפגש ולמצוא משאבים משותפים.

משתתף

אדם שהצטרף לשיחה או שמשתמש במצב Companion, צופה כמשתתף או שמכשיר בחדר מחובר לשיחה. כשמשתתף מצטרף לוועידה, מוקצה לו מזהה ייחודי.

שידורים רלוונטיים

יש הגבלה על מספר הסטרימינגים הווירטואליים של אודיו והסטרימינגים הווירטואליים של וידאו שלקוח יכול לפתוח.

יכול להיות שמספר המשתתפים בשיחת ועידה יהיה גדול יותר. במקרים כאלה, שרתי Meet מעבירים את זרמי האודיו והווידאו של המשתתפים שנחשבים ל "הרלוונטיים ביותר". רמת הרלוונטיות נקבעת על סמך מאפיינים שונים, כמו שיתוף מסך והזמן שעבר מאז שהמשתתף דיבר.

יחידת העברה סלקטיבית (SFU)

יחידת העברה סלקטיבית (SFU) היא רכיב בצד השרת בשיחות ועידה ב-WebRTC שמנהל את ההפצה של זרם המדיה. המשתתפים מתחברים רק ל-SFU, שמעביר באופן סלקטיבי סטרימינג רלוונטי למשתתפים אחרים. כך מצטמצם העיבוד בצד הלקוח ורוחב הפס הדרוש, ומתאפשרות ועידות שניתנות להרחבה.

Session Description Protocol (SDP)

מנגנון האיתות שבו משתמש WebRTC כדי לנהל משא ומתן על חיבור P2P. RFC 8866.

תשובת SDP

התשובה להצעה של SDP. התשובה דוחה או מאשרת את כל הזרמים שהתקבלו מהעמית המרוחק. הוא גם מנהל משא ומתן לגבי הזרמים שהוא מתכנן לשדר בחזרה למשתתף השני בשיחה. חשוב לציין שלא ניתן להוסיף לתשובת ה-SDP זרמים עם אותות מהצעת ה-SDP הראשונית. לדוגמה, אם עמית שמציע שיחה מציין שהוא מקבל עד שלושה זרמי אודיו מהעמית המרוחק שלו, העמית המרוחק לא יכול לציין ארבעה זרמי אודיו להעברה.

SDP offer

ה-SDP הראשוני בתהליך המשא ומתן בין עמיתים (P2P) של הצעה ותשובה. המבצע נוצר על ידי העמית היוזם ומכתיב את התנאים של סשן העמית לעמית. המבצע תמיד נוצר על ידי לקוח Meet Media API ונשלח לשרתי Meet.

לדוגמה, בהצעה יכול להיות מצוין מספר זרמי האודיו או הווידאו שהצד המציע שולח (או יכול לקבל), והאם צריך לפתוח ערוצי נתונים.

מקור סנכרון (SSRC)

מזהה SSRC הוא מזהה בן 32 ביט שמזהה באופן ייחודי מקור יחיד של זרם מדיה בתוך סשן RTP (פרוטוקול להעברה בזמן אמת). ב-WebRTC, מספרי ה-SSRC משמשים להבחנה בין זרמי מדיה שונים שמגיעים ממשתתפים שונים או אפילו מטרקים שונים של אותו משתתף (למשל, מצלמות שונות).

RtpTransceiver

כפי שמפורט במאמר RFC 8829, משדר-מקלט הוא הפשטה של סטרימינג ב-RTP בסשן של תקשורת ישירה.

משדר-מקלט יחיד ממופה לתיאור מדיה יחיד ב-SDP ומתואר על ידו. משדר-מקלט מורכב מRtpSender ומRtpReceiver.

מכיוון ש-RTP הוא דו-כיווני, לכל עמית יש מופע משלו של משדר/מקלט לאותו חיבור RTP. ‫RtpSender של משדר-מקלט נתון עבור העמית המקומי ממופה ל-RtpReceiver של משדר-מקלט ספציפי בעמית המרוחק. ההפך הוא גם נכון. ‫RtpSender של אותו משדר/מקלט של עמית מרוחק ממופה ל-RtpReceiver של העמית המקומי.

לכל תיאור מדיה יש משדר/מקלט ייעודי משלו. לכן, בסשן עמית לעמית עם כמה זרמי RTP יש כמה משדרי רדיו עם כמה RtpSenders ו-RtpReceiver לכל עמית.

Virtual Media Streams

זרמי מדיה וירטואליים הם זרמי מדיה מצטברים שנוצרים על ידי יחידת העברה סלקטיבית (SFU) בוועידות WebRTC. במקום שכל משתתף ישלח לכל אחד אחר סטרימים נפרדים, ה-SFU מבצע מולטיפלקס של סטרימים נבחרים של משתתפים לתוך פחות סטרימים וירטואליים יוצאים. כך אפשר לפשט את טופולוגיית החיבור ולהפחית את העומס על המשתתפים, וגם לאפשר ועידות שניתנות להרחבה. כל זרם וירטואלי יכול להכיל מדיה מכמה משתתפים, שמנוהלת באופן דינמי על ידי SFU.