Pcr repetition error ошибка опорного времени - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

Тема: PCR (Прочитано 10137 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Коллеги, подскажите куда лезть; на одном транспорте появились ошибки PCR, а именно: ошибка точности PCR, ошибка непрерывности PCR, ошибка повторения PCR.
Мультиплексор PBI DMM 1400mx.
Анализатор Планар CIU-003.

« Последнее редактирование: 22.12.2015, 15:42 от qwerty »

Записан

они реально могут к Вам лететб с борта,
pcr может быбиваться даже после КАМ модуля
потом транспорт, мултикастий занятная штука,
прям любит дорогие коммутаторы ,
а самое главное админа который его настроит !!!!
а там настраивать можно много

Записан

ID15 EMR 3.0 _515_544_545_525_51 0_350_508-8_518_471_472_101_201 / T2-MI C404D / EMR 3.0+ _C132 / VB-120 _QAM_SAT_IP _ASI / DGS-6600-48S / IP — PAL ROTON / CAS CTI / EPG CTI

Мультиплексор не может вносить ошибки PCR ?

Записан

ну в практике пару единиц возможно,
то есть если у Вас с приема 36 или 37
после КАМа 38 или 39
после коммутатора уже 40 ,
а потом уже и первая ошибка

Записан

ID15 EMR 3.0 _515_544_545_525_51 0_350_508-8_518_471_472_101_201 / T2-MI C404D / EMR 3.0+ _C132 / VB-120 _QAM_SAT_IP _ASI / DGS-6600-48S / IP — PAL ROTON / CAS CTI / EPG CTI

Записан

важность имеют имено 40
остальные тоже «плохие»
но 40 самая не хорошая

Записан

ID15 EMR 3.0 _515_544_545_525_51 0_350_508-8_518_471_472_101_201 / T2-MI C404D / EMR 3.0+ _C132 / VB-120 _QAM_SAT_IP _ASI / DGS-6600-48S / IP — PAL ROTON / CAS CTI / EPG CTI

Спрошу ещё, как проявляются данные ошибки на ТВ приёмниках. На своём Сони ничего не вижу.

Записан

PCR метки времени по рек DVB разброс допустимый до _+1500мкс
возникает в любых устройствах перетасовывания пакетов — в правильных устройствах после всего этого безобразия выполняется PCR restamping ( иногда называют коррекция)

на приемной стороне это зависит от «экономичности» проектировщиков девайса
принимать поток в котором гуляет PCR в пределах рекоменд _+1500 сильно подороже чем отслеживать _+500

Записан

квалификация это способность определять достаточно малые изменения в ситуации

Что посоветуете в данном случае, забить на ошибки или как ?

Анализатор настроен на: ошибка точности PCR +-500 нс.

Записан

ну Вы же не анализатор «удовлетворяете» а видимо проблему возникшую у реального абонентига?

а если просто ради темы улучшайзинга — тогда ставьте на поток какой нить девайс у которого в спецификации прописано о PCR correct или restamp
много лет назад ( 9 лет) у меня были проблемы на приёме на некоторые китайские ресиверы из за PCR
эпоха ещё мп2 и MMDS ……. не хавали они разнос описаный в рек DVB +-1500

Записан

квалификация это способность определять достаточно малые изменения в ситуации

Источник

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Closed

angusbell opened this issue

Oct 14, 2015

· 10 comments

Closed

PCR interval errors

#284

angusbell opened this issue

Oct 14, 2015

· 10 comments

Comments

We generated transport streams using MP42TS and when we analysed them, we found PCR interval errors. This is where the interval between successive PCRs is greater than 40ms. This is a problem for us as we need to be DVB-compliant; the relevant requirement is test no 2.3a «PCR_repetition_error» in ETSI TR 101 290 v1.2.1.

The tool has an option -pcr-ms which allows you to define the max interval — but even when set to 5 ms, the generated transport stream still has intervals of more than 40ms between PCRs. In the end we found a solution that worked: if we also specify the -single-au option, then the PCR interval is fixed.

Is this what you would expect, or is it a bug?

the -pcr-ms allows adjusting the pcr interval, however due to a limitation in the code PCR insertion is only performed at start of the frame. When packing two frames together in a single PES no PCR insertion is done for the second frame.

We will try to add more frequent PCR insertion but that’s not on the high priority

jeanlf

pushed a commit
that referenced
this issue

Nov 9, 2015

This should now be fixed on git, using -force-pcr-only flag, could you give it a try ?

I tried the -force-pcr-only flag and found two problems:

There are lots of continuity counter errors on pid 111 carrying the video and PCR).
The PTS values in the video are about 2147 seconds out of sync with (i.e. behind) the PCR: so for one sample, the PCR value is 00:36:33.309 (in hh:mm:ss.ms) whereas the PTS in the video is 00:00:46.118, a difference of approx 36 mins.

