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