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

این سند دستورالعمل‌هایی را برای استفاده از پخش جریانی تطبیقی ​​پویا از طریق قالب تحویل HTTP (DASH) برای پخش جریانی داده‌های زنده در YouTube از یک رمزگذار ارائه می‌کند. در نظر گرفته شده است که به فروشندگان رمزگذار کمک کند تا پشتیبانی تحویل DASH را به محصولات خود اضافه کنند.

درک DASH

لیست زیر برخی از ویژگی ها و ویژگی های کلیدی DASH را فهرست می کند:

• بر اساس استانداردهای باز
• مبتنی بر HTTP. در نتیجه، DASH سازگار با زیرساخت اینترنت است و می تواند از فایروال ها عبور کند.
• پشتیبانی از نرخ انتقال بیت بالا DASH از چندین جلسه HTTP همزمان و تحویل غیر متوالی بخش پشتیبانی می کند و انعطاف پذیری بیشتری را نسبت به پروتکل هایی که بر یک اتصال TCP تکیه دارند ارائه می دهد.
• تحویل ایمن از طریق HTTPS.
• تحویل بدون ضرر از طریق HTTP و HTTPS.
• کدک آگنوستیک.
• پشتیبانی از MP4 حاوی H264 و AAC و همچنین WebM حاوی VP8/VP9 و Vorbis/Opus.

مشخصات

• DASH در ISO/IEC 23009-1:2014 فناوری اطلاعات توضیح داده شده است - جریان تطبیقی ​​پویا از طریق HTTP (DASH) .
• WebM over DASH در مشخصات WebM DASH توضیح داده شده است.

الزامات

بخش‌های فرعی زیر الزامات استفاده از DASH برای ارائه جریان‌های زنده به YouTube را توضیح می‌دهند.

زمان بندی

نقطه پایانی YouTube DASH مانند یک سرور HTTP غیرفعال عمل می کند و تماس های روش PUT ارسال شده توسط رمزگذار را ضبط می کند.

• نقطه پایانی DASH از اتصالات TCP همزمان پشتیبانی می کند. می‌توانید طبق HTTP/1.1 از اتصالات دوباره استفاده کنید.
• بخش های MPD و Initialization باید در عرض 3 ثانیه از اولین بخش رسانه قرار داده شوند. (توصیه می کنیم بخش Initialization را در MPD قرار دهید .)
• هر بخش یا MPD باید از یک درخواست PUT جداگانه استفاده کند. آپلود چند قسمتی چندین بخش پشتیبانی نمی شود.
• عملیات PUT برای بخش‌های رسانه ممکن است در زمان برای بهبود پهنای باند آپلود همپوشانی داشته باشند.
• بخش ها را می توان به ترتیب غیر متوالی در یک پنجره زمانی تقریباً 3 ثانیه ای ارائه کرد.
• بخش های MPD و Initialization باید حداقل هر 60 ثانیه یکبار با availabilityStartTime و startNumber به روز شوند. (همانطور که در بالا ذکر شد، بخش Initialization را می توان در MPD گنجاند . در این صورت، یک درخواست PUT می تواند هر دو بخش را به روز کند.)

ساختار URL

رمزگذار شما باید URL های PUT را با الحاق یک رشته به URL پایه نقطه پایانی YouTube تشکیل دهد. باید با استفاده از YouTube Live Streaming API، نقطه پایانی انتقال DASH را ایجاد کنید.

رمزگذار متعاقباً می‌تواند URL پایه نقطه پایانی را به‌صورت برنامه‌نویسی از طریق YouTube Live Streaming API دریافت کند. اگر بخواهید URL را به صورت دستی در اختیار رمزگذار قرار دهید، نشانی وب پایه نیز در رابط کاربری رویدادهای زنده YouTube قابل مشاهده است.

رشته اضافه شده به URL پایه می تواند شامل مجموعه زیر از کاراکترهای ASCII باشد:

• حروف کوچک: az
• حروف بزرگ: AZ
• ارقام: 0-9
• کاراکترهای ویژه: _ (زیر خط)، - (خط تیره)، . (دوره)

آدرس های MPD

علاوه بر شرط بالا، URL MPD باید به .mpd ختم شود و سرور YouTube را قادر می سازد MPD را به راحتی شناسایی کند. سایر URL های بخش نباید به .mpd ختم شوند.

مقداردهی اولیه و URL های بخش رسانه

اگر داده‌ها در یک محفظه ISO BMFF هستند، نشانی وب بخش اولیه و همه نشانی‌های وب بخش رسانه باید به .mp4 یا اگر داده‌ها در محفظه WebM هستند، به .webm ختم شوند.

محتویات MPD

MPD باید کامل و مطابق با استاندارد DASH باشد. باید دقیقاً حاوی یکی از هر یک از عناصر زیر باشد. این فهرست عناصری را که به طور خاص توسط YouTube مورد نیاز است را مشخص می کند و استاندارد DASH ممکن است عناصر مورد نیاز اضافی را شناسایی کند. عناصر با استفاده از سینتکس XPath نمایش داده می شوند و با استاندارد DASH سازگار هستند.

