انواع پروتکل‌های استریم و پخش زنده: RTMP، SRT، WebRTC، HLS و بقیه

تکنولوژی ۶ دقیقه مطالعه
انواع پروتکل‌های استریم و پخش زنده: RTMP، SRT، WebRTC، HLS و بقیه

پروتکل‌های استریم به زبان ساده

وقتی وارد دنیای پخش زنده می‌شوید، با اسم‌هایی مثل RTMP، HLS، SRT و WebRTC زیاد روبه‌رو می‌شوید. همهٔ این‌ها پروتکل هستند: قواعدی که مشخص می‌کنند تصویر و صدا چطور بسته‌بندی شوند و از یک نقطه به نقطهٔ دیگر برسند. در این مطلب هر کدام را خلاصه معرفی می‌کنیم و در پایان با هم مقایسه‌شان می‌کنیم تا بدانید کدام برای چه کاری مناسب است.

اول یک نکتهٔ مهم: ارسال و تحویل

مسیر یک پخش زنده دو نیمه دارد و معمولاً هر نیمه پروتکل خودش را دارد:

  • ارسال (Ingest): رساندن تصویر از نرم‌افزار یا دوربین شما (مثل OBS یا Larix) به سرور پخش.
  • تحویل (Delivery): رساندن تصویر از سرور به هزاران بیننده روی مرورگر، موبایل و تلویزیون.

دو نیمهٔ مسیر پخش زنده: ارسال و تحویل

پروتکلی که برای ارسال عالی است، لزوماً برای تحویل به بیننده مناسب نیست و برعکس. به همین دلیل سرویس‌های پخش، استریم را با یک پروتکل می‌گیرند و با پروتکل دیگری به بیننده می‌رسانند.

RTMP و RTMPS

RTMP (Real-Time Messaging Protocol) قدیمی‌ترین و رایج‌ترین پروتکل ارسال استریم است. در اصل برای Flash Player ساخته شد. Flash مدت‌هاست کنار رفته، اما RTMP به‌عنوان استاندارد ارسال باقی مانده است.

  • کاربرد اصلی: ارسال از OBS، vMix، Larix و نرم‌افزارهای مشابه به سرور.
  • مزیت: تقریباً همهٔ نرم‌افزارها و سرویس‌ها از آن پشتیبانی می‌کنند و راه‌اندازی‌اش ساده است.
  • محدودیت: روی اینترنت ناپایدار حساس است و قابلیت‌های جدید مثل کدک‌های مدرن را به‌طور سنتی پشتیبانی نمی‌کند. مرورگرها هم دیگر نمی‌توانند مستقیم RTMP پخش کنند.
  • RTMPS همان RTMP است که روی اتصال رمزنگاری‌شده (TLS) کار می‌کند. برخی سرویس‌ها مثل اینستاگرام و فیسبوک فقط نسخهٔ امن را می‌پذیرند.

SRT

SRT (Secure Reliable Transport) یک پروتکل متن‌باز و جدیدتر برای ارسال است که مخصوص اینترنت‌های ناپایدار طراحی شده.

  • کاربرد اصلی: ارسال از راه دور، مثلاً پخش از محل رویداد یا بین دو استودیو.
  • مزیت: بسته‌های گم‌شده را جبران می‌کند، رمزنگاری داخلی دارد و تأخیرش کم و قابل تنظیم است.
  • محدودیت: هنوز همهٔ سرویس‌ها و مقصدها آن را نمی‌پذیرند و برای پخش مستقیم به بیننده در مرورگر مناسب نیست.

RTSP

RTSP (Real Time Streaming Protocol) بیشتر در دنیای دوربین‌های مداربسته و دوربین‌های IP دیده می‌شود.

  • کاربرد اصلی: گرفتن تصویر از دوربین‌های IP، سیستم‌های نظارتی و برخی دوربین‌های حرفه‌ای.
  • مزیت: تأخیر کم و پشتیبانی گسترده در تجهیزات نظارتی.
  • محدودیت: مرورگرها مستقیم پخشش نمی‌کنند و معمولاً باید روی سرور به پروتکل دیگری تبدیل شود.

WebRTC و WHIP

WebRTC فناوری‌ای است که داخل مرورگرها ساخته شده و همان چیزی است که تماس‌های ویدیویی تحت وب از آن استفاده می‌کنند.

  • کاربرد اصلی: ارتباط تعاملی با تأخیر کمتر از نیم ثانیه، مثل وبینار تعاملی، حراج زنده، آموزش آنلاین و گفت‌وگوی دوطرفه.
  • مزیت: کمترین تأخیر بین همهٔ پروتکل‌ها و پخش مستقیم در مرورگر بدون نصب برنامه.
  • محدودیت: رساندن آن به تعداد خیلی زیاد بیننده پیچیده و پرهزینه است، چون زیرساخت مخصوص لازم دارد.
  • WHIP یک استاندارد جدیدتر است که ارسال استریم با WebRTC را ساده می‌کند. نسخه‌های جدید OBS هم از آن پشتیبانی می‌کنند.

HLS و LL-HLS

