🤾🏾 🌄 🧝🏾 HighLoad ++ ، Mikhail Raichenko (ManyChat): بدون السحر تقريبًا ، أو مدى سهولة توزيع دفق الفيديو عبر terabit 🏵️ 🙍🏾 🚷

سيعقد مؤتمر HighLoad ++ التالي يومي 6 و 7 أبريل 2020 في سان بطرسبرغ. التفاصيل والتذاكر هنا . HighLoad ++ موسكو 2018. قاعة "دلهي + كالكوتا". 8 نوفمبر ، 2 مساءً الملخصات والعرض .

أنا أعمل في فريق فكونتاكتي وأعمل على تطوير نظام بث فيديو.
في هذا التقرير ، سوف أشارك ميزات تطوير الواجهة الخلفية ، وكيف تطور نظامنا ، والحلول التقنية التي توصلنا إليها: 

كيف قمنا ببث الفيديو الخلفي ، وعملية التطور كما هي ؛
تأثير الأعمال والمتطلبات التشغيلية على الهندسة المعمارية ؛
سيفشل "انتظر" و "حاول مرة أخرى" ؛
كيفية تعقيد أبسط المهام بعدد المستخدمين ؛
كيفية تقليل الكمون بدون UDP ؛
نجري اختبارات الضغط مرتين في اليوم ، أو ما ساعدنا فيه كلوفر.

Mikhail Raichenko (فيما يلي - MR): - رحلة صغيرة. سأخبرك عن الأشخاص الذين يبثوننا ، وعن البث المباشر (المباشر) ، وعن الأنظمة الأساسية التي نستقبلها ، والتي نوزعها. في النهاية ، سأتحدث عن الهندسة الحية الحالية ، عن حدودها وقدراتها ، وكذلك كيف نجت الهندسة الحالية من تأثير مثل "البرسيم".

حول البث المباشر. تقرير مخطط

أولاً ، سأتحدث قليلاً عن البث المباشر واللاعبين أنفسهم ، وإرسال محتوى فيديو نعرضه لمشاهدين آخرين.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

تبدو جميع خدمات البث شيئًا مثل هذا:

لدينا بعض الدفق ، يرسل دفق RTMP إلينا ، ونظهر للجمهور - لا شيء مفاجئ ، لا شيء خارق.

من أين يأتي دفق الفيديو؟ مصدر مهم لحركة المرور بالنسبة لنا هو تطبيق الهاتف المحمول VKlife. ما الجيد فيه؟ في ذلك ، يمكننا التحكم بشكل كامل في كيفية ترميز الفيديو. يمكننا إجراء العديد من التحسينات من جانب العميل ، بحيث نعرضها لاحقًا ، مع الحد الأدنى من التأخير ، لمشاهدينا.

من السلبيات: تعمل تطبيقات الهاتف المحمول على قمة الشبكات. يمكن أن يكون الجيل الثالث 3G ... على أي حال ، غالبًا ما تكون شبكات الهاتف المحمول هي التي تقدم بعض التأخيرات - تحتاج أيضًا إلى تخزين البيانات مؤقتًا على جانب التطبيق ، بحيث يعمل الدفق بسلاسة قدر الإمكان.

المصدر الثاني هو أجهزة البث مع OBS أو Wirecast أو أولئك الذين يجرون من تطبيقات سطح المكتب الأخرى. هذا جمهور كبير إلى حد ما. في بعض الأحيان تكون هذه ندوات ، وأحيانًا - تيارات الألعاب (هناك الكثير منها بشكل خاص من هذه التطبيقات). من الإيجابي: هناك عدد قليل من هذه التطبيقات ، يمكننا تقديم توصيات ضبط جيدة لأجهزة البث لدينا. ولكن في نفس الوقت ، هناك الكثير من الإعدادات ولا ترسل الدفق الذي نريده تمامًا.

الفئة الثالثة هي دفق RTMP من خوادم الوسائط. يمكن أن تكون هذه خوادم وسائط صغيرة جدًا ، أي تنسيق منزلي: يقوم شخص بدفق منظر للشارع أو أي شيء آخر. أو عمليات بث جادة للغاية من شركائنا: يمكن أن يكون هناك أي شيء ، لا يوجد الكثير من هذه التدفقات ، ولكنها في الأساس مهمة جدًا بالنسبة لنا.

