Tr 101 290 что это
Программная опция для анализа параметров ETR 101 290 BridgeTech TR 101 290
Стандарт ETSI TR 101 290 описывает порядок измерения параметров сигнала при цифровом вещании. Классификация методов измерений выполнена по степени серьезности последствий, к которым приводят те или иные ошибки и сбои в работе оборудования (ошибки приоритета 1, 2 и 3).
Bridgetech добавила новые эффективные критерии оценки в технический отчет TR 290. В вышеназванном документе детально описаны измерения, проводимые в соответствии со стандартом ETR 290 оборудованием Bridgetech. При этом проведена четкая грань между критериями ETSI и нововведениями, предложенными Bridgetech. По умолчанию дополнительные функции, предлагаемые Bridgetech, отключены и не могут приводить к формированию ошибок.
Оценка параметров сигнала может производиться по таблицам Комитета по перспективным телевизионным системам (ATSC); при этом в качестве шаблона предельных значений ETR 290 для соответствующего канала устанавливается ATSC, а не DVB (Вещание цифрового видео). В принципе, таблицы ATSC соответствуют таблицам DVB приоритета 3; таким образом, критерии ATCS входят в группу приоритета 3 проба, даже если это не предусмотрено ETSI TR 101 290.
Оборудование Bridgetech, выполняющее оценку по стандарту ETR 290, в графическом пользовательском интерфейсе веб-браузера выводит на экран вкладку ETR 290 ETR
Критерии ETR 290
Приоритет 2
Приоритет 3
ETSI TR 101 290 V1.4.1 ETR 290 Руководство по измерениям для MPEG2-TS
Ошибки первого уровня ETR290
Причины: плохие условия приема сигнала, отсутствие сигнала, некорректный транспортный поток, неправильная настройка сети, сбои в оборудовании источника потока
TS sync loss
TS sync loss – потеря синхронизации с транспортным потоком MPEG-2 TS. Согласно стандарту, ISO/IEC 13818-1, раздел G.01, для успешной синхронизации достаточно принять пять последовательных байт синхронизации транспортных пакетов MPEG-2.
Sync byte error
Sync byte error – отсутствие корректного байта синхронизации (0x47). Индикатор «Sync_byte_error» устанавливается при отсутствии корректного байта синхронизации после приема очередных 188 или 204 байт. Установка корректного байта синхронизации после 188 или 204 байт данных обязательна, потому что такая структура используется во всех кодерах и декодерах для синхронизации. Также важно, чтобы каждый синхронизирующий байт был проверен на корректность, поскольку кодеры могут не проверять байты синхронизации. Некоторые кодеры используют сигнал флага байтового синхросигнала на параллельном интерфейсе для управления повторным использованием рандомизатора и инверсии байта, не проверяя, что соответствующий байт является допустимым байтом синхронизации.
PAT error
PAT error – отсутствие таблицы ассоциации программ (Program Association Table). Таблица ассоциации программ (PAT), которая появляется только в пакетах PID 0x0000, сообщает декодеру, какие сервисы находятся в транспортном потоке TS и указывает на таблицу структуры программ (PMT), которая, в свою очередь, указывает на компоненты видео, аудио и потоки данных, составляющие программу. Если PAT отсутствует, декодер ничего не сможет сделать, и программа не может быть декодирована. В PID 0x0000 не должно содержаться ничего кроме PAT.
Continuity count error
Continuity count error – некорректная последовательность пакетов. Неправильный порядок пакетов, повторения или потеря могут вызвать проблемы для IRD, которые не оснащены дополнительным буферным хранилищем и интеллектом.
PMT error
PMT error – отсутствие разделов таблицы структуры программ. Таблица ассоциации программ (PAT) сообщает декодеру, сколько программ есть в потоке и указывает на таблицу структуры программ PMT, которая содержит информацию о компонентах видео, аудио или данных, составляющие программу. В случае отсутствия таблицы PMT в течение 500мс сервис не может быть декодирован.
PID error
Описание: PID error – отсутствие указанного в таблице PMT PID-а в течение указанного периода времени. Эта ошибка может возникнуть при многократном мультиплексировании, демультиплексировании и ремультиплексировании потока.
Ошибки второго уровня ETR290
Причины: плохие условия приема сигнала, неправильная настройка сети, потери пакетов, сбои и неправильная настройка источника потока.
Transport error
Transport error – ошибка появляется если в заголовке транспортного потока Transport_error_indicator равен «1», что происходит в случае детектирования ошибок приема данных.
CRC error
CRC error – проверка CRC для CAT, PAT, PMT, NIT, EIT, BAT, SDT и TOT указывает, повреждено ли содержимое соответствующей таблицы. В этом случае дальнейшая индикация ошибки не должна выводиться из содержимого соответствующей таблицы.
PCR error
PCR error – временная метка PCR используемая для создания локальных системных часов на частоте 27 МГц. Если временные метки PCR не поступают с достаточной регулярностью, то эти часы могут дрожать или дрейфовать. Разрыв PCR более 100мс, происходящий без специального указания, может привести к потере синхронизации приёмником-декодером. Для DVB, значение интервала времени между двумя последовательными PCR не должно превышать 40мс (2020/06 временной интервал между двумя PCR увеличен с 40мс до 100 мс ETSI TR 101 290 V1.4.1 )
PCR accuracy error
PCR accuracy error – точность установки временной метки PCR. Значение должно быть в пределах ± 500нс, чтобы цветовая поднесущая была синтезирована из системных часов.
PTS error
PTS error – временные метки представления (PTS) должны появляться как минимум каждые 700мс. Они доступны только в том случае, если транспортный поток не скремблирован.
CAT error
CAT error – CAT является указателем, позволяющим IRD находить EMM, связанные с системой условного доступа. Если CAT отсутствует, приемник не может получить соответствующие сообщения управления.
Ошибки третьего уровня ETR290
Причины: неправильная настройка сети, потери пакетов, сбои и неправильная настройка источника потока.
NIT error
NIT error – ошибка указывает на отсутствие NIT в транспортном потоке или неправильный PID таблицы NIT. Таблицы информационных сетей (NIT), определенные DVB, содержат информацию о частоте, кодовых скоростях, модуляции, поляризации и т. д. различных программ, которые может использовать декодер.
SI repetition error
SI repetition error – частота повторения таблиц SI выходит за пределы установленного лимита. Для таблиц SI максимальная и минимальная периодичность указана в ETR 211.
Buffer error
Buffer error – по этому показателю проверяется переполнение буферов декодера.
TB_buffering_error переполнение транспортного буфера.
TBsys_buffering_error переполнение транспортного буфера системной информации.
MB_buffering_error переполнение буфера мультиплексирования или если используется метод vbv_delay.
EB_buffering_error переполнение буфера элементарного потока или если используется leak.
B_buffering_error переполнение основного буфера.
Bsys_buffering_error переполнение входного буфера PSI.
Unreferenced PID
Unreferenced_PID – PID-ы не упомянутые PMT в пределах 500мс, (кроме PAT, CAT, CAT_PID, PMT_PID, NIT_PID, SDT_PID, TDT_PID, EIT_PID, RST_PID, или PID, определенные пользователем как частные потоки данных). Каждый поток данных, не относящийся к частной программе, должен иметь свой PID, указанный в PMT.
SDT error
SDT error – разделы с table_id = 0x42 (SDT, фактический TS) отсутствуют в PID 0x0011 более 2000мс. SDT описывает службы, доступные для просмотра. Он разбивается на подтаблицы, содержащие детали содержимого текущего TS (обязательно) и других TS (необязательно). Без SDT IRD не может предоставить зрителю список доступных сервисов. Также возможно передавать BAT с тем же PID, который группирует сервисы в «букеты».
EIT error
EIT error – Разделы с table_id = 0x4E (EIT-P/F, фактический TS) отсутствуют в PID 0x0012 более 2000мс. EIT описывает и детализирует полное расписание программ. Информация о расписании EIT доступна только в том случае, если TS не скремблирован.
RST error
RST error – Разделы с table_id, отличными от 0x71 или 0x72 найденные в PID 0x0013. RST — это механизм быстрого обновления информации состояния, переносимой в EIT.
TDT error
TDT error – Разделы с table_id = 0x70 (TDT) отсутствуют в PID 0x0014 более 30с. TDT содержит текущую информацию о времени и дате UTC. В дополнение к TDT, может передаваться таблица TOT несущая информацию о локальном смещении по времени в данной области.
Empty buffer error
Empty_buffer_error – транспортный буфер или транспортный буфер системной информации не опустошается пуст как минимум один раз в секунду.
Data delay error
Data delay error – Задержка данных через буферы TSTD, превышает 1 секунду
Вам также может понравиться
DVBMonitor – обзор системы мониторинга ТВ программ
Blocking, Blurring, Ringing
StreamXpert – Анализ манифест-файлов OTT
Добавить комментарий Отменить ответ
Вы должны быть авторизованы, чтобы оставить комментарий.
Особенности формирования и измерения PCR в MPEG-сигнале
На рисунке 1 приведена структурная схема формирования транспортного потока MPEG для цифрового компонентного сигнала. При формировании сжатого видеосигнала MPEG кодер в качестве опорного генератора использует эталонный высокоточный генератор с частотой 27 МГц. Такой выбор опорной частоты обусловлен тем, что путем различных операций деления/умножения из него можно легко сформировать полный набор всех опорных сигналов, необходимых для аналоговых и цифровых видеосигналов различных стандартов. На рисунке 3 показано, как из частоты опорного генератора формируются все основные сигналы, необходимые для формирования телевизионных сигналов BT.601/PAL/NTSC.
В случае формирования транспортного потока из входного сигнала PAL/NTSC схема выглядит несколько сложнее (рисунок 2), но в ней также присутствует опорный генератор 27 МГц.
В этом случае его частота формируется из входного сигнала с использованием петли фазовой автоподстройки частоты (ФАПЧ).
В обеих схемах опорный генератор подключается к счетчику, значения которого периодически фиксируются в регистре и включаются в выходной транспортный поток как сигналы временнóй привязки — PCR.
Период и стабильность следования этих меток не являются слишком критическими. Так, в ISO/IEC13818-1 рекомендуется использовать интервал 100 мс, в то время как в DVB ETR154 это значение составляет 40 мс. Следует только заметить, что более высокая частота следования PCR-меток облегчает работу системы ФАПЧ приемника и делает ее более стабильной.
Требования к стабильности опорной частоты 27 МГц значительно более жесткие. Стандарт ISO/IEC13818-1 определяет допуск на значение PCR в ±500 нс, что соответствует отклонению частоты не более ±810 Гц или ±30 x 10-6.
Эти значения были положены в основу технологии измерений параметров PCR, описанной в документе ETR290, хотя в рекомендации четко указано, что это измерение не включает в себя любые нарушения транспорта.
Если полученные значения PCR совпадают с системными часами декодера, часы на обоих концах синхронизированы. Отклонения опорного генератора декодера корректируются с помощью фазовой автоподстройки частоты — ФАПЧ (англ. PLL).
В процессе формирования цифрового потока и доставки его до декодера в сигналы PCR вносятся погрешности, которые приводят к ошибкам декодирования и являются одной из основных причин искажений в выходных видеосигналах MPEG-декодеров. Поэтому вопросы измерения различных параметров качества входящих PCR-сигналов имеют такое важное значение.
37 нс. Далее мультиплексор сигнала вводит значение PCR в поток не в момент записи сигнала PCR, а в момент передачи соответствующего пакета, что также вносит дополнительную ошибку. При добавлении других сервисов также могут появиться дополнительные ошибки, если мультиплексор изменит положение пакета в потоке, содержащем PCR. Все эти ошибки в документе TR 101 290 получили название PCR_AC.
PCR accuracy (PCR_AC) включает в себя все ошибки опорной частоты 27 МГц, связанные с процессом формирования транспортного потока, но не включает дополнительные ошибки, связанные с транспортом, добавляющиеся при передаче и промежуточных преобразованиях.
Проблемы PCR проявляются в первую очередь в появлении артефактов на выходе MPEG-декодера или потере цветности на PAL/NTSC-изображении. Проблемы джиттера могут возникнуть при повторном мультиплексировании транспортного потока. Причина в том, что, например, меняется порядок следования пакетов транспортного потока без соответствующего изменения значения PCR.
Иногда джиттер PCR может значительно превышать допустимые значения ± 500 ns и не все декодеры могут это отработать. Информация PCR передается в поле адаптации пакета транспортного потока, принадлежащего к соответствующей программе. Информация о типе пакетов TS находится в соответствующей РМТ. Таблица PMT содержит так называемый PCR_PID, чаще всего для этой цели используют PID видео. Этот PID нельзя удалять из потока, так как без него будет невозможно декодирование сервисов.
В приемнике PCR извлекаются из транспортного потока и значения отсчетов сравниваются с аналогичными отсчетами от локального генератора 27 МГц. Разница между полученными значениями PCR и значениями, генерируемыми локальным счетчиком, используется для управления ФАПЧ декодера (Phase Locked Loop).
Система ФАПЧ имеет ограничения по своим возможностям. Так, она может обеспечивать синхронизацию только в ограниченном диапазоне частот, но и это применимо только к медленным изменениям частоты. Для быстрых изменений частоты этот диапазон существенно сужается.
При выборе параметров системы ФАПЧ перед разработчиками стоит сложная задача выбора: если сделать петлю ФАПЧ инерционной, то это обеспечит высокую стабильность локального генератора, но полоса захвата и удержания такой петли получается невысокой. Если сделать постоянную времени петли малой («быстрая» ФАПЧ), то такая ФАПЧ способна захватить и удержать входной поток даже со значительным джиттером, но частота локального генератора при этом получается нестабильной.
Именно разница в настройке петли ФАПЧ является причиной того, что разные приемники по-разному принимают один и тот же поток при наличии в нем ошибок PCR. Некоторые устройства, такие как абонентские телевизоры и STB, в состоянии синхронизироваться, другие устройства, такие как профессиональные декодеры, не могут. В результате система теряет синхронизацию и просмотр ТВ-программы становится невозможным.
Таким образом, система ФАПЧ, обеспечивая синхронную работу опорных генераторов в передатчике и приемнике, дает возможность декодирования цифрового сигнала.
Однако, как отмечалось ранее, в процессе передачи цифрового сигнала по транспортным сетям генерируются дополнительные ошибки PCR, связанные с различиями во времени доставки пакетов (jitter) или даже с изменением порядка следования пакетов.
Ремультиплексоры, вставляя или удаляя некоторые потоки из сервисов, меняют положение пакетов, содержащих метки PCR, что приводит к дополнительным ошибкам PCR. Чтобы уменьшить такие ошибки, профессиональные мультиплексоры рассчитывают величину сдвига пакетов с PCR в транспортном потоке и корректируют содержащиеся в них значения PCR (PCR restamping). Но ошибки полностью не устраняются. Накопление таких ошибок может вызвать проблемы в цепи устройств на последующих этапах.
• PCR drift rate (PCR_DR) — ошибки, вызванные медленными изменениями PCR, связанными с вариациями параметров среды передачи (drift).
• PCR overall jitter (PCR_OJ) — ошибки, вызванные быстрыми изменениями PCR, связанными с вариациями параметров среды передачи (jitter).
• PCR frequency offset (PCR_FO) — смещение опорной частоты по отношению к эталонной частоте 27 МГц.
Можно заметить, что значения PCR_DR и PCR_OJ отражают влияние вариации параметров среды передачи и различаются только диапазоном частот. По рекомендациям DVB MG, вариации с частотами ниже 0,01 Гц относятся к PCR_DR, а выше — к PCR_OJ.
С практической точки зрения ошибки PCR_DR и PCR_FO могут быть относительно легко скорректированы системой ФАПЧ приемника, в то время как ошибки PCR_OJ являются более критичными.
Более сложной получается картина в том случае, когда принимаемый цифровой MPEG-поток преобразуется в сигналы аналогового стандарта PAL/SECAM/NTSC.
Можно заметить, что требования к стабильности цветовых поднесущих стандарта SECAM существенно ниже, чем требования MPEG. Поэтому при использовании этого стандарта цветности вышеописанная ситуация практически не встречается.
На структурных схемах (рис. 1 и 2) видно, что, кроме опорного генератора MPEG-потока, в формирователях присутствует опорный генератор выходного битрейта. Это независимые генераторы. Причем генератор битрейта единый для всего транспортного потока и обеспечивает синхронизацию приемника/передатчика сети передачи. Его нестабильность также может влиять на ошибки PCR. Однако практически во всех системах передачи используется буферизация входного потока, когда нестабильный входной поток сначала загружается в буфер, а затем выдается в MPEG-декодер с равномерной скоростью с использованием вспомогательного стабильного опорного генератора. Это устраняет ошибки PCR, связанные с нестабильностью битрейта (например, от IP jitter), если они находятся в диапазоне буферизации потока.
Сложнее, если MPEG-поток содержит несколько программ. В этом случае он может формироваться как поток, содержащий единый PCR для всех программ (SPTS). Но чаще каждая программа имеет свой собственный PCR (MPTS). В этом случае документ ETSI TS 102 034 накладывает ограничения на передачу таких транспортных потоков через IP-сети. Так, SPTS-поток может передаваться как в режиме VBR, так и в режиме CBR, но при передаче MPTS-потоков, содержащих несколько PCR, передавать их допускается только в CBR-режиме.
Заключение
Единственные измерения, которые могут выявить нарушения транспорта, облегчая тем самым выявление и устранение неисправностей, — это PCR_DR и PCR_OJ.
В случае использования MPEG-сигнала для преобразования программ в аналоговый формат требования к стабильности PCR должны быть значительно ужесточены либо можно рекомендовать использование системы цветности SECAM.
Для передачи по IP-сетям SPTS-сигналов можно использовать CBR- или VBR-режим передачи, для MPTS-сигналов — только CBR.
Использованная литература и полезные ссылки:
Guide to PCR Measurements, document number 25W-14617-0, Tektronix.
A Layman’s Guide to PCR Measurements, Tektronix, Technical Brief
Walter Fischer. Digital Video and Audio Broadcasting Technology. A Practical Engineering Guide. Second Edition.
ETSI TS 102 034 V1.5.1 (2014-05) Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks»
International Standard ISO/IEC13818-1 MPEG Systems
ETSI Technical Report ETR290 — Measurement Guidelines for DVB Systems — May ‘97
Draft ETSI Technical Report TR 101 290 — Measurement Guidelines for DVB Systems
A Guide to MPEG Fundamentals and Protocol Analysis – document number 25W-11418-3
Подпишитесь на канал «Телеcпутника» в Telegram: перейдите по инвайт-ссылке или в поисковой строке мессенджера введите @telesputnik, затем выберите канал «ТелеСпутник» и нажмите кнопку +Join внизу экрана.
Программная опция для анализа параметров ETR 101 290 BridgeTech TR 101 290
Программная опция для анализа параметров ETR 101 290
Добавить в корзину В корзину
Стандарт ETSI TR 101 290 описывает порядок измерения параметров сигнала при цифровом вещании. Классификация методов измерений выполнена по степени серьезности последствий, к которым приводят те или иные ошибки и сбои в работе оборудования (ошибки приоритета 1, 2 и 3).
Bridgetech добавила новые эффективные критерии оценки в технический отчет TR 290. В вышеназванном документе детально описаны измерения, проводимые в соответствии со стандартом ETR 290 оборудованием Bridgetech. При этом проведена четкая грань между критериями ETSI и нововведениями, предложенными Bridgetech. По умолчанию дополнительные функции, предлагаемые Bridgetech, отключены и не могут приводить к формированию ошибок.
Оценка параметров сигнала может производиться по таблицам Комитета по перспективным телевизионным системам (ATSC); при этом в качестве шаблона предельных значений ETR 290 для соответствующего канала устанавливается ATSC, а не DVB (Вещание цифрового видео). В принципе, таблицы ATSC соответствуют таблицам DVB приоритета 3; таким образом, критерии ATCS входят в группу приоритета 3 проба, даже если это не предусмотрено ETSI TR 101 290.
Оборудование Bridgetech, выполняющее оценку по стандарту ETR 290, в графическом пользовательском интерфейсе веб-браузера выводит на экран вкладку ETR 290 ETR
Критерии ETR 290
Приоритет 2
Приоритет 3
Важнейшие параметры QoS для определения ошибок вещания
Сохранение лояльности абонентской базы — главный вызов, с которым сегодня сталкиваются операторы. Стабильно высокое качество вещания — один из ключевых факторов успеха. Чтобы поддерживать качество на высоком уровне и находить ошибки в потоке, операторы используют системы мониторинга.
Все отслеживаемые параметры делятся на два типа: одни относятся к качеству обслуживания (Quality of Service — QoS), другие — к качеству восприятия (Quality of Experience — QoE). В этой статье поговорим об основных параметрах QoS.
Отсутствие сигнала — самый критичный параметр, который относится к «красному» состоянию доставки. Такое событие возникает, когда система мониторинга по какой-либо причине не может получить данные для анализа. Чтобы решить эту проблему, необходимо выяснить её причину и быстро определить место её возникновения: сторона контент-провайдера, оборудование или сеть. Для этого потребуется несколько анализаторов или распределенная система мониторинга с несколькими клиентами (зондами).
Для IP вещания в первую очередь необходимо отслеживать два параметра: потеря пакетов и джиттер.
Если пакеты не теряются и гладко проходят всю цепочку доставки, то качество сигнала можно считать высоким. Если возникает потеря пакетов или джиттер превышает пороговые значения, проблемы с доставкой становятся очевидными для пользователей. Поэтому эти два параметра являются важнейшими для обеспечения высокого качества обслуживания. Потерю пакетов можно оценить, проверив счетчик непрерывности (Continuity Counter), встроенный в заголовок TS.
Ошибки Continuity Counter (CC) возникают, если обнаружен некорректный порядок пакетов, если один пакет повторяется более двух раз, или если пакет потерян.
Media Loss Rate (MLR) — метрика, позволяющая детально оценить потери пакетов. Показывает количество потерянных транспортных пакетов в секунду.
Inter-packet Arrival Time (IAT) — значение времени между приходящими пакетами, зафиксированное за одну секунду измерений. Максимальное значение IAT является мерой джиттера. Джиттер определяется как сравнение временных интервалов между приходящими пакетами.
Коэффициент задержки (Delay Factor) — еще один из наиболее значимых параметров мониторинга. Это временное значение, показывающее сколько миллисекунд данных должны содержать буферы, чтобы устранить временные искажения (джиттер). Как индикатор качества при мониторинге сети доставки вещания видеосервисов, чувствительной к джиттеру и потере данных, может быть использован индекс MDI (Media Delivery Index — DF:MLR).
Чтобы обеспечить полный мониторинг качества обслуживания, помимо основных метрик, перечисленных выше, необходимо контролировать и другие параметры.
Несколько источников вещания. Когда несколько источников мультикаст вещания начинают передавать данные в одной группе, могут возникать различные ошибки.
TR 101 290 — стандарт, описывающий порядок измерений для спутниковых, кабельных, эфирных цифровых телевизионных систем. Стандарт содержит пороговые значения для событий, однако для IPTV-потоков строгое соответствие требованиям стандарта не требуется. Анализ TR 101 290 применяется как для IPTV, так и для нешифрованных OTT-сервисов (или для тех, которые могут быть дешифрованы), основанных на технологии фрагментированного транспортного потока. При ошибках TR 101 290 возникают такие дефекты изображения как пикселизация, шумы, замирания аудио и видео, черный экран и другие.
Итак, это важнейшие ошибки QoS, которые важно отслеживать с помощью системы мониторинга.
Для иллюстраций была использована система мониторинга Elecard Boro.