Доставка живого контента YouTube через DASH

В этом документе представлены рекомендации по использованию формата доставки Dynamic Adaptive Streaming over HTTP (DASH) для потоковой передачи данных в реальном времени на YouTube из кодера. Он призван помочь производителям кодировщиков добавить поддержку доставки DASH в свои продукты.

Понимание DASH

В списке ниже перечислены некоторые ключевые функции и атрибуты DASH:

  • На основе открытых стандартов.
  • На основе HTTP. В результате DASH удобен для интернет-инфраструктуры и может преодолевать межсетевые экраны.
  • Поддерживает высокий битрейт передачи. DASH поддерживает несколько одновременных HTTP-сессий и непоследовательную доставку сегментов, обеспечивая большую отказоустойчивость, чем протоколы, использующие одно TCP-соединение.
  • Безопасная доставка через HTTPS.
  • Доставка без потерь через HTTP и HTTPS.
  • Независимость от кодеков.
  • Поддерживает MP4, содержащий H264 и AAC, а также WebM, содержащий VP8/VP9 и Vorbis/Opus.

Технические характеристики

Требования

В следующих подразделах объясняются требования к использованию DASH для доставки прямых трансляций на YouTube.

Тайминг

Конечная точка YouTube DASH ведет себя как пассивный HTTP-сервер, записывая вызовы метода PUT, отправленные кодировщиком.

  • Конечная точка DASH поддерживает одновременные TCP-соединения. Вы можете повторно использовать соединения согласно HTTP/1.1.
  • Сегменты MPD и инициализация должны быть помещены в течение 3 секунд после первого медиасегмента. (Мы рекомендуем включить сегмент инициализации в MPD .)
  • Каждый сегмент или MPD должен использовать отдельный запрос PUT; многочастная загрузка нескольких сегментов не поддерживается.
  • Операции PUT для медиасегментов могут перекрываться во времени, чтобы улучшить пропускную способность загрузки.
  • Сегменты могут предоставляться в непоследовательном порядке в пределах временного окна длительностью примерно 3 секунды.
  • Сегменты MPD и инициализации должны обновляться по крайней мере каждые 60 секунд с использованием обновленных availabilityStartTime и startNumber . (Как отмечалось выше, сегмент инициализации может быть включен в MPD . В этом случае один запрос PUT может обновить оба сегмента.)

Структура URL

Ваш кодировщик должен формировать URL-адреса PUT, добавляя строку к базовому URL-адресу конечной точки YouTube. Вам необходимо создать конечную точку приема DASH с помощью API YouTube Live Streaming .

Кодировщик может впоследствии получить базовый URL-адрес конечной точки программным путем через API YouTube Live Streaming . Базовый URL-адрес также отображается в пользовательском интерфейсе YouTube Live Events, если вы хотите вручную предоставить URL-адрес кодировщику.

Строка, добавляемая к базовому URL-адресу, может содержать следующий набор символов ASCII:

  • Строчные буквы: аз
  • Прописные буквы: AZ
  • Цифры: 0-9
  • Специальные символы: _ (подчеркивание), - (дефис), . (период)

URL-адреса MPD

В дополнение к вышеуказанному требованию URL-адрес MPD должен заканчиваться на .mpd , чтобы сервер YouTube мог легко идентифицировать MPD. URL-адреса других сегментов не должны заканчиваться на .mpd .

URL-адреса инициализации и медиа-сегментов

URL-адрес сегмента инициализации и URL-адреса всех медиа-сегментов должны заканчиваться на .mp4 если данные находятся в контейнере ISO BMFF, или на .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 определяет номер, который будет присвоен первому медиа-сегменту.)

Длина сегмента инициализации

Сегмент инициализации не должен быть длиннее 100 КБ. (Обычно сегмент инициализации намного меньше этого размера.) Если сегмент инициализации включен в MPD, то URL data: содержащий этот сегмент, не должен быть длиннее 100 КБ.

Выход энкодера

Сегмент инициализации и медиа-сегменты должны представлять собой мультиплексированный файловый поток ISO BMFF или WebM с закрытыми GOP (группами изображений).

  • Размер GOP должен составлять около 2 секунд и не должен превышать 8 секунд.
  • Мультиплексированный поток должен содержать как аудио, так и видеодорожки.

Дополнительные рекомендации

Шифрование

YouTube поддерживает шифрование потока через HTTPS. Мы настоятельно рекомендуем вам использовать эту функцию.

Сегменты инициализации в MPD

Вы можете представить сегмент инициализации непосредственно в MPD, используя URL-адрес data: согласно RFC 2397 . Это упрощает настройку потока и снижает вероятность того, что сегмент инициализации не будет соответствовать остальной части потока.

XPath для этого элемента:

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

Продолжительность целевого сегмента