من يشاهد؟

مرة أخرى ، هذا تطبيق محمول - كل شيء واضح هنا. أكبر مشكلة هي الكمون في الشبكة. من المحترفين: يمكننا تخصيص المشغل - إنه ملائم لنا ، جيد ، ولكن ليس في كل مكان اتضح أنه 100٪.

مشغل الويب في vk.com. هنا أيضًا ، كل شيء بسيط - إنه مشغل ويب عادي يمكنك فتحه لمشاهدته. جمهور كبير بما فيه الكفاية على vk.com ، الكثير من المشاهدين على البث. بعض عمليات البث معلقة في قسم "الفيديو" - يمكن أن يكون هناك عشرات الآلاف (في بعض الأحيان بدون أي علاقات عامة) ، خاصة إذا كان هذا محتوى مثيرًا للاهتمام.

وفقًا لذلك ، تكون القنوات كبيرة بما يكفي للمشاهدين الذين يجلسون على مشغل الويب. لذلك ، هناك الكثير من حركة المرور ، بما في ذلك البث واحد.

والثالث هو مشغل الويب فكونتاكتي على بعض مواقع الطرف الثالث. يمكنك بدء بث كل ما تريد ، وتعليق مشغل ويب فكونتاكتي على موقع الويب الخاص بك. يمكنك أن تصبح شريكًا لنا إذا كان لديك محتوى مثير للاهتمام: يمكنك تعليقه بنفسك ، يمكنك تعليقه معنا - كما يحلو لك. يمكنك تنظيم عمليات البث الخاصة بك بهذه الطريقة ، وسيعمل كل شيء.

مقارنة مع مكالمات الفيديو

في مكالمات الفيديو ، سيتم الصفح عن بعض تشويه الصورة. مكالمات الفيديو أبسط: يمكننا أن نحلل الصورة بشكل ملحوظ ، ولكن في نفس الوقت يجب أن نحافظ على زمن وصول جيد للغاية. مع تأخير طويل ، سيكون من المستحيل استخدام الخدمة على الإطلاق.

في البث بهذا المعنى ، يكون الأمر عكس ذلك تمامًا: يجب أن نحافظ على جودة صورة عالية ، ولكن في الوقت نفسه يمكننا زيادة وقت الاستجابة بسبب العديد من العوامل. على سبيل المثال ، يقوم اللاعب بتخزين تدفقه بطريقة أو بأخرى (يمكن أن يكون ثانية ، واثنان للتغلب على تدهور الشبكة ، على سبيل المثال) ، لذلك لا يوجد تأخير ثاني ، ميلي ثانية في معظم الحالات. يمكنك السعي لتحقيق ذلك ، ولكن الطعام ليس شرطًا أساسيًا.

مع الفيديو العادي ، فإن الوضع هو عكس ذلك تمامًا. نحن بحاجة إلى نوعية جيدة للغاية. في نفس الوقت ، من المستحسن تقليل حجم الفيديو ، ونسبة البت والجودة ، بحيث مع الحد الأدنى من التدفق ، يقدم أفضل حل. من المحترفين: نحن لسنا محددين بالوقت: في وقت تنزيل الفيديو ، لدينا الوقت الكافي لتحسين الفيديو ، ومعرفة كيفية ضغطه بأفضل طريقة ، وفعل شيء ما ، وسحبه إلى ذاكرة التخزين المؤقت ، إذا لزم الأمر - بشكل عام ، كل شيء يكفي حسنا.

في الحياة ، الوضع مرة أخرى هو عكس ذلك: ليس لدينا سوى وقت قليل جدًا لتحويل الشفرة. في الوقت نفسه ، هناك فرص قليلة ، ولكن لا توجد توقعات للبث. سيغفر لنا الجمهور إذا كان لدينا دعم أو الجودة ليست جيدة للغاية.

الإصدار الأول للغاية

إنه أمر متوقع تمامًا: في

الواقع ، الأمر مختلف قليلاً:

"Streamer - خادم الوسائط - مستوى ذاكرة التخزين المؤقت - المشاهدون". من حيث المبدأ ، يسمح لك هذا الإصدار بالقياس بقوة. أود أن أقول أنه يجب أن يتحمل بالفعل عشرات الآلاف من المتفرجين. لها عيوب أخرى ...

