Предисловие:

При передаче аудио и видео в реальном времени механизм повторной передачи протокола TCP приведет к резкому увеличению задержки передачи и серьезному снижению качества передачи, если качество сети низкое, а скорость потери пакетов высока. Протоколы передачи аудио и видео в реальном времени обычно используют UDP (уровень приложений представляет собой протокол RTP на основе UDP, который предоставляет порядковые номера и услуги синхронизации аудио и видео для передачи видео). UDP обладает характеристиками высокой пропускной способности и низкой задержки. Однако передача RTP на основе UDP сталкивается с такими проблемами, как потеря пакетов, нарушение порядка, дублирование и дрожание в сложных средах общедоступных сетей, особенно в сетях 3G, 4G и WIFI, что серьезно влияет на эффект передачи звука в реальном времени. и видео. FEC (упреждающее исправление ошибок) на уровне приложений — это технология, которая эффективно предотвращает потерю пакетов и является эффективным и надежным решением для передачи видео в реальном времени.

1. Технология контроля ошибок:

FEC — это технология контроля ошибок передачи в системах односторонней связи путем отправки дополнительной информации вместе с данными для устранения ошибок, чтобы уменьшить частоту ошибок по битам. Отправитель отправляет данные для отправки вместе с определенным избыточным кодом исправления ошибок, а получатель выполняет обнаружение ошибок в полученных данных на основе кода исправления ошибок. Если ошибка обнаружена, получатель выполняет исправление ошибок. FEC делится на внутриполосное FEC и внеполосное FEC. FEC использует заранее определенный алгоритм, добавляя к передаче избыточную информацию. В 1949 году Хэмминг предложил код Хэмминга, который мог исправить одну случайную ошибку. В 1960 году Хупугем, Бозе и Чаудхум изобрели код BCH и Соломон, который предложил код Рида-Соломона (RS), который позже был назван кодом исправления ошибок Рида-Соломона (код исправления ошибок Рида-Соломона). , то есть) Позже дополнительная прямая коррекция ошибок). ITU-T G.975/G.709 предусматривает, что «внеполосное FEC» означает добавление уровня FEC ниже уровня SDH для решения конкретных проблем FEC. Внеполосное кодирование FEC имеет большую избыточность и сильные возможности исправления ошибок. FEC отличается от ARQ. Если обнаружена ошибка, нет необходимости уведомлять отправителя о необходимости повторной передачи. Как только система потеряет исходный пакет данных, механизм FEC может компенсировать это избыточными сообщениями. Например, есть пакет данных «10», который разделен на два сообщения, а именно «1» и «0», и есть избыточное сообщение «0». Исходный пакет можно собрать после получения любых двух сообщений. . Однако эти избыточные сообщения также создадут дополнительную нагрузку.

ARQ (автоматический повторный запрос) — это один из протоколов исправления ошибок канального уровня и транспортного уровня в модели OSI. Он обеспечивает надежную передачу информации на основе ненадежных сервисов, используя два механизма: подтверждение и таймаут. Если отправитель не получает кадр подтверждения в течение определенного периода времени после его отправки, он обычно отправляет его повторно. ARQ включает в себя протокол ARQ с остановкой ожидания и протокол непрерывного ARQ с такими механизмами, как обнаружение ошибок, положительное подтверждение, повторная передача после таймаута, а также отрицательное подтверждение и повторная передача.

2. Применение FEC при передаче аудио и видео:

