CDN Description

Печать

1. Overview

This guide describes standard procedures required to set up main and optional CDNvideo network services. The procedures include step-by-step instructions and list necessary initial data. Overall architecture and major network components are described in the manual for a better understanding of the process of connection to services.

2. Network architecture and services

To provide services, CDNvideo uses its own content delivery network (Content Delivery Network, CDN). Functionally, CDNvideo network is composed of two domains: the core and content distribution servers.
Content distribution servers are installed in the locations with the highest concentration of end users. In general, the content is first aggregated in the CDNvideo network and then delivered to the end user from the nearest server. The term “closest” refers to the server that has the best integrated metric (an optimum server needs not be the closest geographically). Redirecting user’s requests to optimum content distribution servers is a responsibility of a redirector, which operates as described in Section 3. The redirector is a part of the network core and is actually a DNS-server where an intelligent software assistant that is operationally bound with the DNS service is launched. In the case of real-time online broadcasting (Live Streaming) the stream is first delivered to the publishing servers within the network core and then transmitted to the distribution servers.

“The main CDN purpose is to bring the content, primarily video, as closer to end users as possible.”

Basic CDN services are:

  • Live video streaming (Live Streaming). Allows to perform live video broadcasting of events for large Internet audiences.Broadcasting can go from a content provider server or directly from an IP-camera. Another area of the Live Streaming application is broadcasting of live TV channels over the Internet (implemented by almost every major television channel).
  • Distribution of audio streams
  • Video On Demand Streaming. Viewing video content at any time that is convenient to the end user. Viewing a video clip is possible from any time point without having to download the entire content.
  • HTTP caching. HTTP content is cached on servers on an as-needed basis and released from an optimum server at user request.

Optional CDN services are:

  • Authorization of access to the content.
  • Access to the network programming interface (API).
  • Screenshot generation.
  • Stream transcoding.
  • Over-the-air browsing (DVR).

3. User request redirection

Redirecting user requests to optimal distribution servers occurs at the DNS level. Distributable content should be available by domain names in the CDNvideo responsibility zone. To do this a domain name in the CDNvideo zone (e.g., customer.cdnvideo.ru), is allocated to the content provider. That name should be used when referencing the content. Access to the content by a domain name in the provider responsibility zone (e.g., cdn.customer.com), is also possible. In this case, the supplier should create on their DNS servers a CNAME (alias) resource record of the following kind:
cdn.customer.com. CNAME customer.cdnvideo.ru.