على سبيل المثال ، إذا نظرت إلى هذه الدائرة (الشريحة السابقة) ، يمكنك أن ترى أنها ليست متسامحة مع الخطأ. يجب علينا التخمين مع خادم الوسائط من أجل تحقيق التوازن بين الجمهور بشكل جيد. لا يمكننا تعليق العديد من ذاكرة التخزين المؤقت على كل خادم - فهي ببساطة مكلفة. لذلك ، نظرنا ، أدركنا أنه كان بسيطًا وواضحًا ، كانت هناك بعض الاحتمالات للتوسع ، ولكن من الواضح أن هناك شيئًا مفقودًا ... وبدأنا في صياغة المتطلبات.

متطلبات البنية التحتية

ما هو المهم؟

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
التوصيل للمناطق. أيضا نقطة مهمة! من الغباء سحب كل محتوى الفيديو من بطرسبورغ أو موسكو إلى نوع من نوفوسيبيرسك أو يكاترينبورغ أو حتى من سانت بطرسبرغ إلى موسكو. هذا ليس جيدًا جدًا ، لأن تأخير الشبكة سيكون طويلًا - سيكون هناك تأخيرات ، كل شيء سيتأخر ، وهذا ليس جيدًا. لذلك ، يجب أن تأخذ بنيتنا التحتية بعين الاعتبار أننا نقدم محتوى إلى المناطق.
راحة التشغيل والمراقبة. خاصية مهمة. نظرًا لأن النظام كبير ، فهناك العديد من المشاهدين ، فمن المهم إرسال تنبيهات للمسؤولين في الوقت المناسب في حالة حدوث أي مشاكل ، بما في ذلك مراقبة المنتج والمقاييس الفنية.

كيف تبدو البنية التحتية للبث الآن؟

ونتيجة لذلك ، وصلنا إلى بنية تحتية بسيطة إلى حد ما ولكنها فعالة ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

ومن المثير للاهتمام؟ موازنة! في هذا المخطط ، نختار الموازنة ، ونحاول إرسال المشاهدين الذين يشاهدون نفس الدفق إلى كل خادم حافة. موقع ذاكرة التخزين المؤقت مهم جدًا هنا ، لأنه يمكن أن يكون هناك العديد من خوادم الحافة ؛ وإذا لم نلاحظ كلاً من المؤقت والموقع المؤقت لذاكرة التخزين المؤقت من وجهة نظر الدفق ، فسوف نحمل الطبقة الداخلية فوق طاقتها. لا نود ذلك أيضا.

لذلك ، فإننا نوازن بالطريقة التالية: نختار خادمًا مميزًا للمنطقة التي نرسل إليها المشاهدين ، ونرسل حتى نبدأ في فهم حدوث بعض التعبئة ويجب إرسالها إلى خادم آخر. الدائرة بسيطة وتعمل بشكل موثوق للغاية. بطبيعة الحال ، بالنسبة إلى التدفقات المختلفة ، تختار تسلسلًا مختلفًا من الخوادم المتطورة (التسلسل الذي نرسل فيه المتفرجين). وفقًا لذلك ، تعمل الموازنة ببساطة شديدة.

كما نعطي العميل ارتباطًا بخادم حافة متاح. يتم ذلك بحيث في حالة فشل خادم الحافة ، يمكننا إعادة توجيه العارض إلى آخر. أي ، عندما يشاهد المشاهد البث ، يتلقى رابطًا للخادم المطلوب مرة كل بضع ثوانٍ. إذا كان يفهم أن الرابط يجب أن يكون مختلفًا ، فإنه يقوم بالتبديل (تبديل المشغل) ويستمر في مشاهدة البث من خادم آخر.

دور آخر مهم للخوادم المتطورة هو حماية المحتوى. كل حماية المحتوى تحدث بشكل أساسي هناك. لدينا وحدة nginx الخاصة بنا لهذا الغرض. يشبه إلى حد ما ارتباط الأمان.

التحجيم والتوازن

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

