3.2 Битрейт транспортного потока

Существуют ограничения на верхнюю и нижнюю границу скорости передачи, которые будут поддерживаться оборудованием в соответствии с этими практическими рекомендациями. Как минимум, рекомендуется оборудование способное поддерживать некоторые уровни транспортного потока, перечисленные в практических рекомендациях № 2 и называемые операционными точками. Полный перечень, поддерживаемых режимов, работы, будет зависеть от приложения для которого оно разработано.

Для соответствия назначению все оборудование должно поддерживать уровни транспортного потока: 7.5-1:0:0, 14-0:1:0, 30-0:0:1 и 50-0:0:2, определённые в практических рекомендациях № 2.

3.3 Система вывода ошибок

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

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

4 Протоколы передачи

4.1 Особенности передачи ip

Размер IP пакета выходящего из передающего устройства должен быть ограничен таким образом, чтобы не происходило IP-фрагментации на выходе устройства. Бит «не фрагментировать» должен быть установлен в заголовке IP дейтаграммы. Конечные устройства, как правило, подключаются к Ethernet-сетям, это вносит ограничение максимального блока передачи (MTU) до 1500 байт. Между промежуточными узлами в сети MTU может быть меньше 1500 байт, поэтому нужно позаботиться о том, чтобы IP-пакеты не теряются из-за требования "не фрагментировать".

4.2 Rtp / udp / ip преобразование

Для использование RTP необходимо обеспечить стандартный заголовок пакетов. Для транспортных потоков MPEG-2 необходимо следовать RFC2250, поскольку они обеспечивают подходящее представление. Вопросы передачи 204 байтовых пакетов рассматриваются далее в этом документе.

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

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

Следующие дополнительные ограничения будут наложнны на RFC3550 и RFC2250:

• Бит Заполнения (P) должен быть установлен в ноль. Это означает, что байт полезной нагрузки будет не заполнен.

• Бит Расширения (X) должен быть установлен в ноль. Это означает, что не будет присутствовать никаких заголовков расширения(й).

• Маркер бит (М) должен всегда быть установлен в ноль. Это означает, что нет разрывов в потоке во время сессии. Это ограничение не является основным для целей тестирования.

• Поле CSRC счетчик (CC) должно быть равным нулю. Это означает, что нет записей в CSRC .

• Значение поля SSRC не будет использоваться в приемнике, так что отправитель может присваивать этому полю значение используемое сейчас.

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