זרמי מדיה וירטואליים, בהקשר של ועידות 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 ייחודי משלו כשהוא מצטרף. הערך הזה נשאר קבוע עד שהמשתמשים יוצאים.
מכיוון שמספר ה-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 ייעודי.