Всем привет! Этой статьей мы хотим открыть серию материалов о разработке сервиса, который можно отнести к новым медиа.
Сервис представляет собой большую группу приложений, включающую в себя инструменты для распространения и воспроизведения видеоконтента на разных платформах, приложения второго экрана и множество других интерактивных продуктов, призванных расширить возможности потребителей онлайн-трансляций.
Тема достаточно широкая, поэтому мы решили начать рассказ о развитии нового медиа-сервиса с одного из его основных этапов, а именно с процесса доставки видеоконтента пользователям в прямом эфире.
В этой статье будет описана общая архитектура решения.
Сразу отметим, что описанное ниже решение (как и сама история) не претендует на какую-то новизну или гениальность, но тема вполне актуальна, разработка ведется, поэтому нам было бы очень полезно получить взгляд со стороны на проблему.
Задача Любое публичное событие, которое освещается с помощью нескольких камер, обычно преподносится зрителю в режиссерской версии: режиссеры монтажа сшивают единый, безальтернативный видеоряд, который транслируется зрителю.
Наша задача — разработать сервис, который позволит зрителю выбирать, с какой камеры смотреть событие во время просмотра интернет-трансляции, и даст возможность просмотреть ключевые моменты мероприятия.
Рисунок 1. Общая архитектура решения
У нас получилась следующая схема:
Главный сервер контролирует статус вещания источников вещания и распределяет потоки между подчиненными серверами.
Ведомые серверы, в свою очередь, обрабатывают эти потоки и отправляют результат в Хранилище, указанное в конфигурации, полученной от главного сервера.
Хранилище кэширует текущие данные трансляции, а также сохраняет поток в FS. Конфигурация Мастер-сервера позволяет настроить Серверы хранения в различных режимах — репликация данных, тип данных и т. д. 
Рисунок 2. Как происходит трансляция клиентам
Для распределения нагрузки используется планировщик нагрузки.
Балансировщик — это точка входа клиента в систему.
Он обеспечивает клиентский доступ к серверам, а также отфильтровывает ненужные или просроченные запросы.
Первый запрос клиента всегда отправляется балансировщику.
Балансировщик в зависимости от настроек перенаправляет клиента либо на сервер авторизации, либо привязывает его к серверу видеотрансляции.
В зависимости от количества пользователей количество балансировщиков может быть увеличено.
Мы используем отдельные инстансы для загрузки исторических фрагментов и фрагменты онлайн-трансляций для распределения нагрузки.
Рисунок 3. Кэширование
Во время онлайн-трансляции сервер кэширует фрагменты потока перед сохранением их в хранилище.
Когда к нему обращаются клиенты, он распределяет фрагменты асинхронно.
Буферизация видеофрагментов на клиенте происходит с помощью двух очередей загрузки.
Сначала загружаются фрагменты активного потока.
После загрузки оптимального количества фрагментов для плавного воспроизведения управление передается второму потоку, который начинает синхронно загружать фрагменты камеры для заданного участка таймлайна.
Это позволяет избежать задержек трансляции при переключении камер.
В момент переключения буфер выбранной камеры загружается в очередь основного потока.
Вместо заключения В этом материале мы попытались кратко и схематично изложить наш подход к оформлению раздела доставки видеоконтента в реальном времени потребителю эфира.
В следующих статьях мы расскажем, что получили в результате, и остановимся подробнее на том, как это будет взаимодействовать с другими частями нашего большого нового медиа-сервиса (в частности, с его клиентской частью).
Спасибо за внимание :) Теги: #Работа с видео #дизайн #архитектура #смарт-тв #потоковое видео #новые медиа
-
5-6 Причин Прийти На Golangconf
19 Oct, 24 -
Разбираем Протокол Пейджера Pocsag, Часть 1
19 Oct, 24 -
Советский Спорт
19 Oct, 24 -
Нужно Ли Мне Регистрировать Свой Бренд?
19 Oct, 24 -
Akavita Будет Искать По Блогам И Форумам.
19 Oct, 24 -
4 Марта, Екатеринбург – Java Meetup
19 Oct, 24 -
Создание Симулятора Солнечной Системы
19 Oct, 24
