[BSACPLD 15]

Всем привет!

 

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

 

[_4afc_ 26]

2) Правильно ли я понимаю, что MJPEG это просто поток JPEG картинок передаваемый по Ethernet?

 

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

 

Где-то писали, что параметры всех JPEG картинок в MJPEG должны быть одинаковы.

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

[iosifk 3]

Можно даже коммерческие, если их можно "скачать" или если у них адекватная цена (< 5000$).

Примерно год назад в Питере на семинаре Ксайлинковцы привезли словака и он рекламировал свои разработки для видео.

Думаю что в Силике или в Инлайне подскажут, как с ним связаться..

 

[BSACPLD 15]

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

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

А он по идее заточен как раз для передачи потоков данных.

 

Примерно год назад в Питере на семинаре Ксайлинковцы привезли словака и он рекламировал свои разработки для видео.

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

[iosifk 3]

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

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

 

[BSACPLD 15]

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

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

[x736C 0]

1) Есть ли нормальные проверенные IP Core для MJPEG?

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

 

2) Правильно ли я понимаю, что MJPEG это просто поток JPEG картинок передаваемый по Ethernet?

Стало быть, для начала нужно реализовать JPEG декодер.

MJPEG — последовательность JPEG кадров, снабженная заголовком со служебной информацией. Где каждый кадр JPEG начинается с идентификатора потока и длинны кадра. Это если очень кратко и упрощенно. Смена битрейта, конечно, возможна.

Рекомендую программу riffpad

Скачайте пару роликов, например, отсюда https://archive.org/details/SecretGardenParty

И посмотрите их структуру с помощью riffpad.

По своему опыту, будет намного нагляднее, чем брать для понимания структуру из документации (см. далее).

 

3) Где можно почитать более менее внятное описание, что из себя этот MJPEG представляет?

Google search:

QuickTime File Format Specification

QuickTime-JPEGSpec

OpenDML AVI File Format Extensions

Development and Implementation of an MotionJPEG Capable JPEG Decoder in Hardware

 

4) Как правильно отлаживать подобные алгоритмы?

Пока решил делать вот таким образом:

Думается, порочная практика.

Я бы делал так:

Отработать структуру на матлаб-модели, используя готовый jpeg-декодер.

Потом написать декодер с обвязкой (testbench) для преобразования avi-mjpeg — raw (bmp).

Только после этого переходить к железу.

Это если идти по пути создания своего декодера, допустим, с привлечением готового jpeg-декодера.

Собственно, я так и делал, только кодер, а не декодер.

[BSACPLD 15]

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

Видел.

Смутило то что это Beta версия.

К тому же хотелось бы на verilog.

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).

Только после этого переходить к железу.

Ну testbench никто не отменял :)

Я имел ввиду общий подход.

Это если идти по пути создания своего декодера, допустим, с привлечением готового jpeg-декодера.

Собственно, я так и делал, только кодер, а не декодер.

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

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

 

[x736C 0]

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

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

Странный вопрос. Да, декодер делает то же, что и кодер, только в обратном порядке.

Насколько можно взять за основу кодер.. Думаю, нельзя. Операции подобные, но обратные.

Кое-какие операции будут очень похожи, типа восстановления haffman-дерева по таблице.

Понимание того, как работает кодер, дает понимание, как работает декодер. Но не всегда наоборот.

 

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

Должен ли уметь перестраиваться на лету, или параметры сжатия определяются на этапе компиляции. Нюансов достаточно.

 

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

Изменено 14 марта, 2015 пользователем x736C

[yes 8]

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

 

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

 

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

 

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

[x736C 0]

На очень сильных коэффициентах сжатия оптимальный хаффман дает двукратное преимущество. Качество при этом никакущее.

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

[AlexKit 0]

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

[BSACPLD 15]

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

Потому, что тот кривой девайс, который является источником видеопотока, поддерживает только h264 и MJPEG.

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

 

P.S.

Попробовал запустить в QuestaSim декодер, о котором я упоминал в начале темы.

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

Вроде на выходе получается то, что нужно. :) Буду смотреть дальше.

[x736C 0]

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

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

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

 

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

 

К проприетарным эппловским форматам я бы даже не притрагивался.

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

Для более-менее приличных коэффициентов сжатия им есть альтернатива.

 

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

 

P.S. Из обзора формата ProRes

«Я спросил у менеджера Эппл, какова математическая основа ProRes — это вейвлеты, фракталы, JPEG или другая технология?

Он ответил, что компания Эппл никогда не раскрывает лежащую в основе математику, потому что это будет вызывать у пользователя (лишнее) предубеждение.

Теперь вы знаете, почему вы ничего об этом не знаете».

Если правильно передал смысл.

Изменено 18 марта, 2015 пользователем x736C

[AlexKit 0]

Потому, что тот кривой девайс, который является источником видеопотока, поддерживает только h264 и MJPEG.

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

 

P.S.

Попробовал запустить в QuestaSim декодер, о котором я упоминал в начале темы.

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

Вроде на выходе получается то, что нужно. :) Буду смотреть дальше.

я сейчас ищу ProRes корку, и тоже под Альтеру-),можно скооперироваться, она нечто среднее между JPeg и Jpeg2000, но более простое,

. оптимизирована под видео с небольшой компрессией? т.е. максимальное качество при возможности влезть в стандартные носители.

и думаю вам надо поменять приоритеты-)), самый навороченный сенсор стоит значительно дешевле 5тыс$-), не говоря уж о стоимости работы.

может дешевле и проще поменять камеру?

А для H264 сейчас многие уже делают накопители, и чипы есть готовые.

Изменено 18 марта, 2015 пользователем AlexKit