ارائه محتوای زنده 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 Information technology -- Dynamic adaptive streaming over HTTP (DASH) توصیف شده است.
• WebM over DASH در مشخصات WebM DASH شرح داده شده است.

الزامات

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

زمان‌بندی

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

• نقطه پایانی DASH از اتصالات هم‌زمان TCP پشتیبانی می‌کند. می‌توانید از اتصالات طبق HTTP/1.1 مجدداً استفاده کنید.
• بخش‌های MPD و «مقداردهی اولیه» باید ظرف ۳ ثانیه از اولین بخش رسانه PUT شوند. (توصیه می‌کنیم که بخش «مقداردهی اولیه» را در MPD بگنجانید.)
• هر بخش یا MPD باید از درخواست PUT جداگانه‌ای استفاده کند؛ بارگذاری چندبخشی چند بخش پشتیبانی نمی‌شود.
• عملیات PUT برای بخش‌های رسانه ممکن است ازنظر زمانی هم‌پوشانی داشته باشند تا پهنای باند بارگذاری بهبود یابد.
• بخش‌ها را می‌توان به‌ترتیب غیرمتوالی در یک پنجره زمانی تقریباً ۳ ثانیه‌ای ارائه کرد.
• بخش‌های MPD و «مقداردهی اولیه» باید حداقل هر ۶۰ ثانیه با availabilityStartTime و startNumber به‌روزشده به‌روزرسانی شوند. (همان‌طور که در بالا ذکر شد، بخش «مقداردهی اولیه» می‌تواند در MPD گنجانده شود. دراین‌صورت، یک درخواست PUT می‌تواند هر دو بخش را به‌روز کند.)

ساختار نشانی وب

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

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

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

• حروف کوچک: a-z
• حروف بزرگ: A-Z
• ارقام: ۰-۹
• نویسه‌های خاص: _ (زیرخط)، - (خط تیره)، . (نقطه) را فشار دهید.

نشانی‌های وب MPD

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

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

اگر داده‌ها در محفظه 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> باید روی مقداری برابر یا کمتر از ۶۰ ثانیه (PT60S) تنظیم شود.
• مشخصه media عنصر <SegmentTemplate> باید مشخص کند که نشانی‌های وب بخش رسانه بااستفاده از $Number$ تولید شده‌اند. (مشخصه startNumber عددی را که به اولین بخش رسانه اختصاص داده خواهد شد شناسایی می‌کند.)

طول بخش راه‌اندازی

بخش «مقداردهی اولیه» نباید طولانی‌تر از ۱۰۰ کیلوبایت باشد. (معمولاً بخش «مقداردهی اولیه» بسیار کوچک‌تر از این است.) اگر بخش «مقداردهی اولیه» در MPD گنجانده شده است، نشانی وب data: که حاوی بخش است نباید بیشتر از ۱۰۰ کیلوبایت باشد.

خروجی کدبند

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

• اندازه GOP باید حدود ۲ ثانیه باشد و باید کمتر از ۸ ثانیه باشد.
• جاری‌سازی چندگانه باید شامل قطعه‌های صوتی و ویدیویی باشد.

روال‌های مطلوب بیشتر

رمزگذاری

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

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

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

XPath این عنصر:

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

توجه: نشانی وب data: نباید طولانی‌تر از ۱۰۰ هزار بایت باشد.

مدت بخش هدف

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

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

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

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

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

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

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

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

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

کدهای پاسخ HTTP

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

‫۲۰۰ (تأیید)

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

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

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

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

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

• بخش مقداردهی اولیه قبل‌از MPD دریافت می‌شود.
• بخش‌های رسانه قبل‌از بخش‌های MPD و Initialization دریافت می‌شوند.
• یک بخش رسانه قبل‌از بخش قبلی دریافت می‌شود، مثلاً بخش ۳ قبل‌از بخش ۲ دریافت می‌شود.

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

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

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

• نشانی وب ناقص است.
• پست خیلی بزرگ است (بیشتر از ۱۰ مگابایت).
• MPD تجزیه نمی‌شود.
• بخش مقداردهی اولیه در MPD خراب است.

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

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

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

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

‫۴۰۹ (تداخل)

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

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

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

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

مثال‌ها

توالی نشانی وب

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

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

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

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
...

بخش‌های WebM

MPD با بخش «راه‌اندازی» جاسازی‌شده

MPD نمونه زیر دارای یک بخش «مقداردهی اولیه» جاسازی‌شده در یک نشانی وب داده RFC 2397 است. توصیه می‌کنیم که بخش «مقداردهی اولیه» را به این روش جاسازی کنید و آن را جداگانه ارسال نکنید.

این نمونه برای انتقال 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="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 زیر که بخش «مقداردهی اولیه» جاسازی‌شده ندارد، برای انتقال 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، بخش «مقداردهی اولیه» که به مجموعه‌ای از خوشه‌ها اضافه شده است باید جاری‌سازی WebM معتبری تولید کند.

بخش‌های ISO BMFF

MPD با بخش «راه‌اندازی» جاسازی‌شده

«MPD» نمونه زیر دارای یک بخش «راه‌اندازی» جاسازی‌شده در نشانی وب داده RFC 2397 است. توصیه می‌کنیم بخش «مقداردهی اولیه» را به‌جای ارسال جداگانه، به این روش جاسازی کنید.

این مثال برای انتقال 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"
    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 زیر که بخش «راه‌اندازی» جاسازی‌شده ندارد، برای انتقال داده 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 چندگانه را نشان می‌دهد. YouTube لزوماً از اتم‌ها استفاده نمی‌کند، اما این یک نمونه مطابق است. به‌ویژه، هم قطعه‌های صوتی و هم قطعه‌های ویدیویی نمایش داده می‌شوند.

رسانه

نمودار زیر چیدمان یک بخش رسانه‌ای نمونه از نوع ISO BMFF چندگانه را نشان می‌دهد. ‫YouTube لزوماً از همه اتم‌ها استفاده نمی‌کند، اما این یک مثال منطبق است. به‌ویژه، هم قطعه‌های صوتی و هم قطعه‌های ویدیویی نمایش داده می‌شوند. مجموعه‌ای از این بخش‌ها را می‌توان به بخش «مقداردهی اولیه» اضافه کرد تا یک جریان ISO BMFF چندگانه معتبر و کامل تولید شود.

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

انتقال داده RTMP و DASH

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