HLS: ما هو، البروتوكول ومبدأ العمل

ما هو HLS؟

HTTP Live Streaming (HLS) هو بروتوكول بث وسائط طورته Apple في عام 2009 وتم تقديمه لأول مرة في iOS 3.0 و Safari. في عام 2017، تم اقتراح البروتوكول كمعيار إنترنت من خلال RFC 8216، مما أكد وضعه كمواصفات مفتوحة متاحة للتنفيذ على أي منصة.

الفكرة الرئيسية لـ HLS هي تقسيم تدفق الوسائط المستمر إلى مقاطع قصيرة مدتها 2–10 ثوانٍ. كل مقطع هو ملف مستقل يمكن تنزيله عبر طلب HTTP عادي. تتم إدارة التدفق من خلال قوائم تشغيل نصية بتنسيق M3U8، والتي تحتوي على مراجع للمقاطع وبيانات وصفية لتشغيلها بشكل صحيح.

التكيفية هي الميزة الرئيسية لـ HLS. يقوم الخادم بإعداد إصدارات متعددة لنفس المحتوى بمعدلات بت مختلفة — من 200 Kbps للاتصالات الضعيفة إلى أكثر من 20 Mbps لفيديو 4K. يختار العميل تلقائياً معدل البت المناسب بناءً على عرض النطاق الترددي الحالي للقناة. وفقاً لبحث Apple (WWDC 2024)، يقلل LL-HLS وقت التبديل بين معدلات البت إلى 500 مللي ثانية، مما يضمن تغييراً سلساً للجودة دون توقفات ملحوظة.

تاريخ تطور HLS

الإصدار الأول من HLS (2009) كان يدعم فقط مقاطع MPEG-2 TS مع برنامج ترميز الصوت AAC وبرنامج ترميز الفيديو H.264. iOS 8 (2014) أضاف دعم مقاطع fMP4 (fragmented MP4)، مما سمح باستخدام HLS مع برامج ترميز أكثر حداثة، بما في ذلك HEVC (H.265). iOS 11 (2017) قدم دعم HDR10 و Dolby Vision. iOS 13 (2019) قدم Low-Latency HLS، مما قلل زمن الوصول من 6–30 ثانية تقليدية إلى 2–6 ثوانٍ.

في عام 2023، وسعت Apple HLS بدعم لبرامجي الترميز AV1 و EVC (Essential Video Coding)، وقدمت Content Steering — آلية لإعادة توجيه العملاء ديناميكياً بين خوادم CDN لتحقيق التوازن الأمثل للحمل. يسمح Content Steering للخادم بتغيير عناوين URL للمقاطع أثناء التشغيل، وإعادة توجيه العميل إلى عقدة CDN الأقرب أو الأقل تحميلاً دون مقاطعة التشغيل.

كيف يعمل HLS؟

تتكون بنية HLS من ثلاثة مكونات رئيسية: جانب الخادم (خادم المصدر + المشفر)، وشبكة التوزيع (CDN)، وجانب العميل (مشغل يدعم HLS). العملية بأكملها — من التقاط الفيديو إلى التشغيل على جهاز المستخدم — تتضمن عدة مراحل متتالية، كل منها حاسمة لجودة البث.

الترميز والتقسيم

يتم أولاً ترميز الفيديو المصدر إلى متغيرات متعددة بمعدلات بت ودقات مختلفة. تقوم أدوات الترميز الاحترافية، مثل FFmpeg أو AWS Elemental MediaConvert، بإنشاء 4–12 متغيراً للتدفق في وقت واحد: من 240p (400 Kbps) إلى 4K (40 Mbps). يتم تقسيم كل متغير إلى مقاطع متساوية المدة، عادة 2–6 ثوانٍ لـ LL-HLS أو 6–10 ثوانٍ لـ HLS التقليدي.

