Microsoft Azure Media Services

В течение многих лет Microsoft помогала в проектировании и поддержке крупномасштабной доставки потокового видео в реальном времени. Один из ярких примеров — Олимпийские игры в Сочи в 2014 году. Это потребовало колоссальных технологических ресурсов, в том числе аппаратных серверов, огромного количества исходных видеопотоков, кодирования, избыточности серверов (сдвоенных информационных центров), адаптируемых выходных видеопотоков (output-adaptive video streams), применения сетей доставки контента (Content Delivery Networks, CDN), участия компаний-партнеров и, конечно, сотрудников Microsoft.

Все эти ресурсы наряду с разработкой ПО для заказчиков должны гарантировать полную прямую видеотрансляцию события с минимальными перебоями или вообще без таковых. Стоимость управления этими ресурсами отражает масштаб мероприятия. Приобретение необходимых серверов, коммутаторов и соответствующих технологий влечет за собой высокие капитальные затраты. Это создает очевидные риски и ставит следующие вопросы.

• Достаточно или слишком много было приобретено оборудования для прямой трансляции события данного масштаба?
• Что вы будете делать с этим оборудованием до следующего крупного события?
• На какой срок сохранят свою актуальность приобретенные технологии?
• Правильно ли были подобраны технологические партнеры, чтобы гарантированно избежать любых сбоев?

Опираясь на знания и достижения Microsoft в прямой трансляции видео с крупных мероприятий, группа Microsoft Azure Media Services разработала технологию потоковой передачи видео в реальном времени, чтобы уменьшить эти риски. Группа успешно передавала видеопотоки в реальном времени по глобальным каналам с Олимпийских игр в Сочи, используя Microsoft Azure Media Services. Хотя это было чрезвычайно крупное событие, Microsoft Azure обеспечивала выделение аппаратного обеспечения по требованию для поддержки масштабируемости любого уровня.

В зависимости от масштаба события запрос к Azure Media Services может создавать соответствующую единицу масштаба (малую, среднюю или большую), чтобы обеспечить доставку прямого потокового видео сотням тысяч или всего сотням зрителям. Расценки предусматривают различные предоплатные модели (pay-as-you-go models) с четкими тарифами, известными до использования сервиса прямой потоковой видеотрансляции какого-либо события. Аппаратное обеспечение и инфраструктура постоянно модернизируются и обновляются. Microsoft также поддерживает стратегические отношения с партнерами, связанными с доставкой решений по прямой потоковой видеотрансляции.

В этой статье я сосредоточусь на сценарии-примере, в котором будет использоваться новый сервис прямой потоковой видеотрансляции от группы Microsoft Azure Media Services (он пока доступен только для закрытого предварительного просмотра). Здесь я рассмотрю ранее упомянутые риски и связь предложения прямой потоковой видеотрансляции с существующим сервисом «видео по заказу» (video-on-demand, VOD).

Концепции и терминология

Важно понимать некоторые концепции и терминологию, относящиеся к Azure Media Services. Термином «канал» (channel) обозначают представление на уровне разработчика полного пути, который проходит один видеопоток реального времени через Azure Media Services. Канал может находиться в различных состояниях, из которых наиболее важны два: «остановлен» (stopped) и «работает» (running). Канал включает следующие компоненты, которые координируют видеопотоки в системе.

