Эта страница переведена с помощью Cloud Translation API.

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

В этом документе приведены рекомендации по использованию формата доставки 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 поверх DASH описан в спецификации WebM DASH .

Требования

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

Сроки

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

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

структура URL

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

Кодер впоследствии может программно получить базовый 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, то data: URL, содержащий сегмент, не должен быть длиннее 100 КБ.

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

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

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

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

Шифрование

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

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

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

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

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

Примечание. Длина data: URL не должна превышать 100 000 байт.

Длительность целевого сегмента

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

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

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

Коды ответов HTTP

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

200 (ОК)

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

202 (принято)

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

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

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

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

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

ошибка 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 и 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 секунд . Таким образом, в конечном итоге 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 со встроенным сегментом инициализации

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