Доставка живого контента 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 и Initialization должны обновляться не реже одного раза в 60 секунд с обновлёнными availabilityStartTime и startNumber . (Как отмечалось выше, сегмент Initialization может быть включён в MPD . В этом случае один запрос PUT может обновить оба сегмента.)

Структура URL-адреса

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

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

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

  • Строчные буквы: az
  • Заглавные буквы: 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 (OK) означает, что сервер 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 и инициализации должны обновляться не реже одного раза в 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, не имеющий встроенного сегмента инициализации, также совместим с загрузкой 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, не имеющий встроенного сегмента инициализации, также совместим с загрузкой 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 невозможно. Это касается переключения между ними во время трансляции, а также использования одного из них в качестве основного метода загрузки и другого — в качестве резервного.