At the provider site, references are specified for distributed content, using the domain name in the CDNvideo responsibility zone (e.g., http://customer.cdnvideo.ru/goal.flv) or using the alias name specified in the CNAME record (e.g., http://cdn.customer.com/goal.flv). A simplified diagram for redirecting the requests is shown in Figure 1.

Схема перенаправления запросов

Redirection of user requests is performed by the redirector within the network core, while the result is an IP address of the chosen content distribution server. To choose the optimum distribution server an intelligent software assistant is used that handles multiple availability metrics and operates in conjunction with the DNS service. Continuous monitoring of server availability is carried out that prevents from redirecting of requests to an unavailable server.

4. Основные сервисы

4.1 Потоковое вещание в режиме реального времени (Live Streaming)

Базовые принципы

Для ведения живой трансляции поток сначала должен быть доставлен на сервера публикации CDNvideo. Источником трансляции может быть сервер, IP-камера, ноутбук со специальным ПО, другое кодирующее устройство (кодер). Существует несколько способов доставки потока на сервера публикации CDNvideo, более подробно вопрос рассмотрен в разделе 4.1.3.
В сети CDNvideo поток будет размножен, преобразован в требуемый формат и транслирован конечным пользователям с оптимальных узлов раздачи. Трансляция инициируется по запросу от пользовательского плеера к серверу раздачи. Ограничений на тип пользовательского плеера не накладывается.
Возможно ведение трансляции в нескольких битрейтах, более подробно вопрос рассмотрен в разделе 4.1.4.
После начальной конфигурации вам будет предоставлен URL страницы с тестовым плеером, на которой можно будет оценить трансляцию потока через сеть CDNvideo.

Требования к кодированию потока

Публикуемый поток должен удовлетворять следующим требованиям:

  • видеокодек – H.264;
  • аудиокодек – AAC или MP3.

Настоятельно рекомендуем упорядочить публикуемый поток по ключевым кадрам (key frames), а именно – в настройках H.264 необходимо выставить небольшой фиксированный интервал между ключевыми кадрами (1-2 секунды).

Публикация потока

Возможные способы публикации потока в сети CDNvideo:

  • RTMP-publish
  • RTMP-pull
  • RTSP-publish
  • RTSP-pull
  • MPEG_TS-publish

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 (для других кодеров аналогично):

  • Format: H.264
  • Frame Rate: 30 fps
  • Input Size: 640×480
  • Bit Rate: 700 Kbps
  • Output Size: 640×480
  • Audio: 64k AAC mono 44100 Hz

В случае трансляции одного события в нескольких битрейтах одновременно на вкладке “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. Предварительно должны быть выполнены следующие условия:

  • доступность кодирующего устройства по постоянному публичному IP-адресу;
  • на кодирующем устройстве должен быть доступен для входящих соединений порт 554/tcp.

Для конфигурирования необходимо предоставить следующую информацию:

  • URL RTSP-источника;
  • название потока, например cam1.stream

Пример 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. Необходимо предоставить следующую информацию:

  • количество публикуемых потоков;
  • если есть пожелания по именованию раздаваемых потоков, сообщите нам имя каждого потока, (например, «stream1», «stream2»). Опционально.

Для публикации выделяются адреса двух серверов (основной и резервный) и каждому потоку назначается отдельный UDP-порт. Например:

  • поток stream1, UDP-порт 1111, IP: 1.2.3.4 primary, 2.3.4.5 backup
  • поток stream2, UDP-порт 2222, IP: 1.2.3.4 primary, 2.3.4.5 backup

Кодирующее устройство должно быть настроено на отправку потока (потоков) по указанным адресам и портам. Потоки будут раздаваться под заданными именами.

Вещание конечным пользователям

Для вещания конечным пользователям используются следующие протоколы:

  • RTMP/RTMPT;
  • RTSP;
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).

В случае проблем с трансляцией потока по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности, рекомендуется рассмотреть следующие варианты:

  • Вещание по протоколу RTMP, при этом на сервере раздачи задействован порт tcp/80, обычно используемый веб-серверами. Передаются стандартные RTMP-пакеты. Способ позволяет обойти большинство фильтров.
  • Вещание по протоколу RTMPT (RTMP tunneling over HTTP). Трафик RTMP инкапсулируется в HTTP, сервер раздачи отдаёт пакеты с порта tcp/80. С точки зрения межсетевого экрана такие пакеты ничем не отличаются от стандартного веб-трафика.

Возможно ведение трансляции в нескольких битрейтах, с возможностью переключения между ними в плеере. Переключение между битрейтами вручную или автоматически в адаптивном режиме, в зависимости от реализации плеера. При этом для HTTP-протоколов (HLS/HDS/MSS) мы можем объединить несколько битрейтов одним манифест-файлом, то есть дать на выходе готовое решение для адаптивного вещания.
Возможные варианты реализации вещания в нескольких битрейтах:

  • Для каждого битрейта публикуется отдельный поток.
  • Публикуется один поток в высоком качестве, который на выходе преобразуется в несколько битрейтов. Вариант реализуется за счёт использования сервиса «Транскодирование выходных потоков», описанного в разделе 5.7.

Порядок действий при подключении

