ارائه محتوای زنده YouTube از طریق HLS

این سند نحوه استفاده از پروتکل HLS (HTTP Live Streaming) را برای پخش جریانی داده‌های زنده در YouTube از یک رمزگذار توضیح می‌دهد. این سند برای فروشندگان رمزگذار در نظر گرفته شده است که می خواهند پشتیبانی جذب HLS را به محصولات خود اضافه کنند. مصرف HLS انتخاب خوبی برای محتوای ممتاز است که به کیفیت بالا و وضوح بالا با تاخیر نسبتاً بالاتر نیاز دارد. برای مقایسه مختصری از پروتکل‌های انتقال مختلف که YouTube Live Streaming پشتیبانی می‌کند، به این سند مراجعه کنید.

برای پخش جریانی داده‌های زنده از طریق HLS، رمزگذار باید مجموعه‌ای از فهرست‌های پخش رسانه و بخش‌های رسانه را از طریق درخواست‌های HTTP PUT یا POST به نقطه پایانی HLS YouTube ارسال کند. از دیدگاه رمزگذار، به نظر می رسد نقطه پایانی YouTube HLS یک سرور HTTP غیرفعال است.

هر بخش رسانه، محتوای چندرسانه ای واقعی را برای بخش مختصری از جریان به مدت یک تا چهار ثانیه نشان می دهد. هر فهرست پخش رسانه نحوه جمع‌آوری مجدد بخش‌های رسانه به ترتیب پخش جریانی صحیح را شرح می‌دهد.

الزامات فرمت رسانه

دریافت YouTube HLS دارای شرایط زیر برای محتوای ویدیویی و صوتی است:

• ویدئو و صدا باید با فرمت M2TS مخلوط شوند.
• کدک های ویدیویی پشتیبانی شده H.264 و HEVC هستند.
• نرخ فریم تا 60 فریم در ثانیه پشتیبانی می شود.
• فقط GOP بسته پشتیبانی می شود.
• کدک صوتی پشتیبانی شده AAC است و فقط صدای تک تراک پشتیبانی می شود.

الزامات دقیق تر در مورد بخش های رسانه را در زیر مشاهده کنید.

HDR

ویدیوی محدوده دینامیکی بالا (HDR) از طریق کدک HEVC پشتیبانی می‌شود و دارای شرایط اضافی زیر است:

• استانداردهای رنگ پشتیبانی شده 10 بیتی PQ و HLG با درخشندگی غیر ثابت هستند. به طور خاص:
  • قالب Chroma باید YUV 4:2:0 10 بیتی باشد.
  • عملکرد انتقال باید PQ (با نام مستعار SMPTE ST 2084) یا HLG (معروف به ARIB STD-B67) باشد.
  • رنگ های اولیه باید Rec باشند. 2020.
  • ضرایب ماتریس باید Rec باشد. درخشندگی غیر ثابت 2020.
• هر دو مقادیر نمونه با برد محدود (یا محدوده MPEG) و دامنه کامل (یا محدوده JPEG) پشتیبانی می شوند. مهم است که محدوده با توجه به محدوده مقدار نمونه ای که محتوا استفاده می کند تنظیم شود. مقادیر نمونه با دامنه محدود توصیه می شود.

به دست آوردن یک URL ورودی HLS

دریافت یک URL انتقال HLS از API YouTube

برای به دست آوردن URL کامل انتقال، رمزگذارها می‌توانند از YouTube Live Streaming API برای درج منبع liveStream با ویژگی‌های زیر استفاده کنند:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

در پاسخ API، فیلد cdn.ingestionInfo.ingestionAddress نشانی اینترنتی انتقال اولیه را مشخص می‌کند و قسمت cdn.ingestionInfo.backupIngestionAddress نشانی اینترنتی انتقال نسخه پشتیبان را مشخص می‌کند. برای جزئیات بیشتر، به مستندات منبع liveStreams مراجعه کنید.

دریافت URL انتقال HLS از YouTube Creator Studio

احتیاط: این روش برای به دست آوردن آدرس های اینترنتی انتقال HLS یک ویژگی بتا است و ممکن است در آینده تغییر کند.

در رابط وب YouTube Creator Studio ، پس از اینکه سازنده روی «Create Stream» کلیک کرد، YouTube یک «کلید جریان» متشکل از نویسه‌های حروف عددی و خط تیره را نمایش می‌دهد. این کلید مخفی هم سازنده و هم جریان به YouTube را شناسایی می کند.