أحد البروتوكولات الرئيسية التي كانت لدينا كانت RTMP (ليس فقط للإدخال ، ولكن أيضًا لتوزيع المحتوى). الميزة الرئيسية هي الكمون المنخفض. يمكن أن تكون نصف ثانية ، ثانية ، ثانيتين. في الواقع ، تنتهي الفوائد عند

هذا الحد ... من الصعب مراقبة بروتوكول البث هذا - إنه مغلق بمعنى ما ، على الرغم من حقيقة أن هناك مواصفات. لم يعد مشغل الفلاش يعمل (في الواقع ، إنه "كل شيء بالفعل"). تحتاج إلى دعم على مستوى CDN - أنت بحاجة إلى وحدات nginx خاصة أو برامجك الخاصة لنقل الدفق بشكل طبيعي. هناك أيضًا بعض الصعوبات مع عملاء الجوّال. من خارج الصندوق في الأجهزة المحمولة ، يتم دعمه بشكل سيء للغاية - هناك حاجة إلى تحسينات خاصة ، وكل هذا صعب للغاية.
البروتوكول الثاني الذي استخدمناه هو HLS. يبدو الأمر بسيطًا للغاية: إنه ملف نصي ، يسمى ملف الفهرس. يحتوي على ارتباطات لفهرسة الملفات بأذونات مختلفة ، وتحتوي الملفات نفسها على روابط إلى مقاطع الوسائط.

كيف حاله جيد؟ إنه بسيط للغاية ، على الرغم من كونه قديمًا بعض الشيء. يسمح لك باستخدام CDN ، أي أنك تحتاج فقط إلى nginx لتوزيع بروتوكول HLS. يمكن فهمه من حيث المراقبة.

هنا مزاياها:

سهولة التشغيل - nginx كخادم وكيل ؛
من السهل مراقبة المقاييس وأخذها (يكفي أن تراقب ما يشبه ما تراقبه على موقع الويب الخاص بك) ؛
الآن هذا البروتوكول هو البروتوكول الرئيسي لتسليم المحتوى.

ناقص كبير:

الكمون العالي.

يتم تضمين وقت استجابة HLS في البروتوكول نفسه ؛ نظرًا لأنه يلزم وقت طويل من التخزين المؤقت ، يضطر المشغل إلى الانتظار على الأقل عند تحميل قطعة واحدة ، ولكن بطريقة جيدة ، يجب عليه الانتظار حتى يتم تحميل قطعتين (قطعتان من الوسائط) ، وإلا في حالة التأخير ، سيحمل العميل تحميل المشغل ، وهذا لا يؤثر بشكل جيد تجربة المستخدم.

النقطة الثانية التي تعطي تأخيرًا في HLS هي التخزين المؤقت. يتم تخزين قائمة التشغيل مؤقتًا على الطبقة الداخلية وعلى خوادم الحافة. حتى لو قمنا بالتخزين المؤقت ، نسبيًا ، لمدة ثانية أو نصف ثانية ، فهذا يزيد تقريبًا عن 2-3 ثوانٍ من التأخير. في المجموع ، يتبين من 12 إلى 18 ثانية - هذا ليس لطيفًا جدًا ، من الواضح أنه أفضل.

تحسين HLS

بهذه الأفكار ، بدأنا في تحسين HLS. لقد قمنا بتحسينها بطريقة بسيطة إلى حد ما: دعنا نعطي الجزء الأخير من الوسائط غير المسجل من قائمة التشغيل قبل ذلك بقليل. أي بمجرد أن بدأنا كتابة آخر مقطع إعلامي ، نعلن عنه على الفور في قائمة التشغيل. ماذا يحدث في هذه اللحظة؟ ..

يتم تقليل وقت التخزين المؤقت في اللاعبين. يعتقد اللاعب أنه قد قام بتنزيل كل شيء بالفعل ، ويبدأ في تنزيل الأجزاء المطلوبة بهدوء. بهذه الطريقة "نغش" اللاعب بهذه الطريقة ، لكن إذا راقبنا "الفولاذ" (الأحمال في المشغل) جيدًا ، فهذا لا يخيفنا - يمكننا التوقف عن إعطاء الجزء مقدمًا وسيعود كل شيء إلى طبيعته.