• /mpd:MPD/attribute::type
• /mpd:MPD/mpd:Period
• /mpd:MPD/mpd:Period/mpd:AdaptationSet
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

لطفاً به الزامات زیر برای مقادیر عناصر توجه کنید:

• ویژگی minimumUpdatePeriod عنصر <MPD> باید روی مقداری برابر یا کمتر از 60 ثانیه تنظیم شود ( PT60S ).
• ویژگی media عنصر <SegmentTemplate> باید مشخص کند که URL های بخش رسانه با استفاده از $Number$ تولید می شوند. (ویژگی startNumber شماره ای را که به اولین بخش رسانه اختصاص داده می شود، مشخص می کند.)

طول بخش مقداردهی اولیه

بخش Initialization نباید بیشتر از 100 کیلوبایت باشد. (معمولاً، یک بخش Initialization بسیار کوچکتر از آن است.) اگر بخش Initialization در MPD گنجانده شود، آنگاه data: URL که شامل بخش است، نباید بیشتر از 100 کیلوبایت باشد.

خروجی رمزگذار

بخش Initialization و بخش‌های رسانه باید یک جریان فایل ISO BMFF یا WebM با GOPهای بسته (گروه‌هایی از تصاویر) را تشکیل دهند.

• اندازه GOP باید حدود 2 ثانیه باشد و باید کمتر از 8 ثانیه باشد.
• جریان مالتی پلکس باید شامل تراک های صوتی و تصویری باشد.

بهترین شیوه های اضافی

رمزگذاری

یوتیوب از رمزگذاری جریان از طریق HTTPS پشتیبانی می کند. اکیدا توصیه می کنیم از این قابلیت استفاده کنید.

بخش های اولیه سازی در MPD

شما می توانید بخش Initialization را مستقیماً در MPD با استفاده از یک data: URL، به ازای RFC 2397 . این کار تنظیم جریان شما را ساده می کند و احتمال اینکه بخش Initialization با بقیه جریان مطابقت نداشته باشد را کاهش می دهد.

XPath برای این عنصر:

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

مدت زمان بخش هدف

برای عملکرد خوب انتقال و یک مبادله خوب بین توان عملیاتی و تأخیر، طول بخش‌های رسانه شما باید بین ۱ تا ۵ ثانیه باشد. ما قویاً توصیه می کنیم که مدت زمان هدف آن بخش ها در MPD را با استفاده از این دو عنصر اعلام کنید:

• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

مدت زمان محاسبه شده از این ویژگی ها باید در ضریب 2 از تمام مدت زمان واقعی بخش باشد یا عملکرد پخش ممکن است آسیب ببیند.

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

تلاش های مجدد و عقب نشینی نمایی

همه درخواست‌های HTTP PUT باید با مهلت زمانی انجام شوند که توصیه می‌کنیم مقدار آن را ۵۰۰ میلی‌ثانیه بیشتر از مدت زمان بخش تنظیم کنید.

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

1. پس از شکست، یک دوره تصادفی بین [0 ... 100] میلی ثانیه صبر کنید و درخواست را دوباره امتحان کنید.
2. اگر درخواست دوباره با شکست مواجه شد، یک دوره تصادفی بین [0 ... 200] میلی ثانیه صبر کنید و دوباره درخواست را امتحان کنید.
3. اگر درخواست دوباره با شکست مواجه شد، یک دوره تصادفی بین [0 ... 400] میلی ثانیه صبر کنید و دوباره درخواست را امتحان کنید.
4. و غیره

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

کدهای پاسخ HTTP

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

200 (خوب)

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

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

پاسخ HTTP 202 (پذیرفته شده) به هر عملیات PUT یا POST نشان می دهد که عملیات غیرمنتظره بوده و برای پردازش معوق پذیرفته شده است. با این حال، عملیات به تعویق افتاده می تواند موفقیت آمیز یا ناموفق باشد، بنابراین پاسخ تضمین نمی کند که YouTube واقعاً می تواند عملیات را با موفقیت پردازش کند.

این پاسخ اغلب زمانی رخ می دهد که یک بخش به صورت غیر متوالی تحویل داده شود. معمولاً YouTube می‌تواند پس از دریافت بخش‌های قبلی، بخش پذیرفته شده را به درستی پردازش کند و نیازی به ارسال مجدد بخش ندارید.

به عنوان مثال، YouTube می‌تواند در هر یک از موارد زیر پاسخ 202 را برگرداند:

• یک بخش اولیه قبل از MPD دریافت می شود.
• بخش های رسانه قبل از بخش های MPD و Initialization دریافت می شوند.
• یک بخش رسانه قبل از بخش قبلی دریافت می شود، مانند بخش 3 که قبل از بخش 2 دریافت می شود.

