Ответ 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 секунд, но они обязательно узнают, выпадет ли видео каждую секунду.

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

Ответ 2

Это еще не готово (надеюсь, вторая половина этого года), но DASH через Full Duplex HTTP-протоколы позволит вам использовать MPEG DASH через веб-порты, обеспечивая преимущества DASH (с открытым исходным кодом, ABR, совместимость...), а также с низкой задержкой других форматов (например, WebRTC, который не работает на сафари btw).

Итак, каждый, кто рассматривает формат видео с низкой задержкой через несколько месяцев, попытается найти это.

Ответ 3

Перейдите в WebRTC, потому что:

WebRTC - это стандарт, поддерживающий связь в режиме реального времени на основе браузера. Первоначально разработанный Google, стандарт теперь управляется W3C. WebRTC позволяет приложениям браузера-браузера для голосового вызова, видеочата и совместного использования файлов без необходимости использования каких-либо внешних плагинов, кроме совместимого браузера.

Преимущества:

• Решения WebRTC могут способствовать расширению унифицированных коммуникаций в режиме реального времени (UC) за пределами предприятия - любому клиенту, партнеру или поставщику с браузером с поддержкой WebRTC.
• Технологии, поддерживаемые WebRTC, позволяют операторам мобильной сети создавать более привлекательный опыт работы с клиентами на мобильных устройствах. Например, добавление возможности голоса или видео в приложение, предоставляемое оператором мобильной связи, позволит абоненту обратиться к представителю службы поддержки клиентов для более персонализированной поддержки.
• WebRTC снижает затраты на развертывание ИТ-ИТ и поддержку, устраняя необходимость использования пользователями Unified Communications клиентов. В то же время WebRTC позволяет телекоммуникационным компаниям и разработчикам создавать приложения для обмена и совместной работы с поддержкой WebRTC с ограниченными/основными ресурсами разработки.
• Благодаря использованию открытых стандартов и браузеров, WebRTC устраняет необходимость в сложных системах для расширения доступа пользователей к брандмауэрам для совместной работы и совместного использования видео. В некоторых случаях WebRTC может фактически сократить общий цикл продаж, быстро помогая клиентам и потенциальным клиентам получить необходимую им информацию.

WebRTC Тестирование.

Ответ 4

Вы рассматривали потоковое решение Ant Media Server со сверхнизкой задержкой? Они используют WebRTC Tech в продуктах. Кроме того, AMS является медиа-сервером с открытым исходным кодом.

Ant Media Server поддерживает потоковую передачу со сверхнизкой задержкой с технологией WebRTC, которая обеспечивает типичное значение 0,5 секунды.

Любой вид живого потока может быть доставлен широкому кругу клиентов через масштабируемую кластерную инфраструктуру в облаке. Доступны SDK для Android, iOS и JavaScript.

Также вы можете проверить ссылки ниже;

Издатель WebRTC: https://test.antmedia.io:5443/WebRTCAppEE/

WebRTC Play: https://test.antmedia.io:5443/WebRTCAppEE/player.html

Демоверсия WebRTC: https://antmedia.io/livedemo/

Страница Ant Media Server Github: https://github.com/ant-media/Ant-Media-Server

Сервер Google Ant Media Server: https://groups.google.com/forum/m/#!forum/ant-media-server

Также просмотрите веб-сайт: https://antmedia.io

Ответ 5

Unreal Media Server v12 - это то, что вам нужно. Я наблюдаю за задержкой в ​​200 мс на моем видеопотоке с IP-камеры GeoVision.