النقطة الثانية: نربح حوالي 5-8 ثواني. من أين أتوا؟ تستغرق هذه الفترة من 2 إلى 4 ثوانٍ لكل مقطع ، بالإضافة إلى وقت تخزين قائمة التشغيل في ذاكرة التخزين المؤقت (هذه هي 2-3 ثوانٍ أخرى). علاوة على ذلك ، فإن تأخيرنا يتناقص بشكل كبير. يتم تقليل التأخير من 12-15 ثانية إلى 5-7.

ما هو الجيد الآخر في هذا النهج؟ إنه مجاني بالفعل! نحتاج فقط للتحقق مما إذا كان اللاعبون متوافقون مع هذا النهج. تلك غير المتوافقة ، نرسل إلى عناوين URL القديمة ، ونرسل مشغلات متوافقة إلى عناوين URL الجديدة. لسنا بحاجة إلى ترقية العملاء القدامى الذين يدعمون ذلك ، وهو أمر مهم أيضًا. نحن في الواقع لا نحتاج إلى التعديل ، وإطلاق سراح اللاعبين في الأجهزة المحمولة. لسنا بحاجة لتطوير مشغل ويب. تبدو جيدة بما يكفي!

من السلبيات - الحاجة إلى التحكم في دفق الفيديو الوارد. في حالة عميل الهاتف المحمول ، يمكننا القيام بذلك بسهولة تامة (عندما يأتي الدفق من عميل الهاتف المحمول) ، أو التحويل دون فشل ، حيث يجب أن يعرف المشغل الوقت المستغرق لشريحة وسائط واحدة. وبما أننا نعلن ذلك قبل تسجيله فعليًا ، نحتاج إلى معرفة مقدار الوقت الذي سيستغرقه عند تسجيله.

مقاييس الجودة

وهكذا ، قمنا بتحسين HLS. أريد الآن أن أقول كيف نراقب ومقاييس الجودة التي نطلقها:

أحد المقاييس الرئيسية للجودة هو وقت البدء. من الناحية المثالية ، يكون هذا عند التمرير عبر عميل الهاتف المحمول قبل البث ، والضغط على الزر ، ويبدأ على الفور. سيكون مثاليًا إذا بدأ قبل الضغط على الزر ، ولكن للأسف ، فقط عند الضغط.
النقطة الثانية هي تأخر الإشارة. نعتقد أن بضع ثوانٍ جيدة جدًا ، و 10 ثوانٍ مقبولة ، و 20-30 ثانية سيئة جدًا. لماذا هو مهم؟ على سبيل المثال ، بالنسبة للحفلات الموسيقية وبعض الأحداث العامة ، يعد هذا مقياسًا غير مهم على الإطلاق ، ولا توجد تعليقات ؛ نعرض الدفق فقط - من الأفضل ألا تتأخر عن تأخير بسيط. وبالنسبة لتيار حيث يجري نوع من المؤتمر أو يخبر فيه شخص ما شيئًا ويسألونه أسئلة ، فإن هذا يبدأ مهمًا ، لأنهم يطرحون الكثير من الأسئلة في التعليقات وأريد أن يحصل الجمهور على تعليقات في أقرب وقت ممكن.

مقياس مهم آخر هو التخزين المؤقت والتأخر. في الواقع ، هذا المقياس مهم ليس فقط من وجهة نظر العميل والجودة ، ولكن من وجهة نظر إلى أي مدى يمكننا "تمديد" تسليم HLS ، إلى أي مدى يمكننا ضغط البيانات من خوادمنا. لذلك ، نحن نراقب متوسط وقت التخزين المؤقت في اللاعبين و "الفولاذ".

إن اختيار الجودة في اللاعبين أمر مفهوم: التغييرات غير المتوقعة مزعجة دائمًا.

وبالتالي ، يعد هذا أيضًا مقياسًا مهمًا.

المراقبة

لدينا العديد من مقاييس المراقبة ، ولكن هنا اخترت المقاييس التي تعمل دائمًا إذا حدث خطأ ما:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

سأخبرك الآن كيف تعاملنا مع تطبيق مثل "المشغل" عندما استخدمنا بنيتنا التحتية لبث دفق فيديو مع أسئلة وأجوبة.

Clover هو اختبار عبر الإنترنت. يقول المضيف شيئًا ، يسأل: تسقط الأسئلة - تجيب. 12 سؤالا ، 10 دقائق من المباراة ، في النهاية - نوع من الجوائز. ما هو التعقيد؟ هذا نمو!