hmm that’s strange, do you have a test MP4 source (and command line used) to reproduce the issue ? I don’t have this bug (checking through a DVB analyser)

hi jeanlf, I can make the source available to you if you email me at AngusBell@eurofins.com. this would not be for redistribution and would be for debugging purposes only.

I realised there was a problem with the bitrate that I was specifying on the command line. When I fixed this, it solved the disparity between PTS and PCR.

However, I can still reproduce the continuity count errors. I think it is because I am specifying options «-force-pcr-only» and «-pcr-ms 30» when the video is 25fps and therefore only repeats every 40ms. I presume the multiplexer is adding PCR-only packets on the video pid, which is causing the continuity counter to get out of sync on that pid.

Do you still need an example stream?

are you sure about your conformance checker? PCR-only packets use TS packets with only adaptation fields (no payload), for which continuity counters shall not be incremented

we use DVB Analyser by DVBControl. yes i see what you mean about non-incrementing conditions. it was just my guess that that was the problem. we would normally expect DVB Analyser to be correct; it sounds like you might also use it from one your comments above?

yes that’s the one I use, version 1.1.667, and I don’t have any error thrown. What exact command line do you use?

MP42TS -src audio.mp4:ID=1:name=DTVL1:provider=DigitalTVLabs -src video.mp4:ID=1:name=DTVL1:provider=DigitalTVLabs -temi -pcr-init 0 -pcr-ms 40 -pcr-offset 25000 -rate 4000 -single-au -sdt-rate 1000 -dst-file out.ts

canatella

pushed a commit
to canatella/gpac
that referenced
this issue

Dec 15, 2015

Источник

Транспортный
пакет стандарта MPEG-2
имеет постоянную длину, равную 188 байтам,
заголовок пакета имеет переменную
длину. Как показано на рисунке 8.8, в
состав заголовка транспортного пакета
входит канальный заголовок, имеющий
фиксированную длину 4 байта и поле данных
адаптации (выполняет функцию транспортного
заголовка).

Рисунок
8.8 – формат транспортного пакета

В
общем случае транспортные пакеты могут
формироваться различными путями:
объединением потоков ES,
PES-пакетов
и других TS-пакетов.
Для многопрограммного вещания транспортные
потоки отдельных программ асинхронно
объединяются в мультиплекс, подлежащий
передаче по каналу.

Транспортный
пакет имеет сложную многоуровневую
структуру, показанную на рисунке 8.9.

Канальный
заголовок имеет следующие поля.

Первый
байт заголовка – байт синхронизации
(sync_byte)
– фиксированное
поле длиной 8 бит, имеющее значение
0100 0111 (0x47), легко опознаваемое
демультиплексором. Так как заголовки
транспортных пакетов следуют с интервалом
в 188 байт, то это упрощает определение
начала пакета.

Рисунок
8.9 – структура заголовка и поля адаптации
транспортного пакета

Индикатор
ошибки транспортировки
(transport_error_indicator)
—
флаг
длиной 1 бит. Будучи установленным в 1,
он указывает на то, что в соответствующем
пакете транспортного потока имеется,
по крайней мере,
одна
неисправимая ошибка в битах. Этот бит
может быть установлен в 1 объектами,
внешними по отношению к транспортному
уровню. Будучи установленным в 1, этот
бит не должен быть сброшен в 0, пока не
будут исправлены значения битов, имеющих
ошибки;

Индикатор
ошибки транспортировки
(payload_unit_start_indicator)
—
флаг
длиной 1 бит, который имеет нормативное
значение для пакетов транспортного
потока, переносящих PES-пакеты
или данные сервисной информации SI.

Когда
полезная нагрузка пакета транспортного
потока содержит данные PES-пакета,
то payload_unit_start_indicator
имеет следующий смысл: 1 указывает на
то, что полезная нагрузка этого пакета
транспортного потока начнется с
первым байтом PES-пакета,
а 0 — на то, что в этом пакете транспортного
потока не может быть начала PES-пакета.

Когда
полезная нагрузка пакета транспортного
потока содержит данные сервисной
информации SI,
payload_unit_start_indicator
имеет следующий смысл: если пакет
транспортного потока содержит первый
байт секции SI,
то значение payload_unit_start_indicator
должно быть 1, указывая на то, что первый
байт полезной нагрузки этого пакета
транспортного потока содержит поле
указателя pointer_field.
Если пакет транспортного потока не
содержит первого байта секции SI,
то значение payload_unit_start_indicator
должно быть 0, указывая на то, что в
полезной нагрузке нет поля указателя
pointer_field.

Для
пустых пакетов payload_unit_start_indicator
должен быть установлен в 0.

Значение
этого бита для пакетов транспортного
потока, переносящих только частные
данные в стандарте MPEG-2,
не определено.

Приоритет
транспортировки
(transport_priority)
—
индикатор
длиной 1 бит. Будучи установленным в 1
он указывает на то, что связанный с ним
пакет имеет больший приоритет, чем
другие пакеты, имеющие тот же самый
индикатор PID,
но в которых этот бит не установлен в
1. Транспортный механизм может использовать
этот индикатор для расположения по
приоритетам всех данных в пределах
элементарного потока. В
зависимости от применения поле
transport_priority
может быть кодировано независимо от
PID
или только для одного PID.
Это
поле
может быть изменено кодерами или
декодерами для специфических каналов.

PID:
идентификатор
пакета
—
поле длиной 13 бит, указывающее тип
данных, содержащихся в полезной нагрузке
пакета. PID
служит основным признаком, по которому
демультиплексор сортирует приходящие
PES-пакеты
на приемной стороне. Из общего числа
8192 возможных значений PID
16 выделены на общесистемные цели, номер
8191 закреплен за стаффингом байтами,
остальные могут назначаться пользователем
произвольно для отдельных компанент
своихпрограмм. Значение PID
0x0000 зарезервировано для таблицы
взаимосвязи программ PAT.
Значение PID
0x0001 зарезервировано для таблицы
ограниченного доступа CAT.
Значения идентификатора PID
от 0x0002 до 0x000F
являются зарезервированными. Значение
PID
0xlFFF
сохранено для пустых пакетов. Значения
идентификатора PID
приведены в таблице 8.1.

Таблица
8.1 – значения PID

Значение	Описание
0х0000	Таблица взаимосвязи программ PAT
0х0001	Таблица условного доступа CAT
0х0002 …0х000F	Зарезервированы
0х0010…0x1FFE	Может быть присвоено сетевому идентификатору networkPID, идентификатору структуры программы Program_map_PID. идентификатору элементарного потока elementary_PID или для других целей
0х1FFF	Нулевой пакет
Примечание: транспортные пакеты с PID 0х0000, 0х0001 и 0х0010…0х1FFE предназначены для переноса PCR

transport_scrairibling_control
— поле длиной 2 бита указывает режим
скремблирования полезной нагрузки
пакета транспортного потока. Заголовок
пакета транспортного потока и поле
адаптации, когда таковое присутствует,
не должны скремблироваться. В случае
пустого пакета значение поля
transportscrambling
control
должно быть установлено в 00 (таблица
8.2).

Таблица
8.2 – Значения поля управления
скремблироваеия

Значение	Описание
00	Без скремблирования
01	Определяется пользователем
10	Определяется пользователем
11	Определяется пользователем

adaptation_field_control:
управление
полем адаптации —
поле длиной 2 бита указывает, следует
ли поле адаптации и/или полезная нагрузка
за этим заголовком пакета транспортного
потока (таблица 8.3).