می توانید یک URL HLS از این کلید جریانی به شرح زیر بسازید:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... که در آن $STREAM_KEY کلید جریان نمایش داده شده در رابط وب است. به عنوان مثال: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

برای اطمینان بیشتر، می توانید یک کپی دوم اضافی از انتقال را به این URL پشتیبان انتقال دهید:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

توجه داشته باشید که نسخه پشتیبان دو تفاوت با URL اصلی دارد: هم نام میزبان و هم پارامتر copy= تغییر کرده اند. انتقال پشتیبان باید مقدار پارامتر copy= متفاوتی را نسبت به دریافت اولیه ارسال کند تا از خراب کردن جریان جلوگیری شود.

تکمیل URL انتقال HLS

URL های به دست آمده از طریق هر یک از روش های بالا، قالب های ناقص هستند. هر کدام با یک پارامتر file= query خالی به پایان می رسد. برای تشکیل URL نهایی، رمزگذار باید نام فایل یک فهرست پخش رسانه یا بخش رسانه را به انتهای URL اضافه کند، بنابراین پارامتر file= تکمیل کند.

قوانین زیر برای مقدار پارامتر file= اعمال می شود:

• رمزگذار ممکن است یک فهرست پخش رسانه یا نام فایل بخش رسانه از نویسه‌های الفبایی، زیرخط، اسلش‌های رو به جلو، خط تیره و نقطه بسازد. هیچ شخصیت دیگری پشتیبانی نمی شود.
• رمزگذار نباید URL نام فایل را رمزگذاری کند.
• رمزگذار ممکن است شامل اجزای مسیر نسبی یا مطلق در نام فایل ها باشد، اگرچه این هرگز لازم نیست. اگر رمزگذار شامل یک جزء مسیر در نام فایل Media Segment باشد، باید همان مسیر را در ورودی لیست پخش مربوطه ارجاع دهد.

الزامات پروتکل HLS

فهرست‌های پخش رسانه و بخش‌های رسانه ارسال شده توسط رمزگذار باید با مشخصات نسخه دوم پخش زنده HTTP مطابقت داشته باشد.

مشخصات HLS دو نوع لیست پخش را تعریف می کند: Media Playlist و Master Playlist. از آنجایی که YouTube محتوای پخش‌شده را با وضوح‌ها و نرخ بیت‌های مختلف رمزگذاری می‌کند، رمزگذار نیازی به ارسال محتوای با نرخ بیت متفاوت به YouTube ندارد. در نتیجه، YouTube فقط از فهرست‌های پخش رسانه برای دریافت HLS پشتیبانی می‌کند و فهرست‌های پخش اصلی نادیده گرفته می‌شوند. (یک لیست پخش اصلی مجموعه‌ای از جریان‌های متغیر را ارائه می‌کند که هر کدام نسخه متفاوتی از همان محتوا را توصیف می‌کنند.)

رمزگذار باید:

• دقیقاً یک جریان رمزگذاری شده با بالاترین وضوحی که می خواهید برای کاربران ارائه شود (تک رزولوشن و کدک) ارسال کنید.
• mux صوتی و تصویری
• از HTTPS و یک اتصال دائمی برای همه درخواست ها استفاده کنید

بخش‌های زیر شامل الزامات خاص‌تری برای فهرست‌های پخش رسانه و بخش‌های رسانه است.

لیست پخش رسانه ها

فهرست پخش رسانه‌ای حاوی فهرستی از بخش‌های رسانه است که می‌توانند برای نمایش یک جریان چندرسانه‌ای پیوسته و قابل رمزگشایی به هم متصل شوند. فهرست پخش رسانه‌ها به سرور می‌گوید کدام بخش‌های رسانه را باید انتظار داشته باشد و چگونه آنها را به درستی در جریان دوباره مونتاژ شده سفارش دهد.

الزامات

• نام فایل فهرست پخش رسانه باید به .m3u8 یا .m3u ختم شود.

• اولین فهرست پخش رسانه ارسال شده برای پخش جریانی باید از دنباله شماره 0 شروع شود و تعداد دنباله باید به طور یکنواخت افزایش یابد.

• تگ EXT-X-MEDIA-SEQUENCE باید شماره توالی اولین بخش رسانه فهرست شده در لیست پخش را مشخص کند.

