HLS: چیست، پروتکل و اصل کار

HLS چیست؟

HTTP Live Streaming (HLS) — یک پروتکل پخش جریانی رسانه است که توسط اپل در سال 2009 توسعه یافت و برای اولین بار در iOS 3.0 و Safari معرفی شد. در سال 2017، این پروتکل به عنوان یک استاندارد اینترنتی از طریق RFC 8216 پیشنهاد شد که وضعیت آن را به عنوان یک مشخصات باز قابل پیاده‌سازی در هر پلتفرمی تأیید کرد.

ایده اصلی HLS در تقسیم جریان پیوسته رسانه به بخش‌های کوتاه با مدت 2-10 ثانیه است. هر بخش یک فایل مستقل است که می‌تواند از طریق یک درخواست HTTP معمولی بارگیری شود. مدیریت جریان از طریق پلی‌لیست‌های متنی با فرمت M3U8 انجام می‌شود که حاوی پیوندهایی به بخش‌ها و فراداده‌هایی برای پخش صحیح آنها هستند.

تطبیق‌پذیری — مزیت کلیدی HLS است. سرور چندین نسخه از یک محتوا را با نرخ‌های بیت مختلف آماده می‌کند — از 200 Kbps برای اتصالات ضعیف تا 20+ Mbps برای ویدئوی 4K. کلاینت به طور خودکار نرخ بیت مناسب را بر اساس پهنای باند فعلی کانال انتخاب می‌کند. بر اساس تحقیقات اپل (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، اپل 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 — Adaptive Bitrate) استفاده می‌کند. پخش‌کننده HLS پلی‌لیست اصلی را بارگیری می‌کند، انواع موجود را تحلیل می‌کند و پخش را با مناسب‌ترین نرخ بیت آغاز می‌کند. در طول پخش، پخش‌کننده به طور مداوم سرعت بارگیری بخش‌ها و پر شدن بافر را نظارت می‌کند و در مورد تغییر به نرخ بیت بالاتر یا پایین‌تر تصمیم می‌گیرد. الگوریتم‌های مدرن ABR نه تنها سرعت شبکه، بلکه اندازه بافر، نوع محتوا و حتی مصرف انرژی دستگاه را نیز در نظر می‌گیرند.

ساختار جریان HLS: پلی‌لیست‌ها و بخش‌ها

درک ساختار جریان HLS برای پیکربندی صحیح رمزگذاری، توزیع و رفع مشکلات پخش ضروری است. هر جریان HLS از دو سطح پلی‌لیست و تعداد زیادی بخش رسانه‌ای تشکیل شده است که در یک سلسله‌مراتب سختگیرانه سازماندهی شده‌اند.

Master Playlist (پلی‌لیست اصلی)

Master playlist — نقطه ورود برای پخش‌کننده HLS است. فایل با پسوند .m3u8 حاوی پیوندهایی به همه انواع جریان (variant streams) و ویژگی‌های آنهاست. پخش‌کننده این فایل را ابتدا بارگیری می‌کند و بر اساس اطلاعات نرخ بیت و وضوح، تصمیم اولیه برای انتخاب نوع را می‌گیرد. پلی‌لیست اصلی همچنین می‌تواند حاوی پیوندهایی به آهنگ‌های صوتی جایگزین، زیرنویس‌ها و پلی‌لیست‌های 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 (پلی‌لیست رسانه‌ای)

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 و فشرده‌سازی کارآمدتر پشتیبانی می‌کند. اپل از iOS 10 و macOS Sierra به بعد، fMP4 را برای همه پروژه‌های جدید توصیه می‌کند.

عناصر اضافی جریان HLS شامل پلی‌لیست‌های I-Frame برای عقب‌رفت سریع، فراداده ID3 برای همگام‌سازی زیرنویس‌ها و نشانگرهای تبلیغاتی، و همچنین Session Data برای انتقال اطلاعات پخش به سرور تحلیل است. همه این عناصر اختیاری هستند، اما استفاده از آنها کیفیت تجربه کاربر را بهبود می‌بخشد.

مزایا و معایب HLS

HLS به لطف تعدادی مزیت معماری در بازار استریمینگ ویدئو غالب است، اما محدودیت‌هایی نیز دارد که باید هنگام انتخاب پروتکل برای یک پروژه خاص در نظر گرفته شود. HLS را با پروتکل‌های جایگزین تحویل ویدئو مقایسه می‌کنیم.

مزیت اصلی HLS — پشتیبانی بومی در همه دستگاه‌های اپل (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 — پخش‌کننده رسانه رسمی گوگل — در دسترس است.

HLS در iOS از طریق AVPlayer

در پلتفرم اپل، پخش 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) استفاده از اندازه بخش حداکثر 6 ثانیه برای دستگاه‌های موبایل و حداقل 4 نوع نرخ بیت را توصیه می‌کند. برای صرفه‌جویی در ترافیک شبکه‌های موبایل، سرور باید بخش‌ها را با هدر HTTP Cache-Control ارائه دهد که امکان ذخیره محتوا در سرورهای پراکسی میانی اپراتورهای مخابراتی را فراهم می‌کند.