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