[des00 25]

20 hours ago, petrov said:

Я правильно понял, что в случае если RS не может исправить ошибки (если их много), то он не может вернуть, что пакет неисправляем? Это городить отдельно CRC надо?

В общем случае не может. Можно попробовать сделать второй код просто CRC для определения стираний, после деперемежения RSом исправляете стирания.

 

похоже понял в чем была неясность. Этож теория кодирования, если ошибок в канале больше чем способность кода обнаружить ошибки, то код просто напросто возьмет соседнее кодовое слово. Но и CRC не панацея, где то же в сети есть рассчеты эффективности CRC разных размеров под определенные длины блоков. Тот же CRC32 в Ethernet не просто так появился. Но да, соглашусь, сигнал отсутствия отказа от декодирования кода РС, в общем случае не является индикатором того, что ошибок нет. Но и тот же CRC32 прилично так отьест от блока {32,28}, который обсуждался выше) Получается классический размен: скорость кодирования vs исправляющая способность

28 minutes ago, repstosw said:

Какие есть более эффективные перемежения?   Исправляющая способность сильно зависит от характера ошибок: на случайных одиночных ошибках исправляющая эффективность данной конструкции падает до 40%   (40%  от половины числа исправляющих символов одного RS-блока)

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

[repstosw 18]

1 hour ago, des00 said:

похоже понял в чем была неясность. Этож теория кодирования, если ошибок в канале больше чем способность кода обнаружить ошибки, то код просто напросто возьмет соседнее кодовое слово. Но и CRC не панацея, где то же в сети есть рассчеты эффективности CRC разных размеров под определенные длины блоков. Тот же CRC32 в Ethernet не просто так появился. Но да, соглашусь, сигнал отсутствия отказа от декодирования кода РС, в общем случае не является индикатором того, что ошибок нет. Но и тот же CRC32 прилично так отьест от блока {32,28}, который обсуждался выше) Получается классический размен: скорость кодирования vs исправляющая способность

Про коллизии CRC знаю.  Да, есть вероятность, что проверка по CRC даст верный результат с некорректным блоком (чем меньше CRC тем вероятнее).

У меня несколько CRC.   CRC8 - на столбцы блоков RS (длина столбца 28 байт),  и CRC64 - на декодированный супер-фрейм (длина ~6 кБ).  Финальная проверка по CRC64 - если проверка супер-фрейма проходит, значит данные подаются на декодеры (фреймы MJPEG и CELT). Если проверка неудачна, супер-фрейм отбрасывается.

 

1 hour ago, des00 said:

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

Приоритет на пакетные ошибки.  Потому что наземная подвижная связь в городских условиях.  AWGN там и близко не пахнет...

Перепробовал перемежители:  Zig-Zag("змейка") и шаблон случайной перетасовки.   На пакетных ошибках - перемежение "транспонирование" выигрывает.

 

Изменено 30 августа, 2023 пользователем repstosw

[_4afc_ 25]

37 minutes ago, repstosw said:

У меня несколько CRC.   CRC8 - на столбцы блоков RS (длина столбца 28 байт),  и CRC64 - на декодированный супер-фрейм (длина ~6 кБ).  Финальная проверка по CRC64 - если проверка супер-фрейма проходит, значит данные подаются на декодеры (фреймы MJPEG и CELT). Если проверка неудачна, супер-фрейм отбрасывается.

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

Перепробовал перемежители:  Zig-Zag("змейка") и шаблон случайной перетасовки.   На пакетных ошибках - перемежение "транспонирование" выигрывает.

Забыл, вы переписали MJPEG чтобы при потере части суперфрейма - весь кадр не сыпался?

[des00 25]

1 hour ago, repstosw said:

Приоритет на пакетные ошибки...На пакетных ошибках - перемежение "транспонирование" выигрывает.

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

36 minutes ago, _4afc_ said:

Забыл, вы переписали MJPEG чтобы при потере части суперфрейма - весь кадр не сыпался?