لكل متغير، يتم إنشاء قائمة تشغيل متغير (variant playlist) تحتوي على عناوين URL لجميع المقاطع ومدتها. بالإضافة إلى ذلك، يتم إنشاء قائمة تشغيل رئيسية (master playlist) تجمع جميع المتغيرات وتحتوي على معلومات حول كل منها: الدقة ومعدل البت وبرنامج الترميز والمسارات الصوتية. يقوم العميل بتحميل قائمة التشغيل الرئيسية أولاً، ثم يختار المتغير المناسب بناءً على تحليل سرعة الاتصال.

التوزيع عبر CDN

يتم تخزين المقاطع وقوائم التشغيل مؤقتاً على خوادم CDN الموجودة جغرافياً بالقرب من المستخدمين. استخدام بروتوكول HTTP القياسي للتوزيع يمنح HLS ميزة حاسمة: أي CDN أو موازن تحميل أو خادم وكيل يدعم HTTP يعمل مع HLS دون تكوين إضافي. هذا يميز HLS عن بروتوكولات الوقت الفعلي مثل RTMP أو WebRTC التي تتطلب خوادم متخصصة.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

يستخدم جانب العميل خوارزمية اختيار معدل البت (ABR). يقوم مشغل HLS بتحميل قائمة التشغيل الرئيسية، ويحلل المتغيرات المتاحة، ويبدأ التشغيل بمعدل البت الأنسب. أثناء التشغيل، يراقب المشغل باستمرار سرعة تنزيل المقاطع ومستوى المخزن المؤقت، ويتخذ قرار التبديل إلى معدل بت أعلى أو أقل. تأخذ خوارزميات ABR الحديثة في الاعتبار ليس فقط سرعة الشبكة ولكن أيضاً حجم المخزن المؤقت ونوع المحتوى وحتى استهلاك طاقة الجهاز.

هيكل تدفق HLS: قوائم التشغيل والمقاطع

فهم هيكل تدفق HLS ضروري لتكوين الترميز والتوزيع وتصحيح مشاكل التشغيل بشكل صحيح. يتكون كل تدفق HLS من مستويين من قوائم التشغيل والعديد من مقاطع الوسائط المنظمة في تسلسل هرمي صارم.

قائمة التشغيل الرئيسية (Master Playlist)

قائمة التشغيل الرئيسية هي نقطة الدخول لمشغل HLS. يحتوي الملف بامتداد .m3u8 على مراجع لجميع متغيرات التدفق وخصائصها. يقوم المشغل بتحميل هذا الملف أولاً، وبناءً على معلومات معدلات البت والدقات، يتخذ القرار الأولي بشأن المتغير الذي سيختاره. قد تحتوي قائمة التشغيل الرئيسية أيضاً على مراجع لمسارات صوتية بديلة وترجمات وقوائم تشغيل I-Frame للبحث السريع.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

قائمة تشغيل الوسائط (Media Playlist)

قائمة تشغيل الوسائط تحتوي على قائمة المقاطع الفعلية لمتغير تدفق واحد. يتم تحديد كل مقطع مع مدته وURI. يمكن أن تكون قائمة تشغيل الوسائط ثابتة (لـ VOD — قائمة كاملة بجميع المقاطع) أو محدثة ديناميكياً (للبث المباشر — تتم إزالة المقاطع القديمة وإضافة مقاطع جديدة).

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

تنسيقات المقاطع

يدعم HLS تنسيقين رئيسيين لمقاطع الوسائط: MPEG-2 Transport Stream (.ts) و Fragmented MP4 (.m4s أو .mp4). MPEG-2 TS هو تنسيق HLS الأصلي، مما يوفر أقصى توافق. fMP4 هو تنسيق أكثر حداثة يدعم HDR و HEVC وضغطاً أكثر كفاءة. توصي Apple باستخدام fMP4 لجميع المشاريع الجديدة بدءاً من iOS 10 و macOS Sierra.

تشمل العناصر الإضافية لتدفق HLS قوائم تشغيل I-Frame للبحث السريع، و بيانات ID3 الوصفية لمزامنة الترجمات وعلامات الإعلانات، و بيانات الجلسة (Session Data) لنقل معلومات المشاهدة إلى خوادم التحليلات. كل هذه العناصر اختيارية، لكن استخدامها يحسن جودة تجربة المستخدم.

