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