ПОПРОБОВАТЬ БЕСПЛАТНО
В данном руководстве описаны стандартные процедуры, необходимые для использования основных и дополнительных сервисов сети CDNvideo. В описания процедур включены пошаговые инструкции и перечислены необходимые исходные данные. Для лучшего понимания процессов подключения сервисов в руководстве отражены общая архитектура и основные компоненты сети.
Для оказания услуг компания CDNvideo использует собственную сеть доставки контента (Content Delivery Network, CDN). По функциональным признакам сеть CDNvideo делится на две области: ядро и серверы раздачи контента.
Серверы раздачи устанавливаются в местах наибольшей концентрации конечных пользователей. В общем случае контент сначала агрегируется в сети CDNvideo, а затем доставляется конечному пользователю с ближайшего к нему сервера. При этом под «ближайшим» понимается сервер, обладающий лучшей комплексной метрикой (оптимальный сервер не обязательно будет наиболее близким географически). За перенаправление запросов пользователей на оптимальные серверы раздачи отвечает редиректор, механизм работы которого рассмотрен в разделе 3. Редиректор входит в состав ядра сети и по сути является DNS-сервером, на котором запущено интеллектуальное программное обеспечение, работающее в связке с сервисом DNS.
В случае вещания в режиме реального времени (Live Streaming) поток предварительно доставляется на серверы публикации, входящие в состав ядра сети и далее транслируется на серверы раздачи.
«Главная цель CDN – максимально приблизить контент, в первую очередь видео, к конечным пользователям.»
Основные сервисы CDN:
Дополнительные сервисы CDN:
Перенаправление запросов пользователей на оптимальные серверы раздачи происходит на уровне DNS. Распространяемый контент должен быть доступен по доменным именам, находящимся в зоне ответственности CDNvideo. Для этого поставщику контента выделяется доменное имя в зоне CDNvideo (например, customer.cdnvideo.ru), которое должно использоваться при формировании ссылок на контент. Также возможен доступ к контенту по доменному имени в зоне ответственности поставщика (например, cdn.customer.com), в этом случае поставщику необходимо создать ресурсную запись CNAME (псевдоним) на своих DNS-серверах вида:
cdn.customer.com. CNAME customer.cdnvideo.ru
На сайте поставщика для распространяемого контента указываются ссылки с использованием доменного имени в зоне ответственности CDNvideo (например, http://customer.cdnvideo.ru/goal.flv) или с использованием псевдонима, указанного в записи CNAME (например, http://cdn.customer.com/goal.flv). Упрощённая схема перенаправления запросов представлена на Рис. 1.
Непосредственное перенаправление запросов выполняет редиректор в составе ядра сети, результатом является IP-адрес выбранного сервера раздачи. Для выбора оптимального сервера раздачи используется интеллектуальное программное обеспечение, оперирующее несколькими метриками доступности и работающее в связке с сервисом DNS. Выполняется постоянный мониторинг доступности серверов, что исключает перенаправление запросов на недоступный сервер.
Для ведения живой трансляции поток сначала должен быть доставлен на сервера публикации CDNvideo. Источником трансляции может быть сервер, IP-камера, ноутбук со специальным ПО, другое кодирующее устройство (кодер). Существует несколько способов доставки потока на сервера публикации CDNvideo, более подробно вопрос рассмотрен в разделе 4.1.3.
В сети CDNvideo поток будет размножен, преобразован в требуемый формат и транслирован конечным пользователям с оптимальных узлов раздачи. Трансляция инициируется по запросу от пользовательского плеера к серверу раздачи. Ограничений на тип пользовательского плеера не накладывается.
Возможно ведение трансляции в нескольких битрейтах, более подробно вопрос рассмотрен в разделе 4.1.4.
После начальной конфигурации вам будет предоставлен URL страницы с тестовым плеером, на которой можно будет оценить трансляцию потока через сеть CDNvideo.
Публикуемый поток должен удовлетворять следующим требованиям:
Настоятельно рекомендуем упорядочить публикуемый поток по ключевым кадрам (key frames), а именно — в настройках H.264 необходимо выставить небольшой фиксированный интервал между ключевыми кадрами (1-2 секунды).
Возможные способы публикации потока в сети CDNvideo:
RTMP-publish
Наиболее предпочтительный способ публикации. Кодер должен поддерживать протокол RTMP. Примеры: Adobe FMLE, Apple QuickTime Broadcaster, ffmpeg. Для публикации выделяются два URL (основной и резервный) и имя потока с указанием авторизационного токена. Пример:
URL primary: rtmp://pub1.rtmp.test.cdnvideo.ru/test
URL backup: rtmp://pub2.rtmp.test.cdnvideo.ru/test
Stream: test.sdp?auth=261016ClEq
Резервный URL следует использовать только при наличии достаточной полосы пропускания.
Имя потока в настройках кодера обязательно должно указываться вместе с авторизационным токеном, в противном случае попытка публикации будет отклонена.
Рекомендованные настройки в случае использования ПО Adobe FMLE (для других кодеров аналогично):
В случае трансляции одного события в нескольких битрейтах одновременно на вкладке “Encoding Options” можно создать до 3-х потоков, указав для каждого битрейт и выходное разрешение. Имена потоков произвольные, указываются в строке “Stream:” через точку с запятой:
С системными требованиями к Adobe FMLE можно ознакомиться по ссылке:
Flash Media Encoder
RTMP-pull
Способ может быть использован, если существует готовый RTMP-поток (origin). Необходимо предоставить URL потока вида:
rtmp://origin.server/app/stream
Можно указать два URL — основной и резервный. Сервера CDNvideo будут настроены на забор потока и ретрансляцию.
RTSP-publish
Способ может быть использован, если кодер поддерживает публикацию потока по протоколу RTSP (например Apple QuickTime Broadcaster). Для публикации выделяются два URL (основной и резервный) вида:
rtsp://01.domain.cdnvideo.ru:PORT/domain-publish
rtsp://02.domain.cdnvideo.ru:PORT/domain-publish
Резервный URL следует использовать только при наличии достаточной полосы пропускания. Также выделяется пара Login/Password (запрашивается при подключении к серверу публикации). Имя потока может быть любым.
RTSP-pull
Способ может быть использован, если кодирующее устройство (обычно это IP-камера) поддерживает раздачу потоков по протоколу RTSP. Предварительно должны быть выполнены следующие условия:
Для конфигурирования необходимо предоставить следующую информацию:
Пример URL RTSP-источника для камеры Axis:
rtsp://login:secret@10.1.1.1:554/axis-media/media.amp
где пара login: secret – это, соответственно, логин и пароль для доступа к камере. В URL должен использоваться публичный IP-адрес кодирующего устройства.
Сервера публикации CDNvideo будут настроены на забор потока по заданному URL.
MPEG_TS-publish
Способ используется для публикации в формате MPEG_TS over UDP. Необходимо предоставить следующую информацию:
Для публикации выделяются адреса двух серверов (основной и резервный) и каждому потоку назначается отдельный UDP-порт. Например:
Кодирующее устройство должно быть настроено на отправку потока (потоков) по указанным адресам и портам. Потоки будут раздаваться под заданными именами.
Для вещания конечным пользователям используются следующие протоколы:
В случае проблем с трансляцией потока по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности, рекомендуется рассмотреть следующие варианты:
Возможно ведение трансляции в нескольких битрейтах, с возможностью переключения между ними в плеере. Переключение между битрейтами вручную или автоматически в адаптивном режиме, в зависимости от реализации плеера. При этом для HTTP-протоколов (HLS/HDS/MSS) мы можем объединить несколько битрейтов одним манифест-файлом, то есть дать на выходе готовое решение для адаптивного вещания.
Возможные варианты реализации вещания в нескольких битрейтах:
1. Для размещения ссылок на трансляцию вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.customer.ru (опционально).
2. Оценить максимальное количество одновременных зрителей и предполагаемый средний битрейт и сообщить эти параметры нам для резервирования полосы пропускания (если предполагаемое максимальное количество одновременных зрителей превышает 1000).
3. Выбрать способ публикации потока и сообщить нам. В зависимости от выбранного способа мы запросим или предоставим необходимую информацию.
4. Настроить кодирующее устройство.
5. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
6. Настроить ваш плеер на отображение потоков через сеть CDNvideo.
Потоковое вещание по запросу подразумевает загрузку файлов на сервера раздачи CDNvideo с сервера-источника. Загрузка файла происходит пофрагментно, по мере необходимости и только в случае отсутствия соответствующего фрагмента в кэше сервера раздачи, обрабатывающего запрос пользователя. Например, в обязательном порядке начнётся загрузка файла на сервер раздачи при первом пользовательском запросе, направленном на данный сервер. Для загрузки используется протокол HTTP, полученные фрагменты сохраняются в кэше сервера раздачи и используются при следующих обращениях пользователей.
Требования к исходным файлам – тип контейнера:
Требования к исходным файлам – кодеки:
Для вещания конечным пользователям используются следующие протоколы:
В случае проблем с трансляцией видео по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности, рекомендуется рассмотреть следующие варианты:
В нашей сети поддерживается псевдостриминг видеофайлов по протоколу HTTP c возможностью поиска по файлу (“перемоткой”). Поддержка поиска также должна быть реализована в пользовательском плеере.
Первый вариант реализации поиска — с использованием аргумента start в строке запроса. Время старта указывается в секундах. Пример запрашиваемого URL:
http://customer.cdnvideo.ru/filetoplay.mp4?start=300
Поддерживаемые контейнеры видео для этого варианта – MP4 и FLV, при этом в именах файлов должны использоваться расширения .mp4 или .flv соответственно.
Второй вариант реализации поиска — запрос байтовых диапазонов файла (byte-range requests), при этом специальных требований к формату видео не предъявляется.
Независимо от варианта реализации, необходимо подготовить файлы для псевдостриминга. Во-первых, необходимо правильно настроить вставку ключевых кадров (key frames) при кодировании, мы рекомендуем фиксированный диапазон 1-2 секунды. Во-вторых, необходимо вынести метаданные в начало файла. Более подробно о подготовке файлов можно прочитать по ссылкам:
http://flash.flowplayer.org/plugins/streaming/pseudostreaming.html#prepare
http://nginx.org/ru/docs/http/ngx_http_mp4_module.html
Для обоих вариантов поддерживается опция ограничения скорости отдачи файла, что позволяет контролировать объём передаваемого трафика. По умолчанию скорость отдачи не ограничивается.
1. Для размещения ссылок на контент вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.customer.ru (опционально).
2. Оцените и сообщите нам общий объем контента.
3. Сообщите URL источника контента (например, http://origin.customer.ru/video/).
4. При использовании псевдостриминга – определить необходимость ограничения скорости отдачи файлов и указать значение, если такая необходимость есть. По умолчанию скорость отдачи не ограничивается.
5. После получения подтверждения от службы технической поддержки проверить корректность показа видео на тестовом объекте/домене.
6. Настроить ваш плеер на отображение потоков через сеть CDNvideo.
В нашей сети поддерживается три варианта работы с аудиопотоками:
1. Вещание конечным пользователям в формате Интернет-радиостанций по протоколу Icecast. Доступны все стандартные возможности Icecast. Оригинальный аудиопоток должен быть предварительно опубликован на SHOUTcast/Icecast-сервере, который будет являться источником для серверов раздачи CDNvideo.
Внимание: мы не предоставляем сервер для начальной публикации, выбор возлагается на вас.
2. Источник трансляции в формате Icecast, вещание конечным пользователям по протоколам RTMP, RTSP, HDS, HLS.
Внимание: протокол Microsoft Smooth Streaming не поддерживает audio-only потоки.
Поддерживаемые кодеки: AAC, AAC-LC, HE-AAC (aacPlus), MP3. В этом случае мы забираем предварительно опубликованный Icecast-поток (аналогично варианту 1) и преобразуем его в необходимый формат.
3. Публикация audio-only потоков стандартными средствами (RTMP, RTSP, MPEG-TS), как описано в разделе 4.1.3. Вещание конечным пользователям по протоколам RTMP, RTSP, HDS, HLS.
Для создания ссылок на трансляцию вам будет выделен домен в зоне CDNvideo вида customer.cdnvideo.ru. Вы можете создать псевдоним (CNAME) в своей зоне DNS вида cdn.customer.ru (опционально).
Статистика по текущим подключениям к аудиопотокам доступна через API, подробней в разделах 5.3.1 и 5.3.2.
1. Сообщить нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo. Итоговая ссылка на поток, используемая для вещания через нашу сеть, будет выглядеть следующим образом: http://icecast.customer.cdnvideo.ru:8000/stream_name
1. Сообщите нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.
1. Выберите способ публикации и сообщите нам. В зависимости от выбранного способа мы предоставим дополнительную информацию.
2. Настройте кодирующее устройство.
3. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
4. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.
Под HTTP-контентом понимаются статические изображения, HTML-файлы, CSS-таблицы, Java-скрипты, видеофайлы и прочие объекты, используемые при создании веб-сайтов. Основной принцип – контент по мере необходимости кэшируется на серверах раздачи и отдаётся с оптимального сервера по запросу пользователя. При кэшировании сохраняется не только сам объект данных, но и связанные с ним HTTP-заголовки.
Контент загружается по протоколу HTTP в кэш сервера раздачи с сервера-источника при первом запросе пользователя и используется при обслуживании последующих запросов. Полученный сервером раздачи объект хранится в кэше в течение определенного времени (подробнее в разделе 4.4.3). В случае заполнения кэша происходит замещение объектов по принципу ротации, то есть в первую очередь замещаются объекты с наибольшим сроком хранения. Повторная загрузка из источника происходит только в случае отсутствия запрашиваемого объекта в кэше сервера раздачи.
Характерные особенности:
Как это работает. Допустим, на вашем сайте www.mycompany.com есть картинка с полным URL вида http://www.mycompany.com/images/logo.gif. Вам будет выделено доменное имя вида customer.cdnvideo.ru для модификации доменной части ссылок на кэшируемые объекты. Таким образом, новая ссылка на картинку будем выглядеть так:
http://customer.cdnvideo.ru/images/logo.gif
Обратите внимание, что относительный путь объекта не изменился. Обращение пользователя к такому объекту на сайте попадёт на один из серверов раздачи. Если это обращение было первым, объект будет запрошен с сервера-источника, отдан пользователю и сохранён в кэше для обслуживания последующих запросов.
Примечание: Для того, чтобы быстро поменять доменую часть ссылок на кэшируемые объекты, в некоторых CMS предусмотрен механизм автоматизации этого процесса. Необходимо найти функцию, отвечающую за указание путей к объектам сайта. Рассмотрим механизм автоматизации на примере плагина WordPress SEO plugin:
1. Для примера, поменяем пути ко всем изображениям в файле Sitemap. Необходимо перейти в WordPress к разделу Appearance и кликнуть на «Editor».
2. Открыть файл functions.php и разместить внизу следующий код (предварительно сохранив исходный functions.php если Вы не знакомы с редактированием этого файла), указав Ваш домен:
function wpseo_cdn_filter( $uri ) {
return str_replace( ‘http://yourdomain.ru’, ‘http://cdn.yourdomain.ru’, $uri );
}
add_filter( ‘wpseo_xml_sitemap_img_src’, ‘wpseo_cdn_filter’ );
3. Затем кликните на Sitemap в плагине, правый клик «View source» в Вашем браузере, и убедитесь, что все пути к изображениям Вашего сайта указывают на CDN.
4. Аналогичный способ должен применяться и для других объектов Вашего сайта.
Время хранения объекта в кэше сервера раздачи определяется HTTP-заголовками Cache-Control (со значением ‘max-age’) и Expires. Заголовки должны выставляться на сервере-источнике; достаточно указать только один из них. Одновременное использование обоих заголовков не запрещается, хотя и является избыточным; в этом случае следует проследить, чтобы их значения не противоречили друг другу. Если эти заголовки отсутствуют, то по умолчанию время хранения объекта в кэше принимается равным 24-м часам. Следует особо обратить внимание на правильное выставление указанных HTTP-заголовков в случае динамически меняющегося контента, поскольку это напрямую влияет на актуальность версии объекта, хранящегося в кэше.
Высокого уровня актуальности динамического контента можно добиться, используя API сети CDNvideo для удаления отдельных объектов из кэша всех серверов раздачи. В этом случае объект будет загружен из источника заново при первом обращении пользователя. Более подробно очистка кэша рассмотрена в разделе 5.3.2.
При раздаче объектов с URL, содержащими строку параметров (query string) вида:
http://server/path/program?query_string
следует учесть, что по умолчанию при кэшировании такого объекта ‘query string’ удаляется из HTTP-заголовка Request URI. При последующих запросах пользователям будет выдаваться первый закэшированный объект с таким URL, без учёта значения ‘query string’ в запросе. Если такая модель работы не устраивает и сохранение ‘query string’ в URL необходимо – сообщите нам об этом и мы активируем эту опцию.
Файл robots.txt предназначен для роботов поисковых систем. Поддерживается три варианта использования файла:
По умолчанию мы используем вариант 1, чтобы предотвратить множественную индексацию контента. В большинстве случаев этот вариант наиболее предпочтителен. Тем не менее, в некоторых случаях (например, при кэшировании CSS и скриптов) при использовании варианта 1 возможны нежелательные эффекты, которые могут привести к потере позиций сайта в выдаче поисковых систем. В этом случае более оптимальным выбором может быть вариант 2 или 3. Окончательное решение остаётся за вами, исходя из структуры сайта и характера кэшируемого контента.
Рекомендации Яндекс и Google доступны по ссылкам:
Яндекс
Google
В качестве примера рассмотрим процесс добавления CNAME для домена telecat.cdnvideo.ru вида cdn.telecat.ru.
Порядок действий:
1. В разделе Услуги -> DNS-хостинг выбрать услугу DNS-master для хостинга, к домену которого необходимо добавить ресурсную запись CNAME, кликнув по кнопке <Управление DNS-зонами>.
2. Выбрать домен, для которого необходимо добавить CNAME, кликнув по нему (в нашем примере telecat.ru).
3. Кликнуть по кнопке <Добавить новую запись>.
4. В поле Type выбрать тип ресурсной записи CNAME, добавить алиас и каноническое имя в одноименные поля.
Важное замечание: каноническое имя необходимо указывать с точкой на конце.
При необходимости указать время кеширования в поле TTL. Кликнуть по кнопке <Добавить>.
5. Для того, чтобы предварительно просмотреть полученный с учетом изменений файл зоны, кликнуть по ссылке Предпросмотр зоны.
6. Проверить корректность добавленной записи. Запись должна выглядеть так, как показано на скриншоте.
7. Выгрузить файл зоны на Ваш сервер, кликнув по соответствующей кнопке.
В определённых случаях обращение к контенту, размещённому в CDN, расценивается браузером как кросс-доменный запрос и блокируется. В первую очередь это касается шрифтов. Проблема решается выставлением заголовков CORS (Cross-Origin Resource Sharing) для кэшируемых объектов. Вариантов два:
1. Вы сами выставляете заголовки CORS на сервере-источнике.
2. Мы добавляем заголовок Access-Control-Allow-Origin на своей стороне. Значение заголовка формируется по вашим требованиям. По умолчанию будет выставлено значение Access-Control-Allow-Origin: *, открывающее доступ к ресурсу с любого домена.
Сообщите нам, если вы выбрали второй вариант. По умолчанию заголовки CORS для кэшируемых объектов не добавляются.
Более подробно о CORS можно прочитать по ссылке:
enable-cors.org
1. Сообщите нам полное доменное имя источника контента.
2. Определите и сообщите нам необходимые исходные данные (перечислены ниже).
3. Настройте на сервере-источнике корректную передачу HTTP-заголовков Cache-Control и Expires.
4. Для размещения ссылок на контент вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.mycompany.com (опционально).
5. После получения подтверждения от службы технической поддержки проверить корректность загрузки веб-контента на тестовом объекте/домене.
6. Для кэшируемых объектов разместить на своем сайте ссылки с использованием выделенного доменного имени в зоне ответственности CDNvideo (или псевдонима, указанный в записи CNAME).
Необходимые исходные данные:
Для веб-ресурсов, использующих защищенные соединения HTTPS, мы предлагаем сервис терминации TLS/SSL на наших серверах раздачи. Проясним терминологию. HTTPS – это расширение обычного протокола HTTP, позволяющее передавать веб-трафик в зашифрованном виде. Передаваемые данные защищены от прослушивания (конфиденциальность) и подмены (целостность). Кроме того, при установлении HTTPS-соединения проверяется подлинность сервера (аутентификация сервера). Для установления HTTPS-соединений используется протокол TLS, который ранее назывался SSL. Далее по тексту используется термин TLS.
Необходимым условием работы TLS является наличие на сервере цифрового сертификата. В нашей сети возможно два варианта использования сертификата и выбор находится в прямой зависимости от того, какое доменное имя вы используете для кэшируемого контента.
В первом случае кэшируемый контент находится в зоне *.cdnvideo.ru. Мы используем наш собственный сертификат, подписанный одним из доверенных международных удостоверяющих центров (УЦ), детали сертификата можно уточнить у нашей службы технической поддержки. Сертификат CDNvideo уже размещён на всех серверах раздачи нашей сети, от вас дополнительных шагов не требуется.
Обратите внимание, что наш сертификат валиден только для доменов третьего уровня. Домены 4-го и следующих уровней нашим сертификатом не подтверждаются. Примеры:
домен customer.cdnvideo.ru — OK!
домен static.customer.cdnvideo.ru – FAIL!
Во втором случае кэшируемый контент находится в вашей доменной зоне с использованием CNAME. Используется ваш сертификат, подписанный доверенным УЦ, и соответствующий ему закрытый ключ. От вас нам потребуется два файла, которые будут размещены на всех серверах раздачи CDNvideo:
Цифровой сертификат в формате PEM. Обычно это файл с расширением .crt. Сертификат должен быть подписан общепризнанным доверенным УЦ и быть валидным — с неистёкшим сроком действия, доменное имя в сертификате должно соответствовать используемому CNAME. Проверьте это заранее. В случае сомнений присылайте сертификат нашей службе технической поддержки для проверки.
Соответствующий сертификату закрытый ключ в формате PEM. Обычно это файл с расширением .key. При генерации ключа не используйте passphrase, мы не сможем использовать такой ключ!
Примеры выбора варианта:
Контент в зоне customer.cdnvideo.ru — используется сертификат CDNvideo.
Контент в зоне static.yourcompany.com — используется ваш сертификат.
Терминация TLS в нашей сети подразумевает, что защищённое соединение устанавливается между пользователем и сервером раздачи CDNvideo. Между серверами раздачи и источником обычно используется стандартный HTTP и в большинстве случаев этого вполне достаточно. Если по какой-то причине вам необходимо использовать TLS на участке «сервер раздачи – источник», убедитесь, что на сервере-источнике имеется валидный сертификат, подписанный доверенным УЦ.
Сервис применим как для live-потоков, так и для VOD. Авторизация поддерживается для всех протоколов, доступных в нашей сети: RTMP, RTSP, HLS, HDS, MSS. Реализовано два механизма авторизации:
1. Внешняя авторизация, когда решение о доступе к потоку принимается средствами владельца контента.
2. Локальная авторизация, когда решение о доступе к потоку принимается средствами нашей сети на основе критериев, обозначенных владельцем контента.
В данном случае авторизация запросов к потокам происходит за пределами сети CDNvideo, например, с помощью скрипта авторизации на стороне владельца контента.
При каждом обращении пользователя к защищённому потоку сервер CDNvideo отправляет HTTP-запрос HEAD к скрипту авторизации на стороне владельца контента. В заголовках запроса передаются следующие параметры:
x-cdn-method : тип запрошенного потока;
x-cdn-stream-name : имя запрошенного потока;
x-cdn-client-ip : IP-адрес пользователя;
x-cdn-query : авторизационные параметры запроса; в случае HTTP это queryString, в случае RTMP – аргументы NetConnect, указанные после знака ‘?’;
x-cdn-uri : URI потока;
x-cdn-referrer : URL Flash-плеера (только для Flash);
x-cdn-user-agent : название и версия плеера пользователя;
x-cdn-page-url : URL страницы, содержащей код Flash-плеера (только для Flash);
x-cdn-session-id : идентификатор сессии;
x-cdn-event : событие.
Возможные значения заголовка x-cdn-method:
flash : Adobe Flash Player/RTMP;
http : HTTP-протоколы (HDS, HLS, MSS);
rtp : RTSP
Возможные значения заголовка x-cdn-event:
play : запрос на проигрывание потока;
publish : запрос на публикацию потока (только для RTMP).
Владелец контента может формировать ссылки с указанием авторизационных параметров после знака ‘?’, которые будут переданы в заголовке x-cdn-query. Ниже пример для RTMP:
rtmp://flash.cdnvideo.ru/live?auth_id=13211
Stream name: stream.sdp
В итоге, для ссылки, приведённой в качестве примера, заголовки могут быть следующими:
x-cdn-method: flash
x-cdn-stream-name: stream.sdp
x-cdn-client-ip: 212.2.11.117
x-cdn-query: auth_id=13211
x-cdn-uri: rtmp://flash.cdnvideo.ru/live
x-cdn-referrer: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.swf
x-cdn-user-agent: MAC 10,1,85,3
x-cdn-page-url: http://www.cdnvideo.net/aloha/wowza-examples/LiveVideoStreaming/client/live.html
x-cdn-session-id: 921547595
x-cdn-event: play
В ответ сервер CDNvideo ожидает HTTP response со статусом ‘200 OK’, содержащий следующие заголовки:
x-cdn-status-int : результат авторизации;
x-cdn-status-text : текстовое описание ответа;
x-cdn-msg : текст для передачи ошибки в Flash-плеер (только для Flash/RTMP).
Возможные значения заголовка x-cdn-status-int:
0 : доступ разрешен;
1 : доступ запрещен.
Пример разрешающего ответа:
x-cdn-status-int: 0
x-cdn-status-text: OK
Пример запрещающего ответа:
x-cdn-status-int: 1
x-cdn-status-text: Access forbidden, auth_id not exist.
Для настройки авторизации необходимо предоставить URL внешнего скрипта.
Упрощённая схема успешной авторизации представлена на Рис. 5.
В данном случае авторизация запросов пользователей выполняется исключительно в сети CDNvideo, внешние ресурсы не используются.
В момент обращения пользователя к защищённому ресурсу владельцу контента необходимо сформировать специальную ссылку. Пример для RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516
Ссылка содержит два авторизационных параметра:
‘md5=’ — хэш MD5 в формате Base64 for URL, сгенерированный на основе URI запрошенного ресурса, времени жизни ссылки, секретного ключа, IP-адреса пользователя (опционально);
‘e=’ — время окончания действия ссылки в формате POSIX time.
При обращении к потоку с использованием сгенерированной ссылки, CDN вычисляет значение MD5 и сравнивает его с полученным. Если значение не совпадает или текущее время превышает значение “e”, то пользователю возвращается ответ с кодом ‘403 Forbidden’ (запрет на воспроизведение).
Пример алгоритма расчета MD5-хэша с использованием IP-адреса пользователя в качестве одного из входных параметров:
md5 = base64_url(md5(SECRET:1382106248:1.2.3.4:/app_name/stream_name.sdp))
Обратите внимание, что доменная часть URI при вычислении хэша не используется!
1. Есть следующие входные данные:
секретный ключ: zah5Mey9Quu8Ea1k
IP-адрес пользователя: 1.2.3.4
URI ресурса для RTMP:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4
2. Вычисляем время действия ссылки. В приведённом примере – неделя с момента генерации.
php -r ‘print time() + (7 * 24 * 60 * 60) . «\n»;’
1387984516
3. Вычисляем хэш MD5 в формате Base64 for URL:
php -r ‘print str_replace(«=», «»,strtr(base64_encode(md5(«zah5Mey9Quu8Ea1k:1387984516:1.2.3.4:/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4», TRUE)), «+/», «-_»)) . «\n»;’
xs1YG76uMJF2kfkpg_cRlg
4. Итоговая ссылка:
rtmp://customer.cdnvideo.ru/mc10/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516
Важное замечание: хэш MD5, вычисленный для RTMP, является базовым для данного ресурса. То есть, один и тот же хэш будет использован для ссылок на видеоролик по протоколам RTMP, RTSP, HLS, HDS, MSS несмотря на то, что URI для разных протоколов может немного отличаться. Ещё раз – а) хэш для всех ссылок на данный файл будет один и тот же б) хэш вычисляется на основе URI для RTMP. Для приведённого примера HLS-ссылка будет выглядеть так:
http://customer.cdnvideo.ru/mc10/_definst_/mp4:10/f/s3/75/756_a90c4c43ef0986b5b34df83827adc50b/m/756_a90c4c43ef0986b5b34df83827adc50b_2013-11-07_sample_video_14_63.mp4/playlist.m3u8?md5=xs1YG76uMJF2kfkpg_cRlg&e=1387984516
Обратите внимание, что несмотря на то, что URI отличается, хэш MD5 используется тот же, что и для RTMP.
При локальной авторизации контролируются следующие параметры:
1. URI запрашиваемого ресурса. Проверяется, что ссылка была сформирована именно для этого потока.
2. Секретный ключ. Проверяется, что ссылка сформирована именно владельцем контента.
3. Время окончания действия ссылки.
4. IP-адрес пользователя (опционально). Проверяется, что поток запрошен именно с того IP-адреса, для которого была сформирована ссылка.
Дополнительно могут быть проверены и другие параметры запроса пользователя:
1. Географическая принадлежность пользователя (на основе IP-адреса), с детализацией до уровня города.
2. URL страницы, содержащей код Flash-плеера (только для Flash). Позволяет контролировать, на каких сайтах может быть размещён код плеера.
Для настройки необходимо предоставить следующую информацию:
1. секретный ключ;
2. вариант расчёта MD5 (с использованием IP-адреса пользователя или без);
3. необходимость проводить авторизацию по дополнительным параметрам (GeoIP, привязка к доменам).
Мы поддерживаем два метода ограничения доступа к HTTP-контенту:
1. Внешняя авторизация с обращением к скрипту на стороне владельца контента. Метод хорош для статического контента (большие файлы), настоятельно не рекомендуем для динамически генерируемого контента – файлов HLS, HDS, MSS, MPEG-DASH (чанки и манифесты).
2. Локальная авторизация с проверкой на серверах раздачи MD5-хэша и времени жизни ссылки. Рекомендуемый метод для авторизации контента HLS, HDS, MSS, MPEG-DASH. Для статики тоже подходит без проблем.
Защищаемый статический контент должен быть помещён в отдельный каталог на сервере-источнике. Например:
http://origin.client.ru/secure/
Доступ к каталогу должен быть разрешен только для серверов CDNvideo (мы предоставим IP-адреса). Каталог будет исключён из доступа по прямым ссылкам вида http://client.cdnvideo.ru/secure/file.
Отдача защищенных файлов будет осуществляться только через обязательную проверку по ссылкам с авторизационными параметрами вида:
http://client.cdnvideo.ru/secure/path/to/file?parameter=value
Ссылки формируются владельцем контента. Сервер раздачи при получении такого обращения проксирует запрос к скрипту авторизации на стороне владельца контента. В запрос добавляются следующие заголовки:
X-Real-IP : IP-адрес пользователя;
X-CDN-Query : запрошенный URI.
Например:
X-Real-IP: 1.2.3.4
X-CDN-Query: /secure/file.mp4?parameter=value
Скрипт авторизации должен проверить валидность запроса и прислать HTTP-ответ:
Ответ с кодом 403 или 401 запрещает доступ;
Ответ с кодом 200 разрешает доступ.
Нам нужна следующая информация для настройки:
путь к каталогу с защищаемым веб-контентом на сервере-источнике;
URL скрипта авторизации.
Защищаемый статический контент должен быть помещён в отдельный каталог на сервере-источнике. Например:
origin.client.ru/secure/
Доступ к данному каталогу должен быть разрешен только для серверов CDNvideo (мы предоставим IP-адреса). Каталог будет исключён из доступа по прямым ссылкам вида http://client.cdnvideo.ru/secure/file. Отдача защищенных файлов только через обязательную поверку по ссылкам с авторизационными параметрами вида:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000
В URL содержится два авторизационных параметра:
md5 — MD5-хэш, сгенерированный на основе URI, времени жизни и секретного ключа;
e — время окончания действия ссылки (POSIX time).
При получении такого запроса, сервер раздачи вычисляет значение MD5 и сравнивает его с полученным. Если значение не совпадает или текущее время превышает значение “e”, то пользователю возвращается HTTP-ответ с кодом ‘403 Forbidden’ (запрет на воспроизведение).
Алгоритм расчета MD5-хэша может также использовать IP-адрес пользователя в качестве входных данных. Пример вычисления MD5-хэша без использования IP-адреса:
md5 = base64_url(md5(SECRET:1306830000:/secure/file.mp4))
Пример вычисления MD5-хэша с использованием IP-адреса:
md5 = base64_url(md5(SECRET:1306830000:1.2.3.4:/secure/file.mp4))
Пример генерации MD5 с использованием PHP:
php -r ‘print str_replace(«=»,
«»,strtr(base64_encode(md5(«SECRET:1306830000:1.2.3.4:/secure/file.mp4», TRUE)),
«+/», «-_»)) . «\n»;’
TJwAm-lsft38vJEdDh-Kbg
Результирующая ссылка для пользователя будет следующей:
http://client.cdnvideo.ru/secure/file.mp4?md5=TJwAm-lsft38vJEdDh-Kbg&e=1306830000
Информация, предоставляемая поставщиком контента для настройки внешней авторизации:
путь к каталогу с защищаемым веб-контентом на сервере-источнике;
секретный ключ;
алгоритм расчёта MD5 (с использованием IP-адреса пользователя или без).
Для динамически генерируемого контента HLS, HDS, MSS, MPEG-DASH используется аналогичная схема, но с некоторыми отличиями. Во-первых, нет необходимости выделять контент в отдельный каталог. Во-вторых, при расчёте MD5 используется неизменяемая часть URI. Рассмотрим на примере HLS. Запрос HLS-ресурса инициирует обращение плеера последовательно к мастер-плейлисту, чанклисту, и, наконец, к самим медиа-чанкам:
http://hls.client.cdnvideo.ru/app1/stream1/playlist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/chunklist.m3u8
http://hls.client.cdnvideo.ru/app1/stream1/media_40.ts
http://hls.client.cdnvideo.ru/app1/stream1/media_41.ts
Неизменяемая часть URI: /app1/stream1/
Авторизовываться будет каждая единица контента – плейлисты, чанклисты, медиа-чанки.
Программный интерфейс позволяет просматривать статистику и статус раздачи потокового видео, выполнять просмотр и очистку HTTP-кэша на серверах раздачи.
Доступ к API не открыт по умолчанию, если вы планируете его использовать – сообщите нам об этом для получения идентификатора с соответствующими правами доступа. Также сообщите нам IP-адреса, с которых будут идти запросы к API, чтобы мы внесли их в списки доступа.
API позволяет получить текущее количество подключений к потокам. Исходные потоки могут быть опубликованы в сети CDNvideo с помощью стриминговых протоколов (подробнее в разделе 4.1.3) или проксированы из HTTP origin (только для протокола HLS). Шаблон запроса:
http://api.cdnvideo.ru:8888/0/streams?id=num_name
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.
Пример выполнения запроса:
$ curl -I http://api.cdnvideo.ru:8888/0/streams?id=01_test
HTTP/1.1 200 OK
X-cdn-connections: 62
X-cdn-status: 57
HTTP-ответ содержит следующие заголовки:
X-cdn-connections: текущее общее количество подключений к потокам.
X-cdn-status: диапазон значений [0-100]. Значения, отличные от 0, означают нормальную работу CDN.
В теле ответа содержится список текущих подключений для каждого опубликованного потока, с разбивкой по протоколам:
{
«streams»: {
«live/_definst_/stream1»: {
«sessionsSanJose»: 0,
«sessionsCupertino»: 0,
«sessionsSmooth»: 0,
«sessionsFlash»: 32,
«sessionsRTSP»: 0,
«sessionsTotal»: 32
},
«rr2/_definst_/stream2»: {
«sessionsSanJose»: 0,
«sessionsCupertino»: 0,
«sessionsSmooth»: 0,
«sessionsFlash»: 30,
«sessionsRTSP»: 0,
«sessionsTotal»: 30
}
}
}
Протоколы:
| SanJose | Adobe HDS |
| Cupertino | Apple HLS |
| Smooth | Microsoft Smooth Streaming |
| Flash | RTMP |
| RTSP | RTSP |
Перечень подключений к потокам с подробной информацией о каждом подключении. Шаблон запроса: http://api.cdnvideo.ru:8888/0/streamsinfo?id=num_name
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора. Пример выполнения запроса:
$ curl -v http://api.cdnvideo.ru:8888/0/streamsinfo?id=01_test
HTTP/1.1 200 OK
X-cdn-connections: 199
X-cdn-status: 54
В теле ответа содержится список текущих подключений к потокам:
{
«streams» : {
«live/_definst_/stream1» : [
{
«SessionType» : «Cupertino»,
«SessionId» : «7a8899e2a72573593c415e8d1c892728»,
«UserId» : «50f8c986a2c4ec4e12f2438d719549a5»,
«IpAddress» : «151.33.12.11»,
«UserAgent» : «HLS Client/2.0 (compatible; LG NetCast.TV-2012)»
},
…
],
«stream2» : [
{
«SessionType» : «Icecast»
},
…
],
…
}
}
Для идентификации пользователя/сессии можно использовать все поля, в частности SessionId, UserId, IpAddress, UserAgent. Для подключений Icecast подробная информация по техническим причинам пока недоступна.
Для поиска отдельного объекта в кэше серверов раздачи используется команда list1. Команда проверяет наличие объекта в кэше хотя бы одного из серверов раздачи. Для файла с URL на сервере-источнике вида http://origin/path/to/file.jpg шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/list1?id=num_name&type=http&object=http://origin/path/to/file.jpg
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.
В ответе HTTP 200 OK передаётся заголовок X-cdn-command, содержащий информацию о статусе выполнения команды с диапазоном значений от 0 до 9. Значение, отличное от нуля, означает ошибку выполнения.
Пример успешного выполнения команды:
HTTP/1.1 200 OK
X-cdn-command: 0
Результат выполнения команды передаётся в теле ответа. При наличии объекта в кэше одного или нескольких (или всех) серверов раздачи тело ответа будет содержать URL объекта.
Пример выполнения команды list1 для объекта http://test/7/5/4/754_45966.flv, идентификатор клиента 01_test, объект обнаружен в кэше:
curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
< HTTP/1.1 200 OK
< X-cdn-command: 0
{
"01_test": {
"http": {
"object": [
{
"name": "http://test/7/5/4/754_45966.flv"
}
]
}
}
}
Для поиска объектов с QueryString все знаки ‘&’ после ‘?’ нужно заменить на ‘%26’. Пример:
не сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/list1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’
Для удаления отдельного объекта в кэше всех серверов раздачи следует использовать команду purge1. Для файла с URL на сервере-источнике вида http://origin/path/to/file.jpg шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/purge1?id=num_name&type=http&object=http://origin/path/to/file.jpg
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.
В ответе HTTP 200 OK передаётся заголовок X-cdn-command, содержащий информацию о статусе выполнения команды с диапазоном значений от 0 до 9. Если значение равно нулю, объект был успешно удалён из кэша всех серверов раздачи. Значение, отличное от нуля, означает ошибку выполнения. Также может быть передан заголовок X-cdn-comment, содержащий текстовый комментарий.
Пример ответа после успешного удаления объекта:
HTTP/1.1 200 OK
X-cdn-command: 0
X-cdn-comment: OK
Пример неуспешного выполнения команды:
HTTP/1.1 200 OK
X-cdn-command: 1
X-cdn-comment: Fail. Retry later.
Пример удаления из кэша всех серверов раздачи объекта http://test/7/5/4/754_45966.flv (команда purge1), идентификатор клиента 01_test:
curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test&type=http&object=http://test/7/5/4/754_45966.flv’
>
< HTTP/1.1 200 OK
< X-cdn-command: 0
Для удаления всех объектов на всех серверах раздачи (полная очистка кэша) следует использовать команду purge. Шаблон запроса будет выглядеть следующим образом:
http://api.cdnvideo.ru:8888/0/purge?id=num_name&type=http&object=*
В реальном запросе в поле id должно быть указано значение выделенного вам идентификатора.
Формат ответа и значения заголовков такие же, как и для команды purge1.
Для удаления объектов с QueryString все знаки ‘&’ после ‘?’ нужно заменить на ‘%26’. Пример:
не сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427&height=500&image=/upload/mediabank/619602-106/front_belyy.jpg’
сработает: curl -v ‘http://api.cdnvideo.ru:8888/0/purge1?id=01_test &type=http&object=http://www.shop.test.ru/pictures/image.php?width=427%26height=500%26image=/upload/mediabank/619602-106/front_belyy.jpg’
Для начала работы скачайте скрипт
Скрипту передаются аргументы (* — обязательные):
1. —account * (-a). Акаунт пользователя.
2. —username * (-u). Юзернейм пользователя.
3. —password (-p). Пароль пользователя.
При отсутствии аргумента:
Пароль берется из переменной окружения «CDNVIDEO_PASSWORD».
Пароль запрашивается при выполнении скрипта.
4. —service * (-s). Определяет тип скачиваемого лога.
Возможные значения:
static. Только статические файлы (mp3, jpg, ..) В личном кабинете эти данные представлены в вкладке «Ускорение загрузки web-контента» («Web-content load acceleration»)
media. Только потоки (HLS, ..) В личном кабинете эти данные представлены во вкладке «Онлайн трансляции и видео по запросу» («Live streaming and VOD»)
all. Представляет собой static + media. В личном кабинете эти данные представлены в вкладке «Всего» («Total»)
5. —date * (-d). Определяет дату, за которую нужно скачать лог. Скачать лог можно в точности до часа.
ВНИМАНИЕ: параметр часа указывается в формате GMT.
Возможные значения:
2013. Скачиваем лог за 2013 год
2013-12. Скачиваем лог за декабрь 2013 года
2013-12-23. Скачиваем лог за 23 декабря 2013 года
2013-12-23-04. Скачиваем лог за 23 декабря 2013 года 4 утра по GMT
6. —progressbar (-pb). Вывод статистики при скачивании логов.
ВНИМАНИЕ: для пользования данным функционалом потребуется установить дополнительный python модуль.
7. —file (-f). Вывод логов в файл $account_$date_$service.gz .
По умолчанию скрипт выдает поток жатых логов в stdout.
1. Установить pip (пример установки на RHEL, CentOS, Fedora): sudo yum install python-pip
2. Установить библиотеку requests: pip install requests
3. Положить get_log.py в нужную директорию
ПО представляет собой простой консольный python-скрипт, принимающий различные аргументы (Подробнее в информации по архитектуре). На выход дает поток в формате gzip.
Возможные сценарии использования:
1. Скачиваем полный лог за 2014 год и архивируем его в файл account_2014_all.gz
python get_log.py -a account -u username -s all -d 2014 -f
2. Скачиваем лог по статическим файлам за декабрь 2013 года с выводом прогрессбара, архивируем его в файл account_2013-12_static.gz
python get_log.py -a account -u username -s static -d 2013-12 -pb -f
Структура лог-файла представляет собой таблицу, каждый столбец которой содержит соответстующее поле, описанное ниже. Поля следуют друг за другом слева направо. Каждая строка лог-файла соответствует отдельному запросу.
Ознакомиться с содержимым файла можно по ссылке.
1. «Error: A connection error occurred»
Возможные причины: Отсутствие интернета, проблемы с сетью. Упал сервер.
Что делать:
1. Убедиться, что у вас есть интернет (ping google.com)
2. Если не помогло, обратиться в службу поддержки
2. «Timeout: page connection timeout more than seconds: 5»
Возможные причины: Сервер не отвечает, проблемы с сетью
Что делать:
1. Перезагрузиться.
2. Обратиться в службу поддержки.
3. «Error: Wrong username or password»
Возможные причины: Не правильно введена пара логин/пароль (аргументы -u username, -p password )
Что делать:
1. Проверить, что аргументы username, password правильно заполнены.
2. Если ошибка остается, обратиться в службу поддержки.
4. «Error: account not found»
Возможные причины: Нет такого account для username.
Что делать:
1. Проверить, что аргумент -a account введен верно для username.
2. Если ошибка остается, обратиться в службу поддержки.
5. «Error: Problem with server/page down»
Возможные причины: Проблемы с сервером
Что делать:
1. Обратиться в службу поддержки
Сервис применим только в случае потокового вещания по запросу (VOD), и, соответственно, неприменим для трансляций в режиме реального времени. Для вещания конечным пользователям используются адаптивные протоколы Adobe HTTP Dynamic Streaming (HDS) или Apple HTTP Live Streaming (HLS).
При запросе от плеера пользователя на получение видеопотока HTTP-фрагменты формируются в сети CDNvideo динамически, «на лету», в соответствии с запрошенным битрейтом. При этом на стороне поставщика достаточно одного оригинального видеофайла в хорошем качестве. Качество оригинального файла является верхней границей при отдаче потока пользователям.
Оригинальный файл скачивается с сервера-источника при первом обращении пользователя к контенту, формируются фрагменты в запрошенном битрейте и транслируются пользователю. При этом полученные фрагменты кэшируются на серверах раздачи сети CDNvideo и используются при последующих обращениях пользователей. Повторные обращения к серверу-источнику выполняются только при отсутствии необходимых фрагментов на серверах раздачи. Упрощённая схема работы сервиса представлена на Рис. 6.
Тип контейнера:
Кодеки:
Общие требования:
1. Для размещения ссылок на контент вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.customer.ru (опционально).
2. Сообщить URL источника контента (например, http://origin.customer.ru/video/).
3. Определить и сообщить нам выбранный протокол адаптивного вещания (HDS и/или HLS).
4. Определить и сообщить нам перечень необходимых битрейтов.
5. После получения подтверждения проверить корректность показа видео на тестовом объекте/домене.
6. Настроить плеер, размещаемый на вашем сайте, на отображение потоков через сеть CDNvideo.
Сервис позволяет оперативно получать «моментальные снимки» (скриншоты) live-потока. Условия применимости сервиса:
Скриншот представляет из себя статичное изображение в формате JPEG заранее определённого размера. Скриншоты формируются с заданной периодичностью (по умолчанию 1 минута). Может быть одновременно сформировано несколько скриншотов разного размера. Текущие скриншоты потока доступны для скачивания по HTTP, предоставляется постоянный URL для каждого размера. При остановке потока будет доступен последний зафиксированный скриншот.
1. Сообщить нам URL опубликованного live-потока.
2. Сообщить требуемые размеры скриншотов (по умолчанию формируется один скриншот с размером, равным размеру видео оригинального потока).
3. Сообщить частоту обновления скриншотов (по умолчанию 1 минута).
4. Для каждого выбранного размера будет предоставлен постоянный URL.
В нашей сети есть два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам.
Транскодирование входного потока применяется в том случае, если у вас нет возможности отдать нам поток стандартными для нашей сети способами, описанными в разделах 4.1.2 и 4.1.3, то есть, не выполняются требования к кодированию потока и способам доставки. В этом случае мы берём на себя «нормализацию» потока, приведение его к виду, понятному нашим потоковым серверам. При этом попутно могут меняться и другие характеристики потока, такие, как битрейт и разрешение. После транскодирования поток транслируется в сторону конечных пользователей стандартными средствами нашей сети, описанными в разделе 4.1.4. Важное замечание – вы отдаёте один поток на вход и на выходе получаете тоже один поток.
1. Сообщить нам URL live-потока.
2. Соообщить нам необходимые значения битрейта и разрешения потока после транскодирования (опционально; по умолчанию сохраняются исходные параметры).
3. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
4. Настроить плеер, размещаемый на вашем сайте, на отображение потока через сеть CDNvideo.
В нашей сети есть два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам.
Транскодирование выходных потоков – это преобразование одного входного live-потока в несколько выходных потоков с разным битрейтом и разрешением. При этом упорядочиваются ключевые кадры (key frames) в потоках, что позволяет плавно переключаться между битрейтами в плеере (автоматически в адаптивном режиме или вручную).
Важное замечание – в большинстве случаев один поток на входе преобразуется в несколько потоков с разным битрейтом на выходе. Тем не менее, можно использовать сервис для транскодирования по схеме «один в один», с одним потоком на выходе.
Условия применимости сервиса:
Доступные протоколы вещания в сторону конечных пользователей:
Внимание: протокол Adobe HDS для вещания в нескольких битрейтах не поддерживается.
Для протоколов HLS и MSS сервис позволяет не просто создавать набор потоков с разным битрейтом, но и объединять эти потоки манифест-файлом, то есть получить на выходе готовое решение для адаптивного вещания.
1. Опубликовать оригинальный поток.
2. Определиться с протоколами вещания в сторону конечных пользователей.
3. Соообщить нам требуемые параметры выходных потоков — битрейт, разрешение, профиль кодека H.264 и т.д.
4. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
5. Настроить плеер, размещаемый на вашем сайте, на отображение потоков через сеть CDNvideo.
Смысл сервиса — постоянная запись live-потока в рамках определённого временно́го скользящего окна с возможностью навигации в рамках этого окна. Размер окна называется глубиной DVR. Окно постоянно «скользит», то есть при глубине DVR, равной 2-м часам, «отмотать» назад в плеере удастся максимум на 2 часа от текущего момента.
Условия применимости сервиса:
Для нормальной работы сервиса публикуемый поток должен быть упорядочен по ключевым кадрам (key frames), а именно:
Для вещания в сторону конечных пользователей поддерживаются только HTTP-протоколы:
Cтриминговые протоколы RTMP и RTSP не поддерживаются.
Доступные модели вещания с поддержкой DVR:
1. Вещание в одном битрейте. Публикуется один поток по схеме RTMP-publish.
2. Вещание в нескольких битрейтах, с возможностью переключения между ними. Каждый битрейт публикуется отдельным потоком по схеме RTMP-publish. Переключение между битрейтами вручную или автоматически в адаптивном режиме, в зависимости от реализации плеера.
3. Вещание в нескольких битрейтах, с возможностью переключения между ними. Вариант реализуется за счёт использования сервиса «Транскодирование выходных потоков», описанного в разделе 5.7. Публикуется один поток в высоком качестве, который на выходе преобразуется в несколько потоков с разными битрейтами. Переключение между битрейтами вручную или автоматически в адаптивном режиме, в зависимости от реализации плеера. Действуют ограничения, описанные в разделе 5.7 – не поддерживается протокол HDS при вещании в нескольких битрейтах.
Глубина DVR должна быть разумной. Теоретический предел – 30 часов, но чем больше глубина – тем больше плейлист с описанием всех фрагментов в скользящем «окне», при этом плейлист скачивается раз в несколько секунд. Оптимальная глубина – 1-4 часа; приемлемая – до 10 часов; сомнительно – 10-12 часов; больше 12 часов – необходимо предварительное тестирование, нормальная работа не гарантируется.
В рамках предоставления сервиса доступно две стратегии записи DVR:
1. Опубликовать поток (потоки) по алгоритму, описанному в разделе 4.1.5.
2. Сообщить нам следующие данные:
имя потока (потоков);
требуемую глубину DVR;
выбранную стратегию записи;
протоколы вещания в сторону конечных пользователей.
3. Проверить показ трансляции на странице с тестовым плеером, URL страницы мы предоставим отдельно.
4. Настроить ваш плеер на запрос потоков через сеть CDNvideo.
Смысл сервиса – запись live-трансляций в виде файлов с их последующей выгрузкой в облачное хранилище.
Условия применимости сервиса:
На выходе получаем файлы в формате MP4, длительность отдельного файла не более 3-х часов.
Запись файлов может осуществляться следующими способами: