Pcr discontinuity indicator error

Работа по теме: Лекции по ЦО АВС2. Глава: 8.4 Структура транспортных пакетов. ВУЗ: СибГУТИ.

Транспортный
пакет стандарта 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 битами. Указывает количество
байтов расширенных данных поля адаптации,
следующих непосредственно за этим
полем, включая зарезервированные байты,
если они есть. В расширенные данные поля
адаптации вводится доплнительная
информация, используемая декодером при
декодировании.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

Broadcast DTV has only gotten more complex, requiring more and more training and study by broadcast engineers. And just when it looked like broadcasters had a handle on the all-digital plant, the digital transmitter required new training. Most engineers don’t think too much about the actual transport stream that connects the studio output to the transmitter’s input; they’ll keep an eye on the digital microwave or the fiber optic link — but the actual stream is a given.

With the DTV signal is about to become the only signal, it’s time to really look at and understand one of the most vital links in the broadcast chain, the transport stream (TS). Some stations are lucky enough to have their own stream analyzer or even a stream monitor, but how many operators really understand it?

Monitoring the stream

The best way to become familiar with the TS is to monitor and study it when there are no problems. What does it look like when there are three SD programs compared to when only one HD program is on the air. (See Figure 1.)

An important point is that the following tests were designed for monitoring the TS at its origination point — the output of the multiplexer. Determining if this is correct is the first step in monitoring the TS. After it has been verified at the source, then tests can be performed at the transmitter or off the air to further verify the TS.

The DVB Group has prepared a technical report (TR) for monitoring the TS, which covers a number of faults from the most critical to the least critical. Most, if not all, stream analyzers incorporate these tests to provide a common set of measurements.

TR 101 290

The technical report TR 101 290 entitled “Measurement Guidelines for DVB Systems” is the basis for nearly all transport or MPEG stream analyzers. The tests are intended for continuous or periodic monitoring of the TS while in operation; they are designed to check the integrity of the TS with the aim to provide a check of the most important elements of the stream. The display of information may change and additional tests may be provided, but there is a commonality between all stream analyzers based on the TR 101 290 document, which is available from the DVB Group Web site.

Priority of faults

The tests boil down to a series of tests where different parameters are monitored and measured in either frequency of occurrence or timing variation. The results are displayed on screen as either pass or fail indicators or, in the case of timing, with the use of a scale showing where the parameter’s result is in relation to its maximum allowed value. Other indicators will alert the operator to a pending fault if the values start to come close to the system’s limits. (See Figure 2.)

There are three levels of priority for faults in the stream: first priority are considered necessary to ensure that the TS can be decoded, second priority are recommended for continuous monitoring and third priority are faults that could affect certain applications.

Priority 1

First-priority faults are basically faults that will take you off the air. Although the transmitter is operating and producing at full power, there is no picture or there are other major faults indicated by the transmitter. In this case, monitoring the TS arriving at the transmitter would make sense, and the first things to look at are the first-priority fault tests on the stream analyzer, which include:

  • TS sync loss — The loss of synchronization with the TS is the most serious fault. When 5 sync bytes have been acquired, the decoder is considered synched, but a loss of just 2 sync bytes indicates a loss of sync. (See Figure 3.)

*Once the decoder is synchronized, the rest of the parameters can be evaluated.

  • Sync byte error: If the sync byte is not equal to 47 hexidecimals, then a sync byte error occurs. The system then looks for the reoccurrence of the sync byte (which must be 47 hexadecimals) every 188 bytes.
  • PAT error: The program association table (PAT) is the only packet with packet ID (PID) Hex 0000, and it must occur at least every 0.5s to keep this error from occurring. Every program within the TS is listed in the PAT; if it is missing, then no programs can be decoded.
  • PAT error 2: If the table has an ID other than Hex 00 or there is more than one table ID Hex 00 inside the packet with the PAT PID, then this error can occur.
  • Continuity count error: This error occurs when any of the following faults happen — incorrect packet order, a packet occurs more than twice or a packet is lost.
  • PMT error: This can occur if the program map table (PMT) does not come up at least every 0.5s on the PID that is referred to in the PAT.
  • PID error: When TSes are remultiplexed, this can occur if any PID doesn’t refer to an actual data stream.

Priority 2

Second-priority errors are those that could affect individual programs, but the TS is still intact. The types of problems these errors can cause are frozen frames and loss of lip sync. Tests for these faults on the stream analyzer include:

  • Transport error: This flag is set in the TS header by the demodulator if it can’t correct errors in the stream.
  • CRC error: This indicates that a CRC error (data corruption) occurred in any of the following tables — CAT, PAT, PMT, NIT, EIT, BAT, SDT or TOT.
  • PCR error: This flag is raised if the primary clock reference (PCR) is not seen for more than 100ms. The time interval between two consecutive PCR values should be no more than 40ms. This type of error can cause the decoder to lose lock on the 27MHz clock.
  • PCR repetition error: This error occurs when the time interval between two consecutive PCR values is more than 40ms and can cause the 27MHz clock to drift or lose lock.
  • PCR discontinuity indicator error: If the difference between two consecutive PCR values is outside the range of 100ms, this error can occur.
  • PCR accuracy error: This error can occur when the PCR accuracy of the selected program is outside the range of ±500ns.
  • PTS error: This occurs when the presentation time stamp (PTS) repetition is more than 700ms. The PTS is contained in the MPEG-2 program stream and is used to aid the decoder in presenting the program on time, at the correct speed and synchronized. The PTS is compared to the PCR.
  • CAT error: This is used for conditional access programs (paid programming).

