يتحدث LOLS IRL srtla القياسي المتوافق مع BELABOX، فيتصرف مستقبِلك الخاص تمامًا كما تتصرف مُرحِّلاتنا المستضافة. إليك ما يجب تشغيله، وأي المنافذ تهم، والخطأ الواحد الذي يمنع اتصال الجوّال من الوصول إلى جهازك.
لا يجب أن تستضيف أي شيء: مُرحِّلات LOLS Cloud المجانية موجودة كي يعمل الدمج من أول لحظة، أو يمكنك استضافة مستقبِلك والاعتماد على لا أحد. للاستضافة أسباب وجيهة. تريد أن يصل البث إلى بنية تتحكم بها، أو تريد جهازًا قريبًا منك فعليًا ليس لدينا مُرحِّل بجواره، أو لا تريد حدًا تفكر فيه، أو تفضّل ببساطة تشغيل أشيائك بنفسك. لا شيء في التطبيق مربوط بخوادمنا، فالتحويل تغيير اسم مضيف وليس أكثر.
الهاتف (wifi + شبكة الجوّال)
|
| srtla، UDP، مقبس واحد لكل شبكة
v
srtla_rec يستمع على منفذ UDP عام، ويعيد تجميع الاتصالات
|
| SRT عادي، UDP، على localhost
v
خادم الوسائط MediaMTX أو ما يعادله
|
+--> OBS، أو إعادة بث إلى Twitch / Kick / YouTube
قطعتان، ولكل منهما مهمة واحدة. srtla_rec، من مشروع BELABOX، هي الجزء الذي يفهم الدمج: كل اتصال يفتحه هاتفك يسجّل نفسه لديه ضمن مجموعة واحدة، وهو يحوّل تلك المجموعة إلى بث SRT عادي واحد. ثم يمرّر ذلك البث إلى مستمع SRT، وهناك يتسلم خادم الوسائط. MediaMTX هو الخيار المعتاد ويستطيع تسليم البث إلى OBS أو إعادة نشره أو تسجيله، لكن أي شيء يقبل SRT يصلح.
يجب أن يكون المستقبِل قابلًا للوصول من كل شبكة يبث عبرها هاتفك، وهذا عمليًا يعني عنوانًا عامًا. يكفي VPS صغير: هذا تمرير حزم لا تحويل ترميز، فالسرعة بالميغابت والمعالج المتواضع أهم بكثير من عدد الأنوية. ضعه قريبًا جغرافيًا من مكان بثك، للسبب نفسه الذي تختار به أقرب مُرحِّل: المسافة تأخير لا تستردّه، ويُدفع من جديد مع كل إعادة إرسال.
مستقبِل على شبكة LAN المنزلية، عند شيء مثل 192.168.1.50، يمكن الوصول إليه من Wi-Fi ومن لا شيء آخر. اتصال الجوّال لا يستطيع التوجيه إلى عنوان خاص، فلا يسجّل أبدًا وأنت لست مدموجًا، بل تبث عبر Wi-Fi بخطوات زائدة، وستعرض الإحصاءات اتصالًا واحدًا بدل اثنين.
إما الاستضافة على جهاز له عنوان عام، أو إعادة توجيه منفذ UDP في الراوتر إلى الجهاز على شبكتك المحلية وتوجيه التطبيق إلى العنوان العام للراوتر. اسم DNS ديناميكي يوفر عليك إعادة كتابته كلما تغيّر عنوانك.
| المنفذ | الغرض |
|---|---|
| UDP، منفذ srtla الخاص بك، وارد من الإنترنت | المنفذ الوحيد الذي يلمسه الهاتف. 5000 هو المتعارف عليه. يصل كل اتصال مدموج من عنوانه ومنفذه المصدر الخاص، فلا شيء يُفتح أو يُضبط لكل اتصال. |
| UDP، مستمع SRT الخاص بك، محلي | المكان الذي يمرّر إليه srtla_rec البث المعاد تجميعه. يستمع MediaMTX إلى SRT على 8890 افتراضيًا. لا يلزم كشف هذا للإنترنت إلا إن أردت أيضًا أن ينشر عليه عملاء SRT عاديون. |
| أيًا كان ما يقدّمه خادم الوسائط لديك | RTMP أو RTSP أو HLS أو WebRTC إلى OBS أو إلى مشاهد، وأمره كله لك وليس جزءًا من مسار الدمج. |
جدران الحماية ومجموعات الأمان السحابية وقواعد إعادة التوجيه في الراوتر كثيرًا ما تكون افتراضيًا على TCP. تسجيل srtla المرسل إلى قاعدة TCP فقط يختفي بلا أي خطأ في أي مكان، ويبدو مطابقًا لتعطل المستقبِل. إن رفض اتصال التسجيل، فافحص بروتوكول القاعدة قبل أي شيء آخر.
يمرّر srtla_rec stream id الخاص بـ SRT كما هو، فما يوضع في حقل Stream id بالتطبيق هو ما يتوقعه الخادم خلفه. مع MediaMTX هو صيغة النشر، أي مسار ومعه بيانات اعتماد اختيارية حين تكون المصادقة مفعّلة:
publish:mypath
publish:mypath:username:password
فعّل المصادقة إن كان المنفذ مفتوحًا للإنترنت. نقطة نشر بلا مصادقة على عنوان عام سيجدها في النهاية شخص غيرك.
srtla_rec.srtla_rec تسجيل اتصال لكل اتصال، كلها تحت مجموعة واحدة. اتصالان يعطيانك تسجيلين في المجموعة نفسها. إن لم ترَ إلا واحدًا فقط، فالشبكة الثانية لا تصل إلى المضيف: عنوان خاص، أو قاعدة جدار حماية على TCP فقط، أو VPN يعمل على الهاتف.هل توقفت عند خطوة، أو تريد عينًا ثانية على مستقبِل لا يقبل الاتصال الثاني؟ اسأل في Discord أو راسل support@lols.gg. أحضر المنطقة التي أنت فيها وما تعرضه طبقة الإحصاءات وما سجّله المستقبِل، وعادةً تنتهي المسألة في رسالتين.
ذو صلة: الدمج في خمس دقائق لجانب التطبيق وكيفية قراءة المؤشرات، واستخدام المُرحِّلات المجانية إن كنت تفضّل ألا تستضيف، وكل الأدلة.