вроде написано что суперфрейм тупо отбрасывается, поэтому сие без надобности)

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

[repstosw 18]

1 hour ago, _4afc_ said:

Забыл, вы переписали MJPEG чтобы при потере части суперфрейма - весь кадр не сыпался?

Это можно как-то согласовать с аппаратным кодированием и декодированием?   Использую аппараный кодек JPEG.

54 minutes ago, des00 said:

тогда врядли что-то будет лучше, все сверточники идут лесом, только брутфорс, только хардкор: большой блок, низкая скорость кодирования и размазывание ошибки на бОльшее количество блоков

Сильно большая латентность тоже ни к чему, не очень приятно когда голос собеседника и мой голос идут в разницу 1 секунда. (Full Duplex)

Блоков сейчас 29.  Один блок RS 255 байт.   Скорость одного супер-фрейма 100 мс.   Исправляющая способность на пакетной ошибке :  64 * 28 = 1792 байт,   всего в суперфрейме 7395 байт.

Этого хватает на исправление ошибки длительностью до 24 мс.

Изменено 30 августа, 2023 пользователем repstosw

[petrov 6]

repstosw

Исправляющая способность сильно зависит от характера ошибок: на случайных одиночных ошибках исправляющая эффективность данной конструкции падает

Для не пакетных ошибок надо делать бинарный БЧХ максимальной длины, какой получится.

_

CRC8 - на столбцы блоков RS

CRC8 - очень мало, на шуме в среднем каждый 2^8 блок будет давать ложную верную сумму.

_

Потому что наземная подвижная связь в городских условиях.  AWGN там и близко не пахнет...

Те искажения кодами не исправить.

 

[repstosw 18]

Just now, petrov said:

Те искажения кодами не исправить.

С тем что есть сейчас - лучше, чем без ничего.  Как это ни странно.

[_4afc_ 25]

2 minutes ago, repstosw said:

Это можно как-то согласовать с аппаратным кодированием и декодированием?   Использую аппараный кодек JPEG.

Думаю нет. Ведь у вас период "ресинхронизации" в нём задать нельзя? Там должен хаффман сбрасываться и теги вставляться.

Но самое главное заголовок не передавать.

[repstosw 18]

6 minutes ago, petrov said:

CRC8 - очень мало, на шуме в среднем каждый 2^8 блок будет давать ложную верную сумму.

Но ведь -28 байт столбец.  К тому же, если число стираний превышает число проверочных символов, декодер переходит в режим декодирования без стираний:

2 hours ago, repstosw said:

CRC8 - на столбцы блоков RS (длина столбца 28 байт)

 

4 minutes ago, _4afc_ said:

Но самое главное заголовок не передавать.

Заголовок не передаётся. И кое-какие постоянные данные тоже.

Использую libjpeg8 для восстановления заголовка.

Передаётся только тело и байт качества сжатия(в %)

Изменено 30 августа, 2023 пользователем repstosw

[_4afc_ 25]

9 minutes ago, repstosw said:

Заголовок не передаётся. И кое-какие постоянные данные тоже.

Разбейте картинку на 4. Сожмите отдельно. Передайте восстановите - всёравно кодирование 8х8 идёт.

Можно шахматно 8х8 .

Можно вавелетом разбить и пожать отдельно.

9 minutes ago, repstosw said:

Использую libjpeg8 для восстановления заголовка.

Передаётся только тело и байт качества сжатия(в %)

Декодирование тоже аппаратное? Или libjpeg8?

Как декодируются битые JPEG с восстановленным заголовком? С вылетом за адресное пространство и затиранием стека? Как портит картинку?

[repstosw 18]

16 minutes ago, _4afc_ said:

Разбейте картинку на 4. Сожмите отдельно. Передайте восстановите - всёравно кодирование 8х8 идёт.

Смысл?  Увидеть пол-морды собеседника?

16 minutes ago, _4afc_ said:

Декодирование тоже аппаратное? Или libjpeg8?

Тоже аппаратное.