HLS (HTTP Live Streaming) که اپل معرفی کرد، امروز رایج‌ترین پروتکل برای تحویل پخش زنده به بیننده است.

  • روش کار: ویدیو به تکه‌های چندثانیه‌ای تقسیم می‌شود و پلیر آن‌ها را مثل فایل‌های معمولی از طریق HTTP دانلود و پشت سر هم پخش می‌کند.
  • مزیت: روی تقریباً همهٔ دستگاه‌ها و مرورگرها کار می‌کند، با CDN به‌راحتی برای میلیون‌ها بیننده مقیاس‌پذیر است و کیفیت تطبیقی دارد، یعنی اگر اینترنت بیننده ضعیف شود، پلیر خودکار کیفیت پایین‌تری پخش می‌کند تا تصویر قطع نشود.
  • محدودیت: تأخیر نسبتاً زیاد، معمولاً چند ثانیه تا حدود نیم دقیقه.
  • LL-HLS (Low-Latency HLS) نسخهٔ کم‌تأخیر HLS است و تأخیر را به حدود ۲ تا ۵ ثانیه می‌رساند، به شرطی که سرور و پلیر از آن پشتیبانی کنند.

MPEG-DASH

MPEG-DASH یک استاندارد بین‌المللی و مستقل از شرکت خاص است که روش کارش شبیه HLS است: تکه‌تکه کردن ویدیو و ارسال روی HTTP با کیفیت تطبیقی.

  • کاربرد اصلی: پخش ویدیو در سرویس‌های بزرگ و پلیرهای تحت وب.
  • مزیت: استاندارد باز، انعطاف‌پذیر و مستقل از نوع کدک.
  • محدودیت: پشتیبانی بومی در دستگاه‌های اپل ندارد، برای همین بسیاری از سرویس‌ها کنار آن HLS را هم ارائه می‌دهند. تأخیرش هم مثل HLS است، مگر اینکه از نسخهٔ کم‌تأخیر (LL-DASH) استفاده شود.

مقایسهٔ تأخیر

مقایسهٔ تأخیر پروتکل‌های استریم

جدول مقایسه

پروتکل نقش اصلی تأخیر معمول پخش در مرورگر مقیاس‌پذیری برای بیننده زیاد نقطهٔ قوت
RTMP / RTMPS ارسال ۲ تا ۵ ثانیه ❌ ❌ پشتیبانی همه‌جا، سادگی
SRT ارسال ۰٫۵ تا ۲ ثانیه ❌ ❌ پایداری روی اینترنت ضعیف
RTSP ارسال از دوربین ۰٫۵ تا ۲ ثانیه ❌ ❌ دوربین‌های IP و نظارتی
WebRTC / WHIP ارسال و تحویل تعاملی کمتر از ۰٫۵ ثانیه ✅ محدود و پرهزینه کمترین تأخیر
HLS تحویل ۶ تا ۳۰ ثانیه ✅ ✅ سازگاری کامل و پایداری
LL-HLS تحویل ۲ تا ۵ ثانیه ✅ ✅ تأخیر کمتر با مزایای HLS
MPEG-DASH تحویل ۶ تا ۳۰ ثانیه ✅ ✅ استاندارد باز

اعداد تأخیر تقریبی‌اند و به تنظیمات سرور، کیفیت شبکه و پلیر بستگی دارند.

کدام را انتخاب کنیم؟

  • برای ارسال از OBS، vMix یا موبایل به یک سرویس پخش: RTMP یا RTMPS. ساده‌ترین و سازگارترین گزینه است.
  • برای ارسال از محل رویداد با اینترنت ناپایدار: SRT، اگر سرویس مقصد پشتیبانی کند.
  • برای وصل کردن دوربین مداربسته یا دوربین IP: RTSP، که روی سرور به پروتکل مناسب بیننده تبدیل می‌شود.
  • برای پخش به تعداد زیادی بیننده در سایت یا اپ: HLS، و اگر تأخیر کم مهم است LL-HLS.
  • برای ارتباط واقعاً تعاملی و دوطرفه: WebRTC.

میرول از کدام پروتکل‌ها استفاده می‌کند؟

میرول استریم شما را با RTMP از نرم‌افزارهایی مثل OBS، vMix و Larix دریافت می‌کند و برای پخش روی مقصدهایی مثل لایو اینستاگرام، یوتیوب و آپارات هم از RTMP استفاده می‌کند. برای بینندگانی که پخش را در رسانهٔ اختصاصی شما در میرول یا روی سایت خودتان می‌بینند، یک لینک پخش HLS ساخته می‌شود. لینک‌های HLS را هم می‌توانید به‌عنوان مبدأ پخش به میرول بدهید.

برای شروع کار، این آموزش‌ها را ببینید:

جمع‌بندی

هیچ پروتکلی برای همهٔ کارها بهترین نیست. RTMP و SRT برای رساندن تصویر به سرور ساخته شده‌اند، HLS و DASH برای رساندن آن به بیننده‌های زیاد، و WebRTC برای وقتی که هر ثانیه تأخیر مهم است. بیشتر پخش‌های زندهٔ امروز ترکیبی از این‌ها هستند: ارسال با RTMP و تحویل با HLS.

دیدگاه‌ها

دیدگاه خود را بنویسید

نشانی ایمیل شما منتشر نمی‌شود. دیدگاه پس از تأیید مدیر نمایش داده خواهد شد.