Всем привет!

Недавно у меня появилась задача реализовать 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-декодер сторонний и удобный в настройке и параметризации, то всё очень просто.

порекомендую 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 или другая технология?
Он ответил, что компания Эппл никогда не раскрывает лежащую в основе математику, потому что это будет вызывать у пользователя (лишнее) предубеждение.
Теперь вы знаете, почему вы ничего об этом не знаете».
Если правильно передал смысл.

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

Готовые чипы не подходят по температуре. К тому же плата уже готова и нет времени на переделку.
А насчёт камеры тут вопрос. У нас не камера, а покупной IP видеосервер. Он уже прошёл испытания по климатике.
Вся проблема только в софте.
Насчёт скооперироваться могу помочь только в части тестирования корки на моём железе.
Я хорошо разбираюсь в программировании и схемотехнике, но мало что понимаю в видеообработке, т.к. это мой первый проект с видео.
До этого я занимался только радиолокацией и различными сетевыми вещами (Ethernet, Wi-Fi и т.д.).
Так что в части алгоритмов видеообработки я пока мало чем могу помочь.

Т.е. Вы хотите поменять прошивку в видеосервере? круто! у меня есть на примете несколько команд которые свои серверы лепили, но все как правило с покупным H263,
а Я как раз видео занимаюсь очень плотно, но времени не хватает на все. а под какие интерфейсы сервер?

Не совсем так. Я делаю клиент. И софт и хард.
А сервер как раз готовый и поменять в нём я мало что могу.

а зачем тогда делать хард? можно же софтом обойтись?
все равно надо на чем то делать подсмотр, так взять комп и не парится с железкой.

Нельзя. Габариты. Требования по температуре. И ещё ряд требований...

есть готовые модули на Атоме или ARM, с -40с, + экран который подходит, (обычные плохо видно уже при -20,
а при - 35 вообще ничего не видно, проверяли для камер, и для вертолетов.)
этот вариант сбережет кучу времени и нервов. а размер 2х4см

Ну я же написал про особые требования.
10 RS-485
4 Ethernet
Решение ещё кучи задач, которые Atom просто не потянет.

10 RS? это круто! вопросов нет-)), Удачи...

В общем удалось мне запустить jpeg декодер о котором я упоминал в начале темы, но возник ряд вопросов.
1. При сжатии изображение делится на квадраты 8x8, а декодер выдаёт квадратами 16x16 (сигналы OutPixelX и OutPixelY).
Как такое может быть? И на каком этапе декодирования определяется размер квадрата? Перед IDCT?
2. Оттенок изображения немного немного отличает от изображения сконвертированного с помощью Photoshop (см. папку testbench).
С чем это может быть связано? С целочисленной арифметикой или с тем, что декодер использует квадраты 16x16?

Хоть поздно, но отвечу.


Такого быть не должно. Размер блока определен стандартом, надо проверять настройки декодера.
Подозреваю, что из-за chroma subsampling, декодер может выдавать блок 8x8 с шагом в 2.


Photoshop использует уникальные адобовские таблицы квантования, а декодер, который Вы используете, может быть настроен на таблицы из стандарта, некорректно восстанавливая блок.
Подробнее об отличиях тут.
И это тоже только предположение.