Ответ 1
Технологии и требования
Единственным сетевым набором технологий, действительно ориентированным на низкую задержку, является WebRTC. Он построен для видеоконференций. Кодеки настроены на низкую задержку по качеству. Битрейты обычно являются переменными, что позволяет обеспечить стабильное соединение по качеству.
Однако вам не обязательно нужна такая низкая латентность для всех ваших пользователей. Фактически, из того, что я могу собрать по вашим требованиям, низкая латентность для каждого может повредить пользователю. Хотя вашим пользователям, управляющим роботом, определенно нужно видео с низкой задержкой, чтобы они могли разумно контролировать его, у пользователей, не контролирующих это требование, вместо этого можно выбрать надежное видео высокого качества.
Как настроить
Пользователи, контролирующие подключение к роботу
Пользователи, управляющие роботом, загружают страницу, на которой используются некоторые компоненты WebRTC для подключения к камере и серверу управления. Чтобы облегчить подключение WebRTC, вам нужен какой-то STUN-сервер. Чтобы обойти NAT и другие ограничения брандмауэра, вам может потребоваться сервер TURN. Оба они, как правило, встроены в инфраструктуру WebRTC на основе Node.js.
Серверу Cam/control также потребуется подключиться через WebRTC. Честно говоря, самый простой способ сделать это - сделать ваше управляющее приложение несколько веб-. Поскольку вы используете Node.js уже, посмотрите NW.js или Electron. Оба могут воспользоваться возможностями WebRTC, уже встроенными в WebKit, но при этом сохраняя гибкость, чтобы делать все, что угодно, с помощью Node.js.
Пользователи, находящиеся под контролем, и сервер cam/control будут осуществлять одноранговое соединение через WebRTC (или, если необходимо, сервер TURN). Оттуда вы захотите открыть медиа-канал, а также канал данных. Сторона данных может использоваться для отправки ваших команд робота. Конечно, медиа-канал будет использоваться для видеопотока с низкой задержкой, отправляемого обратно пользователям, находящимся под контролем.
Опять же, важно отметить, что видео, которое будет отправлено назад, будет оптимизировано для латентности, а не качества. Такое соединение также обеспечивает быструю реакцию на ваши команды.
Видео для просмотра пользователей
Пользователи, которые просто просматривают поток и не контролируют робота, могут использовать обычные методы распространения видео. Для вас действительно важно использовать существующие службы CDN и транскодирования, так как у вас будет 10k-15k человек, наблюдающий за потоком. С таким количеством пользователей вы, вероятно, захотите, чтобы ваше видео было в нескольких разных кодеках, и, конечно же, целый массив битрейтов. Распространение с DASH или HLS проще всего работать с на данный момент, и освобождает вас от требований Flash.
Возможно, вы также захотите отправить свой поток в службы социальных сетей. Это еще одна причина, по которой важно начинать с HD-потока высокого качества. Эти услуги снова перекодируют ваше видео, снижая качество. Если сначала вы начнете с хорошего качества, в конце концов вы получите лучшее качество.
Метаданные (чат, сигналы управления и т.д.)
Из ваших требований неясно, какие метаданные вам нужны, но для небольших данных на основе сообщений вы можете использовать библиотеку веб-сокетов, такую как Socket.IO. Поскольку вы масштабируете это до нескольких экземпляров, вы можете использовать pub/sub, например Redis, для распространения сообщений по серверам.
Синхронизация метаданных с видео зависит от того, что в этих метаданных и каково требование синхронизации, в частности. Вообще говоря, вы можете предположить, что между исходным видео и клиентами будет разумная, но непредсказуемая задержка. В конце концов, вы не можете контролировать, сколько времени они будут буферировать. Каждое устройство отличается, каждая переменная подключения. Вы можете предположить, что воспроизведение начнется с первого сегмента, который клиент загрузит. Другими словами, если клиент начинает буферизацию видео и начинает играть его через 2 секунды, видеоролик занимает 2 секунды позади, когда был сделан первый запрос.
Обнаружение, когда воспроизведение фактически начинается на стороне клиента, возможно. Поскольку сервер знает временную метку, для которой видео было отправлено клиенту, он может информировать клиента о его смещении относительно начала воспроизведения видео. Поскольку вы, вероятно, будете использовать DASH или HLS, и вам нужно использовать MCE с AJAX для получения данных в любом случае, вы можете использовать заголовки ответов в ответе сегмента для указания отметка времени для начала сегмента. Затем клиент может синхронизировать себя. Позвольте мне сломать это шаг за шагом:
- Клиент начинает получать сообщения метаданных с сервера приложений.
- Клиент запрашивает первый сегмент видео с CDN.
- Сервер CDN отвечает на сегмент видео. В заголовках ответов заголовок
Date:может указывать точную дату/время начала сегмента. - Клиент читает заголовок ответа
Date:(скажем,2016-06-01 20:31:00). Клиент продолжает буферизацию сегментов. - Клиент начинает буферизацию/воспроизведение как обычно.
- Воспроизведение начинается. Клиент может обнаружить это изменение состояния на проигрывателе и знает, что
00:00:00на видеоплеере действителен2016-06-01 20:31:00. - Клиент отображает метаданные, синхронизированные с видео, отбрасывая любые сообщения с предыдущих времен и буферизируя любые для будущих времен.
Это должно соответствовать вашим потребностям и дать вам возможность делать все возможное, чтобы ваше видео продолжалось.
Почему бы не [magic-technology-here]?
- Когда вы выбираете низкую задержку, вы теряете качество. Качество обеспечивается за счет доступной пропускной способности. Эффективность полосы пропускания заключается в возможности буферизации и оптимизации целых последовательностей изображений при кодировании. Если вы хотите отличное качество (без потерь для каждого изображения), вам понадобится тонна (гигабиты на зрителя) пропускной способности. Вот почему у нас есть эти кодеки с потерями для начала.
- Поскольку вам не нужна низкая латентность для большинства ваших зрителей, лучше оптимизировать для них качество.
- Для 2 пользователей из 15 000, которым требуется низкая латентность, мы можем оптимизировать для них небольшую задержку. Они получат некачественное качество видео, но смогут активно управлять роботом, что является удивительным!
- Всегда помните, что Интернет является враждебным местом, где ничего не работает так хорошо, как должно. Системные ресурсы и пропускная способность постоянно изменяются. Именно поэтому WebRTC автоматически настраивает (насколько это разумно) на меняющиеся условия.
- Не все соединения могут не отставать от требований с низкой задержкой. Поэтому каждое соединение с низкой задержкой будет испытывать проблемы с выбыванием. Интернет с коммутацией пакетов, а не с коммутацией каналов. Нет реальной выделенной полосы пропускания.
- Наличие большого буфера (пара секунд) позволяет клиентам выдержать мгновенные потери соединений. Это почему CD-плееры с анти-скиповыми буферами были созданы и проданы очень хорошо. Это намного лучший пользовательский интерфейс для этих 15 000 пользователей, если видео работает правильно. Им не нужно знать, что они отстают от основного потока на 5-10 секунд, но они обязательно узнают, выпадет ли видео каждую секунду.
В каждом подходе есть компромиссы. Я думаю, что то, что я здесь изложил, отделяет проблемы и дает вам лучшие компромиссы в каждой области. Пожалуйста, не стесняйтесь просить разъяснений или задавать последующие вопросы в комментариях.