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