با این حال، اگر YouTube نتواند پس از دریافت درخواست POST یا PUT، شناسه را به طور کامل تأیید کند، یک پاسخ 202 همچنین می‌تواند نشان دهد که شناسه مورد نادرست است. به عنوان مثال، یکی از مواردی که این اتفاق می افتد زمانی است که YouTube قبل از دریافت MPD یک بخش اولیه را دریافت کرده و می پذیرد، اما مشخص می شود که بخش اولیه نامعتبر است. در این مورد، YouTube بخش اولیه را می‌پذیرد و 202 را برمی‌گرداند، سپس مشخص می‌کند که آیا بخش پس از دریافت MPD معتبر است یا خیر. شما می توانید با قرار دادن بخش Initialization در MPD از این سناریوی خاص جلوگیری کنید.

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

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

• URL بد شکل است.
• پست خیلی بزرگ است (> 10 مگابایت).
• MPD قابل تجزیه نیست.
• بخش Initialization در MPD خراب است.

401 (غیر مجاز)

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

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

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

409 (تعارض)

پاسخ HTTP 409 (تعارض) به هر عملیات PUT یا POST نشان می دهد که YouTube نمی تواند درخواست را پردازش کند. برای مثال، این پاسخ ممکن است در صورتی رخ دهد که درخواست‌کننده بخش‌های رسانه‌ای متعددی ارسال کرده باشد، اما YouTube هنوز MPD، بخش Initialization یا هر دو را ندارد. در آن مثال، رمزگذار باید قبل از امتحان مجدد درخواست ناموفق، بخش‌های MPD و Initialization را دوباره ارسال کند.

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

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

نمونه ها

دنباله URL

دنباله URL زیر مجموعه ای از درخواست های PUT را نشان می دهد که برای ارائه محتوا از طریق DASH انجام می شود. توالی فرض می کند که URL پایه برای نقطه پایانی YouTube DASH این است:

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

توالی بخش MPD و Initialization را به طور جداگانه ارسال می کند. با این حال، بخش Initialization را می توان مستقیماً در MPD نشان داد ، و این تمرین توصیه می شود. علاوه بر این، بخش های MPD و Initialization باید حداقل هر 60 ثانیه به روز شوند. بنابراین، در نهایت، آدرس‌های اینترنتی برای آن بخش‌ها دوباره در این دنباله ظاهر می‌شوند و سپس آدرس‌هایی برای بخش‌های رسانه بیشتر دنبال می‌شوند.

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

بخش های وب ام

MPD با بخش Initialization تعبیه شده

MPD نمونه زیر یک بخش Initialization تعبیه شده در URL داده RFC 2397 دارد. توصیه می کنیم به جای ارسال جداگانه، بخش Initialization را به این روش جاسازی کنید.

این مثال با دریافت WebM (VP8 یا VP9، Opus) در YouTube مطابقت دارد. اکثر URL داده ها برای خوانایی حذف شده اند:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

MPD نمونه زیر، که بخش Initialization تعبیه‌شده ندارد، برای دریافت WebM (VP8 یا VP9، Opus) در YouTube نیز مطابقت دارد:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

مقداردهی اولیه

شکل زیر طرح بندی یک بخش نمونه اولیه WebM را نشان می دهد. این شامل بخشی از جریان WebM تا اولین خوشه است اما شامل آن نمی شود.

رسانه ها

شکل زیر طرح‌بندی یک بخش رسانه WebM نمونه را نشان می‌دهد. از یک خوشه WebM تشکیل شده است. همانند یک جریان ISO BMFF، بخش Initialization که به مجموعه ای از خوشه ها اضافه شده است باید یک جریان WebM معتبر تولید کند.

بخش های ISO BMFF

MPD با بخش Initialization تعبیه شده

MPD نمونه زیر یک بخش Initialization تعبیه شده در URL داده RFC 2397 دارد. توصیه می کنیم به جای ارسال جداگانه، بخش Initialization را به این روش جاسازی کنید.

این مثال با ISO BMFF (H.264, AAC) در YouTube مطابقت دارد. اکثر URL داده ها برای خوانایی حذف شده اند:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

MPD نمونه زیر، که بخش Initialization تعبیه‌شده ندارد، همچنین با ISO BMFF (H.264, AAC) در YouTube مطابقت دارد:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

مقداردهی اولیه

نمودار زیر طرح بندی یک قطعه نمونه مولتی پلکس ISO BMFF Initialization را نشان می دهد. یوتیوب لزوما از اتم ها استفاده نمی کند، اما این یک مثال مطابق است. به طور خاص، هر دو آهنگ صوتی و تصویری نشان داده می شوند.

رسانه ها

نمودار زیر طرح بندی یک قطعه رسانه ای ISO BMFF مالتی پلکس شده را نشان می دهد. یوتیوب لزوماً از همه اتم ها استفاده نمی کند، اما این یک مثال مطابق است. به طور خاص، هر دو آهنگ صوتی و تصویری نشان داده می شوند. یک سری از این بخش ها را می توان به یک بخش Initialization اضافه کرد تا یک جریان ISO BMFF مالتی پلکس معتبر و کامل تولید کند.

محدودیت های شناخته شده

مصرف‌های RTMP و DASH

ترکیب RTMP و DASH در YouTube ممکن نیست. این امر برای جابه‌جایی بین این دو در طول پخش و همچنین استفاده از یکی به عنوان روش اصلی و دیگری برای انتقال پشتیبان اعمال می‌شود.