• URI приема (ingest URI) Представляет входную точку, в которой канал принимает один или более видеопотоков с разным битрейтом (video bitrate streams) для доставки.
• URI предварительного просмотра (preview URI) Представляет выходную точку потока реального времени, принимаемого каналом, которую следует использовать только для мониторинга.
• Программа Связана с каналом и представляет часть прямого потока, сохраненного в Blob Storage как ресурс. В канале должна быть создана минимум одна программа в состоянии «работает», чтобы обеспечить потоковую передачу в реальном времени. Программа будет активно захватывать видео, пока находится в состоянии «работает».
• Ресурс (asset) Связан с программой и представляет данные, хранящиеся в Blob Storage. Ресурс может содержать один или более файлов, включая видео, аудио, изображения, наборы эскизов (thumbnail collections) и манифест. Ресурс может существовать даже после удаления программы.
• Локатор (locator) Связан с ресурсом и источником. Локатор предоставляет URI, используемый как выходная точка потока программы.
• Источник (origin) Связан с локатором и представляет масштабируемую выходную точку для доставки видеопотоков с URI локатора ресурса (asset’s locator URI) в нескольких форматах битрейта (multiple bitrate, MBR), например Smooth, HTTP Live Streaming (HLS) и Dynamic Adaptive Streaming поверх HTTP.

Azure Media Services гарантирует создание необходимых уровней избыточности и доступности для надежной доставки видео с требуемым масштабированием. Такая доставка может включать множество устройств, использующих разнообразные форматы потоковой передачи, такие как Smooth, HLS и DASH. На рис. 1 показано, из чего состоит канал.

Увеличить
Рис. 1. Канал доставки — полный путь видеопотока в реальном времени

Важно понимать связь между каналом и одной или более программами, созданным в рамках канала. На рис. 2 прямая видеотрансляция события отображается на (mapped onto) представление канала, который находится в состоянии «работает» с 5 PM до 2 AM (с 17-00 до 2-00). Заметьте, что время перехода канала из состояния «остановлен» в состояние «работает» может занимать от 10 до 20 минут. Маркеры интервала (interval markers) — Concert1, Vip1, Act1, Act2 и Vip2 — представляют программы и их планируемое время начала и окончания. Кроме того, маркеры интервала Transition представляют время между текущей и следующей программой, где первая заканчивается, а вторая начинается.

Увеличить
Рис. 2. Прямая видеотрансляция события, сопоставленная с началом в 5 PM и окончанием в 2 AM

Azure Media Services гарантирует создание необходимых уровней избыточности и доступности для надежной доставки видео с требуемым масштабированием.

Это один из примеров того, как с помощью программ можно отобразить на канал расписание. На рис. 2 одна программа, которая охватывает все событие.

Concert1 будет в состоянии «работает» с 5:15 PM до 2 AM со скользящим буфером для видео на 10 минут. Буферизация делает возможной перемотку при просмотре с помощью медиа-плеера. Программа Concert1 предоставляет основной видеопоток всего события в реальном времени. URI-идентификаторы сетей CDN предоставляются для сопоставления до начала события.

Остальные программы — Vip1, Act1, Act2 и Vip2 — должны быть в состоянии «работает» в течение интервалов, определенных временем запуска и окончания, с отклонениями, допустимыми для переходов. Программа не начинается и не заканчивается немедленно. Вы должны учитывать переходы, планируя прямое освещение события. В состоянии «работает» одновременно может быть несколько программ, все из которых захватывают видео. Concert1 и другая программа начнутся и закончатся в течение события. Чтобы понять, как использовать переход, вы могли бы выдавать запрос на запуск программы для Vip2 в 6:45 PM, затем запрашивать окончание программы для Vip1 в 7 PM, предусматривая 15-минутный интервал перехода. Таким образом, в течение этого 15-минутного перехода в состоянии «работает» могли бы находится три программы.

Описав общие концепции и терминологию, я сосредоточусь на использовании временного графика события (рис. 2), отображенного на пользовательский сценарий для разработки примеров кода с применением Azure Media Services API.

Тема: Contoso’s Blues Bar

Хорошо известная в США концертная площадка для подающих надежды музыкантов, Contoso’s Blues Bar , имеет жесткие сроки на то, чтобы распланировать предстоящий «живой» концерт европейской группы Contoso and Shock Wallets. Поклонники этой группы в основном находятся в Европе. Концерт в Contoso будет американским дебютом этой группы. Администраторам шоу нужно организовать прямую потоковую трансляцию этого концерта, чтобы ее поклонники в Европе могли смотреть концерт на своих компьютерах и мобильных устройствах.

