בהקשר של כנסים ב-WebRTC, זרמי מדיה וירטואליים הם זרמי מדיה שנוצרים על ידי יחידת העברה סלקטיבית (SFU) כדי לצבור ולחלק מדיה ממספר משתתפים. בניגוד לשידורי מדיה ישירים מ-peer-to-peer, שיוצרים רשת מורכבת של חיבורים בכנסים גדולים, שידורי מדיה וירטואליים מפשטים את הטופולוגיה. ה-SFU מקבל שידורי מדיה נפרדים מכל משתתף ומעביר באופן סלקטיבי את השידורים הפעילים או הרלוונטיים למשתתפים אחרים, ומבצע להם מפולפסיקציה לקבוצה קטנה וקבועה יותר של שידורי מדיה וירטואליים יוצאים.
הגישה הזו מפחיתה את מספר הסטרימינגים הנכנסים בו-זמנית שכל משתתף צריך לטפל בהם, וכך מפחיתה את דרישות העיבוד ורוחבי הפס. כל שידור וירטואלי יכול להכיל מדיה ממשתתף אחד בכל פעם, וה-SFU מתאים אותה באופן דינמי על סמך גורמים כמו פעילות של דובר או הקצאת סרטון. המשתתפים מקבלים את השידורים הווירטואליים האלה, כך שהם רואים תמונה מורכבת של הכנס בלי לנהל שידורים נפרדים מכל משתתף אחר. ההפשטה הזו שמספקים מקורות הווידאו הווירטואליים חיונית להתאמת שיחות ועידה ב-WebRTC למספר גדול של משתתפים.
כדי לקבל אודיו, הלקוח צריך להציע שלושה תיאורי מדיה של אודיו בדיוק, וכך ליצור שלושה משדרים-מקבלים מקומיים של אודיו. כדי לקבל וידאו, הלקוח צריך להציע אחד עד שלושה תיאורי מדיה של וידאו, ולהגדיר את מספר משדרי הווידאו.
תופסים
לכל משדר-מקלט בבעלות הלקוח יש RtpReceiver ייעודי ו'טראק מדיה' ייעודי שמקבל את זרמי ה-RTP של האודיו מהשרתים של Meet.
לכל טראק יש מזהה ייחודי והוא מקבל זרם ייחודי משלו של חבילות RTP ממקור המדיה הספציפי הזה. לדוגמה, טראק א' יכול לקבל אודיו מ-production-1, בזמן שטראק ב' מקבל אודיו מ-production-2.
SSRCs
לכל חבילה של RTP יש ערך כותרת של Synchronization Source (SSRC) שמקשר אותה לטראק ספציפי.
סשנים של אודיו דרך Meet Media API משתמשים בשלושה מקורות מדיה נפרדים, לכל אחד מהם SSRC סטטי משלו. לאחר יצירתם, ערכי ה-SSRC האלה לא משתנים במהלך הסשן.
מקורות נתונים וירטואליים
ב-Meet Media API נעשה שימוש בשידורי מדיה וירטואליים. הם סטטיים במהלך הסשן, אבל המקור של החבילות עשוי להשתנות כדי לשקף את הפיד הכי רלוונטי. התנהגות של שידורי מדיה וירטואליים זהה לאודיו ולווידאו.
המקור שתרם (CSRC) בכותרות של מנות ה-RTP מזהה את המקור האמיתי של מנות ה-RTP. כשמשתתפים מצטרפים לשיחת ועידה ב-Meet, המערכת מקצה להם מזהה CSRC ייחודי. הערך הזה נשאר קבוע עד שהם יוצאים.
מאחר שמספר מזהי ה-SSRC נשאר קבוע במהלך הסשן של Meet Media API, אלה שלושת התרחישים האפשריים:
יש יותר משתתפים מאשר מקורות SSRC זמינים:
ב-Meet, המערכת משדרת את שלושת האנשים עם הקול הכי חזק בשלושת ה-SSRC. מאחר שכל זרם RTP נמצא ב-SSRC ייעודי משלו, אין ערבוב בין הזרמים.
איור 1. ב-Meet, המערכת מעבירה את שלושת האנשים עם הקול הכי חזק בשלושת ה-SSRC. אם אחד מהשידורים המקוריים בפגישה כבר לא נחשב לאחד מהשידורים הקולניים ביותר, מערכת Meet מחליפה את חבילות ה-RTP שמרכיבות את ה-SSRC לשידור הקולני ביותר.
איור 2. מערכת Meet מעבירה את חבילות ה-RTP לאדם החדש עם הקול הכי חזק. מספר המשתתפים הפעילים נמוך משלושת מזהי ה-SSRC של האודיו:
בתרחיש שבו יש יותר מפתחות SSRC מאשר שידורים בכנס, מערכת Meet ממפה את כל חבילות האודיו הזמינות למפתח SSRC ייחודי משלה. כל מזהי SSRC שלא בשימוש עדיין מוכנים וזמינים, אבל לא מועברות חבילות RTP.
איור 3. Meet ממפה את חבילות האודיו הזמינות ל-SSRC ייחודי משלו. מספר המשתתפים הפעילים שווה לשלושת מזהי ה-SSRC של האודיו:
בתרחיש שבו יש מספר שווה של משתתפים ומספר שווה של מזהי SSRC זמינים, המדיה של כל משתתף ממופה למזהה SSRC ייעודי. המיפויים האלה נשמרים כל עוד התרחיש הספציפי הזה נמשך.
איור 4. ב-Meet, כל קובץ מדיה של כל משתתף ממופה למזהה SSRC ייעודי.