1. Для размещения ссылок на трансляцию вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.customer.ru (опционально).
2. Оценить максимальное количество одновременных зрителей и предполагаемый средний битрейт и сообщить эти параметры нам для резервирования полосы пропускания (если предполагаемое максимальное количество одновременных зрителей превышает 1000).
3. Выбрать способ публикации потока и сообщить нам. В зависимости от выбранного способа мы запросим или предоставим необходимую информацию.
4. Настроить кодирующее устройство.
5. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
6. Настроить ваш плеер на отображение потоков через сеть CDNvideo.

4.2 Потоковое вещание по запросу (Video on Demand Streaming)

Базовые принципы

Потоковое вещание по запросу подразумевает загрузку файлов на сервера раздачи CDNvideo с сервера-источника. Загрузка файла происходит пофрагментно, по мере необходимости и только в случае отсутствия соответствующего фрагмента в кэше сервера раздачи, обрабатывающего запрос пользователя. Например, в обязательном порядке начнётся загрузка файла на сервер раздачи при первом пользовательском запросе, направленном на данный сервер. Для загрузки используется протокол HTTP, полученные фрагменты сохраняются в кэше сервера раздачи и используются при следующих обращениях пользователей.
Требования к исходным файлам – тип контейнера:

  • FLV;
  • MP4.

Требования к исходным файлам – кодеки:

  • видеокодек – H.264;
  • аудиокодек – AAC или MP3.

Вещание конечным пользователям

Для вещания конечным пользователям используются следующие протоколы:

  • RTMP/RTMPT;
  • RTSP;
  • HTTP (псевдостримминг, более подробно в разделе 4.2.3);
  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).

В случае проблем с трансляцией видео по протоколу RTMP в сторону пользователей, находящихся в корпоративных сетях с жёсткими политиками безопасности, рекомендуется рассмотреть следующие варианты:

  • Вещание по протоколу RTMP, при этом на сервере раздачи задействован порт tcp/80, обычно используемый веб-серверами. Передаются стандартные RTMP-пакеты. Способ позволяет обойти большинство фильтров.
  • Вещание по протоколу RTMPT (RTMP tunneling over HTTP). Трафик RTMP инкапсулируется в HTTP, сервер раздачи отдаёт пакеты с порта tcp/80. С точки зрения межсетевого экрана такие пакеты ничем не отличаются от стандартного веб-трафика.

Псевдостримминг

В нашей сети поддерживается псевдостримминг видеофайлов по протоколу 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.

4.3 Раздача аудиопотоков

Базовые принципы

В нашей сети поддерживается три варианта работы с аудиопотоками:

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-й вариант)

1. Сообщить нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo. Итоговая ссылка на поток, используемая для вещания через нашу сеть, будет выглядеть следующим образом: http://icecast.customer.cdnvideo.ru:8000/stream_name

Порядок действий при подключении (2-й вариант)

1. Сообщите нам URL потока на сервере-источнике SHOUTcast/Icecast. Пример URL: http://icecast.abc-customer.ru:8000/
2. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
3. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.

Порядок действий при подключении (3-й вариант)

1. Выберите способ публикации и сообщите нам. В зависимости от выбранного способа мы предоставим дополнительную информацию.
2. Настройте кодирующее устройство.
3. Проверьте трансляцию аудио на странице с тестовым плеером (URL страницы мы предоставим).
4. Настройте ваш плеер на вещание аудиопотоков через сеть CDNvideo.

4.4 Кэширование HTTP-контента

Базовые принципы

Под 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”.
wordpress

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.

Обработка query string

При раздаче объектов с URL, содержащими строку параметров (query string) вида:
http://server/path/program?query_string

следует учесть, что по умолчанию при кэшировании такого объекта ‘query string’ удаляется из HTTP-заголовка Request URI. При последующих запросах пользователям будет выдаваться первый закэшированный объект с таким URL, без учёта значения ‘query string’ в запросе. Если такая модель работы не устраивает и сохранение ‘query string’ в URL необходимо – сообщите нам об этом и мы активируем эту опцию.

Файл robots.txt

