Comments 15
А есть какой-нибудь относительно стандартный протокол передачи видео через вебсокет для MSE, или все велосипедят кто во что горазд?
В кратце:
MSE принимает буфера в виде чанков в формате fragmented mp4. Это подмножество стандарта ISO BMFF (base media file format). Каждый такой фрагмент, это самостоятельный файл с заголовком и данными. Данные представляют из себя аудио и видео семплы медиа-последовательности определенной длины.
Для подготовки данных на проигрывание с помощью MSE вам нужно подготовить такие файлы на диске или в памяти, на сервере или оборачивать напрямую на клиенте. Каждый новый буфер для проигрывая с MSE, представляет из себя именно такой файл.
Других альтернатив нет.
MSE принимает буфера в виде чанков в формате fragmented mp4. Это подмножество стандарта ISO BMFF (base media file format). Каждый такой фрагмент, это самостоятельный файл с заголовком и данными. Данные представляют из себя аудио и видео семплы медиа-последовательности определенной длины.
Для подготовки данных на проигрывание с помощью MSE вам нужно подготовить такие файлы на диске или в памяти, на сервере или оборачивать напрямую на клиенте. Каждый новый буфер для проигрывая с MSE, представляет из себя именно такой файл.
Других альтернатив нет.
Есть. Только не протокол, а формат. И даже в виде RFC tools.ietf.org/html/rfc6184.
Спецификация подробно расписывает как должны формироваться RTP видео пакеты для передачи по сети и как должны распаковываться. Собственно IP камеры по этой спецификации и работают (в идеальном мире) — пакуют по ней видео и заворачивают в TCP. Плееры получают и депакетизируют. Т.е. ничего не мешает паковать и заворачивать в Websockets. Только на JavaScript/TypeScript будет парсить тяжеловато чтобы спустить в MSE. Т.е. стандарт как-бы есть и можно использовать, но слишком тяжелый — легче реализовать упрощенный формат.
Спецификация подробно расписывает как должны формироваться RTP видео пакеты для передачи по сети и как должны распаковываться. Собственно IP камеры по этой спецификации и работают (в идеальном мире) — пакуют по ней видео и заворачивают в TCP. Плееры получают и депакетизируют. Т.е. ничего не мешает паковать и заворачивать в Websockets. Только на JavaScript/TypeScript будет парсить тяжеловато чтобы спустить в MSE. Т.е. стандарт как-бы есть и можно использовать, но слишком тяжелый — легче реализовать упрощенный формат.
На самом деле очень многое мешает использовать MSE в отличии от WebRTC. H.264 поток от камеры должен быть не абы какой, а сильно ограниченный (начиная, по-моему, с 76 версии Хром начал действовать жестко по стандарту).
Сегменты скармливаемые в буфера MSE должны начинаться и заканчиваться по RAP-фреймам (для H.264 это IDR — не путать с I). Если это не так, то Хром, например, не видит весь сегмент. До этого на практике было достаточно I-фреймов.
К сожалению многие камеры или кабельные сети формируют поток только из I-фреймов, или так, что IDR-фреймы идут раз в несколько десятков минут, и без перекодирования их никак не скормить MSE.
Сегменты скармливаемые в буфера MSE должны начинаться и заканчиваться по RAP-фреймам (для H.264 это IDR — не путать с I). Если это не так, то Хром, например, не видит весь сегмент. До этого на практике было достаточно I-фреймов.
К сожалению многие камеры или кабельные сети формируют поток только из I-фреймов, или так, что IDR-фреймы идут раз в несколько десятков минут, и без перекодирования их никак не скормить MSE.
Иными словами, сегменты уже не скачиваются по древней технологии Request-Response (HTTP), а весело льются через Websockets соединение — почти прямой TCP канал
Путаница у вас какая-то. Внизу всего два транспортных протокола TCP и UDP. Как раз первый тормозной, второй быстрый — дейтаграмммы. А HTTP он текстовый сверху TCP. А сам TCP и есть Request-Response. Оно не древнее, а надежное с гарантией доставки, поэтому и медленное.
Я просто как раз сейчас видео гоняю с телефона на комп по UDP (а раньше TCP юзал ) и посты на эту тему делал недавно.
а про создание WCS то будет? как создать сервер и прикрутить к нему камеру?
Про создание сервера WCS в DigitalOcean было здесь
Можно и на обычный сервер установить, но придется чуть дольше повозиться.
Можно и на обычный сервер установить, но придется чуть дольше повозиться.
и не в дигитал океане а у себя?
а под виндой? :)
а под виндой? :)
у себя на Linux — см системные требования. рекомендуем Centos 7 или Ubuntu 18.04, как стабильность, проверенную временем и дорогами. Java рекомендуем 8 или 12.
на Windows — только в каком-либо гипервизоре, в WSL тоже должно работать.
на Windows — только в каком-либо гипервизоре, в WSL тоже должно работать.
Буквально вчера удалось скрестить html5_rtsp_player и какой-то случайно нагугленный rtsp вебсокет прокси сервер на дотнете (осторожно, китайская ссылка), работает аднака.
Ivideon, как я понял, скрестили WebRTC и HLS и даже сделали на этом свой бизнес, обещая (и реализуя) реалтайм и малую ресурсоёмкость.
сейчас есть low latency HSL
Sign up to leave a comment.
Как готовить RTSP на сайте в 2020 году, или почему кабаны не успеют убежать