Таблица
8.3 – Значения поля адаптации

Значение	Описание
00	Зарезервирован для будущего использования ISO/IEC
01	Поле адаптации отсутствует, только полезная нагрузка
10	Только поле адаптации, полезная нагрузка отсутствует
11	Поле адаптации расположено за полезной нагрузкой

Декодеры,
определенные в Стандарте ISO/IEC
13818-1, должны отказаться от декодирования
пакетов транспортного потока с полем
adaptation_field_control,
установленным в 00. В случае пустого
пакета значение поля adaptation_field_control
должно быть установлено в 01.

continuity_counter:
счетчик
непрерывности —
поле длиной 4 бита. Четырехбитовый
счетчик непрерывности PES-пакетов
увеличивает свое значение на единицу
при поступлении каждого следующего
PES-пакета
с данными PID
и обнуляется после каждого 15-20 пакета.
Он позволяет декодеру обнаруживать
потерю PES-пакета
и принимать меры по его замене или
маскированию ошибок, которые могут
возникнуть из-за его потери.

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

Поле
адаптации, содержит следующие основные
поля:

adaptation_field_lenght
– длина поля адаптации, поле с 8 битами,
определяющее количество байтов в области
поля адаптации, следующей сразу за
adaptation_field_lenght
. Для пакетов Транспортного потока,
несущих PES-пакеты, наполнение необходимо,
когда PES-пакеты
имеют длину, недостаточную для заполнения
полезной нагрузки пакета Транспортного
потока. Заполнение поля адаптации
выполняется таким образом, чтобы
суммарная длина его данных и байтов
полезной нагрузки, следующих за ним,
точно уместились в доступную длину
PES-пакета.
Дополнительное место в поле адаптации
заполняется байтами наполнения. Для
пакетов Транспортного
потока, несущих PSI,
метод заполнения будет рассмотрен в
разделе 8.6.

Неоднородность
синхронизации системы обозначена при
помощи индикатора discontinuity_indicator
в пакетах Транспортного потока с PID,
определенным как PCR_PID
. Когда состояние неоднородности истинно
для пакета Транспортного потока с PID,
обозначенным как PCR_PID,
следующая PCR в пакете Транспортного
потока с тем же самым PID представляет
отсчет новой синхронизации системы для
данной программы. Когда discontinuity_indicator
установлен в «0, состояние неоднородности
ложно.

elementary_stream_priority_indicator
— индикатор приоритета элементарного
потока является полем с 1 битом. Оно
указывает приоритет данных элементарных
потоков среди пакетов с одинаковым PID,
которые расположены в пределах полезной
нагрузки данного пакета Транспортного
потока. «1» указывает, что полезная
нагрузка имеет более высокий приоритет,
чем полезные нагрузки других пакетов.
В случае видео, это поле может быть
установлено только в «1», если полезная
нагрузка содержит один или более байтов
I-кодированного
слоя.

Затем
идут пять флагов укзывающие на присутствие
или отсутствие тех или иных необязательных
полей в поле адаптации.

PCR_flag
— флаг с 1 битом. Значение «1» указывает,
что область адаптации содержит поле
PCR из двух частей. Значение «0» указывает,
что поле адаптации не содержит поля
PCR. program_clock_reference (PCR) — поле с 42 битами. PCR
— отсчеты программного времени, являются
средством синхронизации программы (PCR
будет рассмотрено в 3.4);

OPCR_flag
– 1-битный флаг. Значение «1» указывает,
что область адаптации содержит поле
OPCR, которое кодируется в двух частях.
Значение «0» указывает, что поле адаптации
не содержит поля OPCR.
original_program_clock_reference_base
– необязательная ссылка оригинала
программы (OPCR) — поле с 42 битами. Поля
OPCR разрешены в однопрограммных и
многопрограммных Транспортных потоках.
OPCR помогает отличить однопрограммный
Транспортный поток от других
Транспортных
потоков. При восстановлении первоначального
однопрограммного Транспортного потока,
OPCR может быть скопирован в поле PCR.
Окончательное значение PCR имеет силу,
если первоначальный однопрограммный
Транспортный поток восстановлен точно
во всей полноте. Он должен включать по
крайней мере любую PSI
и пакеты частных данных, которые
присутствовали в первоначальном
Транспортном потоке; возможно, потребуются
и другие меры. Это также означает, что
OPCR должен быть копией связанного с ним
PCR в первоначальном однопрограммном
Транспортном потоке;