Файл robots.txt предназначен для роботов поисковых систем. Поддерживается три варианта использования файла:

  1. Мы используем собственный robots.txt, который запрещает индексирование для кэшируемого контента. Это стандартная опция, которая применяется по умолчанию.
  2. Мы проксируем с сервера-источника ваш robots.txt без изменений.
  3. Мы используем robots.txt, присланный вами.

По умолчанию мы используем вариант 1, чтобы предотвратить множественную индексацию контента. В большинстве случаев этот вариант наиболее предпочтителен. Тем не менее, в некоторых случаях (например, при кэшировании CSS и скриптов) при использовании варианта 1 возможны нежелательные эффекты, которые могут привести к потере позиций сайта в выдаче поисковых систем. В этом случае более оптимальным выбором может быть вариант 2 или 3. Окончательное решение остаётся за вами, исходя из структуры сайта и характера кэшируемого контента.
Рекомендации Яндекс и Google доступны по ссылкам:
Яндекс
Google

Процедура добавления CNAME

В качестве примера рассмотрим процесс добавления CNAME для домена telecat.cdnvideo.ru вида cdn.telecat.ru.
Порядок действий:

1. В разделе Услуги -> DNS-хостинг выбрать услугу DNS-master для хостинга, к домену которого необходимо добавить ресурсную запись CNAME, кликнув по кнопке <Управление DNS-зонами>.
Управление DNS

2. Выбрать домен, для которого необходимо добавить CNAME, кликнув по нему (в нашем примере telecat.ru).
Выбор домена

3. Кликнуть по кнопке <Добавить новую запись>.

4. В поле Type выбрать тип ресурсной записи CNAME, добавить алиас и каноническое имя в одноименные поля.
Важное замечание: каноническое имя необходимо указывать с точкой на конце.
При необходимости указать время кеширования в поле TTL. Кликнуть по кнопке <Добавить>.
Записи CNAME

5. Для того, чтобы предварительно просмотреть полученный с учетом изменений файл зоны, кликнуть по ссылке Предпросмотр зоны.
6. Проверить корректность добавленной записи. Запись должна выглядеть так, как показано на скриншоте.
Добавление записи

7. Выгрузить файл зоны на Ваш сервер, кликнув по соответствующей кнопке.

Заголовки CORS

В определённых случаях обращение к контенту, размещённому в 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).

Необходимые исходные данные:

  • Общий объем веб-контента (в случае, если этот объем превышает 100 Мбайт). В соответствии с этим значением для вас будет определён размер кэша на каждом сервере раздачи. По умолчанию выделяется 100 Мбайт.
  • Время хранения объектов, для которых не выставлен заголовок Cache-Control или Expires. По умолчанию такой контент хранится в кэше 24 часа.
  • Если вы используете строку параметров (query string) в URL объектов, сообщите нам, следует ли кэшировать такие объекты с полными URL, включающими строку параметров. По умолчанию ‘query string’ удаляется из URL кэшируемых объектов.

Сервис TLS/SSL

Для веб-ресурсов, использующих защищенные соединения HTTPS, мы предлагаем сервис терминации TLS/SSL на наших серверах раздачи. Проясним терминологию. HTTPS – это расширение обычного протокола HTTP, позволяющее передавать веб-трафик в зашифрованном виде. Передаваемые данные защищены от прослушивания (конфиденциальность) и подмены (целостность). Кроме того, при установлении HTTPS-соединения проверяется подлинность сервера (аутентификация сервера). Для установления HTTPS-соединений используется протокол TLS, который ранее назывался SSL. Далее по тексту используется термин TLS.
Необходимым условием работы TLS является наличие на сервере цифрового сертификата. В нашей сети возможно два варианта использования сертификата и выбор находится в прямой зависимости от того, какое доменное имя вы используете для кэшируемого контента.
В первом случае кэшируемый контент находится в зоне *.cdnvideo.ru. Мы используем наш собственный сертификат, подписанный одним из доверенных международных удостоверяющих центров (УЦ), детали сертификата можно уточнить у нашей службы технической поддержки. Сертификат CDNvideo уже размещён на всех серверах раздачи нашей сети, от вас дополнительных шагов не требуется.
Обратите внимание, что наш сертификат валиден только для доменов третьего уровня. Домены 4-го и следующих уровней нашим сертификатом не подтверждаются. Примеры:
домен customer.cdnvideo.ru – OK!
домен static.customer.cdnvideo.ru – FAIL!