Для обеспечения хорошей производительности приема и хорошего компромисса между пропускной способностью и задержкой длина медиасегментов должна составлять от 1 до 5 секунд. Мы настоятельно рекомендуем вам указать целевую продолжительность этих сегментов в 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 должны выполняться с тайм-аутом, для которого мы рекомендуем установить значение, на 500 миллисекунд превышающее длительность сегмента.

Запрос PUT медиасегмента, который завершился неудачно из-за тайм-аута или других ошибок, соответствует разрыву в видеопотоке. Таким образом, вам следует повторить любой такой запрос, используя рандомизированную двоичную экспоненциальную отсрочку :

  1. После сбоя подождите случайный период между [0 ... 100] миллисекундами и повторите запрос.
  2. Если запрос снова не выполнен, подождите случайный период между [0 ... 200] миллисекундами и повторите запрос.
  3. Если запрос снова не выполнен, подождите случайный период между [0 ... 400] миллисекундами и повторите запрос.
  4. и т. д.

Обратите внимание, что о повторяющихся сбоях следует сообщать оператору кодировщика, поскольку они соответствуют неудачной широковещательной передаче.

Коды ответа HTTP

В следующих разделах объясняются коды ответов, которые YouTube возвращает в ответ на сегменты, доставленные через DASH.

200 (ОК)

Ответ HTTP 200 (ОК) указывает на то, что сервер YouTube получил ожидаемую операцию и успешно ее обработал.

202 (Принято)

Ответ HTTP 202 (принято) на любую операцию PUT или POST указывает, что операция была неожиданной и принята для отложенной обработки. Однако отложенная операция может быть успешной или неудачной, поэтому ответ не гарантирует, что YouTube действительно сможет успешно обработать операцию.

Этот ответ возникает чаще всего, когда сегмент доставляется непоследовательно. Обычно YouTube может правильно обработать принятый сегмент после получения предыдущих сегментов, и вам не нужно отправлять его повторно.

Например, YouTube может вернуть ответ 202 в любом из следующих случаев:

  • Сегмент инициализации принимается перед MPD.
  • Медиа-сегменты принимаются до сегментов MPD и инициализации.
  • Медиа-сегмент принимается раньше более раннего сегмента, например сегмент 3 принимается раньше сегмента 2.

Однако ответ 202 также может указывать на то, что идентификатор элемента неверен, если YouTube не может полностью проверить идентификатор после получения запроса POST или PUT. Например, один из случаев, когда это происходит, — это когда YouTube получает и принимает сегмент инициализации до получения MPD, но сегмент инициализации оказывается недействительным. В этом случае YouTube принимает сегмент инициализации и возвращает 202, а затем определяет, действителен ли сегмент, после получения MPD. Вы можете избежать этого конкретного сценария , включив сегмент инициализации в MPD .

400 (неверный запрос)

Ответ HTTP 400 (неверный запрос) указывает на одну из следующих проблем:

  • URL-адрес имеет неверный формат.
  • Сообщение слишком большое (> 10 МБ).
  • MPD не может быть проанализирован.
  • Сегмент инициализации в MPD поврежден.

401 (Несанкционированный)

Ответ HTTP 401 (неавторизованный) указывает на то, что базовый URL-адрес конечной точки YouTube DASH поврежден или срок его действия истек.

405 (Метод не разрешен)

Ответ HTTP 405 (метод не разрешен) указывает, что был отправлен запрос, отличный от POST или PUT .

409 (Конфликт)

Ответ HTTP 409 (конфликт) на любую операцию PUT или POST означает, что YouTube не может обработать запрос. Например, этот ответ может возникнуть, если запрашивающая сторона отправила множество медиасегментов, но у YouTube по-прежнему нет MPD, сегмента инициализации или того и другого. В этом примере кодировщику потребуется повторно передать сегменты MPD и инициализации перед повторной попыткой неудачного запроса.

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 и инициализации, отправленные отдельно. Однако сегмент инициализации может быть представлен непосредственно в MPD , и такая практика рекомендуется. Кроме того, сегменты MPD и Initialization должны обновляться не реже, чем каждые 60 секунд . Таким образом, в конечном итоге URL-адреса этих сегментов снова появятся в этой последовательности, а затем за ними последуют URL-адреса других медиа-сегментов.

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 встроен сегмент инициализации в URL-адрес данных RFC 2397. Мы рекомендуем вам встроить сегмент инициализации таким образом, а не отправлять его отдельно.

Этот пример соответствует загрузке 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, который не имеет встроенного сегмента инициализации, также соответствует загрузке 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 встроен сегмент инициализации в URL-адрес данных RFC 2397. Мы рекомендуем вам встроить сегмент инициализации таким образом, а не отправлять его отдельно.

Этот пример соответствует загрузке 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, который не имеет встроенного сегмента инициализации, также соответствует загрузке 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. Это относится к переключению между ними во время трансляции, а также к использованию одного в качестве основного метода приема, а другого для резервного приема.