Открыть список
Как стать автором
Обновить

Комментарии 15

А есть какой-нибудь относительно стандартный протокол передачи видео через вебсокет для MSE, или все велосипедят кто во что горазд?

В кратце:
MSE принимает буфера в виде чанков в формате fragmented mp4. Это подмножество стандарта ISO BMFF (base media file format). Каждый такой фрагмент, это самостоятельный файл с заголовком и данными. Данные представляют из себя аудио и видео семплы медиа-последовательности определенной длины.
Для подготовки данных на проигрывание с помощью MSE вам нужно подготовить такие файлы на диске или в памяти, на сервере или оборачивать напрямую на клиенте. Каждый новый буфер для проигрывая с MSE, представляет из себя именно такой файл.
Других альтернатив нет.

Я это всё знаю, но на вопрос о стандартном протоколе передачи видео через вебсокет это не отвечает.

MSE создавался вместе с MPEG-DASH, в котором стандартный подход, это чтение чанков в файлах по HTTP. По-этому ответ — нет, придется делать самому, если нужно.
Есть. Только не протокол, а формат. И даже в виде RFC tools.ietf.org/html/rfc6184.
Спецификация подробно расписывает как должны формироваться RTP видео пакеты для передачи по сети и как должны распаковываться. Собственно IP камеры по этой спецификации и работают (в идеальном мире) — пакуют по ней видео и заворачивают в TCP. Плееры получают и депакетизируют. Т.е. ничего не мешает паковать и заворачивать в Websockets. Только на JavaScript/TypeScript будет парсить тяжеловато чтобы спустить в MSE. Т.е. стандарт как-бы есть и можно использовать, но слишком тяжелый — легче реализовать упрощенный формат.
На самом деле очень многое мешает использовать MSE в отличии от WebRTC. H.264 поток от камеры должен быть не абы какой, а сильно ограниченный (начиная, по-моему, с 76 версии Хром начал действовать жестко по стандарту).
Сегменты скармливаемые в буфера MSE должны начинаться и заканчиваться по RAP-фреймам (для H.264 это IDR — не путать с I). Если это не так, то Хром, например, не видит весь сегмент. До этого на практике было достаточно I-фреймов.
К сожалению многие камеры или кабельные сети формируют поток только из I-фреймов, или так, что IDR-фреймы идут раз в несколько десятков минут, и без перекодирования их никак не скормить MSE.
Иными словами, сегменты уже не скачиваются по древней технологии Request-Response (HTTP), а весело льются через Websockets соединение — почти прямой TCP канал

Путаница у вас какая-то. Внизу всего два транспортных протокола TCP и UDP. Как раз первый тормозной, второй быстрый — дейтаграмммы. А HTTP он текстовый сверху TCP. А сам TCP и есть Request-Response. Оно не древнее, а надежное с гарантией доставки, поэтому и медленное.
Я просто как раз сейчас видео гоняю с телефона на комп по UDP (а раньше TCP юзал ) и посты на эту тему делал недавно.
Путаницы нет. Внизу под обоими протоколами HTTP и Websockets работает ровно один протокол — TCP. И сравнение в скорости доставки идет между этими двумя протоколами. В случае HTTP — Request Response, в случае Websocket — поток текстовых сообщений. Второй способ быстрее, несмотря на то, что оба TCP.
а про создание WCS то будет? как создать сервер и прикрутить к нему камеру?
и не в дигитал океане а у себя?
а под виндой? :)
у себя на Linux — см системные требования. рекомендуем Centos 7 или Ubuntu 18.04, как стабильность, проверенную временем и дорогами. Java рекомендуем 8 или 12.
на Windows — только в каком-либо гипервизоре, в WSL тоже должно работать.

Ivideon, как я понял, скрестили WebRTC и HLS и даже сделали на этом свой бизнес, обещая (и реализуя) реалтайм и малую ресурсоёмкость.

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