Начальник IT-отдела Contoso’s Blues Bar созывает собрание и просит свою группу по технологиям провести исследования и порекомендовать решение, которое будет отвечать следующим требованиям:

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

Первый спринт

Группа планирования мероприятий в Contoso’s Blues Bar занимается в течение следующих нескольких дней определением своих пользовательских историй (user stories). Эти истории станут основой для планирования спринта в доставке потокового видео реального времени с концерта. В ходе совещания группа определяет некоторые пробелы, которые вызовут ряд спайков2 (spikes) (вопросов, требующих решения) в течение первого спринта. Группа также определяет следующий список более крупных пользовательских историй, обычно называемых эпопеями (Epics) в стандартном формате «as a… I want… so that…» («как… я хочу…, чтобы…»):

Как поклонник Contoso and the Shock Wallets я хочу смотреть «живой» концерт на своем устройстве с максимально возможным качеством видео, чтобы насладиться их дебютным выступлением в США.

Как поклонник Contoso and the Shock Wallets я хочу смотреть видеозапись концерта на своем устройстве с максимально возможным качеством видео в другой день и другое время, чтобы увидеть это событие на досуге.

Как представитель Contoso’s Blues Bar я хочу доставлять прямые широковещательные трансляции наших концертов и сократить затраты на доставку потокового видео реального времени с нашей концертной площадки, чтобы мы могли привлекать больше музыкантов и посетителей, в то же время экономя деньги.

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

Пользовательская история 1.1 Как специалист отдела производства я хочу разместить одну или более камер, чтобы мы могли захватывать видео «живого» концерта.

Спайк 1.1.1 Какой тип камеры используется и что представляет собой выходной видеопоток?

1Разумеется, в этом примере используется вымышленная концертная площадка. — Прим. ред.

2Терминология из методологии Agile разработки ПО, в том числе SCRUM (Скрам). — Прим. ред.

Производственный персонал выясняет, что они могут приобрести б/у высококачественные видеокамеры, чтобы выдавать видео- и аудиопотоки высокого разрешения (high definition, HD) по Serial Digital Interface (SDI).

Пользовательская история 1.2 Как специалист отдела производства я хочу передавать в реальном времени потоковое видео в Интернет, чтобы поклонники могли смотреть концерт.

Спайк 1.2.1 Как будет доставляться видео с камеры в эксплуатационный комплекс (production station)?

Производственный персонал выясняет, что Contoso Switch Company выпускает коммутатор видео HD SDI-to-fiber-optics. Они могут использовать этот коммутатор максимум с четырьмя камерами.

Спайк 1.2.2 Как этот видеоканал будет доставляться в IT-отдел?

Производственный персонал выясняет, что оптоволоконный коммутатор видео (fiber-optics video switch) будет выводить видео- и аудиопоток HD SDI, который они смогут подключить к коммутатору аудио/видео. Тогда они смогут контролировать, сигнал с какой камеры будет активен, используя широковещательную панель (broadcast panel). Видеопоток реального времени в конечном счете посылается с шипоковещательной панели по соединению HD SDI.

Пользовательская история 1.3 Как сотрудник IT-отдела я хочу доставлять видеопотоки на устройства с Windows, iOS и Android, чтобы видеотрансляция концерта получала максимальную аппаратную поддержку этих устройств.

Вы должны учитывать переходы, планируя прямое освещение события.

Спайк 1.3.1 Какой тип видеопотока я получаю, чтобы доставлять видео в Интернет?

IT-отдел будет получать видеопоток HD SDI.

Спайк 1.3.2 Какие типы видеопотоков нужны для целевых устройств?

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

• Smooth Streaming — для Windows 8 и Windows Phone 8;
• HLS — для iOS и Android;
• DASH — для Windows 8.1, Windows Phone 8 и Xbox One.

