Комментарии 27
Интересно было бы попробовать встроенную в GStreamer поддержку WebRTC, чтобы избавиться от промежуточного браузера.
Правильно я понимаю, что вы изначально использовали непроизводительное решение и вместо того, чтобы разобраться, почему оно непроизводительное и поискать другие решения, запустили браузер?
Чроме же не на волшебстве работает, и раз его движок показывает приемлемую производительность, то это не проблема RPi, а проблема имплементации, которую вы использовали. А раз это проблема aioRTC, значит можно просто другое средство использовать.
Когда каждый текстовый редактор тащит за собой браузер, к этому все привыкли.
Но тащить целый браузер в эмбед, когда вам надо только стрим сделать, это какая-то дичь.
Для пишек можно либо просто μStreamer использовать (если webrtc не обязателен), либо Janus попробовать.
А зачем именно WebRTC?
Можно ведь просто чутьли не напрямую слать MJpeg поток с камеры в браузер (Большинство китайских камер вообще ничего кроме mjpeg не могут даже через USB). В таком случае даже ничего перекодировать не нужно - достаточно сказать камере какое разрешение и FPS вам надо - она сама переключить поток на нужный. Остаётся только эти байты переслать в браузер клиенту "как есть".
Лично я давно использую связку из Python3 + Linuxpy + Flask
Linuxpy - только для удобства работы с камерой. По факту можно вообще напрямую с ней общаться через v4l2
Flask - в качестве веб-сервера. Можно и FastAPI или любой другой сервер использовать. Смотря какой доп. функционал вам нужен прямо в браузере.
Заметка: Orange PI Zero 2 даже по WiFi даёт задержку 200-500мс с таким сервером, нагружая процессор менее чем на 10%.
Интересно, у меня mjpeg был сильно тормозной, особенно по вебу (как грузил проц уже не помню). С другой стороны в интернетах пишут что наименьшая задержка у webrtc
Вы, возможно, пытались как-то обрабатывать картинку (менять разрешение, кол-во кадров, цветовой формат и т.п.), отсюда и куча тормозов (процессор с подобным справляется весьма неважно).
В моём-же случае - мы берём готовые байты (jpeg) и отсылаем их сразу клиенту в браузер. Без обработки, без вмешательства, лиш добавляется немного нагрузки в виде работы с HTTP протоколом.
https://pypi.org/project/linuxpy/ - Пробуйте. Там прямо в описании есть готовый пример с Flask.
А вот так задаются разрешение, формат и фреймрейт
from linuxpy.video.device import Device as VideoDev, BufferType
cam = VideoDev.from_id(1) # /dev/video1
cam.open()
cam.set_format(BufferType.VIDEO_CAPTURE, 1920, 1080, "MJPG") # MJPG or YUYV
cam.set_fps(BufferType.VIDEO_CAPTURE, 30) # 30 FPS
Тоже сталкивался с подобными задачами, в итоге сделал решение на базе rtsp через mediamtx. Только им удалось на первом zero w добиться хорошего fps при 720p. Нагрузка при этом была в районе 60%. Работало стабильно для использования в качестве круглосуточной камеры наблюдения. WebRTC, кстати тоже поддерживается mediamtx.
Слышал про такую штуку, не пробывал. Не знаю как с ним можно еще параллельно получить доступ к видео стриму (локально создавать коннекшн еще один?), например для передачи в Tensorflow.
Никаких проблем с локальной доступностью быть не должно. В примере, что я смотрел, для теста используют команду ffplay rtsp://raspberrypi.local:8554/cam .
Другой вопрос, насколько zero хватит еще и на TF. Я лично выносил обработку потока с камеры zero нейронкой (кстати с usb ускорителем coral) на внешнюю rpi4.
Может стоило взглянуть на mjpeg (https://en.wikipedia.org/wiki/Motion_JPEG)?
Там на самом деле разницы никакой не будет. Энкодинг выполняют аппаратные блоки - процу остаётся только шифрование для webrtc поверх замутить и всё.
Так что в теории, mjpeg даст больше трафика и большую нагрузку по шифрованию
В моем случае RPi3 без проблем справлялась с отправкой нескольких фрэймов в секунду (без шифрования). И главное, не нужно было городить весь этот огород с WEBRTC, который (к тому моменту) не так давно появился на горизонте.
Откуда информация? В WebRTC используется VP8, и библиотека libvpx которая полностью софтварная. Блоков доя аппаратного енкодинга vp8 на rpi нет
Чёт по ощущениям - слишком большая нагрузка.
Я тоже делал что-то подобное на .NET - взял довольно известную либу и немного соптимизоровал.
https://github.com/buldo/RtpToWebRtcRestreamer
Правда по дороге выкинуд часть кода со stun и тп и моё поделие работает только если сервер и клиент в одной сети :)
Последнее - самое как раз важное для меня =) Ибо когда мджпег не через локалку, там уже достаточно большая задержка.
Самое продуктивное здесь, что пробывал и гуглил - это WebRTC.
Так и у меня в примере не mjpeg, a h264.
Проблемы с локалкой обычно решаются zerotier.
Вообще, если нужно быстро и без браузера, то gstreamer на клиенте и сервере. Если нужно ещё быстрее, то здравствуй C++.
Но с другой стороны, камеры и энкодер на raspberry жутко медленные - они дают большую часть задержки
Рекомендую переходить на rk3568 или rk3588, если хотите задержку менее 80-100мс
я бы заменил nodejs на компилируемый язык типа Go, что позволит еще больше сэкономить ресурсы raspberry pi
Video-streaming в Raspberry PI + WebRTC — победа?