Использование сертификата CDNvideo

Во втором случае кэшируемый контент находится в вашей доменной зоне с использованием CNAME. Используется ваш сертификат, подписанный доверенным УЦ, и соответствующий ему закрытый ключ. От вас нам потребуется два файла, которые будут размещены на всех серверах раздачи CDNvideo:
Цифровой сертификат в формате PEM. Обычно это файл с расширением .crt. Сертификат должен быть подписан общепризнанным доверенным УЦ и быть валидным – с неистёкшим сроком действия, доменное имя в сертификате должно соответствовать используемому CNAME. Проверьте это заранее. В случае сомнений присылайте сертификат нашей службе технической поддержки для проверки.
Соответствующий сертификату закрытый ключ в формате PEM. Обычно это файл с расширением .key. При генерации ключа не используйте passphrase, мы не сможем использовать такой ключ!

Использование своего сертификата

Примеры выбора варианта:
Контент в зоне customer.cdnvideo.ru – используется сертификат CDNvideo.
Контент в зоне static.yourcompany.com – используется ваш сертификат.

Терминация TLS в нашей сети подразумевает, что защищённое соединение устанавливается между пользователем и сервером раздачи CDNvideo. Между серверами раздачи и источником обычно используется стандартный HTTP и в большинстве случаев этого вполне достаточно. Если по какой-то причине вам необходимо использовать TLS на участке «сервер раздачи – источник», убедитесь, что на сервере-источнике имеется валидный сертификат, подписанный доверенным УЦ.

5. Дополнительные сервисы

Авторизация доступа к потоковому контенту

Сервис применим как для 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, привязка к доменам).

5.2 Авторизация доступа к HTTP-контенту

Мы поддерживаем два метода ограничения доступа к 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/

Авторизовываться будет каждая единица контента – плейлисты, чанклисты, медиа-чанки.

5.3 Программный интерфейс (API) сети CDNvideo

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

Просмотр HTTP-кэша

Для поиска отдельного объекта в кэше серверов раздачи используется команда 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’

Очистка HTTP-кэша

Для удаления отдельного объекта в кэше всех серверов раздачи следует использовать команду 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’

Выгрузка логов статистики при помощи ПО get_log.py

Для начала работы скачайте скрипт

Скрипту передаются аргументы (* – обязательные):
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. Обратиться в службу поддержки

5.4 Кодирование на лету

Базовые принципы

Сервис применим только в случае потокового вещания по запросу (VOD), и, соответственно, неприменим для трансляций в режиме реального времени. Для вещания конечным пользователям используются адаптивные протоколы Adobe HTTP Dynamic Streaming (HDS) или Apple HTTP Live Streaming (HLS).

При запросе от плеера пользователя на получение видеопотока HTTP-фрагменты формируются в сети CDNvideo динамически, «на лету», в соответствии с запрошенным битрейтом. При этом на стороне поставщика достаточно одного оригинального видеофайла в хорошем качестве. Качество оригинального файла является верхней границей при отдаче потока пользователям.

Оригинальный файл скачивается с сервера-источника при первом обращении пользователя к контенту, формируются фрагменты в запрошенном битрейте и транслируются пользователю. При этом полученные фрагменты кэшируются на серверах раздачи сети CDNvideo и используются при последующих обращениях пользователей. Повторные обращения к серверу-источнику выполняются только при отсутствии необходимых фрагментов на серверах раздачи. Упрощённая схема работы сервиса представлена на Рис. 6.
Работа сервиса

Требования к исходным файлам