Спайк 1.3.3 Как я доставляю это видео в Интернет с масштабированием?

IT-персонал выясняет, что Microsoft объявила о новой функциональности в Azure, которая как раз и решает проблемы потоковой передачи видео реального времени через Интернет. Проведя некоторые исследования, группа обнаруживает, что Azure Media Services может предоставить промежуточный уровень между их концертной площадкой и целевыми устройствами. А самое главное в том, что они узнали следующие детали по Azure Media Services.

• Как только вы зарегистрировали учетную запись в Azure и добавили учетную запись Media, вы можете создать канал потоковой передачи реального времени (live streaming channel). Канал реального времени — это синоним ТВ-канала. Все выделяемые серверные ресурсы отдаются этому каналу для доставки ваших программ. В канале может быть много программ. Программа — это определение слота времени и связанного ресурса. Ресурс — место хранения потокового видео в Azure Media Services.
• Выделение серверов гарантирует, что избыточность встраивается в путь видео без единой точки сбоя.
• Видеопоток реального времени можно приниматься Azure Media Services как RTMP или MPEG TS по URI приема.
• Устройства могут запрашивать видеопоток, который они могут полноценно поддерживать своими аппаратными средствами. Microsoft Azure Media Services гарантирует упаковку видео в должный базовый формат по URI, специфичному для устройства.
• В серверы источника видеопотока реального времени встроена поддержка для защищенного доступа провайдером CDN, таким как Akamai Technologies.

Дополнительные результаты спайков 1.3.1 и 1.3.2 IT-персонал выбирает кодировщик, способный принимать видео/аудио поток HD SDI. Этот кодировщик может использовать потоки HD SDI для динамической генерации нескольких потоков с разными битрейтами для доставки в Azure Media Services, который предоставляет URI входа, принимающий RTMP или MPEG TS как входной формат.

Второй спринт

После утреннего кофейного ритуала разработчики приступают к написанию кода, который поможет освещать событие в реальном времени.

Пользовательская история 1.4.1 Как разработчик я хочу создать необходимые учетные записи Azure, чтобы начать писать код, обеспечивающий потоковую передачу видео.

Зайдите на веб-сайт Azure (azure.microsoft.com), щелкните кнопку Try for free и следуйте инструкциям. Узнайте больше о получении учетной записи на bit.ly/1mfacft. В процессе регистрации вы можете создать учетную запись Windows, используемую как удостоверения администратора. Чтобы создать учетную запись Azure Media Services, вы должны сначала создать учетную запись Azure Storage, так как видеоресурсы трансляции события в реальном времени будут храниться в Blob Storage. В документации Azure Media Services также рекомендуется создавать учетную запись хранилища в том же информационном центре, что и учетную запись Azure Media Services.

Пользовательская история 1.4.2 Как разработчик я хочу написать код для управления каналом, чтобы можно было доставлять видеопотоки реального времени.

Для производственных каналов рекомендуется ограничивать доступ, используя известные значения, например IP-адрес в ваших кодировщиках или маркерах аутентификации.

Создайте базовый проект в Visual Studio 2012. Затем установите NuGet-пакеты для Azure Media Services. Создайте функцию CreateContosLiveEvent и начните с объекта CloudMediaContext, который всегда используется для управления вашими потоками реального времени:

