Структура транспортного потока MPEG
Что такое формат MPEG?. В состав чипсета MPEG энкодера в действительности входит аудио-энкодер и видео-энкодер. Видео-энкодер производит поток MPEG видеоданных, аудио-энкодер производит поток MPEG аудио данных. Эти потоки называются «элементарные MPEG потоки» (MPEG Elementary Streams или кратко ES). Оба аудио и видео элементарные (ES) потоки разбиты на пакеты (например, для видео-декодера пакетом может быть кадр изображения). Результирующие потоки называются MPEG-пакетизированные элементарные потоки (MPEG Packetized Elementary Streams или кратко PES), которые, в свою очередь, мультиплексирует входящий в состав энкодера мультиплексер транспортного потока (Transport Stream Multiplexer). Мультиплексер производит транспортный поток (Transport Stream, TS), который содержит аудио и видео PES потоки вместе с данными синхронизации.
Аудио-данные, видео-данные и данные синхронизации на выходе энкодера вместе уже являются «программой». Данные синхронизации определяют скорость передачи данных и необходимы впоследствии для точного декодирования аудио- и видео-данных программы.
Транспортный поток состоит из TS пакетов длиной 188 байт. Каждый из TS пакетов содержит заголовок и полезную нагрузку данных, например, аудио-, видео-данные, телетекст. Заголовок каждого пакета содержит информацию о содержании этого пакета и является важным для демультиплексера TS. Заголовок начинается со слова синхронизации (47 в hex формате), используемого для распознавания начала пакета. Далее следуют два байта, которые содержат некоторые необходимые флаги (flags) и идентификатор пакета (PID).
PID-код содержит важнейшую информацию о пакете и может быть в диапазоне от 0 до 8191 и используется для идентификации содержания пакета. Например, транспортный поток может содержать пакетизированные элементарные видео-потоки (PES) в пакетах с PID 100, аудио-PES в пакетах с PID 101 и данные синхронизации, принадлежащие к этим потокам в пакетах с PID 102. Но для вторых видео-PES данные синхронизации могут быть в пакетах с PID 200. Итак, в одном транспортном потоке может передаваться много элементарных потоков PES. Но как декодер узнает, какие пакеты (PID-коды) принадлежат определенной программе? Именно для этой цели транспортный поток содержит сервисную информацию (Service Information, SI).
Сервисная информация содержится в нескольких специальных таблицах. Эти таблицы передаются как отдельные потоки, подобно видео- и аудио-потокам. Большинство потоков таблиц сервисной информации имеют фиксированный известный ID, так что декодер всегда может найти их. Ниже приведены наиболее важные SI таблицы с их PID – кодами.
| Наименование таблицы | PID |
| Таблица привязки программы PAT, Program Association Table | 00h |
| Таблица сетевой информации NIT, Network Information Table | 10h |
| Таблица групп программ BAT, Bouquet Association Table | 11h |
| Таблица описания сервисной информации SDT, Service Descriptor Table | 11h |
| Таблица событий EIT, Event Information Table | 12h |
| Таблица запущенных программ RST, Running Status Table | 13h |
| Таблица смещения времени TOT, Time Offset Table | 14h |
| Таблица структуры программ | переменный код |
| PMT, Program Map Table | 10h..1FFEh |
Наиболее важными являются PAT и PMT таблицы. Таблица PAT содержит названия всех программ в данном потоке и пакетные идентификаторы (PID-коды) для PMT этих программ (таблиц структуры программ). Если ресивером принимается неизвестный транспортный поток, то он вначале дожидается TS пакетов с PID=0, содержащих таблицу PAT, затем, в свою очередь, PAT таблица сообщает ресиверу коды PID таблицы структуры программ PMT в этом потоке.
Другие таблицы сервисной информации SI дают дополнительную информацию о вещателе, транспортном потоке, программах и о событиях в программах.
Кроме таблиц PAT и РМТ, существует еще одна чрезвычайно важная таблица – таблица условного доступа (Conditional Access Table, CAT), которая передается при PID = 0001, когда одна или более программ уплотненного потока скремблируются (шифруются).
Для мониторинга содержания транспортного потока используются так называемые анализаторы транспортного потока, которые позволяют оператору в процессе настройки мультиплексоров фильтровать ненужные сервисы. Для инжекции в транспортный поток необходимой оператору сервисной информации используются PSI/SI генераторы. Поскольку сервисная информация передается в TS как последовательная серия иерархических таблиц, PSI/SI генераторы называют ещё «карусельными» генераторами.
Если у Вас возникли какие либо вопросы, обращайтесь по E-mail: 
или по тел.: (495) 221-81-88. Наши специалисты дадут Вам полную исчерпывающую информацию по любому из интересующих Вас вопросов.
Таблицы программно-зависимой информации
Вся информация, необходимая декодеру для обработки принятого цифрового потока и выделения нужных компонент программы, сосредоточена в управляющей информации (ее еще называют метаданными), передаваемой в составе транспортного потока. Она организована в виде нескольких таблиц, содержащих сведения о составе программ и идентификаторах их компонентов и называемых таблицами программно-зависимой информации PSI (Program Specific Information).
Рисунок 3.8 — Алгоритм действия декодера при прочтении таблиц PSI
Алгоритм работы декодера при прочтении таблиц PSI поясняется рисунком 3.8. Первая таблица, пакеты которой находит кодер в потоке — Таблица объединения программ (РАТ — Program Association Table). Таблица РАТ имеет по умолчанию PID = 0 и включает информацию о программах, передаваемых в данном потоке, и идентификаторы, относящиеся к этим программам. Каждый такой PID, в свою очередь, определяет для выбранной программы Таблицу состава программы (РМТ — Program Map Table), в которой перечислены все компоненты, входящие в данную программу, с их идентификаторами. Декодеру остается отобрать из общего потока пакеты с нужными идентификаторами и декодировать их, восстановив изображение и звуковое сопровождение. Если программа платная, декодеру придется анализировать еще и содержание Таблицы условного доступа (САТ — Conditional Access Table) с PID = 1, в которой указаны идентификаторы пакетов с сообщениями системы условного доступа. Иногда в набор таблиц PSI включают еще необязательную Таблицу сетевой информации (NIT — Network Information Table), которая определяет все транспортные потоки, относящиеся к данной сети. Содержимое таблиц вводится в секции — области поля адаптации определенной длины, снабжаемые указателями. Размер секции для передачи служебной информации не должен превышать 1024 байта. Возможна передача нескольких коротких секций в поле адаптации одного пакета транспортного потока или одной длинной секции в нескольких пакетах.
На рисунке 3.9 показана иерархия PSI таблиц и взаимосвязи между ними. Рассмотрим структуру таблиц подробнее.
Рисунок 3.9 — Структура таблиц программно-зависимой информации PSI
Общий формат таблицы РАТ показан на рисунке 3.10,а. Таблица содержит заголовок длиной 8 байт и поле данных. Структура заголовка более детально развернута на рисунке 3.10,б. Первым идет идентификатор таблицы table_id. Это однобайтовое число обязательно входит в состав любой таблицы и определяет ее тип. Может возникнуть вопрос: разве PID не определяет таблицу полностью, и зачем нужен еще один идентификатор?
Рисунок 3.10 — Формат таблицы РАТ:
а — общая структура; б — структура заголовка.
PID является более общим указателем, чем table_id. Например, две таблицы TDT и ТОТ (о них мы узнаем в шестой главе) имеют одинаковый PID, но разные table_id. Следующий существенный указатель — длина секции в байтах. Два старших бита из 12 установлены на «0», так что длина секции не может превышать 1024 байта. Идентификатор транспортного потока transport_stream_id размером 2 байта указывает условный номер в данной сети транспортного потока, в котором передается анализируемая таблица. Указатель номер версии изменяется на единицу каждый раз, когда в таблицу вносятся изменения. Если таблица разбита на несколько секций, однобайтовый указатель номер секции сообщает номер передаваемой секции. Номер последней секции необходим для подтверждения того, что вся таблица принята декодером.В поле данных таблицы РАТ содержатся сведения о программах, передаваемых в транспортном потоке, с их номерами PID. Номер программы занимает 2 байта, затем следуют 3-битовый промежуток и 13-битовое значение PID.
Таблица РМТ создается отдельно для каждой программы, передаваемой в потоке. Общая структура таблицы показана на рисунке 3.11,а, детальная структура заголовка — на рисунке 3.11,б. Заголовок длиной 12 байтов содержит идентификатор таблицы table_id, всегда равный 0×02, номер программы, сведения о версии таблицы, номере секции и номере последней секции, а также PID того PES в потоке, который переносит значения PCR. В поле данных описывается одна из передаваемых программ со всеми ее компонентами, а завершается секция контрольной суммой. Описание программы содержит подробный перечень всех элементарных потоков, составляющих программу, с их основными параметрами. Тип потока (stream_id) указывает на содержимое данного потока (0×01 — МРЕG-1 видео, 0×02 — МРЕG-2 видео, 0×03 — МРЕG-1 звук, 0×04 — МРЕG-2 звук, 0×05 — нестандартные секции, и т.д.), elementary_PID сообщает значение PID пакетированного потока, несущего данный элементарный поток, ES_info_length указывает длину дескриптора элементарного потока. По этим значениям декодер выделяет нужные элементарные потоки из общей цифровой последовательности. На рисунке 3.11 показана одна из таблиц РМТ того же цифрового потока, иллюстрирующая общие принципы.
Рисунок 3.11 — Формат таблицы РМТ:
а — общая структура; б — структура заголовка.
Основными компонентами таблицы САТ являются table_id и дескриптор системы условного доступа — указатель, сообщающий декодеру условное обозначение используемой в потоке системы условного доступа и номер PID потока управляющих сообщений о правах доступа. Дескриптор условного доступа может присутствовать и в РМТ таблице, в этом случае он указывает на РI1Э потока сообщений, необходимого для дешифровки скремблированной программы.
Частота повторения пакетов РАТ и РМТ таблиц должна быть не менее 10 Гц, периодичность сообщений условного доступа определяется конкретной системой условного доступа.
Рассмотренные три таблицы составляют необходимый минимум, без которого декодер МРЕG-2 не сможет декодировать цифровой поток. Для многопрограммного вещания нужны дополнительные данные, описывающие организацию букетов программ, состав вещательной сети, содержание программ и т.д.
3.3. Транспортировка пакетов MPEG-2 в составе ячеек АТМ
Механизм транспортировки данных из одной точки в другую в большинстве систем связи включает идентификацию источника и получателя пункта назначения. Механизм идентификации особенно важен в системах с коммутацией пакетов, в которых пакеты данных пересылаются из одного пункта коммутации в другой до тех пор, пока не достигнут конечного пункта назначения. В комплексных системах связи пакеты данных, относящиеся к одному и тому же сообщению, могут доставляться от источника к пункту назначения различными путями в зависимости от величины трафика системы. Пакеты, предназначенные для применения на уровне звена данных и физическом уровне, обычно содержат следующие шесть элементов: флаг начала пакета и синхроинформацию; информацию для управления кадром с указанием типа кадра; идентификатор пункта передачи в виде адреса источника; идентификатор пункта назначения в виде адреса получателя; полезная нагрузка; символы для обнаружения ошибок или циклической проверки на четность (CRC).
Одной из важных технологий, применяющейся для передачи данных по широкополосным цифровым сетям с интеграцией служб (B-ISDN), является асинхронный способ передачи (Asynchronous Transfer Mode, ATM). Первоначально ATM-технология была разработана для решения задач мультиплексирования и транспортировки применительно к телефонной связи с целью объединения различных видов трафика в одной и той же системе. В структуре ATM информация передается короткими пакетами фиксированной длины, которые называются ячейками. Длина ячейки составляет 53 байта (октета по терминологии МСЭ-Т). Первые 5 байтов (заголовок) содержат информацию о мультиплексировании, а остальные 48 байтов (полезная загрузка) содержат данные пользователя.
Заголовок ячейки ATM обеспечивает выполнение сетевых функций и состоит из шести полей:
— GFC — Generic Flow Control — 4-битовое поле общего контроля потока, служащее для контроля прохождения трафика через сетевой интерфейс пользователя.
— VPI — Virtual Path Identifier — 8-битовое поле идентификатора виртуального пути (указателя фактического маршрута передачи).
— VCI — Virtual Channel Identifier —16-битовое поле идентификатора виртуального (фактически используемого) канала. Функции VCI и VPI совместно обеспечивают информацию о маршруте передачи информации с преобразованием последовательностей из одного вида в другой. Информация, относящаяся к источнику и конечному пункту назначения, передается не в АТМ заголовке, а представляется последовательностью этапов маршрута при выделении АТМ канала.
— PTI — Payload Type Indicator — 3-битовое поле индикации типа полезной нагрузки.
— CLP — Cell-Loss Priority — 1-битовое поле приоритета потери ячейки, т.е. флаг, определяющий прерывание передачи последовательности при перегрузке сети.
— HEC — Header Error Control — 8-битовое поле контроля над ошибками в заголовке, служащее для исправления ошибок в АТМ заголовке.
Метод АТМ разработан для применения в сети с коммутацией пакетов, когда различные ячейки одного и того же сообщения могут следовать по разнообразным путям между источником и приемником. Чтобы гарантировать правильную сквозную доставку информации и восстановление полезной нагрузки в порядке ее передачи, были стандартизированы уровни эталонной модели протоколов B-ISND. Применительно к АТМ важное значение имеют три первых уровня: физический, уровень АТМ и уровень адаптации АТМ (ATM Adaptation Layer, AAL).
Уровень адаптации АТМ обеспечивает выполнение услуг в интересах верхнего уровня, при этом он разбивается на два подуровня: конвергенции (Convergence Sublayer, CS); сегментации и сборки (Segmention and Reassembly Sublayer, SAR). Стандартизированы 5 уровней адаптации АТМ типа 1 — 5, которые обеспечивают маршрутизацию сообщения, ретрансляцию кадров, эмуляцию каналов, идентификацию узлов и информацию о времени, необходимые для правильного восстановления сообщений на приемном конце. Однако, в условиях единственного пути сообщения, характерного для цифрового наземного вещания, байты, относящиеся к идентификации пути сообщения, представляют собой избыточные данные заголовка.
Цифровое наземное телевизионное вещание является системой исключительно для передачи из одной точки на множество точек, и система транспортировки МРЕG-2 предназначена для применения в функции эффективного контейнера сигналов изображения, звука и данных, которые будут подаваться от источника к потребителю. Поскольку участок тракта между источником и потребителем является по существу фиксированным (если не учитывать проблемы многолучевой интерференции) и пропускная способность наземного канала при передаче данных строго ограничена, нет никакой необходимости передавать информацию об источнике, пункте назначения или узловом пункте сети в каждом пакете.
При разработке стандартов МРЕG-2 учитывался вариант сопряжения транспортных потоков цифрового телевидения с сетями АТМ. Известны два метода последовательного ввода пакетов транспортного потока МРЕG-2 в ячейки системы АТМ, рассмотренные в Рекомендации ITU-T J.82. В первом из них используются уровень адаптации АТМ AAL типа 1 и введение отдельного транспортного пакета МРЕG-2 в четыре ячейки системы АТМ.
Подуровень сегментации и сборки ВАН принимает от подуровня конвергенции СВ блоки данных полезной нагрузки длиной 47 октетов и добавляет к ним 1 октет заголовка. Сформированный таким образом блок данных в 48 октетов называется протокольным блоком данных (Protocol Data Unit, PDU), или SAR-PDU. Транспортный пакет стандарта МРЕG-2 состоит из 188 байтов, включающих 4 байта заголовка и 184 байта полезной загрузки.
Этот 188-байтовый пакет может быть размещен в пределах четырех ячеек АТМ как четыре полезные нагрузки по 47 байтов блоков SAR-PDU (4 × 47 = 188), оставляя пространство для одного байта адаптации АТМ AAL типа 1 на одну ячейку АТМ. Пример такого размещения показан на рисунке 3.13.
Рисунок 3.13 — Мультиплексирование транспортного
пакета МРЕG-2 в ячейки АТМ
Транспортная субсистема МРЕG-2 с ее 4-байтовым заголовком транспортного пакета из 188 байтов менее перегружена, чем система АТМ.
Излишнее наполнение заголовка должно приниматься во внимание среди прочих ограничений систем цифрового ТВ вещания.
Если в двух последовательно поступающих пакетах транспортного потока не содержатся эталонные метки времени программы (программный тактовый сигнал — Program Clock Reference, PCR), то они могут быть непосредственно введены в восемь АТМ-ячеек (N =2).
Структурная схема ввода двух транспортных пакетов в 8 ячеек АТМ показана на рисунке 3.14. Общий объем данных полезной нагрузки в составе 8 ячеек АТМ уровня адаптации AAL типа 5 составляет 384 октета. Из них 376 октетов служат для ввода данных двух транспортных пакетов, а 8 октетов хвостовика протокольного блока данных общей части подуровня конвергенции (Common Part Convergence Sublayer, CPCS-PDU) могут использоваться, например, для контроля ошибок.
Рисунок 3.14 — Ввод пакетов (N = 2) в ячейки АТМ (ААL типа 5)
3.4. Принципы обеспечения синхронизации цифровых потоков в стандарте МРЕG-2
Общий отсчет времени задается ссылками на системные часы (SCR), вводимыми в заголовок системного потока, по ним декодер подстраивает свои внутренние часы и «привязывает» потоки видео и звука к абсолютным отсчетам времени. Для выравнивания задержки во времени отдельных пакетов в заголовок PES-пакета вводятся временные метки воспроизведения (PTS) и временные метки декодирования (DTS), которые указывают, в какие моменты этого абсолютного времени декодер должен обработать и вывести на экран соответствующие изображения или звуковые последовательности. Эти же средства используются и в программном потоке МРЕG-2, где все компоненты потока также имеют общую временную базу.
Транспортный поток содержит программные компоненты с разной предысторией, в том числе и с несколько различающимися тактовыми частотами, поэтому невозможно или весьма трудоемко привести все сигналы к единой временной базе. Для управления такими потоками вводится еще один механизм синхронизации, называемый ссылкой на программные часы (PCR — Program Clock Reference). PCR, как и другие временные метки, также представляет собой 33-битовое число, отсчитываемое в периодах частоты 90 кГц, получаемой делением на 300 частоты тактового генератора 27 МГц. Оно показывает ожидаемое время завершения считывания в декодере поля PCR из транспортного потока, после чего декодер может приступить к сравнению пришедшего и местного отсчетов и выработке корректирующего сигнала. Отличие от SCR в том, что PCR вводится в поток на программном, а не системном уровне, в одном потоке могут передаваться несколько различных PCR, по числу программ. Декодер при переключении на каждую новую программу заново синхронизирует внутренний генератор частоты 27 МГц. Стандарт предписывает повторение метки PCR не реже чем 1 раз в 0,7 с. В промежутках декодер вычисляет значения меток путем интерполяции.
Транспортный поток MPEG TS: основные понятия
В данной статье мы рассмотрим основные понятия для MPEG TS, который в настоящее время является стандартом и используется в качестве канального уровня в большинстве систем наземного цифрового телевизионного вещания, использующих передачу пакетных данных в транспортных потоках.
Принимая во внимание то, что структура транспортного потока опирается на некоторые фундаментальные концепции вещания, мы кратко рассмотрим их перед тем, как приступить к MPEG TS.
Вещание и необходимость в сервисах
Большинство вещательных сетей работает, как то, что мы можем назвать однонаправленной сетевой системой (вещательная сеть). Данная структура реализуется таким способом не потому, что невозможно организовать обратный канал с любого устройства в сети, а потому, что конечному пользователю будет довольно затратно приобрести устройство, обладающее необходимыми возможностями. Данная структура делает передачу данных через крупную сеть связи дешевле.
Итак, мы сталкиваемся со структурой, в которой мы должны передавать услуги (например, ТВ каналы) для очень большого количества потребителей. Как вы знаете, старая аналоговая система, используемая для вещания, использует определенную полосу частот в радиочастотном диапазоне. Каждая часть полосы частот называется каналом. Так, в аналоговом телевидении в одном частотном канале у нас передавался только один ТВ канал.
С развитием цифровой передачи мы перестаем использовать концепцию аналоговых данных, и начинаем использовать концепцию передачи битов. Это означает, что в частотном канале, котором ранее передавались видео и аудио сигналы, теперь передаются двоичные данные (обратите внимание, что эти данные передаются последовательно). Использование бита в качестве единицы передаваемых данных дает гибкость для передачи множества типов файлов, что подразумевает снятие ограничения, при котором в канале передавался только один ТВ канал, один аудиоканал и т.д. Теперь канал – это пакет байтов, которые вещатель может распределять, чтобы передавать пользователям множество типов данных. Однако, как мы можем послать все эти данные без их смешивания. Ответ на этот вопрос – мультиплексирование с временным разделением каналов и MPEG TS, который был разработан для возможности такого способа передачи.
Что такое MPEG TS?
MPEG TS определяет канальный уровень, а также уровни данных сервисной информации (с точки зрения модели OSI, MPEG TS охватывает уровни от канального до транспортного). Вся передача данных выполняется с использованием пакетов фиксированного размера, известных как «TS-пакеты». TS пакеты – это базовые кирпичики, в которых передаются все данные канала, а кроме того, они позволяют реализовать временное мультиплексирование, необходимое для передачи.
Структура TS пакета изображена на рисунке ниже:
Структура TS пакета
Любая передача в канале осуществляется путем отправки одного TS пакета за другим (минимальный блок передачи данных составляет 184 байта). Как было показано на рисунке выше, пакет состоит из двух частей:
Полезная нагрузка – это просто двоичные данные для верхних уровней; уровней, которые выходят за рамки темы данной статьи.
4 байта заголовка разделены на несколько секций:
В этой таблице наиболее важными полями являются PID и счетчик непрерывности. В следующем разделе мы кратко рассмотрим их.
Мультиплексирование данных
В начале статьи я упомянул, что одной из ключевых особенностей MPEG TS является возможность мультиплексирования данных. Но как достигается это волшебство? Ну, всё связано с PID.
Значение PID является ключом, который используется в качестве идентификатора типа данных, которые идут через поток. Это означает, что я могу выбрать PID для идентификации видеосигнала, другой PID для идентификации звука для этого видео и, наконец, третий PID, который связывает видео и звук (также известный как таблица структуры программы или «Program Map Table», PMT). Со всеми этими данными приемник может реально показать видео и связанный с ним звук, если он знает, как обнаружить PMT пакеты. И это всё? Конечно, нет! Таким же образом я могу создать множество пар пакетов видео и звука с их PMT и передавать всех их через тот же канал, что дает нам возможность создать мультиплекс из нескольких ТВ каналов, использующих один канал передачи данных! Конечно, приемнику будет нужен четвертый тип пакета, чтобы узнать, какие программы идут в потоке: также известный как таблица программ или «Program Association Table», PAT.
На следующем рисунке приведена идея мультиплексирования программ:
Мультиплексирование программ в MPEG TS
На диаграмме выше, у нас три ТВ канала передаются в одном потоке. Все показанные таблицы являются более или менее связанными группами данных. Обратите внимание, что в этом примере, если приемник хочет знать все программы в канале, ему необходимо просто прочитать PAT (которая хоть в данном примере и передается в одном пакете, но это не всегда так делается). Таким образом, приемник знает все программы, которые есть в наличии, и если он хочет настроиться на одну из них, ему просто необходимо прочитать PMT пакет и начать фильтровать все пакеты с необходимыми видео и аудио, отклоняя видео и звук ненастроенных каналов. В заключение отметим, что PID позволяет мультиплексировать данные, а также предоставляет приемнику механизм фильтрации данных, которые необходимо использовать.
MPTS пакеты несут только 184 байта данных полезной нагрузки. Любой человек, который когда-либо использовал видео или аудио файлы, знает, что этот объем данных довольно мал, чтобы переносить какой-либо объем видео/аудио данных. Таким образом, транспортный уровень отвечает за перенос этой информации (уровень выше MPTS), но всё же мы должны знать, как собрать данные полезной нагрузки, и, самое главное, знать, как определить, когда данные полезной нагрузки были потеряны (нам необходима способность обнаружения случаев потери пакета данных!). Механизм обнаружения потери данных предоставляется счетчиком непрерывности.
Счетчик непрерывности (Continuity counter, CC) – это счетчик от 0 до 15, связанный с PID (CC относится только к PID, в котором он был передан). Он увеличивается на единицу каждый раз, когда в поток передается пакет связанного с ним PID. При таком подходе обнаружение потери пакета осуществляется путем анализа потерь значений в циклическом счетчике в принятых пакетах. Таким образом, если в циклическом счетчике потеряется значение, уровень TS сможет сообщить своему верхнему уровню, что он потерял часть переданных данных, позволяя верхнему уровню выбрать действие, которое необходимо выполнить в этом случае (в большинстве случаев происходит отбрасывание поврежденной информации).
Следующие значения CC показывают пример потери данных, которая обнаруживается благодаря нарушению в последовательности значений счетчика непрерывности (для примера мы допустим, что 4 видео TS пакета представляют собой один видео кадр, и, если кадр будет потерян, то декодер выведет на экран сообщение «No signal!»). Обратите внимание, что CC является циклическим.
Счетчик непрерывности (Continuity counter, CC)
Вот и всё! Надеюсь, статья оказалась вам полезной. Оставляйте комментарии!