Тип контейнера:

  • MP4 с одной аудиодорожкой и одной видеодорожкой.
  • FLV с метатегами, полученными при обработке утилитой flvtool2 (http://www.inlet-media.de/flvtool2/) или другими утилитами, создающими такой же набор тегов.

Кодеки:

  • видеокодек – H.264 (constrainted baseline profile, baseline profile, main profile, high profile);
  • аудиокодек – AAC.

Общие требования:

  • обязательно наличие аудиодорожки;
  • в названии файла должны использоваться английские буквы и знаки препинания, допустимые в именах файлов;
  • расширение файла должно быть flv для FLV-контейнера и mp4 для MP4-контейнера.

Порядок действий при подключении

1. Для размещения ссылок на контент вам будет выделен домен в зоне ответственности CDNvideo вида customer.cdnvideo.ru. Для этого домена вы можете создать псевдоним (CNAME) в своей зоне ответственности DNS вида cdn.customer.ru (опционально).
2. Сообщить URL источника контента (например, http://origin.customer.ru/video/).
3. Определить и сообщить нам выбранный протокол адаптивного вещания (HDS и/или HLS).
4. Определить и сообщить нам перечень необходимых битрейтов.
5. После получения подтверждения проверить корректность показа видео на тестовом объекте/домене.
6. Настроить плеер, размещаемый на вашем сайте, на отображение потоков через сеть CDNvideo.

5.5 Генерация скриншотов

Базовые принципы

Сервис позволяет оперативно получать «моментальные снимки» (скриншоты) live-потока. Условия применимости сервиса:

  • только для трансляций в режиме реального времени (live);
  • live-поток предварительно опубликован в сети CDNvideo.

Скриншот представляет из себя статичное изображение в формате JPEG заранее определённого размера. Скриншоты формируются с заданной периодичностью (по умолчанию 1 минута). Может быть одновременно сформировано несколько скриншотов разного размера. Текущие скриншоты потока доступны для скачивания по HTTP, предоставляется постоянный URL для каждого размера. При остановке потока будет доступен последний зафиксированный скриншот.

Порядок действий при подключении

1. Сообщить нам URL опубликованного live-потока.
2. Сообщить требуемые размеры скриншотов (по умолчанию формируется один скриншот с размером, равным размеру видео оригинального потока).
3. Сообщить частоту обновления скриншотов (по умолчанию 1 минута).
4. Для каждого выбранного размера будет предоставлен постоянный URL.

5.6 Транскодирование входного потока

Базовые принципы

В нашей сети есть два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам.

Транскодирование входного потока применяется в том случае, если у вас нет возможности отдать нам поток стандартными для нашей сети способами, описанными в разделах 4.1.2 и 4.1.3, то есть, не выполняются требования к кодированию потока и способам доставки. В этом случае мы берём на себя «нормализацию» потока, приведение его к виду, понятному нашим потоковым серверам. При этом попутно могут меняться и другие характеристики потока, такие, как битрейт и разрешение. После транскодирования поток транслируется в сторону конечных пользователей стандартными средствами нашей сети, описанными в разделе 4.1.4. Важное замечание – вы отдаёте один поток на вход и на выходе получаете тоже один поток.

Порядок действий при подключении

1. Сообщить нам URL live-потока.
2. Соообщить нам необходимые значения битрейта и разрешения потока после транскодирования (опционально; по умолчанию сохраняются исходные параметры).
3. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
4. Настроить плеер, размещаемый на вашем сайте, на отображение потока через сеть CDNvideo.

5.7 Транскодирование выходных потоков

Базовые принципы

В нашей сети есть два сервиса транскодирования – «Транскодирование входного потока» и «Транскодирование выходных потоков», при необходимости эти два вида могут комбинироваться. Сервисы применимы только к live-потокам.

Транскодирование выходных потоков – это преобразование одного входного live-потока в несколько выходных потоков с разным битрейтом и разрешением. При этом упорядочиваются ключевые кадры (key frames) в потоках, что позволяет плавно переключаться между битрейтами в плеере (автоматически в адаптивном режиме или вручную).

Важное замечание – в большинстве случаев один поток на входе преобразуется в несколько потоков с разным битрейтом на выходе. Тем не менее, можно использовать сервис для транскодирования по схеме «один в один», с одним потоком на выходе.

Условия применимости сервиса:

  • только для трансляций в режиме реального времени (live);
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • публикация потока стандартными для нашей сети способами – RTMP, RTSP, MPEG_TS-publish.

Доступные протоколы вещания в сторону конечных пользователей:

  • RTMP/RTMPT;
  • RTSP;
  • Apple HLS;
  • Microsoft Smooth Streaming – MSS.

Внимание: протокол Adobe HDS для вещания в нескольких битрейтах не поддерживается.

Для протоколов HLS и MSS сервис позволяет не просто создавать набор потоков с разным битрейтом, но и объединять эти потоки манифест-файлом, то есть получить на выходе готовое решение для адаптивного вещания.

Порядок действий при подключении

1. Опубликовать оригинальный поток.
2. Определиться с протоколами вещания в сторону конечных пользователей.
3. Соообщить нам требуемые параметры выходных потоков – битрейт, разрешение, профиль кодека H.264 и т.д.
4. Проверить показ трансляции на странице с тестовым плеером (URL страницы мы предоставим).
5. Настроить плеер, размещаемый на вашем сайте, на отображение потоков через сеть CDNvideo.

5.8 Навигация по эфиру (DVR)

Базовые принципы

Смысл сервиса – постоянная запись live-потока в рамках определённого временно́го скользящего окна с возможностью навигации в рамках этого окна. Размер окна называется глубиной DVR. Окно постоянно «скользит», то есть при глубине DVR, равной 2-м часам, «отмотать» назад в плеере удастся максимум на 2 часа от текущего момента.
Условия применимости сервиса:

  • только для live-трансляций;
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • поток опубликован по схеме RTMP-publish.

Для нормальной работы сервиса публикуемый поток должен быть упорядочен по ключевым кадрам (key frames), а именно:

  • интервал между ключевыми кадрами должен быть фиксированным;
  • интервал между ключевыми кадрами должен быть небольшим (1-2 секунды).

Для вещания в сторону конечных пользователей поддерживаются только HTTP-протоколы:

  • Adobe HDS;
  • Apple HLS;
  • Microsoft Smooth Streaming (MSS).

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:

  • append. В случае остановки потока DVR-контент не удаляется. При возобновлении потока контент бесшовно добавляется к ранее записанному.
  • delete. В случае остановки потока более, чем на 5 минут, записанный DVR-контент удаляется. При возобновлении потока запись DVR начинается заново.

Порядок действий при подключении

1. Опубликовать поток (потоки) по алгоритму, описанному в разделе 4.1.5.

2. Сообщить нам следующие данные:
имя потока (потоков);
требуемую глубину DVR;
выбранную стратегию записи;
протоколы вещания в сторону конечных пользователей.

3. Проверить показ трансляции на странице с тестовым плеером, URL страницы мы предоставим отдельно.

4. Настроить ваш плеер на запрос потоков через сеть CDNvideo.

5.9 Запись трансляций

Базовые принципы

Смысл сервиса – запись live-трансляций в виде файлов с их последующей выгрузкой в облачное хранилище.

Условия применимости сервиса:

  • только для live-трансляций;
  • видеокодек входного потока – H.264;
  • аудиокодек входного потока – AAC или MP3;
  • протокол – RTMP или HLS.

На выходе получаем файлы в формате MP4, длительность отдельного файла не более 3-х часов.

Запись файлов может осуществляться следующими способами:

  • “По кнопке” – запись инициируется пользователем из личного кабинета.
  • По расписанию – запись осуществляется по заранее созданному расписанию.
  • При помощи API вызовов.

Печать
TRY FREE