C: Декодер MJPEG

нает ли кто-нибудь некий проект на Си с гита или еще откуда-то, которым это можно сделать

да! называется FFmpeg

некий проект на Си с гита

https://github.com/TimSC/mjpeg

На сайте apple была документация по QT с описанием структуры Motion-JPEG.

Да даже с вики туда есть ссылка.

MJPEG это кодек. А контейнер какой, avi или mov (quick time)?

Спасибо всем, кто откликнулся, завтра буду все это смотреть. FFmpeg попадался на глаза, ситуация такова, что у меня система embedded с очень малым количеством памяти, и я пока не понял, как можно сделать сборку этой либы на целевом устройстве. Контейнер АVI, будет конвертирован в mjpeg, и скормлен местному драйверу

очень малым - это сколько в байтах?

Любой плейер, умеющий mjpeg, умеет разложить его на кадры. Попробуй vlc, ffmpeg, и если не ошибаюсь, в OpenCV тоже есть компоненты.

ОЗУ 56Кбайт + 256Кбайт внешних, и SD-карта на 32 Мбайт. Плееры - это все хорошо, только мне нужен данный функционал непосредственно в embedded, где это не тривиальная задачка

если под MJPEG подразумевается отдельный готовый файл - то это просто слитые друг за другом JPEG. А jpeg - тегированный формат. Бежишь по тегам находишь границы кадров и всё. Информации из wikipedia должно быть более чем достаточно.

если имеется в виду поток видео MJPEG (например от камер), то там чуть сложнее - камеры передают только необходимый минимум и чтобы получить на выходе корректный файл mjpeg или отдельные jpeg надо дописывать недостающие теги.

Имеется в виду первое: слитые JPEG. Что-то я не найду какого-то конкретного примера с тегами.

Но! спасибо zvezdochiot, кажется, это то, что надо!

а распакованные кадры в неё влезут? видео какого размера?

Должны влезть, это уже другая история: видосы не будут слишком большие, и нужны просто для анимации

ОЗУ 56Кбайт

Видео-то в каком разрешении? Сколько цветов? по 4 байта на пиксель, даже 128х128 не влезет.

ПАРДОН!! НЕ то скинул по поводу камня: 32Мб оперативка и SD-карта 8Гб, то были старые причуды от которых отказались

Другое дело!

Плееры - это все хорошо, только мне нужен данный функционал непосредственно в embedded

Ну можно в цикле искать маркеры начала и конца JPEG-кадров (FFD8/FFD9) и резать по ним. Это не сложно, просто надо учитывать некоторые хитрости, например, что при буферизации файла/потока маркер может попасть на границу буфера.

Как раз поэтому спрашивал про структуру, идея была как раз нарезать. А если я отрежу до FFD9 (мне нужны только данные картинки)..?

Какие еще могут быть подводные камни?

libjpeg/libjpeg-turbo. Просто выполняешь декодирование JPEG с начала потока. В следующий раз - с того места, где декодер остановился в прошлый раз. И так далее. Примеров работы с этими либами - уйма.

Ну вот всё, что между маркерами, ВКЛЮЧАЯ САМИ МАРКЕРА — это и будет полноценный JPEG-файл, его можно скидывать на диск, открывать во вьювере или скармливать библиотеке распаковки.

Какие еще могут быть подводные камни?

Ну кроме того, что я назвал — разве что битая информация, когда попадаются повреждённые маркеры, кадры склеиваются и надо отделять овец от козлищ. Но это не всегда актуально, и тут уже надо думать по ситуации...

Спасибо за ценную информацию.

Надеюсь в нашем деле ответственность за качество кадра возложат на пользователя.

Кстати, если на заметку, то - может ли склеивание кадров произойти в момент конвертирования в MJPEG?

Спасибо за маркеры, все получилось. В итоге так и сделал: распарсил по ним.