4.3 Ts пакеты в ip пакет

Исходя из раздела 4.1, в IP пакет может включать в себя от 1 до 7 MPEG пакетов. Длинные пакеты нежелательны из-за большой потери данных при потере одного IP-пакета. Использование коротких пакетов приводит к увеличению передаваемой служебной информации, поэтому будет выбран компромисс между этими двумя факторами. Для упрощения рекомендуется, фиксировать выбранное значение в течение всей сессии приемо-передачи.

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

4.4 Длина ts пакета (188/204)

Как минимум, все оборудование должно работать в режиме 188 байт.

В более сложных сетях для передач TS пакетов из 204 байт может потребоваться полная проверка от начала до конца всей сети.

В RFC2250 явно не упоминаются пакеты размером 204 байт, так что многие реализованные системы поддерживают только пакеты в 188 байт.

Приемник, который поддерживает пакеты размером как 188, так и 204 байт будет использовать полученную длину IP-пакетов, чтобы определить пакеты 188 или 204 байтовые пакты в нём содержаться. Присутствуют пакеты по 188 байт, то полезная нагрузка RTP будет делить ровно на 188, а не на 204, если наоборот, то на 204 байтовые пакеты.

Длина пакета TS должна сохраняться постоянной.

4.5 Схема fec

4.5.1 История вопроса

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

Самая большая проблема с системами FEC в IP-сетях, в том что из за контрольных сумм UDP, канальные битовые ошибки приводят к потере целых пакетов. Так же, причиной потери пакетов могут быть буферы и проблемы связанные с изменением маршрута доставки. Суммарные потери пакетов по трём причинам - грубые переназначения, потери, вызванные битовыми ошибками и потерями пакетов, необходимо снизить, так чтобы схема FEC не нарушалась из за превышением установленного уровня ошибок. Потому, что любые битовые ошибки приводят к отбрасыванию пакета, не ни каких условий при которых схема коррекции ошибок, могла бы обрабатывать ошибочные пакеты - каждый пакет будет либо доставлен правильно или вообще нет.

Формат полезной нагрузки RTP для пактов общей коррекции ошибок был определен в RFC 2733, чтобы разрешить коррекцию ошибок в реальном времени. Этот стандарт позволяет использование традиционных кодов коррекции ошибок. Основное преимущество этой схемы в том, что она может быть использована с форматом видео любого стандарта (MPEG, SDI, SDTI, ...) до тех пор, пока он инкапсулируется в пакет RTP. Однако этот стандарт ограничивает количество пакетов, используемых для коррекции ошибок, до 24 последовательных пакетов.

4.5.2 Расположение fec пакета

Чтобы восстановить увеличение потерь, существующими RFC предлагается. Также же обычно, коды коррекции ошибок применяются к непоследовательным медиа пакетам, которые может быть больше 24. Каждый FEC пакет связан с периодической последовательностью пакетов. Таким образом, последовательность RTP пакетов может быть восстановлена из последовательности FEC пакетов. Процесс, изображен на рисунке 1.

Рис.1 Схема кодирования FEC

На рисунке 1, схема кодирования составленная для L * D медиа пакетов. Выбран период L. Таким образом, полезная нагрузка FEC пакета вычисляется на основе пронумерованых D пакетов nL + k (0 ≤ n ≤ D - 1).

L столбцов

D строк

Выравнивание столбцов для удобно иллюстрации. При реализации эту выравнивания может использовать для упрощения, но есть некоторые потенциальные преимущества, которые можно получить путем смещения столбцов - см. Информационное приложение А. Это означает, что приёмные устройства не должны делать никаких предположения о связи между FEC пакетами, кроме тех, которые явно указаны.

Основным преимуществом этой схемы является эффективность коррекции возникновения ошибок. Функцией коррекции ошибок выбрана XOR, она даёт возможность восстановить любой из потерянных пакетов. Но если схема, основана на XOR (т.е. применяется к последовательным D пакетам), то возникновение ошибки в двух или более потерянных пакетах не может быть исправлено. Однако, если использовать двумерную схему, значительно улучшится исправление ошибок, так как она может восстановить до L последовательных пакетов.

Хотя эта схема очень устойчивы к потере пакетов (исправляет L последовательно потерянных пакетов), если теряются хотя бы 2 пакета, расположенных в одном столбце, нет никакой возможности, чтобы исправить эти потери. Поэтому рекомендуется, что бы одновременно поддерживались два потока FEC, что обеспечит более высокую корректирующую возможность, за счет увеличения избыточности информации. Эти FEC потоки должны передаваться на отдельные UDP порты, чтобы иметь возможность отдельной обработки элементов последовательности, а также для обеспечения обратной совместимости с предыдущими реализациями, которые поддерживают только один (столбец) FEC потока.

На один порт должен приходить поток столбцов FEC на второй порт поток строк FEC.

Очевидно, что второй поток, чтобы быть полезным, должен отличаться от первого по размеру. Структура второго потока FEC имеет смещение (OFFSET) равное 1, так же желательна нумерация пакетов потока D такая же, как нумерация первого потока L. Это позволит создать эффективную структуру FEC, как показано на рисунке 2, где помеченыt RTP пакеты являются медиа пакетами, а пакеты помеченные FEC являются первым и вторым потоком FEC пакетов.

Рис.2 Двумерная схема кодирования FEC

Второй поток FEC может бороться с потерей любого одного пакета, а первый потока FEC может бороться с потерями L пакетов в длину.

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