أغلق جورج جهاز الكمبيوتر المحمول الخاص به وفرك عيونه الحمراء المحرومة من النوم. "لا يزال العملاء يشكون من تجميد البث المباشر ؛ لم تساعد حزمة الإصلاح الجديدة على الإطلاق! ماذا أفعل مع 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 ، وإذا فعلوا ذلك ، يمكن أن يكون محدودا. انظر كيف هي الأمور الآن:
يمكن أن تكون الأجهزة المفضلة لدى الجميع من Apple بمثابة صداع. لقد بدأوا في دعم WebRTC مؤخرًا وفي بعض الأحيان ، قد يبدو سلوكهم مقارنة بمتصفحات webkit مفاجئًا. عندما لا يعمل WebRTC أو لا يعمل بشكل جيد جدًا ، يعمل HLS بشكل جيد. في هذا الصدد ، يلزم التوافق ، ومثل المحول الذي يسمح لنا بتحويل WebRTC إلى HLS وتشغيله على أي جهاز تقريبًا.
لم يتم تصميم HLS في الأصل لتدفقات في الوقت الحقيقي. في الواقع ، كيف يمكننا دفق الفيديو في الوقت الحقيقي عبر HTTP؟ تتمثل مهمة HLS في تقطيع الفيديو إلى مقاطع وتسليمها إلى المشغل بسلاسة ، دون التسرع ، من خلال تنزيلها واحدة تلو الأخرى. يتوقع مشغل HLS دفق فيديو تم تشكيله بشكل سلس وسلس. هنا لدينا تعارض ، نظرًا لأن WebRTC ، على العكس من ذلك ، يمكن أن يتحمل خسارة الحزم بسبب متطلبات الوقت الفعلي وانخفاض زمن الوصول والحصول على FPS / GOP عائم ومعدل بت متغير - يكون العكس تمامًا من HLS من حيث إمكانية التنبؤ وانتظام الدفق.
هناك طريقة واضحة - قد لا يعمل إلغاء اكتساب WebRTC (SRTP) والتحول اللاحق إلى HLS في مشغل Apple HLS أصلي أو العمل مع التجميد ، وهو نموذج غير مناسب للإنتاج. المشغل الأصلي يعني المشغل المستخدم في 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.
هذه هي أدوات تحليل خاصة تقوم بتحليل B.2 bitstream وضبطها لتتناسب مع ميزات / أخطاء مشغلات HLS الأصلية من Apple. من المسلم به أن اللاعبين غير الأصليين مثل video.js و hls.js هم أكثر تسامحًا مع التدفقات
مع معدل البت الديناميكي و FPS يعمل على WebRTC ولا تبطئ حيث يؤدي تنفيذ مرجع أبل HLS أساسا في التجميد.
3) استخدام RTMP كمصدر دفق بدلاً من WebRTC.
على الرغم من حقيقة أن Flash Player قديم بالفعل ، إلا أن بروتوكول 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 بخادم Origin واحد ؛ في هذه الحالة ، تحجيم سعة النظام 1000 مرة.
كانت المشكلة بالفعل تمييز أعلاه؛ عادة ما تنشأ في لاعبين محليين: iOS Safari و Mac OS Safari و Apple TV. نعني بالأصل كلاعب يعمل مع إشارة مباشرة إلى رابط قائمة التشغيل
العلامة ، على سبيل المثال <video src="https://host/test.m3u8"/> . بمجرد أن يطلب اللاعب قائمة تشغيل - وهذا الإجراء هو بالفعل الخطوة الأولى في تشغيل دفق HLS - يجب على الخادم على الفور ، دون
تأخير ، ابدأ في إرسال مقاطع فيديو HLS. إذا لم يبدأ الخادم في إرسال شرائح على الفور ، فسيقرر اللاعب أنه قد تم خداعه والتوقف عن اللعب. يعتبر هذا السلوك نموذجيًا لمشغلي HLS الأصليين من Apple ، لكن لا يمكننا إخبار المستخدمين "يرجى عدم استخدام iPhone Mac و Apple TV لتشغيل تدفقات HLS."
لذلك ، عند محاولة تشغيل دفق HLS على خادم Edge ، يجب أن يبدأ الخادم على الفور في إرجاع القطاعات ، ولكن كيف يفترض أن يفعل ذلك إذا لم يكن لديه دفق؟ في الواقع ، عندما تحاول تشغيله هناك
ليس دفق على هذا الخادم. يعمل منطق CDN على مبدأ Lazy Loading - لن يتم تحميل الدفق على الخادم حتى يطلب شخص ما هذا الدفق على هذا الخادم. هناك مشكلة من أول اتصال
المستخدم؛ أول من طلب تدفق HLS من خادم Edge وكان لديه الحماسة للقيام بذلك من مشغل Apple الافتراضي سوف يتجمد لسبب أن الأمر سيستغرق بعض الوقت لطلب هذا التدفق
من خادم Origin ، احصل عليه على Edge ، وابدأ تشريح HLS. حتى لو استغرق الأمر ثلاث ثوان ، فإن هذا لن يساعد. سوف تجمد.
لدينا هنا حلان ممكنان: أحدهما مقبول والآخر أقل. يمكن للمرء أن يتخلى عن طريقة تحميل Lazy في CDN ويرسل حركة المرور إلى جميع العقد ، بغض النظر عما إذا كان هناك مشاهدين أم لا. حل ، ربما مناسب لأولئك الذين لا يقتصرون على موارد المرور والحوسبة. سيرسل Origin حركة المرور إلى جميع خوادم Edge ، ونتيجة لذلك ، سيتم تحميل جميع الخوادم والشبكة بينهما باستمرار. ربما يكون هذا المخطط مناسبًا فقط لبعض الحلول المحددة مع عدد صغير من التدفقات الواردة. عند تكرار عدد كبير من التدفقات ، سيكون هذا المخطط واضحًا
غير فعال من حيث الموارد. وإذا كنت تتذكر أننا نقوم فقط بحل "مشكلة المستخدم المتصل الأول من المستعرض الأصلي" ، يصبح من الواضح أنه لا يستحق ذلك.
الخيار الثاني أكثر أناقة ، لكنه أيضًا مجرد نهاية. نمنح أول مستخدم متصل صورة فيديو ، لكن هذا لا يزال غير البث الذي يرغبون في رؤيته - هذا هو أداة التحميل المسبق. نظرًا لأننا يجب أن نمنحهم شيئًا ما بالفعل ونفعله على الفور ، ولكن ليس لدينا دفق المصدر (لا يزال يتم طلبه وتسليمه من Origin) ، فنحن نطلب من العميل الانتظار قليلاً وعرض مقطع فيديو له
preloader مع الرسوم المتحركة المتحركة. ينتظر المستخدم بضع ثوانٍ بينما يدور التحميل المسبق ، وعندما يأتي الدفق الحقيقي أخيرًا ، يبدأ المستخدم في الحصول على الدفق الحقيقي. نتيجة لذلك ، سوف يرى المستخدم الأول
preloader ، وأولئك الذين يتصلون بعد ذلك سيشاهدون أخيرًا دفق HLS منتظم قادم من CDN يعمل وفقًا لمبدأ تحميل Lazy. وبالتالي ، تم حل المشكلة الهندسية.
ولكن ليس بعد حلها بالكامل
يبدو أن كل شيء يعمل بشكل جيد. يعمل CDN ، ويتم تحميل تدفقات HLS من خوادم 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 والتشفير كمصدر دفق. في شبكة موزعة مع Lazy Loading of تدفقات ، توجد مشكلة العارض الأول المتصل ، والتي يتم حلها باستخدام برنامج التحميل المسبق وتحديد الدقة على جانب خادم Origin - نقطة إدخال الدفق في CDN.
الروابط
خادم اتصال الويب - خادم WebRTC
CDN لتدفق WebRTC الكمون المنخفض - CDN المستند إلى WCS
تشغيل دفق الفيديو WebRTC و RTMP عبر وظائف HLS - Server لتحويل التدفقات من مصادر مختلفة إلى HLS