مزايا وعيوب HLS

HLS يهيمن على سوق بث الفيديو بفضل عدة مزايا معمارية، لكن له أيضاً قيود يجب مراعاتها عند اختيار بروتوكول لمشروع معين. دعنا نقارن HLS ببروتوكولات توصيل الفيديو البديلة.

الميزة الرئيسية لـ HLS هي الدعم الأصلي على جميع أجهزة Apple (iPhone, iPad, Apple TV, Mac) من خلال AVPlayer المدمج. هذا يجعل HLS المعيار الفعلي لتطبيقات iOS/macOS. بالإضافة إلى ذلك، استخدام HTTP القياسي للتوصيل يسمح بتخزين المحتوى مؤقتاً على أي CDN وخوادم وكيل دون تكوين إضافي، مما يبسط البنية التحتية للتوصيل بشكل كبير.

تشمل عيوب HLS زمن وصول أعلى مقارنة بـ RTMP أو WebRTC للبث المباشر. حتى مع LL-HLS، فإن الحد الأدنى لزمن الوصول هو 2–6 ثوانٍ، وهو غير مقبول للسيناريوهات التفاعلية في الوقت الفعلي. أيضاً، يولد HLS ملفات أكثر على الخادم (كل مقطع هو ملف منفصل)، مما قد يخلق حملاً على نظام الملفات مع عدد كبير من البثوث المتزامنة.

HLS في التطبيقات المحمولة

تكامل HLS في التطبيقات المحمولة يختلف حسب المنصة. على iOS و macOS، HLS مدعوم على مستوى نظام التشغيل من خلال AVFoundation و AVPlayer، مما يوفر فك تشفير مسرع بالأجهزة واستهلاكاً أدنى للطاقة. على Android، HLS غير مدعوم في MediaPlayer المدمج ولكنه متاح من خلال ExoPlayer — مشغل الوسائط الرسمي من Google.

HLS على iOS عبر AVPlayer

على منصة Apple، تشغيل HLS بسيط للغاية بفضل الدعم المدمج في AVPlayer. يكفي إنشاء AVPlayer بعنوان URL لقائمة التشغيل الرئيسية، وسيقوم النظام تلقائياً بمعالجة التبديل التكيفي لمعدلات البت واختيار المسارات الصوتية ومعالجة الترجمات. يحصل المطور أيضاً على تحكم كامل في التشغيل من خلال AVPlayerItem و AVAssetResourceLoader.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

HLS على Android عبر ExoPlayer

لـ Android، يتم استخدام ExoPlayer الذي يدعم HLS من خلال وحدة توسعة منفصلة. يوفر ExoPlayer تحكماً أدق في تدفق HLS: يمكن إدارة اختيار معدل البت، وتكوين التخزين المؤقت، ومعالجة أخطاء تحميل المقاطع بشكل فردي. يتطلب LL-HLS إصدار ExoPlayer 2.14.0 أو أعلى.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

تحسين HLS للشبكات المحمولة

تتطلب التطبيقات المحمولة نهجاً خاصاً لتكوين HLS بسبب عدم استقرار الشبكات الخلوية وقيود حركة المرور. تشمل التوصيات الرئيسية: تكوين معدل البت الأولي بناءً على نوع الشبكة (Wi-Fi أو خلوي)، استخدام مدد مقطع أقصر (2–4 ثوانٍ) للتكيف بشكل أسرع، التحميل المسبق للمخزن المؤقت عند التبديل إلى Wi-Fi، وإعطاء أولوية للمسار الصوتي عند الإشارة الضعيفة.

في مواصفات HLS Authoring Specification for Apple Devices (2024)، توصي Apple باستخدام حجم مقطع لا يزيد عن 6 ثوانٍ للأجهزة المحمولة وما لا يقل عن 4 متغيرات معدل بت. لتوفير حركة المرور على الشبكات المحمولة، يجب على الخادم تسليم المقاطع مع رأس HTTP Cache-Control، مما يسمح بتخزين المحتوى مؤقتاً على خوادم بروكسي وسيطة لمشغلي الاتصالات.