• فهرست پخش رسانه ای نباید بیش از پنج بخش برجسته داشته باشد. اگر سرور آن را دریافت نکرده باشد یا دریافت آن را تایید نکرده باشد، بخش برجسته است.

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

  توجه داشته باشید که سرور دریافت یک بخش رسانه را با برگرداندن یک پاسخ 200 ( OK ) یا 202 ( Accepted ) در بارگذاری آن بخش تأیید می کند. پاسخ 202 نشان می دهد که سرور بخش را قبل از لیست پخشی که آن بخش را شناسایی می کند دریافت کرده است.

• یک فهرست پخش رسانه به روز شده برای هر بخش رسانه ارسال کنید تا در صورت گم شدن فهرست پخش رسانه، سرور بتواند به سرعت بازیابی شود.

• همانطور که سرور دریافت بخش های رسانه را تایید می کند، می توانید مقدار تگ EXT-X-MEDIA-SEQUENCE را افزایش دهید تا از طولانی شدن فهرست پخش رسانه جلوگیری کنید. به عنوان مثال، اگر سرور قبلاً دریافت نه بخش رسانه اول را تأیید کرده باشد، فهرست پخش رسانه بعدی ممکن است هشتمین، نهمین و دهمین بخش رسانه را فهرست کند.

• برچسب های EXT-X-KEY و EXT-X-SESSION-KEY پشتیبانی نمی شوند.

مثال ها

لیست زیر نمونه ای از فایل هایی را نشان می دهد که انتظار می رود رمزگذار ارسال کند:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

مثال زیر یک فهرست پخش رسانه ای را نشان می دهد که در وسط یک پخش زنده ویدیویی ارسال شده است. از آنجایی که مثال از وسط یک جریان است، تگ EXT-X-MEDIA-SEQUENCE یک مقدار غیر صفر دارد.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

بخش های رسانه ای

لیست زیر الزامات بخش های رسانه را مشخص می کند:

• نام فایل ها
  • نام فایل های بخش رسانه در URL باید دارای پسوند نام فایل .ts باشد و باید با نام فایل های موجود در لیست پخش مطابقت داشته باشد.
  • نام فایل‌های بخش رسانه باید در راه‌اندازی مجدد رمزگذار و راه‌اندازی مجدد جریان منحصربه‌فرد باشد.
• قالب
  • بخش‌های رسانه باید در قالب M2TS باشند و باید خودآغاز شوند.
  • هر بخش M2TS باید شامل یک برنامه MPEG-2 باشد.
  • بخش M2TS باید شامل یک PAT و یک PMT باشد و دو بسته اول انتقال جریان در یک بخش باید یک PAT و یک PMT باشند.
• محتوا
  • ویدئو و صدا باید مختل شوند.
  • کدک های ویدیویی پشتیبانی شده H.264 و HEVC هستند.
  • HDR با HEVC پشتیبانی می شود (به الزامات HDR مراجعه کنید).
  • نرخ فریم تا 60 فریم در ثانیه پشتیبانی می شود.
  • فقط GOP بسته پشتیبانی می شود.
  • کدک صوتی پشتیبانی شده AAC است و فقط صدای تک تراک پشتیبانی می شود.
  • همانطور که در بخش زیر بحث شد، توصیه می‌شود که بخش‌های رسانه دارای مدت زمان بین یک تا چهار ثانیه باشند. بخش‌های رسانه نباید بیش از 5 ثانیه طول بکشد.
  • بخش‌های رسانه فقط باید در لایه TLS/SSL با HTTPS رمزگذاری شوند. سایر مکانیسم های رمزگذاری پشتیبانی نمی شوند.

مدت زمان بخش رسانه

ما انتظار داریم که مصرف HLS برای محتوای ممتازی که به کیفیت بالا و وضوح بالا نیاز دارد استفاده شود. مصرف HLS معمولاً تأخیر بالاتری نسبت به مصرف‌های مبتنی بر RTMP و WebRTC دارد زیرا دریافت HLS مبتنی بر بخش است.

ما مدت زمان بخش رسانه یک تا چهار ثانیه را توصیه می‌کنیم، زیرا داشتن بخش‌های رسانه کوچک‌تر می‌تواند به تأخیر کمتری منجر شود، البته به قیمت نرخ بافر بالاتر و بازده کدگذاری کمتر. همانطور که در بخش قبل ذکر شد، بخش های رسانه نباید بیشتر از 5 ثانیه باشد.

نرخ بیت

