في الجزء الأول ، قمنا بنشر CDN ديناميكي بسيط لبث تدفقات WebRTC إلى قارتين وأثبتنا على سبيل المثال عن مؤقت العد التنازلي أن الكمون في هذا النوع من CDN منخفض بالفعل.
ومع ذلك ، إلى جانب الكمون المنخفض ، من المهم توفير جودة بث جيدة للمستخدمين. بعد كل هذا ، هذا ما يدفعون مقابله. في الواقع ، يمكن أن تختلف القنوات بين خوادم Edge والمستخدمين في سعة النطاق الترددي وجودته. على سبيل المثال ، نقوم بنشر دفق 720p بسرعة 2 ميغابت في الثانية ، حيث يقوم المستخدم بتشغيله على هاتف Android باستخدام اتصال 3G في منطقة استقبال إشارة غير مستقرة ودقة 360 بكسل القصوى التي توفر صورة سلسة بسرعة 400 ميجابت في الثانية هي 360 بكسل.
قد تختلف الأجهزة والمتصفحات التي يستخدمها المشاهدون كثيرًا. على سبيل المثال ، نقوم بنشر دفق WebRTC باستخدام برنامج ترميز VP8 في Chrome على جهاز الكمبيوتر ويقوم المشاهد بتشغيل البث في Safari على جهاز iPhone ، والذي يدعم برنامج ترميز H264 فقط. أو بالعكس ، نقوم بنشر دفق RTMP من OBS Studio ، ونقوم بترميز الفيديو في H264 والصوت في AAC ، ويستخدم العميل متصفحًا يستند إلى Chromium يدعم VP8 أو VP9 فقط للفيديو و Opus للصوت.
قد نحتاج أيضًا إلى تحسين جودة النشر الأولي. على سبيل المثال ، نشترك في دفق من كاميرا IP في حديقة طبيعية ، وفي معظم الأوقات تكون الصورة ثابتة ، وتقوم الكاميرا بتوصيلها بمعدل 1 إطار في الثانية. ومع ذلك ، نريد أن نوفر للمشاهدين 24 إطارًا في الثانية. ما الذي يجب عمله ، إذا لم يكن هناك إمكانية لاستبدال الكاميرا أو تعديل إعداداتها؟
في كل هذه الحالات ، سوف نحتاج إلى تحويل الرمز على الدفق على الخادم ، بحيث يتم فك تشفير كل إطار مستلم ثم تشفيره بمعلمات جديدة. إلى جانب ذلك ، فإن المعلمات المراد تعديلها غالبًا ما تكون معروفة فقط من جانب العميل. دعونا نلقي نظرة على كيفية تحقيق تحويل الشفرة في CDN مع الحفاظ على التوازن بين جودة البث وتحميل الخادم.
الترميز: كيف وأين ولماذا؟
افترض أننا على دراية بمعلمات البث التي يريد العميل استلامها. على سبيل المثال ، بدأ العارض في تشغيل الدفق ، ويبلغنا عدد خسائر الإطار في إحصائيات WebRTC بأنه يجب تقليل الدقة ومعدل البت قبل أن ينتقل العميل إلى عرض آخر . في هذه الحالة. سيتم تحويل الدفق بشكل افتراضي على خادم Edge الذي يتصل به العارض.
إذا كان العميل لا يدعم برنامج الترميز المستخدم أثناء نشر الدفق ، فيمكن فرض التشفير على خوادم Edge و Origin.
تعمل هاتان الطريقتان فقط كحل مؤقت بشرط أن يتم تعيين تكوينات خادم Origin و / أو Edge بهامش. يتم تنفيذ Trascoding دائمًا إطارًا تلو الآخر ، وبالتالي فهو يتطلب موارد وحدة المعالجة المركزية بشدة. وبالتالي ، فإن وحدة المعالجة المركزية واحدة قادرة على تحويل عدد قليل من التدفقات:
حتى إذا كنا سنقوم بتشغيل عملية تحويل الشفرة واحدة لجميع المستخدمين الذين يحتاجون إلى معلمات دفق الوسائط متساوية ، فمن المحتمل جدًا أن يستهلك عدد قليل من المشاهدين بمعلمات مختلفة موارد الخادم بالكامل.
وبهذه الطريقة ، يتمثل القرار الصحيح في تفكيك الخوادم المخصصة في CDN لتنفيذ مهمة الترميز واختيار تكوين الخادم مع مراعاة هذه المهمة.
إضافة العقد Transcoder في CDN
الآن ، سنقوم بنشر خادمي Transcoder في CDN الخاص بنا: واحد في مركز البيانات الأوروبي والآخر في أمريكا.
إعداد خوادم 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 خاصة في ملف 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 ميغابت في الثانية ، وترميز فيديو H264 باستخدام برنامج ترميز OpenH264 ، دون تحويل صوتي.
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
دعنا نشر دفق test 720p على خادم o-eu1 ولعب الدفق على e-eu1 لتحديد ملف التعريف في اسم الدفق ، على سبيل المثال ، test-640x360
الدفق يجري ترميزه!
الآن يمكننا وصف عدد من الملفات الشخصية على خوادم Edge ، على سبيل المثال -240p ، -360p ، -480p ، وإذا تم تشخيص عدد كبير من الإطارات المفقودة من جانب العميل وفقًا لإحصائيات WebRTC ، يمكننا تكرار طلب دفق دقة أقل.
تجميع العقد CDN في القارات
حاليا لدينا خوادم Transcoder النظير. لكن ماذا لو أردنا تحويل الشفرات على أساس الانتشار الجغرافي: للمشاهدين الأمريكيين في أمريكا ، للمشاهدين الأوروبيين في أوروبا؟ بالمناسبة ، سيسمح هذا بتقليل الحمل على القنوات عبر الأطلسي ، لأن خادم Origin EU سوف يرسل إلى أمريكا ويسترجع فقط التدفقات الأصلية بدلاً من جميع المتغيرات من تلك التي تم تحويلها عبر الشفرة.
في هذه الحالة ، من الضروري تحديد مجموعة CDN المطلوبة في إعدادات عقدة 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
دعونا إعادة تشغيل العقد مع إعدادات جديدة. بعد ذلك ، o-eu1 دفق test 720p على خادم o-eu1 ونلعب هذا التدفق على e-eu1 مع الترميز.
من أجل التأكد من تحويل الدفق على t-eu ، يتعين علينا فتح صفحة الإحصائيات على http://t-eu1.flashphoner.com:8081/؟action=stat ، وسنرى التشفير و وحدة فك الترميز في قسم الموارد الأصلية.
علاوة على ذلك ، لا توجد برامج تشفير فيديو على 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 المخصصة لدينا لتحويل تدفقات الوسائط ، وبالتالي ، نحن قادرون على توفير جودة بث جيدة لمشاهدينا وفقًا لقدرات أجهزتهم وجودة القنوات. ومع ذلك ، لم نتطرق إلى موضوع تقييد الوصول إلى البث حتى الآن. سوف نلقي نظرة على هذا في الجزء الأخير.
CDN لتدفق WebRTC كامن منخفض - شبكة توصيل المحتوى المستندة إلى Web Call Server.