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