مرکز راهنمایی YouTube دستورالعمل‌هایی را برای تنظیمات نرخ بیت ارائه می‌کند.

توجه داشته باشید که HEVC در مقایسه با H.264 معمولاً 25 تا 50 درصد فشرده‌سازی داده‌ها را با کیفیت ویدیوی مشابه انجام می‌دهد. به این ترتیب، مقادیر بیت ریت در انتهای پایین محدوده های پیشنهادی را می توان با HEVC برای صرفه جویی در پهنای باند استفاده کرد، که به ویژه برای محتوای 4K مفید است.

ملزومات دیگر

• رمزگذارها باید هدر User-Agent را در درخواست HTTP با استفاده از نحو زیر تنظیم کنند که شامل نام سازنده، نام مدل و نسخه است:

  User-Agent: <manufacturer> / <model> / <version>
  

  توجه: این اطلاعات فقط برای اهداف اشکال زدایی استفاده خواهد شد. برای تصمیم گیری های کاربردی در مدیریت جریان استفاده نمی شود.

زیرنویس‌های بسته

دریافت HLS از دو گزینه برای ارسال زیرنویس‌ها پشتیبانی می‌کند:

• زیرنویس‌های بسته را از طریق درخواست‌های HTTP POST جداگانه ارسال کنید. این برای همه مصرف‌های HLS کار می‌کند.
• زیرنویس‌های بسته 608/708 جاسازی‌شده با دریافت‌های HLS که از کدک ویدیویی H264 استفاده می‌کنند، کار می‌کنند، اما با مواردی که از کدک ویدیویی HEVC استفاده می‌کنند، کار نمی‌کنند. برای جزئیات بیشتر به الزامات زیرنویس زنده در مرکز راهنمایی YouTube مراجعه کنید.

کدهای پاسخ HTTP

بخش‌های زیر کدهای پاسخی را که YouTube در پاسخ به بخش‌های رسانه و فهرست‌های پخش رسانه ارائه شده از طریق HLS برمی‌گرداند، توضیح می‌دهد.

200 (خوب)

در پاسخ به یک درخواست PUT یا POST، یک پاسخ HTTP 200 (OK) نشان می دهد که سرور YouTube عملیات مورد انتظار را دریافت کرده و آن را با موفقیت انجام داده است.

در پاسخ به درخواست DELETE، یک پاسخ HTTP 200 (OK) نشان می دهد که سرور YouTube درخواست را دریافت کرده و نادیده گرفته است. سرور YouTube به مشتری نیازی به حذف هیچ منبعی در جریان ندارد و درخواست‌های DELETE را نادیده می‌گیرد. به دلایل عملکرد، YouTube به مشتریان توصیه می‌کند که DELETE ارسال نکنند.

202 (پذیرفته شده)

پاسخ HTTP 202 (پذیرفته شده) نشان می دهد که سرور YouTube قبل از دریافت فهرست پخش رسانه حاوی آن بخش رسانه، بخش رسانه را دریافت کرده است. این به مشتری نشان می دهد که باید فهرست پخش رسانه حاوی آن بخش رسانه را در اسرع وقت ارسال کند تا از تاخیر در پردازش آن بخش جلوگیری شود. توجه داشته باشید که اگر رمزگذار یک فهرست پخش رسانه به روز شده برای هر بخش رسانه ارسال کند، مشکلی پیش نخواهد آمد.

400 (درخواست بد)

پاسخ HTTP 400 (درخواست بد) نشان دهنده یکی از مشکلات زیر است:

• URL بد شکل است
• لیست پخش قابل تجزیه نیست یا حاوی برچسب های پشتیبانی نشده است

401 (غیر مجاز)

پاسخ HTTP 401 (غیر مجاز) نشان می‌دهد که پارامتر cid در URL پایه برای نقطه پایانی YouTube HLS خراب یا منقضی شده است. مشتری برای ادامه باید پارامتر cid را به روز کند.

405 (روش مجاز نیست)

پاسخ HTTP 405 (روش مجاز نیست) نشان می دهد که درخواست یک درخواست POST، PUT یا DELETE نبوده است.

500 (خطای سرور داخلی)

پاسخ HTTP 500 (خطای سرور داخلی) نشان می دهد که سرور قادر به پردازش درخواست نیست. برای این خطا، توصیه می‌کنیم درخواست را با عقب‌نشینی نمایی دوباره امتحان کنید.