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

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

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

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

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

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

מספר הפרויקט ב-Cloud
מזהה int64 שנוצר באופן בלתי הפיך לפרויקט ב-Google Cloud. הערכים האלה נוצרים על ידי מסוף Google Cloud לכל אפליקציה רשומה.
כנס
מכונה שנוצרה על ידי השרת של שיחה במרחב פגישות. בדרך כלל המשתמשים מתייחסים לתרחיש הזה כפגישה אחת.
Conference Resource Data Channel

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

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

מקור תורם (CSRC)

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

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

ערוצי נתונים

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

Interactive Connectivity Establishment‏ (ICE)

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

Media stream

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

טראק של מקור מדיה

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

מקום הפגישה

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

משתתף/ת

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

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

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

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

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

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

Session Description Protocol ‏ (SDP)

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

תשובה ל-SDP

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

הצעת SDP

ה-SDP הראשוני בתהליך המשא ומתן של הצעה-תשובה ברשת P2P. המבצע נוצר על ידי הצד המבצע, והוא קובע את התנאים של הסשן מול peer-to-peer. הלקוח של Meet Media API תמיד יוצר את המבצע ושולח אותו לשרתי Meet.

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

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

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

RtpTransceiver

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

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

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

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

Virtual Media Streams

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