في الجزء الأول ، قمنا بنشر CDN ديناميكي بسيط لبث تدفقات WebRTC إلى قارتين وتأكدنا من أن التأخيرات في مثل هذا CDN منخفضة حقًا ، وذلك باستخدام مؤقت العد التنازلي كمثال.
ومع ذلك ، بالإضافة إلى الكمون المنخفض ، من المهم تزويد المشاهدين بجودة بث جيدة ، لأنهم يدفعون ثمنها. في الحياة الواقعية ، يمكن أن تكون القنوات بين خوادم Edge والمشتركين مختلفة في النطاق الترددي والجودة. على سبيل المثال ، نقوم بنشر دفق بدقة 720 بكسل بمعدل بت 2 ميغابت في الثانية ، ويقوم المستخدم بتشغيله على هاتف ذكي يعمل بنظام Android باستخدام اتصال 3G في منطقة الاستقبال غير الآمن للإشارة ، ودقة قصوى تكون فيها الصورة سلسة ، 360 بكسل فقط مع معدل بت 400 ميجابت في الثانية .
الأجهزة والمتصفحات التي يستخدمها المشاهدون مختلفة تمامًا. على سبيل المثال ، نقوم بنشر دفق WebRTC باستخدام برنامج ترميز VP8 من متصفح Chrome على جهاز كمبيوتر ، ويقوم المشاهد بتشغيل الدفق في Safari على iPhone ، والذي يدعم برنامج الترميز H264 فقط. أو بالعكس ، ننشر تدفق RTMP من OBS Studio ، ونشفر الفيديو في H264 ، والصوت في AAC ، ويستخدم العميل متصفحًا يستند إلى Chromium ، والذي يدعم VP8 أو VP9 فقط للفيديو والتأليف للصوت.
قد تحتاج أيضًا إلى تحسين جودة المنشور الأصلي. على سبيل المثال ، نقوم بتوزيع الدفق من كاميرا IP في بعض الاحتياطي ، وفي معظم الأوقات تكون الصورة ثابتة ، توفرها الكاميرا بتردد 1 إطار في الثانية. في الوقت نفسه ، نريد أن يلعب المشاهد 24 إطارًا في الثانية. ماذا لو كان من المستحيل استبدال الكاميرا أو تغيير إعداداتها؟
في جميع هذه الحالات ، ستكون هناك حاجة إلى تحويل الشفرة للتيار على الخادم ، أي فك تشفير كل رتل مستلم وترميز لاحق مع معلمات جديدة. علاوة على ذلك ، فإن المعلمات التي يجب تغييرها غالبًا ما تكون معروفة فقط من جانب العميل. دعونا نرى كيف يمكن توفير تحويل الشفرة في CDN ، وتحقيق التوازن بين جودة البث وأحمال الخادم.
الترميز: كيف وأين ولماذا؟
افترض أننا نعرف معلمات التدفق التي يريد العميل استلامها. على سبيل المثال ، بدأ العارض في تشغيل دفق ، ويبلغنا عدد خسائر الإطار في إحصائيات WebRTC بضرورة خفض معدل الدقة والبت حتى قام العميل بتبديل القنوات . في هذه الحالة ، بشكل افتراضي ، سيتم تحويل الدفق على خادم Edge المتصل به العارض.
إذا كان العميل لا يدعم برنامج الترميز المستخدم عند نشر الدفق ، يمكنك تعيين تحويل الشفرة إلى خادم Edge و Origin.
يمكن أن يكون كل من هذا ، والآخر حلاً مؤقتًا فقط ، شريطة أن يتم اختيار تكوين خوادم Origin و / أو Edge بهامش. يتم تنفيذ عملية تحويل الشفرة دائمًا إطارًا تلو الآخر ، لذلك فهي تتطلب موارد المعالج بشكل كبير. لذلك ، يمكن لمعالج واحد أساسي تحويل عدد صغير للغاية من الخيوط:
حتى إذا بدأنا عملية تحويل الشفرة واحدة لجميع المشتركين الذين يحتاجون إلى نفس معلمات دفق الوسائط ، فمن المحتمل أن يختار العديد من المشاهدين ذوي المعلمات المختلفة جميع موارد الخادم.
وبالتالي ، فإن الحل الصحيح هو تخصيص خوادم خاصة في شبكة CDN لمهام تحويل الشفرة ، وتحديد تكوين الخادم بناءً على هذه المهام.
إضافة العقد Transcoder إلى CDN
لذلك ، سنقوم بنشر خادم واحد في CDN لدينا مع دور Transcoder في مراكز البيانات الأوروبية والأمريكية
تكوين خوادم Transcoder:
- Transcoder 1 الاتحاد الأوروبي
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
يجب وصف معلمات تحويل الشفرة cdn_profiles.yml على خوادم Edge كملفات تعريف خاصة في ملف cdn_profiles.yml . كمثال ، خذ بعين الاعتبار ثلاثة ملفات تعريف افتراضية:
- تحويل الشفرة إلى دقة 640 × 360 ، 30 إطارًا في الثانية ، يتم إرسال إطار مفتاح لكل 90 إطارًا ، ترميز فيديو H264 باستخدام مشفر OpenH264 ، ترميز الصوت Opus 48 كيلو هرتز
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- ترميز الفيديو بدقة 1280 × 720 ، ترميز الفيديو H264 باستخدام ترميز OpenH264 ، دون تحويل الصوت
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- تحويل الشفرة إلى دقة 1280 × 720 ، 30 إطارًا في الثانية ، يتم إرسال إطار مفتاح لكل 90 إطارًا ، ومعدل البت 2 Mbit / s ، ترميز الفيديو H264 باستخدام برنامج ترميز OpenH264 ، دون تحويل صوتي
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
نقوم بنشر دفق test بدقة 720 بكسل على o-eu1 ونلعب هذا الدفق على e-eu1 ، مع تحديد ملف التعريف في اسم الدفق ، على سبيل المثال ، test-640x360
يتم تحويل الدفق!
الآن يمكننا وصف عدد من الملفات الشخصية على خوادم Edge ، على سبيل المثال -240p ، -360p ، -480p ، وإذا كان من جانب العميل ، ووفقًا لإحصائيات WebRTC ، يتم تشخيص عدد كبير من الإطارات المفقودة ، وإعادة طلب الدفق تلقائيًا بدقة أقل.
مجموعة CDN العقد حسب القارة
الآن خوادم Transcoder لدينا متساوية. لكن ماذا لو أردنا تحويل الشفرات عبر الجغرافيا: للمشاهدين الأمريكيين في أمريكا ، للمشاهدين الأوروبيين في أوروبا؟ هذا ، بالمناسبة ، سيقلل الحمل على القنوات عبر الأطلسي ، لأنه في هذه الحالة فقط ستنقل التدفقات الأصلية من خوادم Origin EU إلى أمريكا والعكس ، وليس كل الإصدارات المحولة.
في هذه الحالة ، في إعدادات عقد Transcoder ، يجب عليك تحديد المجموعة
- Transcoder 1 الاتحاد الأوروبي
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
أيضًا ، يجب إضافة المجموعة إلى إعدادات خوادم Edge.
- الحافة 1-2 الاتحاد الأوروبي
cdn_groups=EU
- الحافة 1-2 الولايات المتحدة
cdn_groups=US
أعد تشغيل العقد بالإعدادات الجديدة. نقوم بنشر دفق test بدقة 720 بكسل على o-eu1 ، نلعب هذا الدفق على e-eu1 مع الترميز
تأكد من تحويل الدفق إلى t-eu ، لذلك نقوم بفتح صفحة الإحصائيات http://t-eu1.flashphoner.com:8081/؟action=stat ومشاهدة وحدة فك ترميز الفيديو وفك التشفير في قسم Native resources
في الوقت نفسه ، لا توجد برامج تشفير فيديو على t-us1 في الإحصاءات
المزيد من محولات الشفرة: موازنة التحميل
دعنا نقول أن عدد المشاهدين مستمر في النمو ، وقدرات خادم Transcoder في القارة ليست كافية بالفعل. حسنا ، إضافة خادم واحد أكثر
cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
ومع ذلك ، نحن الآن نواجه مشكلة موازنة التحميل عبر محولي الشفرة. حتى لا نسمح لجميع سلاسل العمليات من خلال خادم واحد ، سنحد من الحد الأقصى المسموح به لتحميل المعالج على عقد Transcoder
cdn_node_load_average_threshold=0.95
عندما يصل متوسط تحميل المعالج ، مقسومًا على عدد النوى المتاحة ، إلى هذه القيمة ، سيتوقف الخادم عن قبول طلبات تحويل سلاسل الرسائل الجديدة.
يمكنك أيضًا تحديد الحد الأقصى لعدد تشغيل تشفير الفيديو في وقت واحد
cdn_transcoder_video_encoders_threshold=10000
عند الوصول إلى هذا المبلغ ، سيتوقف الخادم أيضًا عن قبول طلبات تدفقات الشفرة ، حتى لو كان تحميل المعالج ما زال يسمح بذلك.
في أي حال ، سوف يستمر خادم Transcoder في توزيع الخوادم التي تم تحويلها بالفعل إلى خوادم Edge.
إنهاء يلي
لذلك ، قمنا بنشر خوادم مخصصة لترميز وسائط البث في CDN لدينا ، وبالتالي ، يمكننا تزويد المشاهدين بجودة البث وفقًا لقدرات معداتهم وجودة القنوات. ومع ذلك ، ما زلنا لم نعالج مشكلة تقييد الوصول إلى المواضيع. سننظر فيه في الجزء الأخير.
مراجع
دفق WebRTC ذو زمن انتقال منخفض هو شبكة توصيل محتوى تستند إلى Web Call Server.