andrewkrot 0 31 марта, 2011 Опубликовано 31 марта, 2011 (изменено) · Жалоба Да, может. При правильных настройках. Алгоритмы типа зип не дадут существенного сжатия картинки с камеры. Это не обсуждение, а какое-то переливание из пустого в порожнее. Сказано же, любой процессор справится с сжатием кадра в JPEG за 5 минут. Лишь бы памяти хватало. 1 кадр видео с качеством 8бит 15МГц передается на скорости 115200 бит/сек прибл. 41 секунду (если я не ошибся в расчетах). С полным качеством и безо всякого сжатия за 5 минут. Вопрос - зачем себе городить проблемы со сжатием и распаковкой JPEG на AVR или еще на чем, если для этого нужно время >41 сек.+ время на передачу этого сжатого кадра? Просто пишите кадр в буфер и передавайте себе спокойно. Быстрее передать на меньшей скорости, чем кодировать и раскодировать видео на микроконтроллерах. И к тому же еще и дешевле будет. И еще не понятно, каким образом это видео в цифру кодируется - простым АЦП, или как? Изменено 31 марта, 2011 пользователем andrewkrot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам. А кто будет заниматься синхронизацией, уовнями белого черного итд.? Вы сами хоть делали такое, перед тем как советовать. Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть. MPEG для чего то придумали, ну и как его на F2 сделать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khach 33 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба А кто будет заниматься синхронизацией, уовнями белого черного итд.? Вы сами хоть делали такое, перед тем как советовать. Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть. MPEG для чего то придумали, ну и как его на F2 сделать? Вообще то видео-ацп обычно имеет схемы синхронизации внутри. И уровни белого-черного тоже он привязывает. Именно на STM32F2xx- нет, не делал. Семплы только недавно приехали, юзерманул только появился, а аппликух по DCMI (Digital Camera Interface) тоже еще нет. Пока макетную плату разводим на свой страх и риск. Чтобы MPEG жать надо внешнюю память ставить. Для этого у STM32F2xx есть FSMC - прийдется внешнюю SRAM цеплять. Для наших задач оно ненадо, поэтому не разводим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Да нет STM32F2xx никакого MPEG или H264, непотянет, нет в них видео ацп, медленный проц, архитектура проца вообще для работы с обработкой видео потока не годиться. Какая там еще внешняя память, если проц не тот. Если не хочется делать то можно и готовый чип купить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба JPEG можно без потери качества восстановить в первоиссточник??? Можно сжать раз в 5 и на глаз не отличить от оригинала. На кортексе. Только как уже все задавали вопрос - зачем сжимать, если со скоростью 19200 бод можно свободно передавать картинку 768*576 ч/б в несжатом виде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Но это же долго. При большом расстоянии, как указывалось, большая вероятность потери данных. Передавать желательно за короткое время. Сжимать раз 20...100 желательно. Это позволяет и MPEG и H264 и ряд других алгоритмом. В 5 раз не очень интересно. Потери части информации не избежать. Просто нужно оговорить, какие потери информации приемлемы. Обычно это мелкие детали на ч/б изображении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
M_Andrey 0 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 1 апреля, 2011 Опубликовано 1 апреля, 2011 · Жалоба Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр. Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF или TIFF или RAW. В JPEG при потери пары байт вы получите несколько 8x8 квадратиков с неправильными пикселями по ярости. И то это маловероятно в канале передаче, где есть коды исправляющие ошибки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pofikus 0 5 апреля, 2011 Опубликовано 5 апреля, 2011 · Жалоба для черно-белой картинки хорошо должна подойти простенькая RLE компрессия. http://en.wikipedia.org/wiki/Run-length_encoding Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 5 апреля, 2011 Опубликовано 5 апреля, 2011 (изменено) · Жалоба для черно-белой картинки хорошо должна подойти простенькая RLE компрессия. http://en.wikipedia.org/wiki/Run-length_encoding Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет. Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF. Опять-таки -- только если это графика без полутонов. На любой нормальной фотографии JPEG будет работать существенно лучше. Он был сделан именно для компресссии фоток, в отличии от гифа, который вообще не в курсе, что сжимаемый поток байтов -- картинка. Изменено 5 апреля, 2011 пользователем ar__systems Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pofikus 0 5 апреля, 2011 Опубликовано 5 апреля, 2011 (изменено) · Жалоба Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет. пробовал, по этому и советую.... но предварительно надо подготовить картинку.... В данном случае так как радио канал наверно зашумлен, я бы картинку не компресировал, а редко передавал бы полную картинку, а в промежутках изменения происшедшие с момента передачи полной картинки.... Изменено 5 апреля, 2011 пользователем pofikus Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 5 апреля, 2011 Опубликовано 5 апреля, 2011 · Жалоба ar__systems чёт не то пишет. GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа. ... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия. LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NetTracer 0 5 апреля, 2011 Опубликовано 5 апреля, 2011 · Жалоба Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр. Какие потери байт? О чем вы? Передача данных разве не подразумевает протокол? Пакеты, кадры, CRC. итд итп. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pofikus 0 5 апреля, 2011 Опубликовано 5 апреля, 2011 · Жалоба ar__systems чёт не то пишет. GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа. ... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия. LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали. у автора сжатие потока - глобальная задача, а ваши GIF, TIF, JPEG - тоже методы сжатия потока... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
