Имеется вокодер(Speex), выдаёт он по 20байт на каждый фрейм.
Необходимо обеспечить передачу по низкоскоростному каналу и защититься от выпадения байтов.
Достаточно просто определения самого факта выпадения и отбрасывания всего 20ти байтового пакета(скормив декодеру вместо него предыдущий правильный).
Проблема у меня с созданием метки, по которой определялись бы границы пакетов - ведь данные идут в RAW и там могут встречаться(теоретически) любые последовательности! Избыточность должна быть минимально возможной(канал не резиновый).

Что делать? Допустим, прикрутить CRC16 не проблема, но меня смущает возможность такого сценария:
Передатчик передаёт, а приёмник принимает данные в буфер(20байт) до его заполнения.
По заполнению буфера, приёмник считает, что фрейм вокодера принят и отправляет его на декодинг
НО ведь на самом деле к этому моменту передатчик мог передать уже 21байт и к премеру где-то посередине байт выпал и последний байт буфера приёмника уже будет содержать первый байт следующего фрейма.
Точно такая-же проблема может возникнуть при использовании CRC.

Нужны какие-то признаки начала фрейма.
Чтобы приёмник мог отреагировать, если наткнётся на признак начала пакета ДО заполнения буфера.
Как быть??

Может быть есть какие-то особенности Speex, о которых я не знаю(может быть какие-то коды он не использует).
Была мысль для уменьшения вероятности собрать статистику по кодам(двух байтовым комбинациям) и использовать самую редко попадающуюся, но решение, мягко говоря тупое.
Также думал о замене некой последовательности на другую(заранее определённую) для того, чтобы "освободить" эту последовательность под код начала фрейма(но вот та заранее определённая,опять таки встретится в потоке и всё).Но тоже всё это как-то не очень красиво...

Нет идей больше, а это самое плохое, что может быть:-)

Первое, что приходит на ум, это использовать не только маркер начала пакета, но и маркер его конца (полученный из первого по определенному алгоритму), с проверкой числа принятых байт (длина пакета ведь фиксированная). Это позволит существенно уменьшить вероятность ошибки. А если для генерации первого маркера применить псевдогенератор, то еще лучше. Это, конечно, решение в лоб...
Если допустить некоторую избыточность и позволяют вычислительные мощности, то можно использовать и кодеры/декодеры, обнаруживающие и исправляющие ошибки...

Примеры организации протоколов с фреймами и байт-стаффингом это SLIP и Wake.

Так, есть некоторые сдвиги!
Более детальное изучение мануала по Speex и небольшое ковыряние исходников выявили некоторые полезные признаки:
первый бит всегда 0(для моего режима), следующие 4бита образуют число 3(subMode). Т.е. 5первых бита всегда образуют число 3.
К тому-же, если паковать несколько фреймов в пакет, то последние 4бита будут = 15.
Так что частично проблема решена. Как всегда RTFM:-)

Ага, всем отозвавшимся спасибо.
Пока принял следующее решение:
1. Передавать фреймы не по одному, а по 3-5 за раз.
2. Из битстрима, созданного Speex,из каждого фрейма вырезать первые 5 бит и терминатор в конце пакета(при 3х пакетах уже экономия 15 бит+4 на терминаторе)
3. Вместо терминатора(те самые 4бита) будет использоваться 3бита в качестве начала пакета.
Таким образом для CRC высвобождается 16бит и bits per second будет тот-же.
Единственный недостаток, конечно, это то, что если CRC не сойдётся придётся выкинуть сразу 3 фрейма(60ms).

Про всякие там коды с коррекцией думал, но может как-нибудь в версии 2 уже прикручу. Посмотрим на практике как оно будет.

Как считаете, будет иметь такой вариант право на жизнь и нормальную связь?(используется GSM DataCall)