В этом документе приведены рекомендации по использованию формата адаптивной потоковой передачи данных по 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 DASH…
Требования
В следующих разделах описаны требования к использованию DASH для трансляций на YouTube.
Время
Конечная точка YouTube DASH работает как пассивный HTTP-сервер, записывая вызовы метода PUT, отправленные кодером.
- Конечная точка DASH поддерживает одновременные TCP-подключения. Вы можете повторно использовать подключения в соответствии с HTTP/1.1.
- Файлы MPD и сегменты инициализации должны быть отправлены методом PUT в течение трех секунд после первого медиасегмента. (Рекомендуем включить сегмент инициализации в MPD.)
- Для каждого сегмента или MPD-файла необходимо использовать отдельный запрос PUT. Пакетная загрузка нескольких сегментов не поддерживается.
- Операции PUT для сегментов медиаконтента могут выполняться одновременно, чтобы повысить пропускную способность при загрузке.
- Сегменты могут предоставляться в непоследовательном порядке в течение временного окна продолжительностью около 3 секунд.
- MPD и сегменты инициализации должны обновляться не реже чем каждые 60 секунд с помощью обновленных значений
availabilityStartTimeиstartNumber. Как уже отмечалось, сегмент инициализации может быть включен в файл описания медиапотока. В этом случае один запрос PUT может обновить оба сегмента.)
Структура URL
Видеокодер должен формировать URL-адреса PUT, добавляя строку к базовому URL-адресу конечной точки YouTube. Чтобы создать конечную точку для приема данных по протоколу DASH, используйте YouTube Live Streaming API.
Затем видеокодер может программно получить базовый URL конечной точки через YouTube Live Streaming API. Базовый URL также можно найти в интерфейсе YouTube Live Events, если вы хотите указать его в видеокодере вручную.
Строка, добавляемая к базовому URL, может содержать следующие символы ASCII:
- Строчные буквы: а–я.
- Прописные буквы: A–Z.
- Цифры: 0–9.
- Специальные символы: _ (подчеркивание), - (дефис), . (точка)
URL MPD
Кроме того, URL файла описания медиапотока должен заканчиваться на .mpd, чтобы сервер YouTube мог легко его найти. URL других сегментов не должны заканчиваться на .mpd.
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 должен составлять около двух секунд и не превышать восьми секунд.
- Мультиплексированный поток должен содержать как аудио-, так и видеодорожки.
Дополнительные рекомендации
Шифрование
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
Рассчитанная на основе этих атрибутов длительность должна отличаться от фактической длительности сегментов не более чем в два раза, иначе качество трансляции может снизиться.
Обратите внимание, что целевая продолжительность загрузки не равна продолжительности фрагмента, который YouTube создает для трансляции. YouTube перекодирует и заново разбивает входной поток на фрагменты. Целевая продолжительность выходного потока зависит от того, оптимизирована ли трансляция для качества или для задержки.
Повторные попытки и экспоненциальная выдержка
Все PUT-запросы в формате HTTP следует выполнять с тайм-аутом. Рекомендуем задавать для него значение, которое на 500 миллисекунд превышает продолжительность сегмента.
Если PUT-запрос сегмента медиаконтента не выполняется из-за превышения времени ожидания или других ошибок, в видеопотоке возникает пробел. Поэтому вам следует повторить запрос, используя рандомизированную двоичную экспоненциальную выдержку:
- После сбоя подождите случайный период времени в диапазоне
[0 ... 100]миллисекунд и повторите запрос. - Если запрос снова не будет выполнен, подождите случайный период времени от
[0 ... 200]миллисекунд и повторите попытку. - Если запрос снова не удался, подождите случайный период времени от
[0 ... 400]миллисекунд и повторите попытку. - другие подобные критерии.
Если ошибки повторяются, сообщите об этом оператору кодера, поскольку они указывают на сбой трансляции.
Коды HTTP-ответов
В следующих разделах описаны коды ответов, которые YouTube возвращает в ответ на сегменты, доставленные через DASH.
200 (OK)
Ответ 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 (Method Not Allowed)
Ответ 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©=0&file=
На последовательности показаны MPD и сегменты инициализации, отправленные отдельно. Однако сегмент инициализации можно представить непосредственно в MPD, и мы рекомендуем делать именно так. Кроме того, MPD-файл и сегменты инициализации должны обновляться не реже чем раз в 60 секунд. В итоге URL этих сегментов снова появятся в последовательности, а за ними будут следовать URL других медиасегментов.
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=dash.mpd PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media001.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media002.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media003.mp4 ...
Сегменты WebM
MPD со встроенным сегментом инициализации
В приведенном ниже примере MPD сегмент инициализации встроен в URL данных RFC 2397. Рекомендуем встраивать сегмент инициализации таким образом, а не отправлять его отдельно.
Этот пример соответствует требованиям для загрузки на YouTube контента в формате WebM (VP8 или VP9, Opus). Для удобства чтения большая часть 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©=0&file=media-$Number%09d$.webm"/> <Representation id="1" width="1920" height="1080"> <SubRepresentation contentComponent="1"/> </Representation> </AdaptationSet> </Period> </MPD>
MPD
Приведенный ниже пример MPD-файла, в котором нет встроенного сегмента инициализации, также соответствует требованиям для загрузки на YouTube контента в формате WebM (VP8 или VP9, Opus):
<?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©=0&file=init.webm" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=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. Рекомендуем встраивать сегмент инициализации таким образом, а не отправлять его отдельно.
Этот пример соответствует требованиям к загрузке на YouTube файлов в формате ISO BMFF (H.264, AAC). Для удобства чтения большая часть 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©=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©=0&file=init.mp4" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=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
Нельзя одновременно использовать для трансляции на YouTube протоколы RTMP и DASH. Это относится как к переключению между ними во время трансляции, так и к использованию одного из них в качестве основного метода приема, а другого – в качестве резервного.