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

این سند نحوه استفاده از پروتکل «جاری‌سازی زنده اچ‌تی‌تی‌پی» (HLS) را برای جاری‌سازی داده‌های زنده در YouTube از کدبند توضیح می‌دهد. این سند برای فروشندگان کدبند است که می‌خواهند پشتیبانی از انتقال HLS را به محصولات خود اضافه کنند. دریافت HLS انتخاب خوبی برای محتوای ممتاز است که به کیفیت بالا و وضوح بالا با تأخیر نسبتاً بیشتر نیاز دارد. برای مقایسه مختصر پروتکل‌های انتقال مختلفی که «جاری‌سازی زنده YouTube» پشتیبانی می‌کند، به مقایسه پروتکل انتقال جاری‌سازی زنده YouTube مراجعه کنید.

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

هر «بخش رسانه» نشان‌دهنده محتوای چندرسانه‌ای واقعی برای بخشی کوتاه از جاری‌سازی است که بین یک تا چهار ثانیه طول می‌کشد. هر «فهرست پخش رسانه» نحوه مونتاژ مجدد «بخش‌های رسانه» را به ترتیب صحیح جاری‌سازی شرح می‌دهد.

الزامات قالب رسانه

دریافت HLS در YouTube برای محتوای ویدیویی و صوتی الزامات زیر را دارد:

• ویدیو و صدا باید در قالب M2TS ترکیب شوند.
• کدک‌های ویدیویی پشتیبانی‌شده H.264 و HEVC هستند.
• نرخ فریم تا ۶۰ فریم در ثانیه پشتیبانی می‌شود.
• فقط GOP بسته پشتیبانی می‌شود.
• کدک صوتی پشتیبانی‌شده AAC است و فقط از صدای تک‌آهنگ پشتیبانی می‌شود.

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

HDR

ویدیو «دامنه پویای بالا» (HDR) بااستفاده از کدک HEVC پشتیبانی می‌شود و الزامات تکمیلی زیر را دارد:

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

دریافت نشانی وب انتقال داده HLS

دریافت نشانی وب انتقال داده HLS از YouTube API

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

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

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

دریافت نشانی وب انتقال داده HLS از «استودیوِ YouTube»

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

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

می‌توانید نشانی وب 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=

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

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

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

تکمیل نشانی وب انتقال داده HLS

نشانی‌های وب به‌دست‌آمده بااستفاده از هریک از این روش‌ها الگوهای ناقصی هستند؛ هرکدام با پارامتر پُرسمان file= خالی به‌پایان می‌رسند. برای تشکیل نشانی وب نهایی، کدبند باید نام فایل «فهرست پخش رسانه» یا «بخش رسانه» را به انتهای نشانی وب اضافه کند، و به این ترتیب پارامتر file= را تکمیل کند.

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

• کدبند می‌تواند نام فایل «فهرست پخش رسانه» یا «بخش رسانه» را از نویسه‌های الفباعددی، زیرخط، کج‌خط، خط تیره، و نقطه بسازد؛ نویسه‌های دیگر پشتیبانی نمی‌شوند.
• کدبند نباید نام فایل را کدبندی نشانی وب کند.
• کدبند ممکن است شامل مؤلفه‌های مسیر نسبی یا مطلق در نام فایل‌ها باشد، اگرچه این هرگز الزامی نیست. اگر کدبند شامل مؤلفه مسیر در نام فایل «بخش رسانه» باشد، باید به همان مسیر در مدخل فهرست پخش مربوطه ارجاع دهد.

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

«فهرست‌های پخش رسانه» و «بخش‌های رسانه» ارسال‌شده توسط کدبند باید با مشخصات نسخه دوم جاری‌سازی زنده اچ‌تی‌تی‌پی مطابقت داشته باشند.

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

کدبند باید:

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

بخش‌های زیر حاوی الزامات دقیق‌تر برای «فهرست‌های پخش رسانه» و «بخش‌های رسانه» است.

فهرست‌های پخش رسانه

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

الزامات

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

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

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

• «فهرست پخش رسانه» نباید بیش‌از پنج بخش معوقه داشته باشد. اگر سرور بخشی را دریافت نکرده باشد یا رسید آن را تأیید نکرده باشد، آن بخش معوقه است.

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

  توجه داشته باشید که سرور دریافت «بخش رسانه» را با برگرداندن پاسخ 200 (OK) یا 202 (Accepted) در بارگذاری آن بخش تأیید می‌کند. پاسخ A 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

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

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

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

مدت بخش رسانه

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

توصیه می‌کنیم مدت «بخش رسانه» یک تا چهار ثانیه باشد زیرا داشتن «بخش‌های رسانه» کوچک‌تر می‌تواند منجر به تأخیر کمتر شود، هرچند این امر به قیمت نرخ میان‌گیرسازی مجدد بالاتر و بازده کدبندی پایین‌تر تمام می‌شود. همان‌طور که در بخش قبلی اشاره شد، «بخش‌های رسانه» نباید طولانی‌تر از ۵ ثانیه باشد.

نرخ‌های بیت

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

توجه داشته باشید که HEVC به‌طورکلی در مقایسه با H.264، فشرده‌سازی داده‌ها را با همان کیفیت ویدیو بین ۲۵ تا ۵۰ درصد افزایش می‌دهد. به همین دلیل، مقادیر نرخ بیت در انتهای پایین‌تر محدوده‌های پیشنهادی را می‌توان با HEVC برای صرفه‌جویی در پهنای باند استفاده کرد، که به‌ویژه برای محتوای 4K مفید است.

سایر الزامات

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

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

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

زیرنویس ناشنوایان

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

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

کدهای پاسخ HTTP

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

‫۲۰۰ (OK)

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

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

‫۲۰۲ (پذیرفته‌شده)

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

‫۴۰۰ (درخواست نامناسب)

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

• URL خراب است
• فهرست پخش تجزیه نمی‌شود یا حاوی برچسب‌های پشتیبانی‌نشده است

‫۴۰۱ (غیرمجاز)

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

‫۴۰۵ (روش مجاز نیست)

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

‫۵۰۰ (خطای سرور داخلی)

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