أغلق إيجور غطاء الكمبيوتر المحمول وفرك عينيه الحمراء من قلة النوم. "لا يزال العملاء يشكون من تجميد الدفق ، لم تساعد حزمة الإصلاح الجديدة على الإطلاق! فما العمل مع هذا HLS (الخاضع للرقابة)؟" وقال في الفراغ من الدراسة.
المتصفح ليس فقط النص التشعبي ، ولكن أيضا غاسل
حصلت المتصفحات على مشغلات لفترة طويلة ، لكن مع وجود مشفر فيديو وتدفق القصة مختلفة. الآن ، في أي متصفح تقريبًا من أحدث إصدار ، يمكنك العثور على وحدات للتشفير والتدفق وفك التشفير والتشغيل. تتوفر هذه الوظائف من خلال واجهة برمجة تطبيقات JavaScript ، ويطلق عليها اسم Web Real Time Communications أو WebRTC. يمكن لهذه المكتبة المدمجة في المتصفحات القيام بالكثير: التقاط الفيديو من كاميرا مدمجة أو افتراضية أو USB ، وضغطها باستخدام برامج الترميز H.264 أو VP8 أو VP9 أو إرسالها إلى الشبكة عبر بروتوكول SRTP ، أي يعمل كبرنامج ترميز الفيديو غاسل. نتيجةً لذلك ، نرى متصفحًا يشبه ffmpeg أو gstreamer أسفل الغطاء ، والذي يضغط الفيديو جيدًا ويدفق على RTP ويقوم بتشغيل دفق الفيديو.
يمنحك WebRTC حرية تنفيذ مجموعة متنوعة من حالات التدفق في JavaScript:
- دفق الدفق من المستعرض إلى الخادم للتسجيل والتوزيع اللاحق
- توزيع تيارات من الند للند
- تشغيل دفق مستخدم آخر وإرسال ملفك الشخصي (دردشة فيديو)
- قم بتحويل البروتوكولات الأخرى بواسطة الخادم ، على سبيل المثال RTMP ، RTSP ، إلخ ، واللعب في المستعرض مثل WebRTC
قد تبدو النصوص البرمجية للتحكم في التدفق المكررة كما يلي:
HLS يعمل حيث WebRTC لا يعمل
يعمل WebRTC في أحدث إصدارات المتصفحات ، ومع ذلك ، هناك عاملان من العوامل التالية: 1) لا يقوم جميع المستخدمين بتحديث المتصفحات في الوقت المناسب وقد يجلسون في بعض أنواع Chrome لمدة ثلاث سنوات. 2) يتم إصدار تحديثات مرة واحدة في الأسبوع تقريبًا ومتصفحات جديدة ، WebView ، بالإضافة إلى عملاء آخرين ورسائل فورية يمكنهم تصفح الإنترنت. وغني عن القول ، ليس كلهم لديهم دعم WebRTC ، وإذا كان الأمر كذلك ، يمكن اقتطاعها تمامًا. انظر كيف هي الأمور الآن:
صداع منفصل - أجهزة التفاح المفضلة لدى الجميع. لقد تلقوا مؤخرًا دعمًا لـ WebRTC ، وفي بعض الأحيان ، يفاجئون في سلوكهم مقارنة بمتصفحات الويب الأرثوذكسية. وحيث لا يعمل WebRTC أو لا يعمل بشكل جيد ، يعمل HLS بشكل جيد. في هذا الصدد ، يلزم التوافق ، ومثل المحول الذي سيحول WebRTC إلى HLS وتشغيله على أي جهاز تقريبًا.
في البداية ، لم يتم تصميم HLS للتدفقات في الوقت الحقيقي. في الواقع ، ما يمكن أن يكون وقت الفيديو عبر HTTP؟ تتمثل مهمة HLS في تقطيع الفيديو إلى مقاطع وتسليمها إلى المشغل بسلاسة ، دون التسرع ، من خلال تنزيل واحد تلو الآخر. يتوقع مشغل HLS دفق فيديو تم تشكيله بشكل سلس وسلس. وهنا ينشأ تعارض ، حيث أن WebRTC ، على العكس من ذلك ، يمكن أن يسمح لنفسه بفقدان الحزم بسبب متطلبات الوقت الحقيقي وانخفاض زمن الوصول والحصول على FPS / GOP عائم ومعدل بت متغير - ليكون عكسًا تمامًا لـ HLS من حيث قابلية التنبؤ وأبعاد الدفق.
أسلوب واضح - إزالة WebRTC (SRTP) والتحويل اللاحق إلى HLS ، قد لا يعمل في مشغل HLS الأصلي من Apple أو يعمل بشكل غير مناسب للإنتاج باستخدام أفاريز. يعني اللاعب الأصلي هنا اللاعب الذي يتم استخدامه في Apple iOS Safari و Mac OS Safari و Apple TV.
لذلك ، إذا لاحظت إفريز HLS في المشغل الأصلي ، فربما هذا هو ، ومصدر الدفق هو WebRTC أو دفق ديناميكي آخر ذو علامة غير متساوية. بالإضافة إلى ذلك ، في تطبيق مشغلات Apple الأصلية ، هناك سلوك لا يمكن فهمه إلا تجريبياً. على سبيل المثال ، يجب أن يبدأ الخادم في إرسال شرائح HLS على الفور ، فور إرجاع قائمة التشغيل m3u8. تأخير في الثانية الواحدة يهدد بالتجميد. إذا تغير تكوين bitstream في العملية (وهو أمر شائع إلى حد ما مع تدفق WebRTC) ، فسيكون هناك أيضًا إفريز.
محاربة الأفاريز في لاعبين محليين
وبالتالي ، لا يعمل إلغاء تجزئة وحزم WebRTC المباشر والصادق في HLS بشكل عام. في خادم الفيديو على خادم الويب (WCS) ، نحل المشكلة بطريقتين ، ونقدم المشكلة الثالثة كبديل:
1) تحويل الشفرة.
هذه هي الطريقة الأكثر موثوقية لمحاذاة دفق WebRTC مع متطلبات HLS ، وتعيين GOP ، FPS ، إلخ. ومع ذلك ، في بعض الحالات ، ليس تحويل الشفرة حلاً جيدًا ، على سبيل المثال تحويل الشفرة 4K تدفقات من فيديو VR هي فكرة رائعة. هذه التدفقات الثقيلة مكلفة للغاية لتحويل الشفرة من حيث وقت وحدة المعالجة المركزية أو موارد وحدة معالجة الرسومات.
2) التكيف ومواءمة تدفق WebRTC على الطاير تحت متطلبات HLS.
هذه عبارة عن موزعات خاصة تقوم بتحليل تيار البتات H.264 وتصحيحه لميزات / أخطاء مشغلات Apple HLS الأصلية. هنا يجب أن نعترف بأن اللاعبين غير الأصليين مثل video.js و hls.js أكثر تسامحًا مع التدفقات ذات معدل البت الديناميكي و FPS ، وهما WebRTC ولا يبطئان حيث يقع التنفيذ المرجعي لـ Apple HLS بشكل أساسي في التجميد الدائم.
3) استخدم RTMP كمصدر دفق بدلاً من WebRTC.
على الرغم من حقيقة أن الفلاش قد تم إيقافه ، إلا أن بروتوكول RTMP يستخدم بشكل نشط للتدفق ، خذ نفس OBS Studio. ويجب أن أعترف أن أجهزة تشفير RTMP تنتج تدفقات أكثر عمومًا من WebRTC ، وبالتالي لا تنتج عمليًا أفاريز في HLS ، أي تحويل RTMP> HLS من وجهة نظر الأفاريز يبدو أكثر ملاءمة ، بما في ذلك في HLS الأصليين. لذلك ، إذا تم إجراء التدفق من سطح المكتب و OBS ، فمن الأفضل استخدامه للتحويل إلى HLS. إذا كان المصدر عبارة عن متصفح Chrome ، فلا يمكن استخدام RTMP دون تثبيت المكونات الإضافية ، وهنا فقط WebRTC.
تم اختبار جميع الطرق الثلاث الموضحة أعلاه والعمل ، لذلك هناك فرصة للاختيار بناءً على شروط المهمة.
WebRTC إلى HLS على CDN
يمكن أن تنتظر بعض المشكلات في نظام موزع عند وجود العديد من خوادم تسليم دفق WebRTC بين مصدر دفق WebRTC ومشغل HLS ، أي CDN ، في حالتنا ، بناءً على خادم WCS. يبدو الأمر كما يلي: يوجد Origin - خادم يستقبل دفق WebRTC ، وهناك خوادم Edge - تقوم بتوزيع هذا الدفق بما في ذلك HLS. يمكن أن يكون هناك العديد من الخوادم ، مما يتيح القياس الأفقي للنظام. على سبيل المثال ، يمكن توصيل 1000 خادم من خوادم HLS بخادم أصل واحد ، وفي هذه الحالة يتم قياس سعة النظام 1000 مرة.
تم تحديد المشكلة بالفعل أعلى قليلاً ، وعادةً ما تنشأ هذه المشكلة في اللاعبين الأصليين: iOS Safari و Mac OS Safari و Apple TV. نعني <video src="https://host/test.m3u8"/> كلاعب يعمل مع إشارة مباشرة إلى عنوان url لقائمة التشغيل في العلامة ، على سبيل المثال ، <video src="https://host/test.m3u8"/> . بمجرد أن يطلب اللاعب قائمة تشغيل ، وهذا الإجراء هو في الواقع الخطوة الأولى في تشغيل دفق HLS ، يجب أن يبدأ الخادم فورًا ، دون أي تأخير ، في إرسال مقاطع فيديو HLS. إذا لم يبدأ الخادم في إعطاء الشرائح فورًا ، يقرر اللاعب أنه قد تم خداعه وتوقف عن اللعب. مرة أخرى ، يعتبر هذا السلوك نموذجيًا لمشغلي HLS الأصليين من Apple ، ولكن لا يمكننا إخبار المستخدمين - "من فضلك لا تستخدم iPhone Mac و Apple TV لتشغيل تدفقات HLS" ، فلن يفهم المستخدمون.
لذلك ، عند محاولة تشغيل دفق HLS على خادم Edge ، يجب أن يبدأ الخادم على الفور في إرجاع القطاعات ، ولكن كيف سيفعل ذلك إذا لم يكن لديه دفق؟ في الواقع ، عند محاولة تشغيل دفق على هذا الخادم مفقود. يعمل منطق CDN على مبدأ Lazy Loading - لن نوجه الدفق إلى الخادم حتى يطلب شخص ما هذا الدفق على هذا الخادم. هناك مشكلة في الاتصال الأول - أول من طلب دفق HLS من خادم Edge وكان لديه التهور للقيام بذلك من مشغل Apple الأصلي ، سيتلقى إفريزًا لسبب يستغرق بعض الوقت لطلب هذا الدفق من خادم Origin ، للحصول عليه على الحافة والمضي قدما في تشريح HLS. حتى لو استغرق الأمر ثلاث ثوانٍ ، فلن يقوم اللاعب بحفظه. سوف يذهب إلى الإفريز.
هنا مرة أخرى ، هناك قراران يلوحان في الأفق: أحدهما طبيعي والآخر ليس غاية. يمكن للمرء التخلي عن نهج Lazy Loading في CDN وإرسال حركة المرور إلى جميع العقد ، بغض النظر عن وجود المشاهدين هناك أم لا. حل ، ربما مناسب لأولئك الذين لا يقتصرون على موارد المرور والحوسبة. ستحرك Origin حركة المرور إلى جميع خوادم Edge ، ونتيجة لذلك ، سيتم تحميل جميع الخوادم والشبكة بينهما باستمرار. ربما يكون هذا المخطط مناسبًا فقط لبعض الحلول المحددة مع عدد صغير من التدفقات الواردة. عند تكرار عدد كبير من مؤشرات الترابط ، سيكون هذا المخطط واضحًا في عدم كفاءة الموارد. وإذا كنت تتذكر أننا نقوم فقط بحل "مشكلة الاتصال الأول من المتصفح الأصلي" ، فمن الواضح أنه لا يستحق ذلك.
الخيار الثاني هو أكثر أناقة ، ولكن أيضا الحل. نمنح أول مستخدم متصل صورة فيديو ، لكن هذا لا يزال غير البث الذي يريد رؤيته - هذا هو أداة التحميل المسبق. نظرًا لأننا يجب أن نعطي شيئًا الآن وننفذه على الفور ، ولكن ليس لدينا دفق المصدر (لا يزال يتم طلبه وتسليمه من Origin) ، فقد قررنا مطالبة العميل بالانتظار قليلاً وعرض شريط فيديو له على المحمل المسبق مع تحريك الرسوم المتحركة. ينتظر المستخدم بضع ثوانٍ ، ويدور التحميل المسبق ، وعندما يصل الدفق الحقيقي ، يبدأ المستخدم في عرض الدفق الحقيقي. نتيجةً لذلك ، رأى المستخدم الأول برنامج التحميل المسبق ، وشاهد المستخدمون اللاحقون الذين وصلوا أخيرًا دفق HLS العادي قادمًا من CDN ، معتمدين على مبدأ تحميل Lazy. حل مشكلة الهندسية.
ولكن ليس حتى النهاية
يبدو أن كل شيء يعمل بشكل رائع. CDN تعمل ، وتدفقات HLS مأخوذة من خوادم Edge Edge وتم حل مشكلة الاتصال الأول. وفي ما يلي مشكلة أخرى - نمنح برنامج التحميل المسبق بنسبة أبعاد ثابتة تبلغ 16: 9 ، ويمكن أن يشتمل CDN على تدفقات من أي تنسيق: 16: 9 ، 4: 3 ، 2: 1 (فيديو VR). وهذه مشكلة ، لأنه إذا أعطيت اللاعب أداة التحميل المسبق بتنسيق 16: 9 ، وسيكون الدفق المرتقب بتنسيق 4: 3 ، فسينتظر اللاعب الأصلي مرة أخرى الإفريز.
لذلك ، تنشأ مهمة جديدة - تحتاج إلى معرفة نسبة العرض إلى الارتفاع التي يدخل فيها الدفق CDN وإعطاء المحمل المسبق بنفس النسبة. تتمثل ميزة تدفقات WebRTC في الحفاظ على نسبة العرض إلى الارتفاع عند تغيير الدقة وأثناء تحويل الشفرة - إذا قرر المستعرض خفض الدقة ، فإنه يخفضها بنفس النسبة. إذا قرر الخادم تحويل رمز الدفق ، فسيحتفظ بنسبة العرض إلى الارتفاع بنفس النسبة. لذلك ، فمن المنطقي أننا إذا أردنا إظهار برنامج التحميل المسبق لـ HLS ، فإننا نعرضه بنفس نسبة العرض إلى الارتفاع التي يدخل فيها التدفق.
يعمل CDN على النحو التالي: عندما تدخل حركة المرور إلى خادم Origin ، فإنها تُعلم الخوادم الأخرى على الشبكة ، بما في ذلك خوادم Edge ، بالتيار الجديد. تكمن المشكلة في أنه عند هذه النقطة ، قد لا يكون تحليل دفق المصدر معروفًا بعد. يتم تنفيذ الدقة بواسطة H.264 bitstream configs مع إطار المفتاح. لذلك ، قد يحدث أن يتلقى خادم Edge معلومات عن وجود دفق ، لكنه لن يعرف دقة ونسبة العرض إلى الارتفاع ، مما لن يسمح له بإنشاء المحمل المسبق بشكل صحيح. في هذا الصدد ، من الضروري الإشارة إلى وجود دفق في CDN فقط إذا كان هناك إطار مفتاح - وهذا مضمون لإعطاء معلومات حجم خادم Edge وإتاحة إنشاء أداة التحميل المسبق الصحيحة لمنع "مشكلة العارض الأول المتصل".
النتائج
يوفر تحويل WebRTC إلى HLS عمومًا أفاريز عند تشغيلها في مشغلات Apple الأصلية. يتم حل المشكلة عن طريق تحليل وضبط تيار البتات H.264 حسب متطلبات HLS من Apple ، إما الترميز ، أو باستخدام الترحيل إلى بروتوكول RTMP ومشفّر كمصدر تيار. في شبكة موزعة مع التحميل البطيء للتدفقات ، هناك مشكلة في أول عارض متصل ، والتي يتم حلها باستخدام برنامج التحميل المسبق وتحديد الدقة على جانب خادم Origin - نقطة إدخال الدفق في CDN.
مراجع
خادم اتصال الويب - خادم WebRTC
انخفاض زمن انتقال WebRTC CDN - CDN المستند إلى WCS
قم بتشغيل دفق الفيديو WebRTC و RTMP عبر وظائف HLS - Server لتحويل التدفقات من مصادر مختلفة إلى HLS