في سياق مؤتمرات WebRTC، تشير "تدفقات الوسائط الافتراضية" إلى تدفقات الوسائط التي تنشئها وحدة إعادة التوجيه الانتقائي (SFU) لتجميع الوسائط وتوزيعها من عدة مشاركين. وعلى عكس بث وسائط الند للند المباشر الذي يؤدي إلى إنشاء شبكة معقّدة من الاتصالات في المؤتمرات الكبيرة، تعمل عمليات بث الوسائط الافتراضية على تبسيط البنية. يتلقّى SFU تدفقات وسائط فردية من كل مشارك ويعيد توجيه التدفقات النشطة أو ذات الصلة بشكل انتقائي إلى المشاركين الآخرين، مع دمجها في مجموعة أصغر وثابتة من تدفقات الوسائط الافتراضية الصادرة.
يقلّل هذا الأسلوب من عدد عمليات البث الواردة المتزامنة التي يحتاج كل مشارك إلى التعامل معها، ما يقلّل من متطلبات المعالجة ومعدل نقل البيانات. يمكن أن يتضمّن كل بث مباشر افتراضي محتوى وسائط من مشارك واحد في كل مرة، ويتم تعديله ديناميكيًا من خلال SFU استنادًا إلى عوامل مثل نشاط المتحدث أو تعيين الفيديو. يتلقّى المشاركون هذه الفيديوهات الافتراضية، ما يتيح لهم رؤية عرض مؤلَّف للاجتماع بدون الحاجة إلى إدارة فيديوهات فردية من كل مشارك آخر. هذه الطبقة المجردة التي توفّرها بث الوسائط الافتراضي ضرورية لتوسيع نطاق مؤتمرات WebRTC لتشمل عددًا كبيرًا من المشاركين.
لتلقّي الصوت، يجب أن يقدّم العميل عرضًا يتضمّن ثلاثة أوصاف لوسائط صوتية بالضبط، ما يؤدي إلى إنشاء ثلاث أجهزة إرسال واستقبال صوتية محلية. لتلقّي الفيديو، يجب أن يقدّم البرنامج من وصف واحد إلى ثلاثة أوصاف لوسائط الفيديو، ما يؤدي إلى إنشاء هذا العدد من أجهزة إرسال واستقبال الفيديو.
مستلمو الكرة
يحتوي كل جهاز إرسال واستقبال يملكه العميل على
RtpReceiver مخصّص و"مسار وسائط" مخصّص يتلقّى حِزم بروتوكول النقل في الوقت الفعلي (RTP) الصوتية من خوادم Meet.
يحتوي كل مسار على معرّف فريد ويتلقّى دفقًا مميزًا من حِزم بروتوكول النقل في الوقت الفعلي (RTP) من مصدر الوسائط المحدّد. على سبيل المثال، قد يتلقّى المقطع الصوتي أ الصوت من
production-1 بينما يتلقّى المقطع الصوتي ب الصوت من production-2.
SSRCs
تحتوي كل حزمة RTP على قيمة عنوان مصدر المزامنة (SSRC)، ما يربطها بمقطع صوتي أو فيديو معيّن.
تستخدم جلسات الصوت من خلال Meet Media API ثلاثة مصادر بيانات وسائط مميّزة، ولكل منها رقم SSRC ثابت خاص به. وبعد تحديد قيم SSRC، لا تتغير هذه القيم أبدًا طوال مدة الجلسة.
مصادر بيانات افتراضية
تستخدم واجهة Meet Media API Virtual Media Streams. تكون هذه الحزم ثابتة طوال الجلسة، ولكن قد يتغيّر مصدر الحزم ليعكس الخلاصات الأكثر صلة. تتصرّف "أحداث البث الافتراضية للوسائط" بالطريقة نفسها مع الصوت والفيديو.
يحدّد مصدر المساهمة (CSRC) في عناوين حزم RTP المصدر الحقيقي لحزم RTP. يخصّص Meet لكل مشارك في مكالمة جماعية معرّف مصدر مساهمة متزامن وفريد عند انضمامه إلى المكالمة. تبقى هذه القيمة ثابتة إلى أن يغادر المستخدم.
بما أنّ عدد مصادر SSRC يظل ثابتًا طوال جلسة Meet Media API، إليك السيناريوهات الثلاثة المحتملة:
عدد المشاركين أكبر من عدد جلسات الاستماع المباشرة المتاحة:
يرسل Meet أصوات ثلاثة أشخاص من بين المشاركين في الاجتماع، وهم الأشخاص الذين يتحدثون بصوت أعلى، وذلك عبر ثلاثة مصادر SSRC. بما أنّ كل مجموعة بث RTP لها رقم SSRC مخصّص، لا يحدث أي تداخل بين مجموعات البث.
الشكل 1. يرسل Meet أصوات ثلاثة أشخاص من بين الأعلى صوتًا في جميع قنوات SSRC الثلاث. إذا لم يعُد أي من البث الأصلي في الاجتماع من بين البث الأكثر ارتفاعًا في مستوى الصوت، سيغيّر Meet حِزم بروتوكول النقل في الوقت الفعلي (RTP) التي تشكّل معرّف مصدر المزامنة (SSRC) إلى البث الأكثر ارتفاعًا في مستوى الصوت.
الشكل 2. يبدّل Meet حِزم بروتوكول النقل في الوقت الفعلي (RTP) إلى الشخص الجديد الذي يتحدث بصوت أعلى. عدد المشاركين النشطين أقل من ثلاثة مصادر متزامنة لتقارير المصادر الذاتية:
في حال توفّر عدد من أرقام تعريف مصدر البث المتزامن (SSRC) أكبر من عدد عمليات البث في الاجتماع، يربط Meet أي حِزم صوتية متاحة برقم تعريف مصدر البث المتزامن (SSRC) الفريد الخاص به. تظل أي أرقام تعريف مصدر المزامنة غير مستخدَمة جاهزة ومتوفّرة، ولكن لا يتم إرسال أي حِزم RTP.
الشكل 3. تعيّن "خرائط الاجتماع" حِزم الصوت المتوفّرة إلى رقم تعريف مصدر المزامنة (SSRC) الفريد الخاص بها. عدد المشاركين النشطين يساوي ثلاثة مصادر SSRC صوتية:
في سيناريو المشاركين المتساوين وSSRC المتاحة، يتم ربط وسائط كل مشارك بـ SSRC مخصّصة. وتظل عمليات الربط هذه سارية طالما استمر هذا السيناريو المحدّد.
الشكل 4. تربط خدمة Meet وسائط كل مشارك بمعرّف SSRC مخصّص.