الاختيار بين HLS و HTTP-FLV ليس مجرد مسألة تحديد أي التنسيقين أحدث. يعتمد القرار الصحيح على ما يحتاج المشاهدون إلى فعله، وأين يشاهدون، وعدد الاتصالات المتزامنة التي يجب أن تدعمها المنصة، ومقدار التأخير الذي يمكن للتطبيق تحمله. قد تبدأ البث الشبكي العام، ووحدة تحكم المراقبة عبر المتصفح، وتطبيق المشاهدة المباشرة على الهواتف المحمولة من نفس مصدر الفيديو ولكنها تتطلب مسارات تسليم مختلفة.
يشرح هذا الدليل دور كل تقنية ويوضح كيفية دمجها في بنية بث عملية. يحتفظ بالتمييز الأساسي: صُمم HLS للتسليم الموثوق والقابل للتكيف عبر البنية التحتية القياسية لـ HTTP، بينما يرسل HTTP-FLV دفق FLV مستمر عبر HTTP ويُختار عادةً عندما يجب أن يظل تشغيل المتصفح أقرب إلى البث المباشر.
ابدأ بفصل البروتوكول والنقل والحاوية
غالبًا ما تُستخدم مصطلحات HLS و FLV و HTTP-FLV و RTMP كما لو كانت تصف الطبقة نفسها. لكنها ليست كذلك.
-
HLS، أو البث المباشر عبر HTTP، هو بروتوكول تسليم وسائط طورته شركة Apple في الأصل. يستخدم قوائم تشغيل وسلسلة من مقاطع الوسائط يتم تسليمها عبر HTTP أو HTTPS.
-
FLV، أو فيديو فلاش، هو تنسيق حاوية يمكنه حمل الصوت والفيديو المشفرين. FLV في حد ذاته لا يحدد كيفية انتقال الدفق عبر الشبكة.
-
HTTP-FLV يبقي دفق FLV مفتوحًا عبر اتصال HTTP. يستقبل المشغل الوسائط باستمرار بدلاً من طلب قائمة تشغيل ومقاطع منفصلة.
-
RTMP هو بروتوكول بث منفصل يرتبط تاريخيًا بـ Flash. لا يزال شائعًا في جانب المساهمة أو الاستقبال، حتى عندما يتلقى المشاهدون HLS أو تنسيق إخراج آخر.
هذا التمييز مهم أثناء تصميم النظام. يمكن للمنصة قبول RTMP من جهاز ترميز، ومعالجة المصدر مرة واحدة، ونشر مخرجات HLS و HTTP-FLV لمجموعات مختلفة من المشاهدين. وبالتالي، فإن اختيار طريقة التسليم لا يتطلب بالضرورة تغيير الكاميرا أو جهاز الترميز أو بروتوكول المساهمة الأعلى.
لماذا يعمل التسليم المجزأ بشكل جيد على نطاق واسع
يقسم HLS البرنامج المباشر أو عند الطلب إلى مقاطع وسائط ويسردها في قائمة تشغيل M3U8. تستخدم النشرات التقليدية عادةً مقاطع MPEG-2 Transport Stream، التي يُشار إليها غالبًا بالامتداد .ts. يمكن لـ HLS الحديث أيضًا استخدام MP4 مجزأ، والذي يُسمى غالبًا fMP4، مما يوفر أساسًا عمليًا لسير عمل الترميز والتغليف المعاصر. يمكن تقديم الصوت والترجمات المصاحبة كإصدارات منفصلة إلى جانب الفيديو.
نظرًا لأن قوائم التشغيل والمقاطع هي موارد HTTP عادية، يمكن تقديمها بواسطة خوادم ويب قياسية ووكلاء عكسيون وشبكات توصيل المحتوى. يمكن للتخزين المؤقت الحوفي الاحتفاظ بالمقاطع الشائعة بالقرب من المشاهدين، مما يقلل من حركة المرور المتكررة إلى المصدر. هذا يجعل HLS خيارًا قويًا للأحداث العامة المباشرة، وبوابات التدريب، وتطبيقات الهواتف المحمولة، والخدمات ذات الجماهير الموزعة جغرافيًا.
يعد التسليم التكيفي بمعدل بت متغير ميزة مركزية أخرى. تحضر المنصة عدة إصدارات من نفس البرنامج بدقات ومعدلات بت مختلفة. بناءً على الإنتاجية الحالية، وحالة المخزن المؤقت، وقدرة الجهاز، يمكن للمشغل التنقل بين هذه المتغيرات للحفاظ على استقرار التشغيل. قد يستقبل مشاهد على اتصال متنقل متغير إصدارًا أقل دقة بدلاً من التعرض لانقطاع كامل.
المقابل هو أن تشغيل HLS التقليدي ينتظر عادةً إنشاء المقطع، وتحديث قائمة التشغيل، ومخزن تشغيل مؤقت. يعتمد التأخير الفعلي على مدة المقطع، وتصميم قائمة التشغيل، وإعدادات المشغل، وظروف الشبكة. يمكن لـ Low-Latency HLS تقليل هذا التأخير، لكنه يتطلب دعمًا منسقًا عبر أدوات التجميع، والمصدر، وCDN، والمشغل. يجب التعامل معه كخيار تصميم شامل بدلاً من مفتاح يُضاف في المرحلة النهائية.
يجب اختيار مدة المقطع وفقًا لهدف الخدمة. يمكن للمقاطع الأقصر أن تساعد المشغل في اكتشاف الوسائط الجديدة بشكل أسرع، لكنها تزيد أيضًا من تحديثات قائمة التشغيل، وطلبات الكائنات، والعبء الإضافي للتغليف. تقلل المقاطع الأطول من تكرار الطلبات وقد تحسن كفاءة التسليم، لكنها قد تزيد من وقت البدء وتجعل تغييرات الجودة أقل استجابة. يجب أن تتبع فترة الإطارات الرئيسية لجهاز الترميز خطة التغليف بحيث يعرض كل إصدار نقاط تبديل نظيفة في نفس المواضع.
حيث لا يزال الدفق المستمر عبر HTTP مفيدًا
يرسل HTTP-FLV علامات FLV عبر استجابة HTTP طويلة العمر. بمجرد بدء التشغيل، تستمر بيانات الوسائط في الوصول عبر نفس الاتصال. لا توجد قائمة تشغيل مقاطع لتحديثها، لذا يمكن للنظام المضبوط بشكل صحيح أن يظل عادةً أقرب إلى المصدر الحي من سير العمل المجزأ التقليدي.
هذا السلوك مفيد في التطبيقات الموجهة للمشغلين حيث يحتاج الأشخاص إلى مراقبة الأحداث والتفاعل بسرعة: صفحات مراقبة الفيديو، ولوحات تحكم الإنتاج، والإشراف على المعدات، والفحص عن بُعد، وأنظمة المشاهدة الداخلية. يمكنه أيضًا تبسيط التسليم عبر الشبكات التي تسمح بالفعل بحركة HTTP أو HTTPS.
ومع ذلك، لا ينبغي الخلط بين HTTP-FLV ودعم الفيديو الأصلي للمتصفح. أدت نهاية Adobe Flash Player إلى إزالة مسار تشغيل المكونات الإضافية القديم: أنهت Adobe دعم Flash Player في 31 ديسمبر 2020 وبدأت في حظر محتوى Flash في 12 يناير 2021. لذلك، يعتمد تشغيل HTTP-FLV الحديث على مشغل HTML5، وعادةً ما يستخدم JavaScript لتحليل دفق FLV وواجهة برمجة تطبيقات وسائط المتصفح لتغذية برامج الترميز الصوتية والمرئية المدعومة في وحدة فك التشفير.
هذا يخلق تبعية توافقية. يجب أن يدعم المتصفح واجهة برمجة تطبيقات الوسائط المطلوبة وبرامج الترميز المحمولة داخل حاوية FLV. وبالتالي، فإن HTTP-FLV أكثر ملاءمة للعملاء الويب المتحكم بهم والتطبيقات المخصصة بدلاً من الجمهور العام غير المقيد. يمكن لعدد كبير من الاتصالات المستمرة أيضًا أن يضع ضغطًا مستدامًا أكبر على خادم التسليم وأجهزة الشبكة الوسيطة مقارنة بالكائنات المجزأة القابلة للتخزين المؤقت.
طابق مسار التسليم مع متطلبات المشاهدة
يجب أن يبدأ قرار البروتوكول بالمتطلبات التشغيلية، وليس بقائمة تدقيق الميزات. توفر المقارنة التالية نقطة بداية مفيدة.
| عامل القرار | HLS | HTTP-FLV |
|---|---|---|
| نموذج التسليم | قائمة تشغيل بالإضافة إلى مقاطع وسائط | دفق FLV مستمر عبر HTTP أو HTTPS |
| الأولوية النموذجية | تشغيل مستقر وتوزيع واسع | تأخير أقل للمشاهدة المباشرة |
| معدل بت تكيفي | مدمج في البروتوكول عبر تدفقات متغيرة | غير متأصل؛ يتطلب عادةً تبديل تدفق خاص بالتطبيق |
| كفاءة CDN | عالية، لأنه يمكن تخزين المقاطع مؤقتًا ككائنات HTTP | أكثر محدودية، لأن كل مشاهد يحافظ على استجابة مستمرة |
| وصول العميل | قوي عبر أجهزة Apple، ومنصات الهواتف المحمولة، والأجهزة الذكية، وأنظمة تشغيل الويب | أفضل في المتصفحات المتحكم بها أو التطبيقات المخصصة مع مشغل متوافق |
| تقلب الشبكة | يتعامل مع تغير النطاق الترددي بشكل جيد عند توفر إصدارات متعددة | أكثر حساسية ما لم يزود التطبيق بمنطق تبديل الجودة الخاص به |
| الملاءمة التشغيلية | البث المباشر العام، والمشاهدة عبر الهاتف المحمول، وبوابات الفيديو، والجماهير الكبيرة | وحدات تحكم المراقبة، والأنظمة الداخلية، والمشاهدة منخفضة التأخير عبر المتصفح |
استخدم HLS كمخرج أساسي عندما يكون حجم الجمهور غير متوقع، أو يستخدم المشاهدون مجموعة واسعة من الأجهزة، أو تكون استمرارية التشغيل أكثر أهمية من الفورية، أو كان تسليم CDN جزءًا من الخطة. استخدم HTTP-FLV عندما تتحكم المنصة في مشغل الويب، والجمهور معروف، وعدد المشاهدين المتزامنين يمكن التحكم فيه، ولتأخير المشاهدة المباشرة قيمة تشغيلية واضحة.
قبل الموافقة على أي من المسارين، حدد ميزانية تأخير لكل مرحلة: الالتقاط، الترميز، استقبال الشبكة، معالجة الوسائط، التوزيع، تخزين المشغل المؤقت، وفك التشفير. هذا يمنع إلقاء اللوم على بروتوكول التسليم بسبب تأخير ناتج عن مكان آخر. لا يمكن لمخرج منخفض التأخير تعويض جهاز ترميز بفترة إطارات رئيسية طويلة، أو معالج تحويل مثقل، أو مشغل مهيأ بمخزن مؤقت أمان كبير. قم بقياس النتيجة على نقطة النهاية الفعلية والشبكة المستخدمة في الإنتاج.
لا يناسب أي من الخيارين كل شكل من أشكال الاتصال في الوقت الفعلي. إذا كان يجب على المستخدمين إجراء محادثة ثنائية الاتجاه أو تشغيل جهاز بتوقيت تفاعل ضيق للغاية، فقد تكون تقنية الاتصالات في الوقت الفعلي أكثر ملاءمة. النقطة المهمة هي فصل توزيع الفيديو أحادي الاتجاه عن الوسائط التفاعلية قبل اختيار بنية التسليم.
تصميم هجين يغطي المزيد من المستخدمين دون تكرار المصدر
لا تحتاج العديد من المشاريع إلى قرار إما/أو. يمكن لمنصة هجينة استقبال مصدر واحد، وتوحيد الطوابع الزمنية وبرامج الترميز، ثم تجميع مخرجات منفصلة لعملاء مختلفين.
-
استقبل المصدر. استقبل الفيديو المباشر من كاميرا أو جهاز ترميز أو بوابة أو منصة أعلى عبر بروتوكول المساهمة الذي يدعمه الجهاز الميداني.
-
افحص الوسائط. تحقق من برنامج الترميز، والدقة، ومعدل الإطارات، وتنسيق الصوت، واستمرارية الطابع الزمني قبل تحديد ما إذا كان يمكن إعادة تجميع الدفق أو يجب تحويله.
-
أنشئ إصدارات التسليم. أنتج سلم معدل بت تكيفي لـ HLS. أنشئ مخرج HTTP-FLV فقط للعملاء الذين يحتاجونه ويمكنهم فك تشفير ملف الوسائط الخاص به.
-
افصل مسارات الجمهور. أرسل HLS عبر مصدر و CDN للمشاهدة الخارجية أو واسعة النطاق. وجّه HTTP-FLV عبر مجموعة تسليم متحكم بها لمستخدمي العمليات.
-
طبق ضوابط الوصول. استخدم HTTPS، والتراخيص قصيرة العمر، وحماية المصدر، وسياسات الجلسة المناسبة لكل مسار.
-
قس السلسلة الكاملة. راقب استمرارية الاستقبال، وحمل المعالجة، وأخطاء التجميع، وزمن الإطار الأول، والتخزين المؤقت، والانقطاعات، والتأخير الشامل.
يتجنب هذا النموذج إجبار كل عميل على نفس التسوية. يتلقى المشاهدون العامون دفقًا مرنًا وقابلاً للتوسع، بينما يمكن للمشغلين استخدام مسار أقل تأخيرًا. تصبح منصة الوسائط أيضًا النقطة التي يتم فيها تحويل تنسيقات المصدر القديمة إلى مخرجات يمكن للمتصفحات والتطبيقات الحالية استهلاكها.
اختر بين إعادة التجميع والتحويل البرمجي
إذا كانت برامج الترميز الواردة تطابق بالفعل ملف التسليم، فقد تحتاج المنصة فقط إلى إعادة تجميع الوسائط المضغوطة. تغير إعادة التجميع الحاوية أو هيكل المخرج دون فك تشفير وتشفير كل إطار، لذا تستهلك عادةً موارد معالجة أقل وتحافظ على جودة المصدر. تكون مناسبة فقط عندما يكون دعم برنامج الترميز، والطوابع الزمنية، وموضع الإطارات الرئيسية، ومعلمات الصوت مناسبة بالفعل للمشغلات المستهدفة.
يكون التحويل البرمجي مطلوبًا عندما لا يمكن فك تشفير برنامج الترميز المصدر بواسطة العميل المقصود، أو عندما تكون هناك حاجة إلى عدة دقات ومعدلات بت، أو عندما يجب توحيد معدل الإطارات وتنسيق الصوت وهيكل الإطارات الرئيسية. يضيف تكلفة حسابية وتأخير معالجة، لذا يجب حساب السعة لذروة القنوات المتزامنة بدلاً من الاستخدام المتوسط. يمكن للتسريع بالأجهزة زيادة كثافة القنوات، ولكن لا يزال يجب اختبار جودة المخرج وسلوكه مع المشغل المختار.
يجب على الأنظمة الإنتاجية أيضًا إزالة نقاط الفشل الفردية. استخدم مصادر احتياطية، وإعادة اتصال متحكم بها للمشغل، وقواعد تجاوز الفشل المختبرة دون إنشاء حلقات إعادة محاولة عدوانية تضاعف من العطل.
فحوصات النشر التي تمنع الأعطال التي يمكن تجنبها
لا يضمن اختيار البروتوكول وحده خدمة موثوقة. قبل الإطلاق، تحقق من مسار الوسائط والشبكة بالكامل.
-
تأكد من دعم برنامج الترميز في نقطة النهاية. قد يصل النقل إلى المشغل بنجاح بينما يفشل التشغيل لأن المتصفح لا يمكنه فك تشفير ملف الصوت أو الفيديو.
-
حافظ على استمرارية الطوابع الزمنية. يمكن أن تتسبب الطوابع الزمنية المكسورة أو غير الرتيبة في التوقف، وانجراف الصوت، وفشل تبديل الجودة.
-
حاذِ الإطارات الرئيسية مع قواعد التجميع. يجب أن تستخدم إصدارات HLS حدود إطارات رئيسية منسقة حتى يتمكن المشغل من تبديل الجودة دون انقطاع مرئي.
-
خطط لـ HTTPS من المصدر إلى المشغل. يجب ألا تطلب الصفحات الآمنة وسائط غير آمنة، ويجب أن تكون الشهادات صالحة عبر المصدر وطبقات التوزيع.
-
اختبر ظروف الشبكة الحقيقية. تحقق من بدء التشغيل، والاسترداد، وتغييرات الجودة تحت نطاق ترددي محدود، وفقدان الحزم، وانقطاعات قصيرة بدلاً من الاختبار فقط على شبكة محلية.
-
ضع حجمًا مناسبًا لسلوك الاتصال. يركز تخطيط سعة HLS بشكل كبير على طلبات المقاطع، والتخزين، ومعدل إصابة ذاكرة التخزين المؤقت. يجب أن يأخذ تخطيط HTTP-FLV في الاعتبار الاتصالات المتزامنة طويلة العمر والإنترنت الصادر المستمر.
-
قدم سياسة احتياطية. إذا كان المشغل أو التنسيق المفضل غير متاح، يجب أن يعيد التطبيق بديلاً مدعومًا أو خطأ واضحًا بدلاً من إعادة المحاولة إلى ما لا نهاية.
بالنسبة لمعظم الخدمات المواجهة للخارج، يعد HLS الافتراضي الأكثر أمانًا لأنه يجمع بين تشغيل معدل بت تكيفي وتوزيع HTTP ناضج. يظل HTTP-FLV مفيدًا حيث يكون المشغل المُدار والتأخير المنخفض أكثر أهمية من الوصول الشامل. غالبًا ما تكون البنية الهجينة هي الإجابة الأكثر عملية عندما يجب أن يخدم نفس المصدر الحي كلا المجموعتين.
الأسئلة الشائعة
هل يمكن إضافة ترجمات مصاحبة إلى سير عمل البث المباشر؟
نعم. يمكن إنشاء الترجمات المصاحبة في اتجاه المنبع أو إدراجها أثناء معالجة الوسائط. بالنسبة لـ HLS، تعد إصدارات ترجمات WebVTT خيارًا شائعًا. قد يحتاج مشغل HTTP-FLV المخصص إلى قناة نصية موقوتة منفصلة ومنطق مزامنة خاص به.
هل يمكن للمشاهدين إعادة الترجيع أثناء استمرار الحدث المباشر؟
يمكنهم ذلك إذا كانت الخدمة تحافظ على نافذة مباشرة طويلة بما يكفي ويعرض المشغل عناصر التحكم في الإزاحة الزمنية. يجب تحديد نافذة الاحتفاظ، وسعة التخزين، وحقوق المحتوى قبل تمكين إعادة الترجيع المباشر.
هل يمكن للمشغل التبديل إلى الصوت فقط عندما يكون عرض نطاق الفيديو غير متاح؟
نعم، بشرط أن تنشر المنصة إصدارًا صوتيًا فقط أو دفقًا صوتيًا منفصلاً، وأن يكون المشغل مهيئًا لتحديده. يمكن أن يحافظ ذلك على التعليق الحرج أو التعليمات على الاتصالات المحدودة للغاية.
هل يمكن للتحليلات التمييز بين خروج المشاهد وفشل الشبكة؟
ليس من حدث انقطاع واحد فقط. ادمج أحداث المشغل، وفواصل ضربات القلب، ومعرفات الجلسة، وسلوك إعادة المحاولة، وسجلات اتصال الخادم لتصنيف حالات الخروج بثقة أكبر.
ماذا يجب أن يحدث لعنوان URL المباشر بعد انتهاء الحدث؟
يمكن للمنصة إغلاق الجلسة المباشرة، أو نشر لوحة نهاية، أو إعادة توجيه المستخدمين إلى برنامج مؤرشف بعد اكتمال المعالجة. حدد الانتقال مسبقًا حتى لا تفشل المشغلات المضمنة والروابط المشتركة دون تفسير.