Priority 3

Third-priority errors are application dependent and are concerned mostly with errors in the network information tables (NIT), buffer over- and underruns for the transport, multiplexer and elementary streams.

The most likely error under priority three is “unreferenced PID,” which is a packet with a PID that is not listed in the PMT. This is not critical, but it indicates that packets are being disassociated from the PMT, possibly through remultiplexing.

PCR monitoring

A very important parameter to monitor is the PCR and its relative advancement or delay in the transport stream. This can be shown as a graph that displays this timing variation in a variety of ways. The point is to know how close the PCR is to arriving at the correct time and if it comes close to causing an error. Each program or channel must be selected and monitored separately because each has its own PCR. (See Figures 4 and 5.)

ATSC recommendations

The Advanced Television Systems Committee (ATSC) has its own publication entitled “ATSC Recommended Practice: Transport Stream Verification” (document A/78a) that provides a common method for describing TS parameters that should be verified for it to be considered decodable. While A/78a does overlap with TR 101 290, the ATSC recommendation specifies five groups of priority tests, each with a range of deviation. The five groups are:

  • TOA (transport stream off-air): In this case, the station is technically off-air, because the TS errors are so severe. Receivers will not be able to tune and decode anything within this broadcast — e.g., repeated absence or complete absence of sync bytes.
  • POA (program off-air): Here, a major service is in error to the point where decoders will not be able to decode the program — e.g., the absence of an entry in the virtual channel table (VCT) for a service.
  • CM (component missing): Typically, in this case, one of the audio or video elementary streams cannot be found, like a mismatch between the video PID signaled in the service location descriptor (SLD) and the actual PID used for the video elementary stream.
  • QOS (quality of service): In this error, parameters are out of specification by such a margin that a significant fraction of the receivers can be expected to produce flawed outputs — e.g., the master guide table (MGT) cycle time being somewhat longer than the specification, which would cause slower than normal tuning.
  • TNC (technically nonconformant): In this case, the error violates the letter of the standard, but in practice will have little effect on the viewing experience.

Monitoring equipment

Today’s stream monitoring devices come in a variety of configurations and price ranges. Some devices will continually monitor the stream and alert an operator to any error or potential error, while other devices must be monitored manually by an observer with a screen. Most, if not all, of these devices will list the TR 101 290 parameters for reporting, because they are used in virtually all transport streams, while some others will have the ATSC A/78a parameters as well.

For more critical tests involving the PCR, look for the following in a stream analyzer: PCR accuracy, which looks for accuracy in the originating 27MHz clock at the encoder; PCR drift rate, which looks for slow changes in the PCR frequency; and PCR jitter, which covers high-frequency changes in the 27MHz clock. These last two measurements cover errors introduced at the encoder/multiplexer and in the transmission path. The PCR accuracy test is only meant for testing of the encoder/multiplexer, however all these tests require highly-accurate local 27MHz clocks, which will be found in only the more expensive test equipment.

Some lower-cost devices connect to a computer through a USB connection and use the power of the computer to do the hard work of decoding the stream. Some are also capable of recording and playing back a transport stream, which is useful for later analyses of a suspect transport stream. If the device will also play back, then it can be used to feed the transmitter with a prerecorded transport stream when maintenance needs to be performed on the STL or data link from the studio. It also can be used in case the studio link is lost. In this case, a hard disk at the transmitter with evergreen programming can be kept and used in an emergency.

References

Tektronix has a thorough booklet entitled “MPEG Fundamentals and Protocol Analysis.” It covers a variety of MPEG formats as well as transport stream fundamentals. It can be downloaded at http://www.tek.com/Measurement/programs/mpeg_fundamentals/.

The ATSC has all of the specifications for DTV broadcasting available for download at www.atsc.org/.

The Digital Video Broadcasting (DVB) Project is the repository for the specifications for MPEG TS as well as satellite and cable transmissions. Many of the specifications can be downloaded at www.dvb.org/.

Next time

The next “Transition to Digital” tutorial will cover fiber-optic cabling for broadcasters.

Future US’s leading brands bring the most important, up-to-date information right to your inbox

Источник

Стрим Лабс MultiScreen позволяет осуществлять инструментальный контроль сигнала и без визуализации всего набора телеканалов.

В данном варианте работы все каналы выводятся в виде ячеек в клиентском приложении MultiMonitor.

