1 кадр видео с качеством 8бит 15МГц передается на скорости 115200 бит/сек прибл. 41 секунду (если я не ошибся в расчетах). С полным качеством и безо всякого сжатия за 5 минут. Вопрос - зачем себе городить проблемы со сжатием и распаковкой JPEG на AVR или еще на чем, если для этого нужно время >41 сек.+ время на передачу этого сжатого кадра? Просто пишите кадр в буфер и передавайте себе спокойно. Быстрее передать на меньшей скорости, чем кодировать и раскодировать видео на микроконтроллерах. И к тому же еще и дешевле будет. И еще не понятно, каким образом это видео в цифру кодируется - простым АЦП, или как?

Сообщение отредактировал andrewkrot - Mar 31 2011, 09:44

Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам.

А кто будет заниматься синхронизацией, уовнями белого черного итд.?
Вы сами хоть делали такое, перед тем как советовать.
Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть.
MPEG для чего то придумали, ну и как его на F2 сделать?

Вообще то видео-ацп обычно имеет схемы синхронизации внутри. И уровни белого-черного тоже он привязывает. Именно на STM32F2xx- нет, не делал. Семплы только недавно приехали, юзерманул только появился, а аппликух по DCMI (Digital Camera Interface) тоже еще нет. Пока макетную плату разводим на свой страх и риск. Чтобы MPEG жать надо внешнюю память ставить. Для этого у STM32F2xx есть FSMC - прийдется внешнюю SRAM цеплять. Для наших задач оно ненадо, поэтому не разводим.

Да нет STM32F2xx никакого MPEG или H264, непотянет, нет в них видео ацп, медленный проц, архитектура проца вообще для работы с обработкой видео потока не годиться.
Какая там еще внешняя память, если проц не тот. Если не хочется делать то можно и готовый чип купить.

Можно сжать раз в 5 и на глаз не отличить от оригинала. На кортексе.
Только как уже все задавали вопрос - зачем сжимать, если со скоростью 19200 бод можно свободно передавать картинку 768*576 ч/б в несжатом виде.

Но это же долго. При большом расстоянии, как указывалось, большая вероятность потери данных. Передавать желательно за короткое время.
Сжимать раз 20...100 желательно. Это позволяет и MPEG и H264 и ряд других алгоритмом. В 5 раз не очень интересно. Потери части информации не избежать.
Просто нужно оговорить, какие потери информации приемлемы. Обычно это мелкие детали на ч/б изображении.

Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр.

Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF или TIFF или RAW.
В JPEG при потери пары байт вы получите несколько 8x8 квадратиков с неправильными пикселями по ярости.
И то это маловероятно в канале передаче, где есть коды исправляющие ошибки.

для черно-белой картинки хорошо должна подойти простенькая RLE компрессия.
http://en.wikipedia.org/wiki/Run-length_encoding

Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет.


Опять-таки -- только если это графика без полутонов. На любой нормальной фотографии JPEG будет работать существенно лучше. Он был сделан именно для компресссии фоток, в отличии от гифа, который вообще не в курсе, что сжимаемый поток байтов -- картинка.

Сообщение отредактировал ar__systems - Apr 5 2011, 13:32

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

Сообщение отредактировал pofikus - Apr 5 2011, 19:49

ar__systems чёт не то пишет.
GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа.
... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия.
LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали.

Какие потери байт? О чем вы?
Передача данных разве не подразумевает протокол?
Пакеты, кадры, CRC. итд итп.

у автора сжатие потока - глобальная задача, а ваши GIF, TIF, JPEG - тоже методы сжатия потока...