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

Материал из Wiki - Факультет компьютерных наук
Версия от 17:01, 20 сентября 2017; Dkorolev (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Компания On-Air.Pro
Учебный семестр Осень 2017
Учебный курс 3-й курс
Максимальное количество студентов, выбравших проект: 4-6



Что это за проект?

Видеотрансляции в интернет стали совсем обычным делом с тех пор, как ими вплотную занялись Youtube и, позже, соцсети. До них раздача видеопотоков зрителям решалась или своими силами, или через сети доставки контента (CDN). Суть задачи в том, что, в отличие от телевидения, которое посылает один сигнал всем, а смотрят его те, кто хотят, в интернет работает только метод передачи данных от точки к точке (unicast), что для сервера трансляций оборачивается необходимостью каждому зрителю индивидуально отправить поток. Тот же самый, что другому зрителю, в то же время, но отправить персонально. В итоге нагрузка на канал связи растет пропорционально аудитории трансляции. И задерживать такой поток нельзя.

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

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

Вторая часть проекта -- это frontend. Если при трансляции через Youtube зритель видит плеер Youtube, то при трансляции через собственный CDN зрителю надо показать какой-то свой плеер. А может быть и не только плеер. Есть множество "фич", которые становится возможным реализовать, если вести раздачу потоков через свои ресурсы: обратная связь, учет зрительской активности, взимание платы за трансляции, учет географии и других данных о пользователе, многопоточный звук для трансляции многоязычных конференций, субтитры (у нас есть распознавание голоса в текст). Можно организовать чат, голосования и даже принимать от зрителей видеопотоки, звук и файлы через WebRTC. Разумеется, здесь задачи будут выбираться исходя из состава и готовности проектной группы.

Чему научатся студенты? Что самое интересное в проекте?

Проект в первую очередь -- сетевой, в чистом виде -- облачный. Это разработка распределенной системы, динамически меняющейся в зависимости от нагрузки. Более того, практика показывает, что нельзя привязываться к одному провайдеру услуг: там тоже бывают перебои. В результате разработки CDN должна иметь REST API и хотя бы минимальную админ-панель, для зрителей должен предлагаться плеер (как минимум -- HLS) и страница для просмотра.

Организация работы (Как студенты будут работать в команде?)

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

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

Компоненеты (Из каких частей состоит проект?)

1. Работа с API хостинг-провайдеров.

2. Балансировщик

3. REST API для сервиса трансляций.

4. Плеер и фронтенд (для зрителя, для админа)

5. WebRTC обвеска (в дополнение к предыдущему пункту)

Какие будут использоваться технологии?

Облачные серверы запускаются с использованием API соответствующего провайдера. Некоторые провайдеры используют OpenStack, но это (на практике) не решает проблем унификации работы. Сетевой мониторинг -- само по себе важное направление в инфраструктуре ИТ. Конкретные инструменты предстоит выбрать. Плеер и фронтенд -- есть смелая идея раздавать поток через WebRTC (а это пиринговая технология, то есть, на стороне серверов будет о чем подумать), через него же собирать обратную связь. Но это отдельная часть проекта, для смелых веб-разработчиков, причем, ее можно реализовывать независимо от успехов в CDN (можем запустить в действующем проекте). Однозначно можно сказать, что Flash использовать нельзя, но при этом доставить на все платформы поток в едином виде можно лишь http-based протоколами (HLS, например), а у них есть свои недостатки -- большая задержка, от которой теряется смысл в обратной связи реального времени. Поэтому нужно предусматривать запасные протоколы: WebRTC - RTMP - HLS. Это в порядке увеличения задержки.

Какие начальные требования?

CDN -- это серверная разработка под Linux. Язык жестко не регламентирован, попытки что-то сделать уже предпринимались на Java. Веб-разработка -- основной проект написан на Ruby on Rails, желательно не вносить разнообразие языков, но это не блокирующее требование. Плеер -- если беретесь за плеер, то хорошо бы иметь хоть какой-то опыт общения с ними. Задача может оказаться сложнее, чем кажется на первый взгляд.

Темы вводных занятий

Не в порядке изложения:

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

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

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

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

Критерии оценки

Про работу и оценки почитайте здесь: https://d.pr/143bq Обратите внимание, что проект составной и то, какие части пойдут в работу, мы поймём, когда сформируется состав рабочей группы. То есть, отсутствие в итоге какой-то из частей, не блокирующей работу (например, WebRTC не запустили, но HLS плеер есть -- его поставить недолго) никак не снижает оценки проделанной работы по тем частям проекта, которые выполнены. Участники проекта имеют свою область ответственности и оценки получают в соответствии с успехами в этих областях.

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

Похожие проекты

CDNVideo, NGenix -- российские CDN, классические, на физических серверах. Akamai и т.д. -- зарубежные, их много. Но они решают больше задач: DVR -- запись с timeshift, раздача статического контента (про это есть отдельный проект среди предложенных здесь, и он базируется на бесконечных GoogleDrive)

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

По использованию WebRTC: appear.in -- видеочат. Но чат связывает участников одного уровня между собой, причем, всех со всеми, а тут задача другая -- на противоположной стороне от зрителя будет сервер.

Контактная информация

Денис Королев,

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

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

d.korolev@gmail.com

Источник — «http://wiki.cs.hse.ru/index.php?title=Разработка_динамической_сети_доставки_потокового_видеоконтента._(командный_проект)&oldid=24352»