libjpeg там только для заголовка и расчёт Хаффманов всяких. Причём всё просчитано заранее для качества от 5% до 95% с шагом +5%

16 minutes ago, _4afc_ said:

Как декодируются битые JPEG с восстановленным заголовком?

Никак.  Пропуск фрейма.

Там ещё сжатые аудио-данные в конце супер-фрейма. Они тоже пропускаются.

Работаю на уровне данных в буфере, никакой специфики вытащить разрушенный JPEG или CELT-аудио - нет.

 

JPEG кадр 160x240 (портретный) режим.   Дисплей 320x240:  поделён на две половины - слева собеседник, справа - я (камера).

Изначально был H264, но с переходом на Allwinner T113-s3 пришлось отказаться от H264. Потому что он не умеет кодировать H264, а Allwinner V3s умеет.

JPEG очень сильно даёт артефакты на резких переходах или токих линиях в картинке, что бросается в глаза даже при качестве 90%. H264 такого недостатка не имеет.

Может я слишком привередлив.  Whatsapp видео-звонок тоже даёт картинку, которая мне не нравится.

Изменено 30 августа, 2023 пользователем repstosw

[repstosw 18]

Касаемо темы ECC,CIRC и прочего.

Удалось "пощупать" CIRC через elbyecc.dll

Данный ECC меня разочаровал.  Слишком малая ээфективность для моих целей: из  2352  байт (сектор диска+ остальное) допустимы 52 ошибочных байта.  А проверочные байты (P,Q) вообще сильно чувствительные.

Приложил рабочий бенчмарк для тестирования CIRC:

diskecc.zip

[petrov 6]

repstosw

Но ведь -28 байт столбец.

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

[repstosw 18]

Есть интересный девайсик под названием Spy Gear Video Walkie Talkie.

Удалось найти кое-какую информацию о его внутренностях.

Дисплей там 1,8 дюйма  (разрешение скорее всего 160x128),  камеру опознать не удалось.

 

Трансивер там- модуль на AMICCOM A7137 - это 2,4 ГГц. Лучше бы сделали 430-440 МГц.

С наличием аппаратной FEC - Хемминг (7,4). Как-то ни о чём:  исправляет 1/7 всех данных и строго 1 бит на 1 байт.   Он как мёртвому припарки на Релеевских/Райсовских каналах.  Модуляция FSK, не OFDM.

 

Но девайсик сам забавный.  Дальность 50 метров по прямой, питание 3 ААА.

 

Внутренности:  int-photos-2619495.pdf

 

Изменено 30 августа, 2023 пользователем repstosw

[_4afc_ 25]

53 minutes ago, repstosw said:

Смысл?  Увидеть пол-морды собеседника?

Никак.  Пропуск фрейма.

Отсутствие изображение лучше частичного отсутствия?

 

53 minutes ago, repstosw said:

Там ещё сжатые аудио-данные в конце супер-фрейма. Они тоже пропускаются.

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

А не просто выбрасывать.

 

53 minutes ago, repstosw said:

Работаю на уровне данных в буфере, никакой специфики вытащить разрушенный JPEG или CELT-аудио - нет.

Процессор повиснет на битом JPEG?

 

53 minutes ago, repstosw said:

JPEG кадр 160x240 (портретный) режим. 

600 подблоков независимых на кадр. Можно передать 25субблоков с независимыми JPEG и 3 субблока аудио.

Будет биться 1\25 картинки при потере субблока. Ошибка в байте качества допустима - можно из предыдущего кадра взять...

 

53 minutes ago, repstosw said:

JPEG очень сильно даёт артефакты на резких переходах или токих линиях в картинке, что бросается в глаза даже при качестве 90%. H264 такого недостатка не имеет.

Может я слишком привередлив.  Whatsapp видео-звонок тоже даёт картинку, которая мне не нравится.

Эффукт гибса от сосинусного преобразования при низком bpp. Мне больше нравится Wavelet - он замыливает ВЧ составляющую картинки.