على اليمين يوجد هذا الرسم البياني:

الذروة [على الرسم البياني] هي الحمل على الخوادم من حيث واجهة برمجة التطبيقات في وقت بدء "Clover". ما تبقى من الوقت هو التدفق المعتاد للبث. لا يمكن مساواة ذلك بعدد المشاهدين. ربما هذا هو عدد الطلبات والحمل.

الأمر صعب: في 5 دقائق وصل إلينا مليون متفرج في ذروة. يبدأون بمشاهدة البث ، والتسجيل ، وتنفيذ نوع من العمل ، وطلب فيديو ... يبدو أنها لعبة بسيطة للغاية ، ولكن هذا يحدث في فترة زمنية قصيرة جدًا (جميع الإجراءات ، بما في ذلك اللعبة النهائية) - وهذا يعطي حمولة عالية إلى حد ما.

ما الأسئلة والتحديات التي واجهناها؟

نمو سريع. في بعض الأحيان كانت النسبة + 50٪ في الأسبوع. على سبيل المثال ، إذا كان لديك 200 ألف شخص يوم الأربعاء ، فربما يكون هناك بالفعل 300 يوم السبت أو الأحد. هذا كثير! تبدأ المشاكل في الظهور التي لم تكن مرئية من قبل.
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

الهندسة المعمارية تناسبنا تمامًا ، ويمكنني أن أوصي بها بأمان. ستبقى HLS معنا البروتوكول الرئيسي لموقع الويب على الأقل وبروتوكول النسخ الاحتياطي على الأقل لكل شيء آخر. ربما سننتقل إلى MPEG-DASH.

RTMP مهجور. على الرغم من حقيقة أنه يعطي تأخيرًا أقل ، قررنا أن نقوم بضبط HLS. ربما تفكر في مركبات التسليم الأخرى ، بما في ذلك DASH كبديل.

سنحسن التوازن القادم. كما نرغب في إجراء فشل سلس للموازنة الواردة ، بحيث يكون التبديل غير مرئي تمامًا في حالة وجود مشاكل على أحد خوادم الوسائط للعميل.

ربما سنقوم بتطوير أنظمة التسليم من خوادم الحافة إلى العميل. على الأرجح ، سيكون نوعًا من UDP. أيهما - نفكر الآن ونحن في مرحلة البحث.

في الواقع ، هذا كل شيء. شكرا للجميع!

الأسئلة

سؤال من الجمهور (فيما يلي - أ): - شكرا جزيلا على التقرير! فقط المتحدث من Odnoklassniki تحدث ، وقال إنه كان عليهم إعادة كتابة جهاز البث ، التشفير ، التشفير ... هل تستخدم مثل هذه الحلول أو تستخدم تلك الموجودة في السوق (مثل Harmonic ، إلخ)؟

MR: - لدينا الآن حلول الطرف الثالث الدوارة. من الحلول المفتوحة المصدر التي استخدمناها ، كان لدينا nginx ، وحدة RTMP (لفترة طويلة). من ناحية ، لقد أسعدنا لأنه عمل ، بسيط للغاية. قاتلنا لفترة طويلة جدا حتى يعمل بشكل مستقر. الآن ينتقل من Nginx-RTMP إلى حله الخاص. نحن نفكر مع محول الآن. كما تم إعادة كتابة جهاز الاستقبال ، وهو الجزء المستقبل ، من Nginx-RTMP إلى حله.

و:- أردت أن أطرح سؤالًا حول تشريح RTMP على HLS ، ولكن كما أفهمها ، لقد أجبت بالفعل ... أخبرني ، هل حلولك مفتوحة المصدر؟

MR: - نحن نفكر في إطلاقه في مصدر مفتوح. نرغب في الإفراج عنه ، ولكن السؤال هو وقت الإصدار في المصدر المفتوح. فقط ضع المصدر على الإنترنت - هذا لا يكفي. تحتاج إلى التفكير ، وجعل بعض الأمثلة على النشر. ولأي غرض تسأل؟ تريد استخدامها؟

ج: - لأنني جئت أيضًا عبر Nginx-RTMP! إنه ، بعبارة ملطفة ، غير مدعوم لفترة طويلة جدًا. المؤلف لا يجيب حتى على أسئلة خاصة ...