transport_private_data_flag
– 1-битный
флаг.
Значение
«1» указывает, что поле адаптации содержит
один или большее количество байтов
private_data. Значение «0» указывает, что поле
адаптации не содержит байтов с частным
данными. transport_private_data_length — поле с 8 битами,
определяющее количество байтов
private_data, следующих непосредственно за
полем private_data_length. Количество байтов не
должно быть таким, чтобы частные данные
простирались за пределы поля адаптации;

adaptation_field_extension_flag
– 1-битное поле, которое указывает
присутствие расширения поля адаптации
при значении «1». Значение «0» указывает,
что расширения поля адаптации нет в
данном поле адаптации.
adaptation_field_extension_length
— поле с 8 битами. Указывает количество
байтов расширенных данных поля адаптации,
следующих непосредственно за этим
полем, включая зарезервированные байты,
если они есть. В расширенные данные поля
адаптации вводится доплнительная
информация, используемая декодером при
декодировании.

Источник

The main question is what the time for PCR error in DVB streaming ?

I am asking it because according to DVB standards (see additional information)
PCR error retention period > 100 ms.
But there is a lot of hardware which is logging PCR errors with PCR ~50 ms.

Aditional information

You can skip it, if you already know the answer, this information presents just as additional info about standards that I was found

ETSI TR 101 290 V1.2.1 (2001-05) — aka true DVB
http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr_101290v010201p.pdf

A PCR _accuracy_error occurs when a transmitted PCR value differs from what is expected by more >than 500 nanoseconds. The expected PCR value is calculated using an extremely stable internal clock >n the test device and previous PCR values. The calculated PCR is then compared to the transmitted >PCR values to check for accuracy. It is important to note that most receivers do not contain very >accurate clocks and therefore can be severely affected by this error.

ETSI TS 101 154 V1.9.1 (2009-09)
http://www.etsi.org/deliver/etsi_ts/101100_101199/101154/01.09.01_60/ts_101154v010901p.pdf

Program Clock Reference (PCR)
Encoding: The time interval between two consecutive PCR values of the same program shall not >exceed
100 ms as specified in clause 2.7.2 of ITU-T Recommendation H.222.0 / ISO/IEC 13818-1 [1].
Decoding: The IRD shall operate correctly with PCRs for a program arriving at intervals not exceeding
100 ms

ISO/IEC 13818-1 (Information technology — Generic coding
of moving pictures and associated audio
information: Systems)
https://forums.xilinx.com/xlnx/attachments/xlnx/DSPTOOL/15095/1/iso13818-1.pdf

Thank you.

Источник

Добавлено 20 сентября 2017 в 18:30

Одной из важнейших задач при формировании, приеме и распространении цифровых телевизионных MPEG-потоков является обеспечение временной синхронизации сигналов. Этой цели служит вставка в цифровой поток специальных временных меток Program Clock Reference — PCR. Описанию того, что это за метки, как они влияют на работу цифровых устройств, методам измерений и диагностики посвящена эта статья. Основной материал для нее базируется на результатах исследований фирмы Tektronix, которые были использованы с любезного разрешения ее московского представительства.

Прием и ретрансляция сигналов цифрового телевидения требуют восстановления всех временных интервалов, использованных при формировании исходного сигнала. В ряде случаев восстановление принятых потоков может быть проблематичным в результате флуктуаций сигналов синхронизации. Далее кратко описываются принципы формирования сигналов синхронизации и измерений их флуктуаций

