Comments 9
Душнила. Извините и спасибо! )
Ещё один шедевр душнаты. Читаю статьи в захлеп. Спасибо!
Тогда у меня для Вас хорошие новости, следующая статья будет не менее душной!
А вот вопрос как спецу, Подскажите, пожалуйста, какой pipeline лучше использовать на MaixCAM Lite для edge AI: одновременно RTSP stream + YOLO detection + MQTT metadata. Лучше ли делать overlay bbox прямо в H264/RTSP потоке, или профессиональнее держать RTSP отдельно, а bbox/детекции передавать отдельно через MQTT/WebSocket metadata? Интересует именно самый стабильный и производительный вариант для lichee. Спасибо
Сам когда-то думал над этим. С одной стороны, если вы overlay рисуете не на стороне платы, а на стороне клиента, то нагрузка на процессор уменьшается, что достаточно важно в случае с lichee. Хотя, нагрузка от того, что вы пишите текст/прямоугольники рисуете достаточно низкая. Но в таком случае, клиент - это не просто ffmpeg/vlc, а уже что - то более сложное (хотя ffmpeg, наверное, и с таким справится, но там нужно будет постараться). Мне кажется, что смысл в отдельном потоке с детекциями есть, если вы кроме визуализации баундинг боксов с этими данными ещё что-то будете делать (записывать в какую-то внешнюю бд, отправлять какие-то уведомления и т.д.). По моему опыту, в большинстве задач визуализация детекций на стриме - это отладочная часть, т.е. когда устройство будет работать в продакшене, то визуализация будет выключена. И когда у вас два разных потока: изображение в RTSP и отдельно сокет с данными, то нужно их синхронизировать. Т.е. как минимум для каждого RTSP кадра и массива bbox нужно указывать совпадающий timestamp и при визуализации сопоставлять. При этом, если данные детекции скорее всего будут идти стабильно без потерь, то RTSP кадры могут пропадать, что тоже нужно будет учесть
ну вот и я подумал, что делать overlay metadata по верх картинок которые потом пойдут в rtsp, лишний лаг и нагрузка на проц личи. Но тогда вопрос, личии сможет и rtsp гнать и метадата отдельно mqtt-ws или сложно ей будет. Может делали что-то похожее. Аля rtsp и ещё чето вторым поток?
ну я так понимаю лучше сразу C++ делать или выиграш не сильный будет и MaxPy нормально будет отрабатывать?
Личи справится. Я не делал именно с mqtt, но я делал параллельно с rtsp стримом и YOLO детектором: постоянный обмен данными через UART, обмен данными через Zenoh. И ещё много свободных ресурсов оставалось. Касательно языка, не думаю, что будет особая разница, потому что особо большого потока данных не будет, тем более какой-то тяжёлой обработки. Единственное, через C++ решение будет более оптимальное по оперативной памяти, но и через MaixPy всё должно уложиться.
В своих проектах на личи я MaixCDK (в том числе MaixPy) не использую, но это просто специфика такая (нужно выжимать максимум из платы), библиотеки от Sophgo более гибкие в этом плане. Но поверх части C/C++ кода я делал Python врапперы (собственно, MaixPy это такой же враппер поверх сишного MaixCDK) и всё хорошо работает. Главное, чтобы вся обработка данных шла через C/C++, а Python просто оркестрировал
тоесть у вас не используется MaixCDK а свои методы на базе библиотеки от Sophgo? а в тг канале есть ссылки на эти либы?
Я скорее всего упоминал, но ещё раз тут напишу какой стек сейчас мне кажется самым удобным для личи:
Образ - https://github.com/scpcom/LicheeSG-Nano-Build. Он основывается на либах от Sophgo. В нём нормальный middleware (https://github.com/sophgo/middleware/), который без проблем работает с камерой.
Также теперь там последняя версия TDL SDK (https://github.com/sophgo/tdl_sdk).
В итоге в этом образе у меня есть возможность полностью настроить пайплайн обработки, используя все аппаратные возможности (аппаратные кодеки, VPSS, чтобы заресайзить кадры в несколько каналов и т.д.)
Axera AX650N: архитектура Edge ML SoC под CNN, LLM и VLM