MR: - إذا أردت ، يمكنك الكتابة إلى مكتب البريد. يعطى للاستخدام الخاص؟ أننا يمكن أن نتفق. نحن حقا نخطط لفتحه.

و:- قلت أيضًا أنه يمكنك الانتقال من HLS إلى DASH. HLS لا تناسب؟

MR: - هذا سؤال حول ما نستطيع ، أو ربما لا. يعتمد هذا إلى حد كبير على ما سنأتي إليه من حيث البحث عن طرق التسليم البديلة (أي UDP). إذا وجدنا شيئًا جيدًا "تمامًا" ، فربما لن نلمس HLS. إذا بدا أن MPEG-DASH أكثر راحة - فربما سننقله. لا يبدو الأمر صعبًا للغاية ، لكننا لسنا متأكدين مما إذا كان ذلك ضروريًا أم لا. من الواضح أن المزامنة بين التدفقات ، بين الصفات وأشياء أخرى أفضل هناك. هناك إيجابيات.

ج: - بخصوص التنبيهات. لقد تحدثت عن حقيقة أنه إذا توقفت التدفقات عن التدفق ، فهذا على الفور تنبيه. ولم تلتقط شيئًا مستقلاً عنك: سقط مقدم الخدمة ، سقط ميجافون ، وتوقف الناس عن البث؟ ..

MR:- دعنا نقول فقط أن شيئًا مستقلاً عنا هو في الأساس جميع أنواع العطلات وما إلى ذلك. نعم لقد فعلوا. حسنًا ، لقد فعلوا ، نعم. نظر المسؤولون - اليوم هو العطلات ، وبقية الخصائص على ما يرام - هدأوا.

ج: - وحول التحجيم. على أي مستوى يتدرج؟ على سبيل المثال ، طلبت دفقًا من الهاتف - هل سأتلقى على الفور رابطًا معينًا مع خادم الرماد الصحيح؟

MR: - سيأتي رابط على الفور ، وإذا لزم الأمر ، سيتم تبديلك (إذا كانت هناك مشاكل على خادم معين).

ج: - من سيتحول؟

MR: - مشغل محمول أو مشغل ويب.

ج: - سيعيد تشغيل التيار أم ماذا؟

MR: - سيصل إليه رابط جديد حيث يجب أن يبدأ البث المباشر. سيذهب إلى هناك ويطلب من التيار.

و:- على أي مستوى لديك مخابئ؟ وقوائم التشغيل ، والقطع ، أم مجرد ذلك؟ ..

MR: - وقوائم التشغيل ، والقطع! يتم تخزين ذاكرة التخزين المؤقت بشكل مختلف قليلاً ، سواء من حيث الوقت أو من حيث عودة الوقت ، ولكننا نقوم بتخزين كليهما.

ج: - فيما يتعلق بإنشاء خوادم الرماد؟ هل كان لديك مثل هذا الموقف الذي تشاهد فيه 2 مليون مشاهد في بث واحد ، وليس لديك الوقت لشيء ما وتلتقط بسرعة بعض خادم الرماد؟ أو هل ترفع كل شيء مقدمًا بهامش؟

السيد:- ربما لم يكن هذا. أولاً ، المخزون دائمًا صغير أو كبير - لا يهم. ثانيًا ، لا يحدث أن يصبح البث فجأة شائعًا للغاية. يمكننا التنبؤ بعدد المشاهدين بشكل جيد. في الأساس ، من أجل الحصول على الكثير من الناس ، يجب علينا بذل جهد. وفقًا لذلك ، يمكننا ضبط عدد المشاهدين للبث ، اعتمادًا على الجهود المبذولة.

ج: - قلت إنك تقيس التأخيرات الآلية من جانب اللاعب. كيف؟

MR: - بسيط للغاية. في القطع (في قطاعات الوسائط) لدينا طابع زمني ، باسم شريحة الوسائط - في المشغل نعيده فقط. إذا لم يكن صراحة على الإطلاق ، يعود.

ج: - أتذكر أنني كنت أحاول تشغيل تقنية pending على WebRTC. لماذا رفضت؟