private void CreateContosLiveEvent()
{
  string liveAccount = "yourAzureMediaAccount";
  string liveKey = "yourAzureMediaAccountKey";
  CloudMediaContext LiveServices = new CloudMediaContext(
    liveAccount,  // URI, созданный ранее
    liveKey );    // имя учетной записи

Напишите код для работы сервиса источника. Этот сервис будет доставлять потоки реального времени провайдерам CDN, как показано на рис. 3.

Рис. 3. Сервис источника доставляет видеопотоки реального времени провайдерам CDN

string originName = "abcdefg";
IOrigin origin = LiveServices.FindOrigin(originName);
if (origin == null)
{
  Task<IOrigin> originTask =
    LiveServices.Origins.CreateAsync(originName, 2);
  originTask.Wait();
  origin = originTask.Result;
}
if (origin.State == OriginState.Stopped)
{
  origin.StartAsync().Wait();
}

Затем вам нужно написать код для создания канала (рис. 4). Канал требует конфигурирования защиты, чтобы обеспечить аутентификацию входящего исходного видеопотока. Источником обычно является кодировщик, сконфигурированный по IP, который преобразует сигнал HDI SDI в требуемые MBR-видеопотоки.

Рис. 4. Создание канала для вашего видеопотока

string channelName = "ContsoBluesChannel";
IChannel channel = LiveServices.FindChannel(channelName);
if (channel != null)
{
  Debug.WriteLine("Channel already exists!");
  return;
}
ChannelSettings settings = new ChannelSettings();
Ipv4 ipv4 = new Ipv4();
// Установка IP в 0.0.0.0/0 разрешает все соединения.
// Не делайте так для производственных целей.
ipv4.IP = "0.0.0.0/0";
ipv4.Name = "Allow all connections";
// Защита URI приема
settings.Ingest = new IngestEndpointSettings();
settings.Ingest.Security = new SecuritySettings();
settings.Ingest.Security.IPv4AllowList = new List<Ipv4>();
settings.Ingest.Security.IPv4AllowList.Add(ipv4);
// Защита URI предварительного просмотра
settings.Preview = new PreviewEndpointSettings();
settings.Preview.Security = new SecuritySettings();
settings.Preview.Security.IPv4AllowList = new List<Ipv4>();
settings.Preview.Security.IPv4AllowList.Add(ipv4);
// Создание канала
Task<IChannel> taskChannel = LiveServices.Channels.CreateAsync(
  channelName, "video streaming", ChannelSize.Large, settings);
taskChannel.Wait();
channel = taskChannel. Result;

В примере кода URI приема и предварительного просмотра конфигурируются на IP-адрес в формате Classless Inter-Domain Routing (CIDR): «0.0.0.0/0». Это позволяет обращаться к URI приема и предварительного просмотра со всех IP-адресов. Для производственных каналов рекомендуется ограничивать доступ, используя известные значения, например IP-адрес в ваших кодировщиках или маркерах аутентификации. Указывайте уникальное название канала. Если уже существует канал с тем же названием, вы получите исключение.

Напишите код, который создает программы, связанные ресурсы и локаторы, как показано на рис. 5. Значения, использованные в качестве имен и расписаний, соответствуют тем, которые были представлены на рис. 2. Флаг enableArchive устанавливается в true при создании программы для всего, кроме Concert1. Значение true указывает, что видеопоток реального времени захватывается, когда программа находится в состоянии «работает», и сохраняется вместе со связанным ресурсом для последующего использования как VOD. Для файла манифеста ресурса создается локатор с политикой доступа в течение 30 дней. Он предоставляет URI для доступа к потоковому видео.

Рис. 5. Создание программ, которые будут работать в ходе вашей трансляции

// Определяем название программы, окно DVR и предполагаемую
// длительность в минутах.
// Примечание: значение окна DVR скорее всего будет
// удалено, когда сервис станет общедоступным
// для предварительной оценки.
Tuple<string, int, int>[] programSettings =
  new Tuple<string, int, int>[]
{
  new Tuple<string,int,int>( "Concert1", 60, 60 ),
  new Tuple<string,int,int>( "Vip1", 75, 75 ),
  new Tuple<string,int,int>( "Act1", 90, 90 ),
  new Tuple<string,int,int>( "Act2", 165, 165 ),
  new Tuple<string,int,int>( "Vip2", 120, 120 ),
};

foreach (Tuple<string, int, int>
  programSetting in programSettings)
{
  IAsset asset = null;

  // Чтобы сохранить ресурс конкретной программы для VOD, этот
  // код проверяет, равны ли по длительности окно DVR и Event.
  // Если да (true), код выставляет флаг, разрешающий
  // архивацию, в true, сообщая системе, что ресурс программы
  // не следует автоматически удалять.
  bool enableArchive = programSetting.Item2 ==
    programSetting.Item3;
  try
  {
    // Создаем ресурс, который используется для сохранения
    // потокового видео, пока программа работает, и VOD
    asset = LiveServices.Assets.Create(
      programSetting.Item1 + "_asset",
      AssetCreationOptions.None);
    Task<IProgram> taskProgram = channel.Programs.CreateAsync(
      programSetting.Item1, "program description",
      true, // enableArchive,
      // Примечание: значение окна DVR скорее всего будет
      // удалено. Не используется.
      TimeSpan.FromMinutes(programSetting.Item2),
      // Оцениваемая длительность
      TimeSpan.FromMinutes(programSetting.Item3),
      asset.Id);
    taskProgram.Wait();
    LiveServices.CreateLocators(asset, TimeSpan.FromDays(30));
  }
  catch (Exception exp)
  {
    Debug.WriteLine(exp.Message);
  }
}

Вы можете получить URI источника от локатора, как и в случае ресурса VOD в Azure Media Services, и предоставить его провайдеру CDN. Поскольку флаг enableArchive установлен, по окончании программы тот же URI источника можно использовать для доставки потока реального времени как ресурса VOD.

Остается написать код для запуска канала и старта программ, когда это нужно. Запрос на запуск канала уведомляет Azure Media Services начать выделять ресурсы для входных сервисов (ingress services), поддержки избыточности и балансировки нагрузки. После запуска канала время между состояниями «запускается» и «выполняется» может достигать от 10 до 20 минут.

Поэтому вы должны заблаговременно запускать канал до начала события, чтобы не помешать возможности просмотра видеопотока реального времени. Кроме того, важно отметить, что после запуска канала начнут накапливаться счета за услуги. Если вы не планируете работу канала в режиме «24×7», то должны останавливать канал и связанные с ним программы, когда они не используются. Код для запуска канала довольно прост:

// Запуск канала
Task start = channel.StartAsync();
start.Wait();

Код для запуска программы тоже несложен:

start = program.StartAsync();
start.Wait();

Одно из основных требований для события — возможность управлять запуском и остановкой канала, а также началом и окончанием каждой программы. Поэтому следующий шаг в разработке — создание простого UI, который будет создавать событие во всей его полноте вызовом метода CreateContosoLiveEvent. Это позволяет запускать/останавливать канал и начинать/заканчивать соответствующие программы тогда, когда это нужно.

Наконец, пока вы разрабатывали приложение, использующее Azure Media Services, другие члены команды занимались настройкой камер, подключали кабели, устанавливали кодировщик видео и конфигурировали CDN-сети. Кроме того, ваш персонал должен выполнить серию тестов, чтобы убедиться в работе всей системы.

Когда концерт должен вот-вот начаться, начинается передача видеопотока реального времени, и различные устройства, настольные компьютеры и планшеты подключаются к Azure Media Services для просмотра видеопотоков реального времени.

Устрашающая задача стала проще

Прямое освещение масштабных событий может оказаться устрашающей задачей. До появления таких решений, как Azure Media Services, доставка видеопотоков реального времени часто требовала значительных капиталовложений в инфраструктурное оборудование. К другим критически важным факторам относится количество систем, необходимых для поддержки различных мероприятий, которые могут быть разными по своему масштабу. В итоге зачастую делались либо чрезмерные, либо недостаточные закупки. Microsoft Azure Media Services устраняет эту проблему. Предложение Live опирается на набор функциональности VOD в Azure Media Services, обеспечивая единые платформу и API для доставки как контента реального времени, так и контента VOD в промышленных масштабах.