Всем привет!

Недавно у меня появилась задача реализовать MJPEG на ПЛИС.
Поскольку раньше видеообработкой я не занимался, возникло множество вопросов.
Так что прошу пнуть меня в нужном направлении.
1) Есть ли нормальные проверенные IP Core для MJPEG?
Можно даже коммерческие, если их можно "скачать" или если у них адекватная цена (< 5000$).
2) Правильно ли я понимаю, что MJPEG это просто поток JPEG картинок передаваемый по Ethernet?
Стало быть, для начала нужно реализовать JPEG декодер.
Поиском нашёл тут вот такой декодер:
http://electronix.ru/forum/index.php?showt...119&hl=JPEG
Кто-нибудь его использовал?
3) Где можно почитать более менее внятное описание, что из себя этот MJPEG представляет?
4) Как правильно отлаживать подобные алгоритмы?
Пока решил делать вот таким образом:
1. Bitmap File -> Ethernet -> DDR2 -> HDMI
Проверяем, что несжатое видео выводится нормально.
2. JPEG File -> Ethernet -> JPEG Decoder -> DDR2 -> HDMI
Проверяем правильность работы декодера.
3. MJPEG -> Ethernet -> JPEG picture -> JPEG Decoder -> DDR2 -> HDMI
Проверяем правильность работы MJPEG.

Почему обязательно поток? Может быть и файл в каком-нибудь контейнере, в том же avi.

Где-то писали, что параметры всех JPEG картинок в MJPEG должны быть одинаковы.
Если это касается только цветности и размера - ладно, а вот если ещё и коэффициенты должны быть одинаковы - хреново.

Примерно год назад в Питере на семинаре Ксайлинковцы привезли словака и он рекламировал свои разработки для видео.
Думаю что в Силике или в Инлайне подскажут, как с ним связаться..

Ну я так решил потому, что вроде как для этого должен использоваться RTP протокол.
А он по идее заточен как раз для передачи потоков данных.


Забыл уточнить. У меня Stratix III. Его корка была исключительно под xilinx или "универсальная"?

я не помню, уточните в Инлайне...

Ладно, попробую...

Скорее всего видели: http://opencores.org/project,mjpeg-decoder

MJPEG — последовательность JPEG кадров, снабженная заголовком со служебной информацией. Где каждый кадр JPEG начинается с идентификатора потока и длинны кадра. Это если очень кратко и упрощенно. Смена битрейта, конечно, возможна.
Рекомендую программу riffpad
Скачайте пару роликов, например, отсюда https://archive.org/details/SecretGardenParty
И посмотрите их структуру с помощью riffpad.
По своему опыту, будет намного нагляднее, чем брать для понимания структуру из документации (см. далее).

Google search:
QuickTime File Format Specification
QuickTime-JPEGSpec
OpenDML AVI File Format Extensions
Development and Implementation of an MotionJPEG Capable JPEG Decoder in Hardware

Думается, порочная практика.
Я бы делал так:
Отработать структуру на матлаб-модели, используя готовый jpeg-декодер.
Потом написать декодер с обвязкой (testbench) для преобразования avi-mjpeg — raw (bmp).
Только после этого переходить к железу.
Это если идти по пути создания своего декодера, допустим, с привлечением готового jpeg-декодера.
Собственно, я так и делал, только кодер, а не декодер.

Видел.
Смутило то что это Beta версия.
К тому же хотелось бы на verilog.

Спасибо. Посмотрю.

Ну testbench никто не отменял
Я имел ввиду общий подход.

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

Странный вопрос. Да, декодер делает то же, что и кодер, только в обратном порядке.
Насколько можно взять за основу кодер.. Думаю, нельзя. Операции подобные, но обратные.
Кое-какие операции будут очень похожи, типа восстановления haffman-дерева по таблице.
Понимание того, как работает кодер, дает понимание, как работает декодер. Но не всегда наоборот.

Еще важно, насколько ваш декодер должен быть универсальным. Должен ли понимать DRI, таблицы Хаффмана стандартные или оптимальные и т.д.
Должен ли уметь перестраиваться на лету, или параметры сжатия определяются на этапе компиляции. Нюансов достаточно.

P.S. Это все актуально, если речь о самописном декодере. Если jpeg-декодер сторонний и удобный в настройке и параметризации, то всё очень просто.

Сообщение отредактировал x736C - Mar 14 2015, 13:36

порекомендую compression.ru

когда-то давно мне этот сайт помог

если MJPEG, то наверно плевать на степень сжатия, и можно по фиксированной таблице (не адаптивный) "Хаффманом кодировать" - у меня, например, разницы не было, а код значительно проще

upd: я чего-то не понял, кодер или декодер? если декодер, то там ес-сно нужно все варианты поддерживать, и опять же контейнер (avi или какой еще) разбирать

На очень сильных коэффициентах сжатия оптимальный хаффман дает двукратное преимущество. Качество при этом никакущее.
На средних — менее ~7%. И код усложняет, добавляется задержка. Большого смысла не имеет, согласен.

А почему Mjpeg? им давно никто не пользуется, лучше посмотрите PRORES или Jpeg2000, ну или LosLess, зависит от задачи и объема куда надо впихнуть,

Потому, что тот кривой девайс, который является источником видеопотока, поддерживает только h264 и MJPEG.
h264 чисто на HDL это слишком ресурсоёмко. Отдать больше половины ПЛИС под декодер я не могу.

P.S.
Попробовал запустить в QuestaSim декодер, о котором я упоминал в начале темы.
Оказалось, что он напрямую может работать с JPEG файлами (сохранил тестовый файл из Paint и прогнал через QuestaSim).
Вроде на выходе получается то, что нужно. Буду смотреть дальше.

Благодаря простоте им еще очень много кто пользуется. Вы jpeg2000 представляете в реализации на ПЛИС?
Боюсь, Вы даже не найдете открытой корки jpeg2000. А написание с нуля — это много человеко-часов.

Если брать h264, то там помимо ресурсов, цена будет впечатляющая.

К проприетарным эппловским форматам я бы даже не притрагивался.
Еще такой момент, ProRes или LosLess — форматы для жирных каналов и видео высокой четкости (10, 12 бит и т.п.). LosLess — сжатие без потерь — узкая область применения.
Для более-менее приличных коэффициентов сжатия им есть альтернатива.

BSACPLD, таких камер очень много, Вы не одиноки.

P.S. Из обзора формата ProRes
«Я спросил у менеджера Эппл, какова математическая основа ProRes — это вейвлеты, фракталы, JPEG или другая технология?
Он ответил, что компания Эппл никогда не раскрывает лежащую в основе математику, потому что это будет вызывать у пользователя (лишнее) предубеждение.
Теперь вы знаете, почему вы ничего об этом не знаете».
Если правильно передал смысл.

Сообщение отредактировал x736C - Mar 18 2015, 08:28

я сейчас ищу ProRes корку, и тоже под Альтеру-),можно скооперироваться, она нечто среднее между JPeg и Jpeg2000, но более простое,
. оптимизирована под видео с небольшой компрессией? т.е. максимальное качество при возможности влезть в стандартные носители.
и думаю вам надо поменять приоритеты-)), самый навороченный сенсор стоит значительно дешевле 5тыс$-), не говоря уж о стоимости работы.
может дешевле и проще поменять камеру?
А для H264 сейчас многие уже делают накопители, и чипы есть готовые.

Сообщение отредактировал AlexKit - Mar 18 2015, 11:44