| |
 Восстановление данных переданных по радиоканалу., Кодирование файла JPEG. |
|
|
|
|
 Apr 22 2010, 14:36
|
Группа: Участник
Сообщений: 5
Регистрация: 23-04-09
Пользователь №: 48 123
|
Необходимо написать программу восстанавливающую данные - файл JPEG, переданные по беспроводному каналу.
Ограничения: использовать как можно меньше вычислительных ресурсов, при использовании избыточных кодов добавляемая информация не
должна превышать 10% от изначального объёма.
Если чуть подробнее, то полученная картинка обрабатывается (кодируется) микроконтроллером AVR32 AT32UC3 и передаётся по
беспроводному каналу NanoNet. Принимаются данные на ПК, там происходит их декодирование. Язык программирования С.
Так как повторная передача исключена, то кроме корректирующих кодов вариантов вроде нет.
Корректирующие коды выбираются исходя из наиболее вероятного типа ошибок, вот тут пробел - какой тип ошибок более характерен для
NanoNet? У него частота что и у WiFi, но модуляция другая.
Для одиночных ошибок лучше всего подходит классика - код Хемминга. Учитывая 10% ограничение минимально возможный код (63, 57).
Только работа в с файлами происходит побайтно и использование такого кода означает лишние сдвиги, создание массивов и т.д. Как вариант
код (88,80), но он избыточен и лишь чуть более удобен.
Циклические коды БЧХ или Рида-Соломона выглядят более привлекательными и вроде не сложны в реализации. У БЧХ как я понимаю можно
задавать и длину кодируемого блока и количество исправляемых ошибок. Для кода Рида-Соломона в качестве символа можно задать байт.
В общем задача с разными решениями и где оптимальный путь, пока не определил.
С благодарностью приму любой совет.
|
|
|
|
|
|
|
 |
Ответов
|
|
Apr 29 2010, 15:59
|
Частый гость
Группа: Участник
Сообщений: 197
Регистрация: 8-04-05
Пользователь №: 3 977
|
Цитата(mdmitry @ Apr 29 2010, 19:26)  С помощью NanoNet Вы не сможете гарантированно передать данные без квитирования. Мощная помеха перегрузит приемник и пакет потеряется. Если у Вас нет режима реального времени, то обычный режим с квитированием (CRC в пакете считает сам модуль) и перезапросами на повторение работает нормально. Так вроде если есть возможность видеоданные поджать ( хотя бы на 20% ) появится в реальном времени и место для контрольных данных и время для повторной выдачи сбойных пакетов.
|
|
|
|
|
|
|
|
Apr 30 2010, 04:31
|
Частый гость
Группа: Участник
Сообщений: 197
Регистрация: 8-04-05
Пользователь №: 3 977
|
Цитата(V_G @ Apr 30 2010, 06:23) По-любому надо вводить избыточность (перезапросы или коды, исправляющие ошибки). Но если неисправимый сбой случится с jpeg картинкой, она будет испрочена достаточно сильно. А если не сжимать, выпадет несколько пикселов, которые и не заметишь. Так что может, не стоит сжимать картинку, а гнать bmp? Дальше человеческий глаз - лучший из фильтров! Ре понял. Вы полагаете, что, если будет сбой в передаче, который не получится восстановить повторной передачей ( вылетит больше 10% пакетов ), то такой сбой будет незаметен на глаз при передаче некодированного видео? И - лучше постоянные точечные помехи на картинке, чем чистая картинка, иногда сильно искажающаяся? Вопрос был - как передать видео без искажений. Согласен, мое предложение не проходит, если искажается более 10% пакетов.
|
|
|
|
|
|
|
|
Apr 30 2010, 05:29
|
Профессионал
Группа: Свой
Сообщений: 1 818
Регистрация: 15-10-09
Из: Владивосток
Пользователь №: 52 955
|
Цитата(vallav @ Apr 30 2010, 15:31) то такой сбой будет незаметен на глаз при передаче некодированного видео?
И - лучше постоянные точечные помехи на картинке, чем чистая картинка, иногда сильно искажающаяся? Ну, мы не знаем зашумленности реального канала связи, имеющегося у топикстартера. У меня смутные подозрения, что искажения 10% информации приведут к меньшему зашумлению картинки, чем многие из нас привыкли видеть у себя в телевизоре на даче. Да и требования к зашумленности выходного сигнала не обнародованы. Может, там дальше система распознавания образов, тогда "дачная картинка" не прокатит... Я к тому, что в IP-телефонии используется (вроде как) UDP-протокол, или что-то похожее, без повторных запросов. Заранее мирятся с некоей потерей информации. Может, и тут так можно поступить?
Сообщение отредактировал V_G - Apr 30 2010, 05:35
|
|
|
|
|
|
Сообщений в этой теме
 _Leo_ Восстановление данных переданных по радиоканалу. Apr 22 2010, 14:36 r_dot Цитата(_Leo_ @ Apr 22 2010, 18:36) повтор... Apr 28 2010, 22:46  juvf Цитата(r_dot @ Apr 29 2010, 04:46) Если н... Apr 29 2010, 05:58 _Leo_ Приятно видеть живое обсуждение темы.
Я обычно ищу... Apr 30 2010, 16:18 blackfin Цитата(_Leo_ @ Apr 30 2010, 20:18) ... та... Apr 30 2010, 17:42 mdmitry Цитата(_Leo_ @ Apr 30 2010, 20:18) BER ув... Apr 30 2010, 20:02 x736C Цитата(vallav @ Apr 30 2010, 08:31) Вопро... Apr 30 2010, 21:49 _Leo_ RE: Восстановление данных переданных по радиоканалу. May 31 2010, 14:30
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