На рисунке 1 приведена структурная схема формирования транспортного потока MPEG для цифрового компонентного сигнала. При формировании сжатого видеосигнала MPEG кодер в качестве опорного генератора использует эталонный высокоточный генератор с частотой 27 МГц. Такой выбор опорной частоты обусловлен тем, что путем различных операций деления/ умножения из него можно легко сформировать полный набор всех опорных сигналов, необходимых для аналоговых и цифровых видеосигналов различных стандартов. На рисунке 3 показано, как из частоты опорного генератора формируются все основные сигналы, необходимые для формирования телевизионных сигналов BT.601/PAL/NTSC.

Рисунок 1 – Формирование транспортного потока MPEG

В случае формирования транспортного потока из входного сигнала PAL/NTSC схема выглядит несколько сложнее (рисунок 2), но в ней также присутствует опорный генератор 27 МГц. В этом случае его частота формируется из входного сигнала с использованием петли фазовой автоподстройки частоты (ФАПЧ).

Рисунок 2 – Формирование транспортного потока из входного сигнала PAL/NTSC

В обеих схемах опорный генератор подключается к счетчику, значения которого периодически фиксируются в регистре и включаются в выходной транспортный поток как сигналы временнóй привязки — PCR.

Период и стабильность следования этих меток не являются слишком критическими. Так, в ISO/IEC13818-1 рекомендуется использовать интервал 100 мс, в то время как в DVB ETR154 это значение составляет 40 мс. Следует только заметить, что более высокая частота следования PCR-меток облегчает работу системы ФАПЧ приемника и делает ее более стабильной.

Требования к стабильности опорной частоты 27 МГц значительно более жесткие. Стандарт ISO/IEC13818-1 определяет допуск на значение PCR в ±500 нс, что соответствует отклонению частоты не более ±810 Гц или ±30 x 10^-6.

Эти значения были положены в основу технологии измерений параметров PCR, описанной в документе ETR290, хотя в рекомендации четко указано, что это измерение не включает в себя любые нарушения транспорта.

Рисунок 3 – Формирование импульсов из опорной частоты

Сигналы PCR в составе цифрового потока проходят весь путь распространения цифрового сигнала и дают цифровому ТВ-приемнику возможность синхронизации декодированного выходного видео c исходным видео на входе кодера. Приемник, то есть MPEG-декодер, для правильного функционирования должен считывать значения PCR, сравнивать их с собственными внутренними системными часами

Если полученные значения PCR совпадают с системными часами декодера, часы на обоих концах синхронизированы. Отклонения опорного генератора декодера корректируются с помощью фазовой автоподстройки частоты — ФАПЧ (англ. PLL).

В процессе формирования цифрового потока и доставки его до декодера в сигналы PCR вносятся погрешности, которые приводят к ошибкам декодирования и являются одной из основных причин искажений в выходных видеосигналах MPEG-декодеров. Поэтому вопросы измерения различных параметров качества входящих PCR-сигналов имеют такое важное значение.

Точность формирования 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_AC. Учет ошибок, связанных с транспортом сигналов, потребовал доработки документов ETR290 и TR 101 290. Были добавлены еще три измеряемых параметра:

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.

Рисунок 4 – Прием и декодирование MPEG TS

Здесь, как и во многих подобных преобразователях, для формирования всех необходимых опорных частот используется общий опорный генератор 27 МГц (см. рисунки 3 и 4). В таблице 1 приведены требования к стабильности опорных частот для различных систем цветного телевидения. Из этой таблицы видно, что для систем PAL/NTSC эти требования существенно выше, чем требования к опорной частоте цифрового MPEG-декодера. Поэтому при преобразовании MPEG=>PAL/NTSC встречаются ситуации, когда при нормальном функционировании MPEG-декодера выходной сигнал PAL/NTSC формируется со сбоями. Чаще всего это проявляется в виде потери цветности. Исправить данную ситуацию можно ужесточением требований к ошибкам PCR или отключением опорного генератора PAL/NTSC от генератора MPEG-декодера и функционированием его в автономном режиме. Однако это требует поддержки от разработчиков оборудования.

Таблица 1. Допустимые погрешности установки частоты опорного генератора в зависимости от системы цветного телевидения

	NTSC (SMPTE)	PAL (ITU-R-1-624)	SECAM (ITU-R-1-624)