السيد:"لا أستطيع الإجابة على هذا السؤال لك - لقد حدث ذلك بدوني". لا أستطيع أن أقول لماذا حاولت ذلك ولا أستطيع أن أقول لماذا رفضت.

ج: - فيما يتعلق بجهاز الاستقبال وخادم الوسائط. كما أفهمها ، كنت تستخدم Nginx-RTMP ، الآن هناك وهناك لديك حلول ذاتية. في الواقع ، يعد هذا أحد خوادم الوسائط التي تقوم بوكل خوادم الوسائط الأخرى ، وهي موجودة بالفعل في ذاكرة التخزين المؤقت وعلى الحافة.

MR: - إذن ، ليس حقًا. هذا حل قائم بذاته ، ولكنه مختلف من حيث خادم الوسائط ومن حيث جهاز الاستقبال. Nginx-RTMP - كان نوعًا من الحاصدة يمكنه القيام بكليهما. لدينا الداخلية للمستقبل وخادم الوسائط مختلفة للغاية - سواء من خلال التعليمات البرمجية وفي جميع أنحاء. الشيء الوحيد الذي يوحدهم هو معالجة RTMP.

ج: - فيما يتعلق بالتوازن بين الحواف. كيف يحدث هذا؟

MR: - نقوم بقياس حركة المرور ، وإرسالها إلى الخادم المطلوب. لم أفهم السؤال قليلاً ...

ج: - سأشرح: يطلب المستخدم قائمة تشغيل من خلال المشغل - يعيد المسارات النسبية للمظاهر والقطع أو المسارات المطلقة ، على سبيل المثال ، عن طريق IP أو المجال؟ ..

MR: - المسارات نسبية.

ج: أي أنه لا يوجد توازن عند عرض دفق بواسطة مستخدم واحد؟

MR: - يحدث ذلك. صعب بما فيه الكفاية. يمكننا استخدام إعادة التوجيه 301st عند التحميل الزائد على الخادم. إذا رأينا أن كل شيء سيئ تمامًا هناك ، فيمكننا إرساله إلى خادم آخر للمقاطع.

ج: - ولكن يجب أن يتم إدخالها في منطق اللاعب؟

السيد:- لا ، لا يجب خياطة هذا الجزء فقط. إعادة توجيه 301st! ببساطة ، يجب أن يتمكن اللاعب من الخروج من الرابط 301. يمكننا إرسالها إلى خادم آخر من جانب الخادم في وقت التحميل الزائد.

ج: أي يسأل الخادم ، ويعطيه الخادم له؟

السيد: - نعم. هذا ليس جيدًا جدًا ، لذلك ، يتم استخدام منطق اللاعب لإعادة تغريد الروابط إلى حالة فشل أحد الخوادم - وهذا موجود بالفعل في منطق اللاعب.

ج: - ولم تحاول العمل ليس بشكل نسبي ، ولكن بطرق مطلقة: عندما تطلب من اللاعب القيام ببعض السحر ، اكتشف أين توجد الموارد وأين لا ، وقم بالفعل بتقديم قوائم التشغيل التي تشير إلى خادم معين؟

السيد:- في الواقع ، يبدو وكأنه حل فعال. إذا كنت قد أتيت بعد ذلك ، لكنا كنا نزن كلاهما! لكن الحل الحالي يعمل أيضًا ، لذلك لا أريد حقًا القفز من واحد إلى آخر ، على الرغم من أن هذا ربما يبدو أيضًا كحل ناجح.

ج: - أخبرني ، هل هذا ودي بطريقة ما مع الإرسال المتعدد؟ HLS ، كما أفهمها ، لا شيء على الإطلاق ...

MR: - في التنفيذ الحالي ، ربما لا يوجد لدينا شيء في النظام مع البث المتعدد في البث المباشر. نحن لا ندرج مفهوم الإرسال المتعدد هناك. ربما في مكان ما في أعماق سحر الإدارة ، يوجد شيء داخل الشبكة ، ولكنه مخفي عن الجميع على الإطلاق ولا أحد يعرف ...

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك VPS القائم على السحابة للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة عن VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟

HighLoad ++ ، Mikhail Raichenko (ManyChat): بدون السحر تقريبًا ، أو مدى سهولة توزيع دفق الفيديو عبر terabit