זרמי מדיה וירטואליים, בהקשר של ועידות WebRTC, הם זרמי מדיה שנוצרים על ידי יחידת העברה סלקטיבית (SFU) כדי לצבור ולהפיץ מדיה מכמה משתתפים. בניגוד לזרמי מדיה ישירים בין עמיתים, שיוצרים רשת מורכבת של חיבורים בוועידות גדולות, זרמי מדיה וירטואליים מפשטים את הטופולוגיה. ה-SFU מקבל זרמי מדיה נפרדים מכל משתתף ומעביר באופן סלקטיבי את הזרמים הפעילים או הרלוונטיים למשתתפים אחרים, תוך ריבוב שלהם לקבוצה קטנה וקבועה של זרמי מדיה וירטואליים יוצאים.
הגישה הזו מצמצמת את מספר הזרמים הנכנסים בו-זמנית שכל משתתף צריך לטפל בהם, וכך מקטינה את דרישות העיבוד ורוחב הפס. כל זרם וירטואלי יכול להכיל מדיה ממשתתף אחד בכל פעם, והוא מותאם באופן דינמי על ידי SFU על סמך גורמים כמו פעילות הדובר או הקצאת סרטונים. המשתתפים מקבלים את הזרמים הווירטואליים האלה, ובעצם רואים תצוגה מורכבת של הכנס בלי הצורך לנהל זרמים נפרדים מכל משתתף אחר. ההפשטה הזו, שמתקבלת מזרמי מדיה וירטואליים, חיונית להרחבת שיחות ועידה ב-WebRTC למספר גדול של משתתפים.
כדי לקבל אודיו, הלקוח צריך להציע בדיוק שלושה תיאורים של מדיה עם אודיו, וכך ליצור שלושה משדרי אודיו מקומיים. כדי לקבל וידאו, הלקוח צריך להציע תיאור אחד עד שלושה של מדיה של וידאו, כדי לקבוע את מספר משדרי הווידאו.
תופסים
לכל משדר שבבעלות הלקוח יש RtpReceiver ייעודי ו'טראק מדיה' ייעודי שמקבל את זרמי ה-RTP של האודיו מהשרתים של Meet.
לכל טראק יש מזהה ייחודי והוא מקבל זרם נפרד של מנות RTP ממקור המדיה הספציפי הזה. לדוגמה, טראק א' יכול לקבל אודיו מproduction-1 וטראק ב' יכול לקבל אודיו מproduction-2.
SSRCs
לכל מנה (packet) של RTP יש ערך כותרת של מקור סנכרון (SSRC), שקושר אותה לטראק ספציפי.
בסשנים של אודיו דרך Meet Media API נעשה שימוש בשלושה מקורות מדיה נפרדים, שלכל אחד מהם יש SSRC סטטי משלו. אחרי שהערכים האלה נקבעים, הם לא משתנים במהלך הפעילות.
מקורות נתונים וירטואליים
Meet Media API משתמש בזרמי מדיה וירטואליים. הם קבועים לאורך הסשן, אבל המקור של החבילות עשוי להשתנות כדי לשקף את הפידים הרלוונטיים ביותר. התנהגות של זרמי מדיה וירטואליים זהה באודיו ובווידאו.
השדה Contributing Source (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. המיפוי של חבילות אודיו זמינות ל-SSRC ייחודי משלהן. מספר המשתתפים הפעילים שווה ל-3 מקורות ה-SSRC של האודיו:
בתרחיש שבו יש מספר שווה של משתתפים ומקורות SSRC זמינים, קובצי המדיה של כל משתתף ממופים למקור SSRC ייעודי. המיפויים האלה נשמרים כל עוד התרחיש הספציפי הזה נמשך.
איור 4. ב-Meet, קובצי המדיה של כל משתתף ממופים ל-SSRC ייעודי.