Технология прямого исправления ошибок FEC широко используется в различных областях обработки информации, различных кодах исправления ошибок, таких как код Хэмминга, код BCH, код Рида-Соломона (RS), сверточный код, турбокод, код проверки четности низкой плотности (Low Коды проверки четности плотности (LDPC). Эти коды исправления ошибок обычно используются в базовых протоколах (таких как уровень канала передачи данных) для выполнения исправления ошибок в единицах битовых строк.

В реальной разработке проекта нет необходимости обращать внимание на базовый протокол канального уровня, но FEC можно использовать на прикладном уровне для обнаружения и восстановления потери пакетов для каждого пакета. Поскольку протокол UDP может гарантировать правильность данных в пакете, нет необходимости рассматривать возможность исправления ошибок внутри пакета. Мы можем использовать FEC для восстановления потери пакетов UDP.

Расширяем заголовок группы пакетов FEC (Group head）,Группа — это полностью независимая единица обработки FEC.,Он состоит из k медиа-пакетов и r избыточных пакетов.,Каждая посылка в группе имеет номер группы.,Определите, потеряла ли группа пакет данных, на основе непрерывности номера группы.,Выборочное восстановление,Если избыточные пакеты утеряны, восстанавливать их нет необходимости. Избыточность FEC-кодирования определяется как отношение количества избыточных пакетов r к числу исходных медиа-пакетов k.,Чем выше избыточность,Это означает, что тем сильнее способность противостоять потере пакетов.,Однако эффективность передачи также соответственно снизится.,поэтомуFECАлгоритм представляет собой компромисс между эффективностью передачи и устойчивостью к потере пакетов.。Условия восстановления потерянных пакетов：Количество полученных медиа-пакетов+Количество полученных избыточных пакетов>=groupКоличество оригинальных медиа-пакетов,При условии соблюдения вышеуказанных условий,Потеря пакетов может быть восстановлена. Когда сеть не теряет пакеты,Модуль FEC не вносит задержку,Когда в сети происходит потеря пакетов,Необходимо дождаться прибытия всех посылок группы.,И восстанавливайте потерянные пакеты перед их загрузкой на уровень приложения.,Это вызовет определенную задержку.

Весь процесс передачи выглядит следующим образом: отправитель сначала выполняет кодирование видео h264 для собранных аудиоданных, затем кодирование FEC вводит избыточные пакеты и, наконец, упаковывает их в RTP и отправляет. Получатель выполняет декодирование FEC для восстановления потерянных пакетов данных. . Кроме того, для решения проблем с нарушением порядка пакетов и джиттером мы используем стратегию QOS принимающей стороны (буферизация джиттера для решения таких проблем, как нарушение порядка пакетов UDP и дублирование пакетов), а также используем сортировку карт и настройку ожидания. задержки для восстановления нарушенного порядка пакетов и решения проблемы дрожания сети для адаптации к передаче видео в различных состояниях канала. С помощью вышеуказанных стратегий мы стремимся найти разумное решение для устранения проблем потери пакетов и беспорядка при передаче UDP, а также обеспечить надежную гарантию передачи видео в реальном времени.

FEC : partiy,Reed-Solomonz, Hamming,LDPC,XOR

• parity,Reed-Solomon, Hamming codes,

Все эти три алгоритма FEC требуют дополнительной поддержки протокола и не являются аннотациями, охватываемыми форматом RTP. Они были определены в устаревших RFC2733 (алгоритм XOR) и RFC3009.

• RFC 5109 (алгоритм XOR) определяет ULPFEC и FLEXFEC и реализуется вместе с определением протокола RTP.
• RFC 6105 RTP Payload Format for 1-D Interleaved Parity
• RFC 6682 Raptor FEC, фонтанкодирование
• RFC 6865 Reed-Solomon FEC

Связанная реализация с открытым исходным кодом:

• FLEXFEC реализован в версии WebRTC
• Проект с открытым исходным кодом OPENFEC (http://openfec.org/accueil.html): кодек LDPC-Staircase, кодек Рида-Соломона GF(256), кодек 2D четности, кодек LDPC из файла

• feclib (http://feclib.sourceforge.net/) может найти отсутствующий пакет данных через избыточные пакеты, но не может найти внутреннюю ошибку пакета данных.

• RSCODE (http://rscode.sourceforge.net/) может исправлять внутренние ошибки пакета данных.

Ссылка на статью: http://t.csdn.cn/Z9tPd