Технологии и требования

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

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

Как это настроить

Пользователи, контролирующие подключение роботов

Пользователи, управляющие роботом, загрузят страницу, которая использует некоторые компоненты WebRTC для подключения к камере и серверу управления. Для облегчения соединений WebRTC вам понадобится какой-то STUN-сервер. Чтобы обойти NAT и другие ограничения брандмауэра, вам может потребоваться сервер TURN. Оба они обычно встроены в фреймворки WebRTC на основе Node.js.

Сервер камеры / управления также должен будет подключаться через WebRTC. Честно говоря, самый простой способ сделать это - сделать ваше управляющее приложение в некотором роде веб-ориентированным. Поскольку вы уже используете Node.js, попробуйте NW.js или Электрон. Оба могут использовать возможности WebRTC, уже встроенные в WebKit, но при этом дают вам возможность делать с Node.js все, что захотите.

Контролируемые пользователи и сервер камеры / управления будут устанавливать одноранговое соединение через WebRTC (или сервер TURN, если требуется). Оттуда вы захотите открыть медиа-канал, а также канал данных. Сторона данных может использоваться для отправки команд роботу. Медиа-канал, конечно, будет использоваться для видеопотока с низкой задержкой, отправляемого обратно контролирующим пользователям.

Опять же, важно отметить, что видео, которое будет отправлено обратно, будет оптимизировано по задержке, а не по качеству. Такое соединение также обеспечивает быстрый ответ на ваши команды.

Видео для просмотра пользователей

Пользователи, которые просто просматривают поток и не управляют роботом, могут использовать обычные методы распространения видео. На самом деле для вас очень важно использовать существующие CDN и сервисы транскодирования, так как у вас будет 10-15 тысяч человек, которые будут смотреть поток. С таким количеством пользователей вы, вероятно, захотите, чтобы ваше видео было в паре разных кодеков и, конечно же, с целым набором битрейтов. Распространение с помощью DASH или HLS на данный момент проще всего использовать, и он освобождает Вы о требованиях к Flash.

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

Метаданные (чат, контрольные сигналы и т. Д.)

Из ваших требований не ясно, какие метаданные вам нужны, но для небольших данных на основе сообщений вы можете использовать библиотеку веб-сокетов, такую ​​как Socket.IO. При масштабировании до нескольких экземпляров вы можете использовать pub / sub, например Redis, для распространения сообщений по всему серверы.

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

Обнаружение фактического начала воспроизведения возможно на стороне клиента. Поскольку серверу известна метка времени, для которой видео было отправлено клиенту, он может сообщить клиенту свое смещение относительно начала воспроизведения видео. Поскольку вы, вероятно, будете использовать DASH или HLS, и вам все равно нужно использовать MCE с AJAX для получения данных, вы можете использовать заголовки ответа в ответе сегмента, чтобы указать метку времени начала сегмента. Затем клиент может синхронизировать себя. Позвольте мне разобрать это шаг за шагом:

1. Клиент начинает получать сообщения метаданных от сервера приложений.
2. Клиент запрашивает первый сегмент видео из CDN.
3. Сервер CDN отвечает фрагментом видео. В заголовках ответов заголовок Date: может указывать точную дату / время начала сегмента.
4. Клиент читает заголовок ответа Date: (скажем, 2016-06-01 20:31:00). Клиент продолжает буферизацию сегментов.
5. Клиент начинает буферизацию / воспроизведение как обычно.
6. Начнется воспроизведение. Клиент может обнаружить это изменение состояния на проигрывателе и знает, что 00:00:00 на видеопроигрывателе действительно 2016-06-01 20:31:00.
7. Клиент отображает метаданные, синхронизированные с видео, отбрасывая все сообщения за предыдущее время и буферизуя их на будущее.

Это должно удовлетворить ваши потребности и дать вам возможность делать все, что вам нужно, с вашим видео в будущем.

Почему бы не [магическая-технология-здесь]?

• Выбирая низкую задержку, вы теряете качество. Качество зависит от доступной полосы пропускания. Эффективность полосы пропускания достигается за счет возможности буферизовать и оптимизировать целые последовательности изображений при кодировании. Если вам нужно идеальное качество (без потерь для каждого изображения), вам потребуется тонна (гигабит на зрителя) полосы пропускания. Вот почему у нас есть эти кодеки с потерями для начала.
• Поскольку на самом деле вам не нужна низкая задержка для большинства ваших зрителей, лучше оптимизировать для них качество.
• Для 2 пользователей из 15 000, которым действительно нужна низкая задержка, мы можем оптимизировать для них. Они получат некачественное видео, но смогут активно управлять роботом, и это круто!
• Всегда помните, что Интернет - враждебное место, где ничто не работает должным образом. Системные ресурсы и пропускная способность постоянно меняются. На самом деле, именно поэтому WebRTC автоматически приспосабливается (насколько это возможно) к изменяющимся условиям.
• Не все соединения могут соответствовать требованиям к низкой задержке. Вот почему каждое соединение с низкой задержкой будет отключаться. В Интернете используется коммутация пакетов, а не коммутация каналов. Нет доступной реальной выделенной полосы пропускания.
• Наличие большого буфера (пара секунд) позволяет клиентам пережить мгновенные потери соединений. Вот почему были созданы CD-плееры с буферами, препятствующими пропуску, и которые очень хорошо продавались. Если видео работает правильно, для этих 15 000 пользователей будет гораздо лучше. Им не нужно знать, что они отстают от основного потока на 5-10 секунд, но они точно будут знать, пропадает ли видео каждую вторую секунду.

В каждом подходе есть компромиссы. Я думаю, что то, что я здесь изложил, разделяет проблемы и дает вам наилучшие компромиссы в каждой области. Не стесняйтесь обращаться за разъяснениями или задавать дополнительные вопросы в комментариях.