Просмотр исходного текста страницы Разработка матрицы видеопотоков (командный проект)

{{Карточка_командного_проекта
|name=Разработка матрицы видеопотоков
|company=On-Air.Pro
|semester=Осень 2017
|course=3
|number_of_students=3-8
|categorize=yes
}}

=== Что это за проект? ===
Матрица -- это узел, куда в телевизионном центре сходятся все сигналы и оттуда распределяются по потребителям. Технически это коробка с N входами и M выходами. И каждый выход m может быть сопоставлен входу n, при этом, на один вход может быть скоммутировано сколько угодно выходов. Ко входам подключаются камеры, выходы пультов, спутниковые приёмники с сигналами  от выездных студий и внешних источников, а выходы подаются на пульты, рекордеры и эфирные кодеры. 
В нашем случае коммутироваться будут не сигналы в проводах, а потоки в сети. Представьте здания Вышки, в каждом по несколько оборудованных видеокамерами залов. В итоге по сети мы получаем множество потоков, но одновременно  нужны далеко не все. И для режиссера эфира удобно иметь перед глазами только нужные камеры. Микшер подключен, например, к выходам 1-8 матрицы, а эти выходы коммутируются на нужные входы. Выходы матрицы также могут отдавать потоки на телевизионные панели в зданиях, сетевые рекордеры (такая тема тоже есть по соседству) и т.д.

Этот проект в минимальном виде за час собирается "на коленке" -- связка из двух VLC образует цепочку "переключатель/выход", где на переключателе указывается адрес входного потока, а выходной поток формируется вторым vlc (он является сервером RTSP. Количество таких пар определяет количество выходов, а входы -- это любые адреса потоков. Важно, что если к одной камере напрямую подключится много зрителей, то она не справится -- она является сервером, но не предназначена для массового доступа. Матрица выполняет роль прокси. 

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

=== Чему научатся студенты? Что самое интересное в проекте? ===
1. Работа с linux-серверами
2. Манипуляции с медиапотоками в сети. Придется разобраться в RTSP серверах (в простейшем случае это многим знакомый VLC)
3. Разработка пользовательского интерфейса (личный кабинет с настройками, групповой доступ, отображение предпросмотра с минимизацией трафика) -- здесь достаточно ruby on rails (для совместимости поддержки с соседними проектами) и верстки bootstrap.

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

=== Организация работы (Как студенты будут работать в команде?) ===
Роли и точный состав работ формируется по итогам регистрации желающих участвовать (команда может быть смешанной, в т.ч. со студентами МИЭМ и других факультетов, аналогичная тема заявлена на ярмарке проектов.

Далее организуется slack и трекер (обычно trello), где ведется рабочее общение и трекинг задач. 
Встречи -- по договоренности (на первых порах это понадобится точно) на Кочновском, альтернативный и более частый вариант -- аудио/видеосвязь. Удобно, т.к. можно собираться по актуальному вопросу безотлагательно и в любое время в любом составе.

=== Компоненеты (Из каких частей состоит проект?) ===
1. Каналы: пара RTSP приёмник и RTSP сервер для каждого канала. Таких каналов должно поддерживаться значительное количество (сотни, пределы определяются возможностями серверов). Отдельно стоит рассмотреть возможность запуска на нескольких серверах.
2. Личный кабинет: аутентификация, настройки источников (включая ONVIF discovery), группировка каналов, делегирование доступа, статистика/логи.
3. Пользовательский интерфейс, предпросмотр
4. REST API / ONVIF

=== Какие будут использоваться технологии? ===
* RTSP потоки и RTSP сервер -- протокол передачи видео в реальном времени, широко используется в системах IPTV и видеонаблюдения. В быту RTSP сервер легко сделать из VLC, но есть и другие варианты (FFSERVER, Live555 и т.д.). 

* ONVIF -- стандарт управления для систем видеонаблюдения. Очень пригодится для обнаружения источников в сети и адресов потоков в этих источниках. Также, полезно сделать управление матрицей совместимым со стандартами управления прочим видеооборудованием.

* REST API -- не технология, но очевидно, что программное взаимодействие с матрицей будет необходимо, в частности, для автоматизации вещания (расписание -- это уже тема отдельного проекта)

* OAuth -- общее требование по аутентификации пользователей. Встречается повсеместно, освоить всегда полезно. 

* Ruby on Rails -- веб-разработка крайне желательная на этой связке. 

* FFMPEG/GStreamer -- на случай необходимости все-таки обработать поток. Например, чтобы сгенерировать превью или сделать транскодирование в RTSP или в нужный формат (если такое указано для данного канала).

=== Какие начальные требования? ===
* Навыки программирования (рельсы можно изучить. После Python вы не будете очень страдать). 

* Ожидается, что разработчики умеют пользоваться поисковыми системами и stackoverflow. Руководитель может консультировать вас по предметной области (видео/тв), но не по программной разработке. 

* Разработка обычно имеет недельный цикл трекинга, встречи (как индивидуальные, так и групповые) по умолчанию -- по видеосвязи, но порой надо и очно (на факультете). Необходимые технические и серверные ресурсы предоставляются.

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

=== Темы вводных занятий ===
Не в порядке изложения: 

1. Архитектура проекта. API, внешние связи и зависимости.

2. Специфические технологии и используемые инструменты.

3. Доступные ресурсы, организация доступа. 

4. Разделение ролей

=== Критерии оценки ===
Про работу и оценки почитайте здесь: https://d.pr/143bq

Постарайтесь отнестись к этому с пониманием. Очень часто бодрое начало длится 3-4 недели и потом наступает тишина. Очень хочется, чтобы проекты доводились до запуска, а вы получали опыт успешной разработки и, возможно, работу в этих проектах уже в другом статусе. Но пока это для вас учебная работа, поэтому будем придерживаться описанных по ссылке правил и критериев. Спасибо!

=== Похожие проекты ===
Как выглядит матрица сигналов (не потоков), можно посмотреть по программным оболочкам к аппаратным телевизионным матрицам. Например, Blackmagic VideoHub. Но в нашем случае это сомнительный аналог. 
Технологически чуть ближе сетевые видеорекордеры. Вы видели такие у охранников: на экране сетка из разных камер, при этом все потоки записываются. Это не матрица, но суть та же: в сетевом рекордере (NVR) записываются адреса камер и сопоставляются с номерами каналов записи, просто их не меняют на ходу. Поток при этом не перекодируется.

Этот проект на Ярмарке проектов ВШЭ: https://pf.hse.ru/207816915.html

=== Контактная информация ===
Денис Королев,

https://www.hse.ru/staff/dkorolev (там есть ссылки на соцсети)

+7 903 610 3290 (месенджеры по вкусу)

d.korolev@gmail.com