Блог Cisco в России и СНГ
Share

Cisco Telepresence Content Server версии 7 – что нового, поддержка протоколов и форматов вещания

- March 24, 2016 13:50

В ноябре прошлого (2015) года вышла новая версия программного обеспечения сервера записи – Cisco TCS, отношение к которой со стороны пользователей я могу оценить как неоднозначное. В этой статье я постараюсь объяснить особенности и причины принятых при разработке этого ПО решений, а также отвечу на часто задаваемые вопросы.

tcs

Хочу напомнить, что сегодня рекомендуемым решением для записи видео с устройств телеприсутствия и последующей его трансляции является именно Cisco TCS, предлагаемый в двух конфигурациях:

Cisco Content Server, поставляемый в виде готового сервера TCS-M4-PROBUN-K9 или виртуальной машины R-VMTCS-PROBUN-K9 – обеспечивает запись одновременно 5 соединений, 2 из которых может быть транслировано в режиме реального времени.
Поддерживается расширение на еще 5 дополнительных сессий записи.

Второй, существенно более дешевый вариант, можно приобрести в составе пакетного решения для небольших и средних предприятий – сервера Be6k, в виде виртуальной машины – BE6K-VMTCS-1R-1L. Такой сервер может записывать 1 соединение и параллельно транслировать еще одно (но уже без записи), то есть поддерживает 2 соединения одновременно. Еще в числе ограничений решения записи для Be6k – отсутствие поддержки формата WMV, поддержка потокового вещания только с помощью внешнего сервера и не возможность включения его в кластер.
Что касается кластера (а это отдельная платная опция + необходимо дополнительное оборудование и ПО для обеспечения его работы), понятно что тем кому необходимо масштабирование решения, оптимально (в том числе и по соотношению цена/производительность) просто приобрести его полнофункциональный вариант, а вот о том насколько остальные ограничения сегодня принципиальны, станет ясно из текста статьи. Забегая вперед сразу скажу что они практически не ограничивают функционал по сравнению со старшей моделью в TCS версии 7.

Какие же новшества нам принесло ПО версии 7?
В первую очередь это, конечно, поддержка новой аппаратной платформы версии 4, на базе сервера Cisco UCS C220 M4 (Intel(R) Xeon(R) CPU E5-2680 v3 @2.50GHz 24 cores,
 64 GB RAM 
), как видно из описания, аппаратная платформа стала гораздо более производительной.
Ответ на частый вопрос, как узнать номер ревизии аппаратной платформы TCS очень прост – достаточно знать его серийный номер.
Он имеет формат – 49A(ID_версии)xxxx, то есть, например, номер 49A40001 соответствует 4-й аппаратной ревизии сервера.

Еще одно важное новшество – миграция на Windows server 2012 R2 Standard Edition и SQL Server 2012.

Напомню, что все редакции Windows Server 2012 R2 Microsoft больше не включают Windows Media Services (или Streaming Media Services, в дальнейшем – SMS), который использовался в предыдущих версиях ПО TCS для распространения контента.
Кто то может возразить, что с октября 2013 года у Microsoft доступен для скачивания Windows Server Essentials Pack с дополнительным расширением Windows Server Essentials Media Pack, который позволяет реализовать Media Streaming. Меня это тоже сначала ввело в заблуждение.
Дело в том, что SMS Windows Server 2008 R2 использует в качестве основных транспортных протоколов потокового вещания RTSP и HTTP (c помощью модуля WMS HTTP Server Control Protocol), и именно эти протоколы используются TCS для вещания с модуля кодирования (encoder) на сервер SMS. К сожалению, сервис с похожим названием в Windows Server 2012 R2 их не поддерживает.
(С Windows Server 2012 R2 Essentials Media Pack поддерживается только вещание на DLNA-совместимые приемники, вещание по технологии “Smooth streaming HTML5” на HTML5-совместимые браузеры в сессии Remote Web Access и другие web приложения. Таким образом он ничем не поможет нам в раздаче потоков с TCS).
Насколько это ограничит встроенный функционал? Часто пользователи TCS опасаются модернизировать ПО до версии 7, беспокоясь что у них может пропасть возможность просмотра видео из браузера.

Чтобы ответить на этот вопрос давайте рассмотрим технологии, применяемые сегодня для передачи контента, а также их особенности.
Условно все технологии можно разделить на 3 категории:

1. Семейство протоколов файлового доступа (http(s),(s)ftp, samba и т.д.)
– Отлично подходят для передачи одиночных, больших файлов.
– Обеспечивается максимальная совместимость (браузеры, клиенты, OS, платформы).
– По сути не являются протоколами мультимедийного вещания.

2. Семейство протоколов обеспечивающих потоковую передачу (RTMP, MMS, RTSP и т.д.)
– Могут использовать в качестве транспорта UDP.
– Организуют медиасессию / сессию вещания, обеспечивая возможность управления / перемотки.
– Обычно, позволяют реализовать доступ к контенту/авторизацию, отдельно от самой медиасессии, что делает возможным реализацию сценария многоадресного вещания (multicast).
– Позволяют передавать сегменты оригинального видео.