Погрешность поднесущей цвета	3 • 10^-6	0,23 • 10^-6 (для I); 1 • 10^-6 (для B/G)	400 • 10^-6
Скорость дрейфа	0,1 Гц/с	0,1 Гц/с (для I)
Нестабильность строчной синхронизации	1,0 нс	2,5 нс (среднее за одно поле)	32 нс (по I-624); 2,5 нс (по Rc.711)

Можно заметить, что требования к стабильности цветовых поднесущих стандарта 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-режиме.

Заключение

Для обеспечения надежной работы сети распространения цифровых MPEG-сигналов выполнение требований по допуску на сигналы PCR в ±500 нс является недостаточным, необходимо проводить измерения параметров PCR по 4 параметрам:

PCR_AC;
PCR_DR;
PCR_OJ;
PCR_FO.

Единственные измерения, которые могут выявить нарушения транспорта, облегчая тем самым выявление и устранение неисправностей, — это PCR_DR и PCR_OJ.

В случае использования MPEG-сигнала для преобразования программ в аналоговый формат требования к стабильности PCR должны быть значительно ужесточены либо можно рекомендовать использование системы цветности SECAM.

Для передачи по IP-сетям SPTS-сигналов можно использовать CBR или VBR режим передачи, для MPTS-сигналов — только CBR.

К сожалению, ограниченный объем статьи позволил дать только краткий обзор вопросов, связанных с проблемами PCR. Те, кого заинтересовал данный материал, могут найти более подробную информацию в первоисточниках, ссылки на которые приведены в конце статьи.

Использованная литература и полезные ссылки:

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 ETSITechnical ReportTR 101 290 — Measurement Guidelines for DVB Systems;
A Guide to MPEG Fundamentals and Protocol Analysis – document number 25W- 11418-3.

Функция Monitor (монитор) позволяет пассивно контролировать и анализировать многоадресные каналы IPTV, которые принимаются на порту 2000 10/100 LAN устройства DataScout 1G. Если в вашем сегменте сети потоки IPTV передаются на каждый порт коммутатора, можно просто подключиться к порту коммутатора и монитору. В противном случае для мониторинга данных между модемом/маршрутизатором и STB понадобится концентратор или устройство TAP.

Перед началом мониторинга в приборе должен быть установлен IP адрес и выбрана нужная (или создана новая) конфигурация прибора в меню «Настройки».

Чтобы запустить процесс мониторинга, нажмите кнопку «Вправо». Подождите, пока не появится хотя бы один пассивно отслеживаемый поток.

Рисунок 1 – Результаты измерения IPTV в режиме мониторинга

На рисунке 1 показан список подключенных потоков. Щелкните на значке «+», чтобы развернуть дерево с информацией о номерах PID внутри потока:

Рисунок 2 – Результаты измерения IPTV в режиме мониторинга: дерево с информацией о номерах PID внутри потока

Тип PID (таблица типа PAT/PMT/… и данные аудио/видео)
Номер PID
Пропускная способность для каждого PID, соответственно.
Общая пропускная способность для всех подключенных каналов. (Примечание: Если общая пропускная способность превышает 40 Мбит/с, лишние каналы будут отключены.)

Чтобы просмотреть подробные результаты, пользователю следует щелкнуть на соответствующем узле дерева потоков на экране MONITOR, а затем нажать кнопку «Вправо», чтобы перейти на экран статистики. Для каждого PID, а также для всего потока, на трех вкладках, обозначенных как Basic (основные), Packets (пакеты) и TR101290, будут представлены подробные показатели и информация о состоянии.

Вкладка Basic (основные)

Рисунок 3 – Результаты измерения IPTV в режиме мониторинга: информация о потоке (STREAM) или PID в потоке

На этой вкладке представлена информация о потоке (STREAM) или PID в потоке, включая:

Адрес многоадресной передачи
Тип данных (поток/PID)
Номер PID только для PID
Битрейт
IP-адреса источника и адресата
UDP-адрес источника и адресата

Вкладка Packets (пакеты)

Рисунок 4 – Результаты измерения IPTV в режиме мониторинга: информация о статистике пакетов потока

