Ха, я таки сделал это.
Но сначала хочу поговорить о магии.
Недавно в
комментарии написал.
Очень сложную технологию выгоднее воспринимать как магию. Это позволяет сэкономить очень много времени. "Магия" это такая черная коробка, которая непонятно как устроенна. Но если делать определённые магические пассы, то будут определённые результаты.
Или переформулируем так «Знание - сила! А незнание - скорость!»
Тут я побуду немного Капитаном очевидность. Невыучить что-то значительно быстрее, чем выучить. А на работе больше ценятся работники, которые делают всё быстро. А магия в большинстве случаев позволяет сделать всё знаачительно быстрее, чем подход на основе знаний.
Вот возмём для примера «магическое заклинание»:
ssh root@moto.local
Если подходить с точки зрения знаний - то там очень много скрыто под капотом. WiFi/сетевые протоколы/алгоритмы шифрования. Куда-то надо прописать ключи доступа. Причем изменение любой буквы приведёт к неработоспособности «заклинания». Изменение окружения (например попытка зайти с другого копьютера) так-же не увенчается успехом. Научный подход сдесь бесполезен, даже вреден. Надо просто запомнить последовательность действий. «Переключить тублер на желтой коробочке так, чтобы зажегся синий светодиод, подождать 20 секунд, потом ввести на компьютере home-amd в консольке ssh root@moto.local и у тебя будет доступ по ssh к соответствующему ресурсу»
Но это пример простой магии. Понятной, бытовой. Но вот, что надо сделать, что-бы показать видео в браузуре.
- Надо запаковать видео в h264 (или h265) поток.
- Передать его по WebSocket протоколу.
- Запаковать требуемый поток в mp4 контейнер и скормить window.MediaSource.
И каждый из этих пунктов разбивается на кучу подпунктиков. Если подходить к этому с точки зрения знаний, то времени уйдёт «вагон и маленькая тележка». А вот если подходить к этому с точки зрения магии, то есть шанс управиться за разумное время. У нас есть магический блок, который хардварно пакует в h264 (естественно без всякого описания). У нас есть WebSocket сервер, в котором желательно бы не разбираться. У нас есть jmuxer который умеет raw h264 поток принимать и передавать его в window.MediaSource. Надо только это всё вместе соединить, и ВЖУХ - всё заработает и за разумное время. Так что без магии никуда.
Но тут в нам приходит печальная действительность. WebSocket сервера кривые и косые, мне пришлось все новогодние выходные с ними провозиться. Протоколы шифрования с разной скоростью пакуют. h264 протокол имеет внутри разные nal unit. И магия превращается в тыкву.
Но я таки смог запустить h264 видео в браузере прямиком с Maix III.
Перечислю некоторые моменты, на которых тупил. Ествественно с позиций незнания. В самом начале обязательно надо указывать размеры и формат изображения. Это nal sps и pps. sps - sequence parameter set. pps - picture parameter set. Как эти поля выглядят - не знаю! Просто скопипастил их из файла сгенерированного ffmpeg файла (это были первые 38 байт). После этого у нас получается уже вполне хороший файл формата .h264 который умеет смотреть ffplay, если содержимое ws пакетов записать в файл. Но вот jmuxer эти пакеты упорно не воспринимал как валидные. Я уже начал отчаиваться, но тут (о чудо!) вместо jmuxer.min.js решил поотлаживаться на jmuxer.js. И всё магическим образом заработало. МАГИЧЕСКИМ.
Ещё из интересных моментов команда ffmpeg -i rtsp://moto.local:8554/axstream0 -vcodec copy abc.h264 генерирует файл, который jmuxer.min.js вполне успешно принимает. В чем причина для меня пока остаётся загадкой. Понял только, что в abc.h264 есть багованные последовательности, когда идёт подряд 00 00 00 01 00 00 00 01 . Т.е последовательность 3 нуля единица встречается два раза подряд.
Так что пока криво, косо, на соплях, но таки смог добиться вывода видео в окне браузера.