Восстановление данных переданных по радиоканалу., Кодирование файла JPEG. Опции

[_Leo_]

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

должна превышать 10% от изначального объёма.
Если чуть подробнее, то полученная картинка обрабатывается (кодируется) микроконтроллером AVR32 AT32UC3 и передаётся по

беспроводному каналу NanoNet. Принимаются данные на ПК, там происходит их декодирование. Язык программирования С.

Так как повторная передача исключена, то кроме корректирующих кодов вариантов вроде нет.
Корректирующие коды выбираются исходя из наиболее вероятного типа ошибок, вот тут пробел - какой тип ошибок более характерен для

NanoNet? У него частота что и у WiFi, но модуляция другая.
Для одиночных ошибок лучше всего подходит классика - код Хемминга. Учитывая 10% ограничение минимально возможный код (63, 57).
Только работа в с файлами происходит побайтно и использование такого кода означает лишние сдвиги, создание массивов и т.д. Как вариант

код (88,80), но он избыточен и лишь чуть более удобен.
Циклические коды БЧХ или Рида-Соломона выглядят более привлекательными и вроде не сложны в реализации. У БЧХ как я понимаю можно

задавать и длину кодируемого блока и количество исправляемых ошибок. Для кода Рида-Соломона в качестве символа можно задать байт.

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

[mdmitry]

С помощью NanoNet Вы не сможете гарантированно передать данные без квитирования. Мощная помеха перегрузит приемник и пакет потеряется. Если у Вас нет режима реального времени, то обычный режим с квитированием (CRC в пакете считает сам модуль) и перезапросами на повторение работает нормально.

[vallav]

С помощью NanoNet Вы не сможете гарантированно передать данные без квитирования. Мощная помеха перегрузит приемник и пакет потеряется. Если у Вас нет режима реального времени, то обычный режим с квитированием (CRC в пакете считает сам модуль) и перезапросами на повторение работает нормально.

Так вроде если есть возможность видеоданные поджать ( хотя бы на 20% ) появится в реальном времени и место для контрольных данных и время для
повторной выдачи сбойных пакетов.

[V_G]

Так вроде если есть возможность видеоданные поджать ( хотя бы на 20% ) появится в реальном времени и место для контрольных данных и время для повторной выдачи сбойных пакетов.

По-любому надо вводить избыточность (перезапросы или коды, исправляющие ошибки). Но если неисправимый сбой случится с jpeg картинкой, она будет испрочена достаточно сильно. А если не сжимать, выпадет несколько пикселов, которые и не заметишь. Так что может, не стоит сжимать картинку, а гнать bmp? Дальше человеческий глаз - лучший из фильтров!

Сообщение отредактировал V_G - Apr 30 2010, 02:24

[vallav]

По-любому надо вводить избыточность (перезапросы или коды, исправляющие ошибки). Но если неисправимый сбой случится с jpeg картинкой, она будет испрочена достаточно сильно. А если не сжимать, выпадет несколько пикселов, которые и не заметишь. Так что может, не стоит сжимать картинку, а гнать bmp? Дальше человеческий глаз - лучший из фильтров!

Ре понял.
Вы полагаете, что, если будет сбой в передаче, который не получится восстановить повторной передачей ( вылетит больше 10% пакетов ),
то такой сбой будет незаметен на глаз при передаче некодированного видео?
И - лучше постоянные точечные помехи на картинке, чем чистая картинка, иногда сильно искажающаяся?
Вопрос был - как передать видео без искажений.
Согласен, мое предложение не проходит, если искажается более 10% пакетов.