На этой вкладке представлена информация о статистике пакетов потока (STREAM), включая:

Потери пакетов (общее количество и процентное соотношение)
Нарушение последовательности пакетов (общее количество и процентное соотношение)
Отброшенные пакеты (общее количество и процентное соотношение)
Полученные пакеты (общее количество и процентное соотношение)

Вкладка TR101290

Рисунок 5 – Результаты измерения IPTV в режиме мониторинга: информация о показателях потока Priority 1 и Priority 2 для TR101290

На этой вкладке представлена информация о показателях потока Priority 1 и Priority 2 для TR101290, включая:

Показатели Priority 1:

TS Sync Loss (потеря синхронизации),
Sync Byte Error (ошибка байтовой синхронизации),
PAT Error (ошибка PAT),
PAT 2 Error (ошибка PAT2),
Continuity Error (ошибка последовательности),
PMT Error (ошибка PMT),
PMT 2 Error (ошибка PMT 2),
PID Error (ошибка PID).

Показатели Priority 2:

Transport Error (ошибка транспорта),
CRC Error (ошибка CRC),
PCR Error (ошибка PCR),
PCR Repetition Error (ошибка повторяемости PCR),
PCR Discountinuity Error (ошибка нарушения последовательности PCR),
PCR Accuracy Error (ошибка точности PCR),
PTS Error (ошибка PTS),
CAT Error (ошибка CAT).

СОДЕРЖАНИЕ

Настройка анализатора DataScout 1G для тестирования IPTV
Импортирование, создание, редактирование списка тестируемых IPTV каналов
Тестирование IPTV в режиме эмуляции ресивера (STB EMULATION)
Тестирование IPTV в режиме мониторинга (Monitor)
Тестирование IPTV в режиме сканирования каналов (CHANNELS SCAN)

Рисунок
8.8 – формат транспортного пакета

Транспортный
пакет имеет сложную многоуровневую
структуру, показанную на рисунке 8.9.

Канальный
заголовок имеет следующие поля.

Рисунок
8.9 – структура заголовка и поля адаптации
транспортного пакета

Для
пустых пакетов payload_unit_start_indicator
должен быть установлен в 0.

Таблица
8.1 – значения PID

Значение	Описание
0х0000	Таблица взаимосвязи программ PAT
0х0001	Таблица условного доступа CAT
0х0002 …0х000F	Зарезервированы
0х0010…0x1FFE	Может быть присвоено сетевому идентификатору networkPID, идентификатору структуры программы Program_map_PID. идентификатору элементарного потока elementary_PID или для других целей
0х1FFF	Нулевой пакет
Примечание: транспортные пакеты с PID 0х0000, 0х0001 и 0х0010…0х1FFE предназначены для переноса PCR

Таблица
8.2 – Значения поля управления
скремблироваеия

Значение	Описание
00	Без скремблирования
01	Определяется пользователем
10	Определяется пользователем
11	Определяется пользователем

Таблица
8.3 – Значения поля адаптации

Значение	Описание
00	Зарезервирован для будущего использования ISO/IEC
01	Поле адаптации отсутствует, только полезная нагрузка
10	Только поле адаптации, полезная нагрузка отсутствует
11	Поле адаптации расположено за полезной нагрузкой

Поле
адаптации, содержит следующие основные
поля:

Источник

<img itemprop="url image" decoding="async" src="https://macatel.ru/forumsmf/Themes/default/images/topic/normal_post.gif" alt /> Тема: PCR (Прочитано 10137 раз)

PCR interval errors #284

Comments

Заключение

Теги

Вкладка Basic (основные)

Вкладка Packets (пакеты)

Вкладка TR101290

СОДЕРЖАНИЕ

Настройка анализатора DataScout 1G для тестирования IPTV

Импортирование, создание, редактирование списка тестируемых IPTV каналов

Тестирование IPTV в режиме эмуляции ресивера (STB EMULATION)

Тестирование IPTV в режиме мониторинга (Monitor)

Тестирование IPTV в режиме сканирования каналов (CHANNELS SCAN)

Тема: PCR (Прочитано 10137 раз)

PCR interval errors

#284