3. HLS (Http Life Streaming) – Apple, IIS Smooth Streaming – Microsoft
– Оригинальный файл разбивается на множество мелких (chunks)
– “Manifest file” содержит список (индекс) всех частей
– в качестве транспортного протокола для передачи “chunks” используется http

С моей точки зрения эта последняя, 3-я категория протоколов вещания, сегодня получает наибольшее распространение из-за объединения в себе сильных сторон первых двух категорий – максимальная управляемость и совместимость.
Таким образом, привычные нам ранее, протоколы потокового вещания начинают отходить на задний план. Немаловажную роль в этом процессе имеет все большее распространение видео на мобильных устройствах пользователей. Это, отчасти, объясняет позицию Microsoft по поддержке сервисов потокового видео в ее современных OS.

Но вернемся к Content Server. Не смотря на отсутствие в моей конфигурации серверов вещания:

IIS

Я вполне могу использовать для просмотра видео по требованию в браузере встроенный web сервер – IIS.

On-demaunt servers

С точки зрения пользователя (по крайней мере корпоративного, с быстрым каналом связи до сервера TCS) – разницы в работе с устройством нет, видео грузится мгновенно и управляется не хуже чем в предыдущих версиях.

myvideo

Заслуга в этом конечно не IIS, а современных версий проигрывателей Adobe Flash Player и Microsoft Silverlight, которые умеют проигрывать файлы с сетевых ресурсов. (Один из этих проигрывателей можно выбрать в настройках TCS, как используемый “по умолчанию”).

С точки зрения доступа – это обычный http get запрос:

wireshark

Что касается кодирования, предпочтительный формат зависит от платформы на которой будут просматривать видео и пользовательских установок. Нативный (понятный по умолчанию) формат для Silverlight – WMV, для Flash – MP4.

(Говоря “формат” я подразумеваю что мы имеем дело с различными контейнерами, поддерживаемыми протоколами кодирования для аудио и видео и т.д. Я нарочно упрощаю изложения материала, чтобы не запутаться в терминологии и не допустить неточности.)

На ПК платформах с различными OS, практически всегда доступна возможность установки обоих проигрывателей, использование универсальных проигрывателей других производителей и соответственно, – доступно воспроизведение обоих форматов.
На мобильных платформах все не так просто. Для мобильных устройств на базе IOS и Android воспроизведение видео, закодированного с использованием VC-1(WМV3) встроенными средствами (проигрывателями) не возможно. А вот форматы кодирования MPEG-4 (h264/AVC) проигрываются без проблем. Конечно, для проигрывания потокового видео в QT и Flash, требуется пакетирование в разные контейнеры и поддержка различных технологий, но что касается кодирования – MPEG-4 подходит для всех мобильных платформ.

Таким образом для самых распространенных сценариев работы, поддержка кодеков от Microsoft и устаревшей (даже с точки зрения производителя) технологии вещания нам не нужна (напомню что теперь сервера потокового видео SMS лишена и старшая модель TCS).

Так что единственное, с моей точки зрения, существенное ограничение функционала TCS в версии для небольших предприятий – это меньшее количество поддерживаемых сессий записи. Но это искупается более чем в 4-е раза меньшей стоимость, по сравнению со старшей моделью устройства.

Если же ваша цель – с минимальными затратами обеспечить вещание одного мероприятия (в идеале – в режиме ВКС) максимально широкой аудитории и обеспечить возможностью последующего его просмотра, TCS в составе Be6k, идеально решает эту задачу.

Все равно для обеспечения доставки контента придется строить CDN (Content Delivery Network) и здесь без специализированных серверов вещания не обойтись.

Именно поэтому в конце статьи я хочу привести несколько аргументов, которые позволят принять решение использовать  специализированный сервер потокового вещания, или ограничиться встроенным IIS.

  • Медиа-сервера специально разработаны для вещания медиа-контента. Метод доставки данных, реализованный в них, учитывает особенности этого типа контента. Web-сервер передает данные с максимально возможной для пользователя скоростью, сервер потокового вещания имеет механизмы для поддержания постоянной скорости трансляции и обеспечения минимальной задержки при передаче блоков информации.
  • Сервер потокового видео имеет механизмы получения отклика от проигрывателя, таким образом, он может регулировать передачу, в зависимости от полученной информации, реализуя такой функционал как быстрый старт, быстрое кэширование и т.д.
  • Web-сервер не поддерживает форматов кодирования с несколькими скоростями (MBR) для того чтобы передавать пользователю только подходящий профиль кодирования.
  • Web-сервер не поддерживает динамический выбор транспортного протокола, нет возможности использования UDP, высока вероятность паузы при воспроизведении в момент буферизации данных.
  • Web-сервер не поддерживает механизмов позволяющих реализовать живое (live) или многоадресное (multicast) вещание.
  • Web-сервер не поддерживает индексирование, что не позволяет реализовать быструю перемотку видео без его полной загрузки.
  • Технологии проксирования http и кеширования Web-контента плохо подходят для распространения видео.

Если все вышеперечисленное в рамках решаемой задачи Вам не принципиально, можно ограничиться встроенным Web-сервером. Для тех же, кто собирается использовать внешние сервера потокового вещания, я в последующих статьях, опишу возможные сценарии и дам рекомендации по интеграции.

Tags:
Оставить комментарий

Share