Так же, любой канал может быть отображен на Penalty Screen в ручном, либо в автоматическом режиме.

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

Схема использования MultiScreen lkz контроль DVB сигнала в различных точках системы:

Поддерживаемы транспортные потоки:

Stream MultiScreen — представляет собой эффективную медиа-платформу, которая позволяет осуществлять визуальный и инструментальный контроль неограниченного количества Теле- и Радио- каналов. Количество физических входов сервера зависит от установленной в него платы:

  • IP/Ethernet (ETSI TS 102 034). MPEG-2 TS (ISO/IEC 13818-1), MPTS or SPTS
  • DVB-ASI (ETSI EN 50083-9). Bitrate range 0..214 Mbit/s;
  • DVB-T/T2 (ETSI EN 300 744, 302 755);
  • DVB-S/S2 (ETSI EN 300 421, EN302-307, EN301-210);
  • DVB-C/C2 (ETSI EN 300 429 Annex A/B/C);
  • HLS (HTTP Live Streaming Monitoring); supports encrypted streams

Входные видео форматы:

  • MPEG-1 (ISO/IEC 11172-1);
  • MPEG-2 (ISO/IEC 13818-1);
  • MPEG-4.2 (ISO/IEC 14496-2);
  • MPEG-4.10 (H.264, ISO/IEC 14496-10).
  • HEVC (ITU-T H.265 High efficiency video coding)

Входные аудио форматы:

  • MPEG-2 Layer II (ISO 11172-3);
  • Dolby Digital (E-AC3, AC-3, ATSC A.52b);
  • AAC/ADTS/LATM/ADIF (ISO/IEC 13818-7, ISO 14496-3);
  • AES SMPTE 302M

Поддерживаемые форматы внешних событий :

  • SNMP Trap (RFC 3411-3418, STD0062);
  • SNMP Get (RFC 1155, RFC 1212, RFC 1213, RFC 1157, RFC 3411).

Все выявленные ошибки могут выводиться различными путями:

  • Оповещение об ошибке на экране
  • Звуковое оповещение
  • Оповещение в панели статусов MultiMonitor
  • SNMP трапы
  • Отправка E-mail

Список поддерживаемых ошибок:

Прием и отображение видео/аудио сигналов, облегчающих интеллектуальный инструментальный анализ и контроль входных сигналов по важным параметрам, определенные стандартом ETSI TR 101-290 ( ETR 290) level 1 and 2:

  • No license
  • Low throughput
  • TR-290 TS_sync_loss
  • TR-290 transport_error
  • TR-290 PAT sections loss
  • Service lost
  • TR-290 PMT sections error
  • TR-290 CAT sections error
  • TR-290 PCR repetition error
  • TR-290 continuity counter error
  • PID scrambled
  • PES decoder error
  • Black video
  • Video aspect ratio
  • Audio signal level: overload
  • Transport Stream Bitrate
  • Teletext page loss
  • TR-290 EIT Error
  • TR-290 EIT PF Error
  • HLS Transport error
  • Sync loss
  • Signal loss
  • TR-290 sync_byte_error
  • TR-290 PAT sections error
  • TR-290 PMT sections loss
  • TR-290 CAT sections loss
  • TR-290 PCR discontinuity indicator error
  • PID lost
  • RTP sequence error
  • TR-290 PTS error
  • Decoder runtime error
  • Frozen video
  • R-128 Loudness Level
  • Audio signal level: silence
  • Service Bitrate
  • Subtitles Loss
  • TR-290 EIT Actual Sections Loss
  • TR-290 EIT Other Error

Отображение событий в панели статусов и визуализация каналов на PenaltyScreen

Отображение информации о транспортном потоке поверх видео:

  • Service number and Service bitrate
  • PID Program Map Table (PMT)
  • PID Program Clock Reference (PCR)
  • PID and audio stream codec of the program
  • PID and video stream codec of the program
  • Resolution of video stream and FPS
  • Aspect Ratio
  • Bitrate of Video stream
  • Bitrate of Audio stream
  • Teletext PID and bitrate
  • DVB Subtitles PID and bitrate

Схема, показывающая пример системы мониторинга транспортных потоков с 20 транспондеров

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

Эта уникальная особенность системы решает проблему контроля большого количества каналов с минимальными затратами. MultiMonitor позволяет контролировать все доступные источники сигналов на удаленных серверах MultiScreen : входы плат ввода/вывода, IP интерфейсы, PAT , PMT и SDT таблицы. Используя специальный набор параметров, встроенный редактор может создавать новые конфигурации отображения выбранных каналов буквально в несколько кликов мышью.

Все события и ошибки со всех MultiScreen сохраняются в базе данных.

Источник

Понравилась статья? Поделить с друзьями:
  • Partition basic data guid ошибка
  • Parsing error unexpected token expected jsxtagend
  • Parseerror syntax error unexpected expecting laravel
  • Parity error что такое
  • Parameter parsing error vinf getopt not option please refer to the