Google Meet Media API מאפשר לכם לגשת למדיה בזמן אמת משיחות ועידה ב-Google Meet. התכונה הזו מאפשרת מגוון תרחישי שימוש, כמו אפליקציות שמתעדות פעולות לביצוע, מציעות תובנות בזמן אמת לגבי הפגישה הנוכחית או משדרות אודיו ווידאו לממשק חדש.
תרחישים לדוגמה
אפליקציות שרשומות במסוף Google Cloud יכולות להשתמש ב-Meet Media API כדי להתחבר לוועידות ב-Meet, וכך:
- צפייה בסטרימינג של סרטונים.
- צריכת שידורי אודיו.
- צריכת מטא-נתונים של משתתפים.
מחזור החיים של 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. אחרי שהחיבור נוצר, המארח, המארחים הנוספים או כל המשתתפים באותו הארגון של המארח רואים את תיבת הדו-שיח של ההפעלה. -
איור 8. כל המשתתפים בשיחה יכולים להפסיק את השימוש ב-Meet Media API במהלך השיחה.
הדרישות לקבלת הסכמה
אפליקציות של Meet Media API יכולות להצטרף לפגישה רק אם יש בה מישהו שיכול לתת הסכמה בשם הפגישה.
פגישות ב-Google Workspace
כדי לתת הסכמה בפגישות ב-Google Workspace, אתם צריכים להיות חלק מהארגון שהוא הבעלים של הפגישה. ברוב המקרים, הבעלים של הפגישה הוא אותו אדם שמארגן אותה. אם המארח או מי שהפעיל את הציוד נמצאים בפגישה וגם שייכים לארגון שבבעלותו הפגישה, הם יראו את תיבת הדו-שיח להפעלת הציוד.
לפגישות לצרכנים
בפגישות שנוצרו באמצעות חשבונות Gmail, היוזם צריך להיות בפגישה כדי לתת הסכמה.
מונחים נפוצים
- מספר פרויקט בענן
- מזהה קבוע שנוצר
int64לפרויקט ב-Google Cloud. הערכים האלה נוצרים על ידי מסוף Google Cloud לכל אפליקציה רשומה. - Conference
- מופע שנוצר בשרת של שיחה במרחב לפגישות. בדרך כלל המשתמשים רואים בתרחיש הזה פגישה אחת.
- Conference Resource Data Channel
במקום לבקש משאבים באמצעות HTTP, כמו ב-Google Meet API בארכיטקטורת REST, לקוחות של Meet Media API מבקשים משאבים מהשרת באמצעות ערוצי נתונים.
יכול להיות שייפתח ערוץ נתונים ייעודי לכל סוג משאב. אחרי הפתיחה, הלקוח יכול לשלוח בקשות דרך הערוץ. עדכוני משאבים יועברו באותו ערוץ.
- מקור תורם (CSRC)
בזרמי מדיה וירטואליים, אי אפשר להניח שזרם מדיה תמיד מצביע על אותו משתתף. ערך ה-CSRC בכותרת של כל חבילת RTP מזהה את המקור האמיתי של החבילה.
כשמשתתפים מצטרפים לפגישה ב-Meet, המערכת מקצה לכל אחד מהם ערך CSRC ייחודי. הערך הזה נשאר קבוע עד שהמשתמשים יוצאים.
- ערוצי נתונים
ערוצי נתונים של WebRTC מאפשרים להחליף נתונים שרירותיים (טקסט, קבצים וכו') באופן עצמאי מזרמי אודיו ווידאו. ערוצי נתונים משתמשים באותו חיבור כמו זרמי מדיה, ומספקים דרך יעילה להוסיף חילופי נתונים לאפליקציות WebRTC.
- Interactive Connectivity Establishment (ICE)
פרוטוקול ליצירת קישוריות, למציאת כל המסלולים האפשריים לשני מחשבים כדי לתקשר אחד עם השני דרך רשתות עמית לעמית (P2P), ואז לוודא שהחיבור נשמר.
- זרם מדיה
מקור מדיה של WebRTC מייצג זרם של נתוני מדיה, בדרך כלל אודיו או וידאו, שצולמו ממכשיר כמו מצלמה או מיקרופון. הוא מורכב מטראקים של מדיה בסטרימינג אחד או יותר, שכל אחד מהם מייצג מקור מדיה יחיד, כמו טראק וידאו או טראק אודיו).
- Media stream track
מורכב מזרימה חד-כיוונית אחת של מנות RTP. רצועת מדיה בסטרימינג יכולה להיות אודיו או וידאו, אבל לא שניהם. חיבור דו-כיווני של פרוטוקול להעברה בטוחה בזמן אמת (SRTP) מורכב בדרך כלל משני ערוצי מדיה, תעבורת נתונים יוצאת (egress) מעמית מקומי לעמית מרוחק ותעבורת נתונים נכנסת (ingress) מעמית מרוחק לעמית מקומי.
- מרחב לפגישות
מקום וירטואלי או אובייקט קבוע (כמו חדר ישיבות) שבו מתקיימת ועידה. בכל רגע נתון יכולה להתקיים רק שיחת ועידה פעילה אחת במרחב. בנוסף, מתחם ישיבות מאפשר למשתמשים להיפגש ולמצוא משאבים משותפים.
- משתתף
אדם שהצטרף לשיחה או שמשתמש במצב Companion, צופה כמשתתף או שמכשיר בחדר מחובר לשיחה. כשמשתתף מצטרף לשיחת הוועידה, מוקצה לו מזהה ייחודי.
- הזרמות רלוונטיות
יש הגבלה על מספר שידורי האודיו הווירטואליים ושידורי הווידאו הווירטואליים שלקוח יכול לפתוח.
יכול להיות שמספר המשתתפים בשיחת ועידה יהיה גדול יותר. במקרים כאלה, שרתי Meet מעבירים את זרמי האודיו והווידאו של המשתתפים שנחשבים ל "הכי רלוונטיים". רמת הרלוונטיות נקבעת על סמך מאפיינים שונים, כמו שיתוף מסך והזמן שעבר מאז שהמשתתף דיבר.
- יחידה להעברה סלקטיבית (SFU)
יחידת העברה סלקטיבית (SFU) היא רכיב בצד השרת בשיחות ועידה ב-WebRTC שמנהל את ההפצה של זרם המדיה. המשתתפים מתחברים רק ל-SFU, שמעביר באופן סלקטיבי סטרימינג רלוונטי למשתתפים אחרים. כך מצמצמים את העיבוד בצד הלקוח ואת רוחב הפס הנדרש, ומאפשרים לקיים ועידות שניתנות להרחבה.
- Session Description Protocol (SDP)
מנגנון האיתות שבו משתמש WebRTC כדי לנהל משא ומתן על חיבור P2P. הוא כפוף לתנאים של
RFC 8866.- תשובת 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.
נושאים קשורים
כדי ללמוד איך להתחיל לפתח לקוח Meet Media API, פועלים לפי השלבים במאמר תחילת העבודה.
כדי ללמוד איך להגדיר ולהריץ לקוח לדוגמה של Meet Media API, אפשר לקרוא את המדריך לתחילת העבודה עם לקוח לדוגמה ב-C++.
סקירה כללית של המושגים מופיעה במאמר מושגים ב-Meet Media API.
מידע נוסף על WebRTC זמין במאמר WebRTC For The Curious.
מידע על פיתוח באמצעות ממשקי API של Google Workspace, כולל טיפול באימות ובמתן הרשאות, זמין במאמר פיתוח ב-Google Workspace.