eng
Цифровое телевещание приобретает все большую популярность, и в недалеком будущем должно стать единственной формой передачи телевизионного сигнала. Соответственно велика и потребность в современных устройствах его приема и обработки. Сегодня эти устройства реализуются на основе систем на кристалле (СнК). Ключевой модуль таких СнК – демультиплексор потока цифровых аудио- и видеоданных. Новый высокопроизводительный сложнофункциональный (СФ) блок демультиплексирования представлен в этой статье.
Рис.1. Схема организации цифрового вещания
На сегодняшний день массовое цифровое телевизионное вещание может производиться с помощью трех основных сетей: кабельной, наземной и спутниковой. При этом для любой из выбранных сетей генерируется одинаковый поток цифровых данных. В этом потоке мультиплексированы (перемешаны) аудио- и видеоданные множества каналов, а также необходимая для их корректного восстановления сопроводительная сервисная информация. Затем цифровой мультиплекс проходит через модулятор и направляется на передатчик (наземный, спутниковый либо кабельный), сигнал с которого уже принимается антенной и абонентским устройством зрителя, где демодулируется, декодируется, демультиплексируется и выводится на экран (рис.1).
В роли абонентского устройства может выступать как телевизор со встроенным цифровым приемником, так и отдельная приставка к нему (Set Top Box).
Поскольку подготовку данных для цифрового телевидения можно проводить множеством различных способов, на этапе разработки систем цифрового телевизионного вещания возникла необходимость в выработке единого стандарта, которым бы руководствовались различные компании при создании компонентов для систем вещания, и который бы обеспечивал совместимость таких компонентов от различных производителей. Таким международным стандартом стал MPEG-2 – стандарт, который определяет только формат данных, но не методы их обработки. Это оставляет возможность производителям создавать разные по характеристикам (таким как используемый объем памяти, вычислительная мощность, устойчивость к потерям данных или площадь кристалла) компоненты для построения удовлетворяющих данному стандарту систем. Стандарт MPEG-2 состоит из трех основных частей – аудио, видео и системной. Первые две определяют форматы сжатия аудио- и видеоданных. Последняя, в свою очередь, описывает способы мультиплексирования аудио- и видеоданных одного и более телевизионных каналов, а также формат сервисной информации, необходимой для последующего восстановления исходных каналов.
Системная часть стандарта MPEG-2 [1] определяет два формата потока данных: один для надежных сред передачи данных (таких как цифровые носители информации) – "программный" поток (Program Stream), и второй для сред передачи данных с высокой вероятностью возникновения ошибок (спутниковые, кабельные и другие сети) – транспортный поток (Transport Stream). Последний формат данных используется в различных широковещательных сетях, в частности в цифровом телевизионном вещании (см. рис.1).
Рассмотрим подробнее процесс приема и обработки сигнала на стороне зрителя (см. рис.1). Тюнер извлекает из поступающего с приемной антенны аналогового сигнала полезную составляющую. Затем демодулятор преобразует данные в цифровой формат с помощью встроенного АЦП. Результирующий битовый поток содержит избыточные данные для последующего восстановления ошибок и формирования уже непосредственно транспортного потока стандарта MPEG-2. Эта группа функций обычно выполняется устройством, совмещающим в себе тюнер и демодулятор, которое называют сетевым интерфейсным модулем (Network Interface Module, NIM). Следующее устройство, демультиплексор транспортного потока, извлекает из потока аудио- и видеоданные (а также субтитры и другую сопроводительную информацию) для просмотра телевизионных программ. Руководствуясь дополнительной сервисной информацией из транспортного потока, центральный процессор управляет потоками аудио- и видеоданных, фильтруя их и направляя на устройства декодирования и дальнейшего отображения видео и воспроизведения аудио для просмотра выбранной телепрограммы.
В данной статье рассматривается новая архитектура демультиплексора транспортного потока, который предназначен для интеграции в приемную часть системы цифрового телевизионного вещания, а именно в состав систем на кристалле (СнК), реализующей функции центрального вычислительного блока абонентских устройств стандарта DVB. Например, блок был успешно интегрирован в состав системы на кристалле декодера цифрового телевизионного сигнала высокой четкости, разработанной НТЦ "Модуль" [2]. При разработке архитектуры СФ-блока прежде всего необходимо сформулировать требования к нему. В следующем разделе представлено краткое описание формата транспортного потока и основных его составляющих, информация о которых необходима для четкой формулировки таких требований.
Транспортный поток
В формате транспортного потока (ТП) для ненадежных сред передачи данных используются короткие пакеты размером 188 байт. Небольшая длина пакетов минимизирует количество данных, которые могут потеряться или повредиться в сети во время передачи.
Транспортный поток состоит из мультиплексированных во времени пакетов, содержащих данные из различных элементарных потоков (например, аудио-, видео- и сервисных потоков). Пакеты каждого отдельного потока перемешаны внутри общего мультиплексированного потока, что уменьшает влияние пакетных ошибок на каждый из потоков данных.
Пакет транспортного потока состоит из заголовка, необязательного поля Adaptation Field и содержимого пакета (payload).
Заголовок транспортного пакета состоит из нескольких полей: байт синхронизации, идентификатор пакета, счетчик непрерывности.
Байт синхронизации (Sync Byte) используется для определения границ передаваемых пакетов и обеспечения произвольного доступа к транспортному потоку. Идентификатор пакета (PID) позволяет установить, к какому элементарному потоку относится данный пакет, что делает возможным восстановление исходного потока на стороне приемника. Таким образом, пакеты с одинаковым полем PID относятся к одному элементарному потоку. Помимо байта синхронизации и идентификатора пакета в заголовке содержится поле CC – счетчик непрерывности, значение которого используется для обнаружения потерь пакетов в каждом из потоков. В этом поле содержится значение счетчика по модулю 16, которое увеличивается на 1 с каждым следующим пакетом из потока с одним идентификатором PID. Таким образом, если принятый пакет содержит отличное от ожидаемого значение поля CC, то это означает, что один или несколько пакетов потеряны в процессе передачи.
За заголовком пакета может следовать поле Adaptation Field, в котором может содержаться значение программной тактовой частоты (Program Clock Reference, PCR), которая используется для синхронизации декодирования и воспроизведения программ. Более подробно ее функции описаны ниже в разделе "синхронизация аудио- и видеопотоков".
За полем Adaptation Field (или за заголовком пакета в случае отсутствия поля Adaptation Field) может следовать содержимое пакета. В состав содержимого могут входить только аудиоданные, видеоданные, сервисная информация поставщика услуг или разделы таблиц (рис.2).
Рис.2. Пример транспортного потока
Разделы таблиц
В синтаксисе транспортного потока определены такие структуры данных, как разделы таблиц. Стандарт на формат сервисной информации в транспортном потоке [3] определяет несколько обязательных типов таблиц, которые необходимы для описания содержимого транспортного потока. Эти таблицы содержат информацию для разделения телевизионных программ в потоке, а также необходимые данные для определения того, какой из потоков с одним PID относится к той или иной телевизионной программе. Такая же структура данных используется и для передачи сервисной информации, например обновления программного обеспечения абонентской приставки Set Top Box.
Таблица передается внутри потока как один или несколько разделов. Первое поле в разделе таблицы – это идентификатор таблицы Table ID, который определяет, к какой из таблиц относится данный раздел. Таким образом, обеспечивается возможность полного восстановления таблицы. Идентификаторы таблиц позволяют передавать несколько различных таблиц внутри одного транспортного пакета, например пакет с PID 21 на рис.2 содержит разделы для таблиц 38, 12 и 51.
Синхронизация аудио- и видеопотоков
Стандарт MPEG-2 предполагает, что задержка прохождения транспортного потока от источника к абонентской приставке является постоянной. Во время построения транспортного потока в него помещается значение программной тактовой частоты PCR. Оно содержится в поле Adaptation Field (см. рис.2). Поскольку транспортный поток распространяется с постоянной задержкой между источником и приемником ТП, значение PCR (отсчет тактовой частоты источника сигнала) может быть использовано для контроля и коррекции системной тактовой частоты абонентской приставки STC. Совпадение значений PCR и STC показывает, что ТП обрабатывается приемником с той же частотой, что и формируется передатчиком, и аудио- и видеобуферы приемника не пустуют и не переполняются. Если же значения отсчетов существенно отличаются, то частоты обработки приемником ТП и формирования передатчиком ТП различны, поэтому аудио- и видеобуферы приемника могут опустеть или переполниться, в результате чего зритель увидит или услышит короткие искажения изображения или звука. Если же в случае существенного отличия значений отсчетов PCR и STC подстраивать системную частоту приемника STC под частоту передатчика, то можно с высокой вероятностью избежать искажений изображения и звука. Для подстройки обычно используют ШИМ-генератор, выход которого через RC-цепочку заводят на построечный вход контролируемого напряжением генератора частоты VCXO.
Приведенное краткое описание транспортного потока позволяет сформулировать некоторые требования к блоку его демультиплексирования.
Требования к СФ-блоку демультиплексора ТП
Основной задачей при разработке блока демультиплексирования транспортного потока было обеспечение максимальной разгрузки центрального процессора от задач, связанных с обработкой транспортного потока. При этом данный блок должен иметь достаточно компактную реализацию в составе системы на кристалле, чтобы обеспечить экономическую эффективность ее серийного выпуска в виде СБИС. Кроме того, необходимо реализовать аппаратный интерфейс приема эфирного транспортного потока.
Стандарт MPEG-2 [1], а также рекомендации по его применению [4], выдвигают определенные требования к любой реализации демультиплексора транспортного потока. Помимо формата транспортного потока требования распространяются на интерфейсы, по которым ТП из сетевого интерфейсного модуля (NIM) поступает в демультиплексор. Потоковый интерфейс между демультиплексором ТП и модулем NIM может быть как последовательным (1 бит), так и параллельным (8 бит). Сегодня достаточно поддерживать только параллельный интерфейс.
Если рассматривать сценарии применения демультиплексора ТП в составе СнК для обработки телевизионного сигнала, то помимо получения ТП из NIM-модуля необходимо также обеспечить возможность чтения ТП напрямую из системной памяти. Такая функция делает возможным воспроизведение записанного заранее эфирного ТП, поступившего из модуля NIM, а также воспроизведение ТП из других источников (например, цифровые носители данных, IP-сети – IPTV). Также возникает необходимость одновременной обработки нескольких транспортных потоков, чтобы обеспечить аппаратную поддержку таких востребованных функций, как Personal Video Recorder (PVR, одновременная запись и воспроизведение одного потока) и "картинка в картинке" (отображение одной или нескольких телепрограмм во время просмотра другой).
Кроме того, в распространенных повсеместно системах условного доступа, призванных защищать телепрограммы от несанкционированного просмотра, используется потоковое шифрование аудио- и видеоданных. Это требует наличия высокопроизводительного аппаратного блока дешифрации в приемном оборудовании для просмотра защищенных программ.
После анализа современного рынка телевизионных услуг и изучения стандартов, связанных с обработкой ТП, были разработаны следующие требования к блоку демультиплексирования транспортного потока:
получение данных транспортного потока от внешнего тюнера (NIM-модуля), а также из внутренней системной памяти посредством встроенного контроллера прямого доступа к памяти (ПДП);
демультиплексирование одновременно до двух ТП (одновременный показ телевизионной программы из первого потока и запись на внешний носитель телевизионной программы из второго потока);
потоковая дешифрация ТП с помощью стандартных алгоритмов DVB CSA или ATSC 3DES по выбору;
наличие многоканального ПДП-контроллера для записи демультиплексированной информации напрямую в системную память;
возможность формирования частного транспортного потока (ЧТП) (ТП, в котором присутствуют только пакеты с заданными идентификаторами PID) для последующей записи на HDD или любой другой внешний носитель;
возможность подстройки системной тактовой частоты посредством встроенного ШИМ-генератора на основе извлекаемой из ТП информации о PCR.
Отметим, что при разработке требований к блоку рассматривалась возможность аппаратной реализации фильтра разделов таблиц (см. описание транспортного потока). Однако при рассмотрении уже существующих реализаций было принято решение перенести эту функцию на программное обеспечение, поскольку аппаратная реализация обычно получается излишне громоздкой, при этом требует активной программной поддержки, сравнимой по ресурсоемкости с полностью программным решением.
Архитектура блока демультиплексора
Исходя из перечисленных требований, была разработана архитектура СФ-блока демультиплексора транспортного потока (рис.3). В соответствии с этими требованиями, блок может получать ТП либо из общей системной памяти (по двум каналам), либо с внешних тюнеров (также по двум каналам). Таким образом, ТП может поступать из четырех источников, при этом в реальном времени возможна обработка до двух ТП. Далее происходит синтаксический разбор заголовков пакетов, фильтрация пакетов ТП по идентификаторам PID и дешифрация содержимого пакетов в случае необходимости. После этого содержимое прошедших фильтрацию пакетов через канал записи с ПДП отправляется в оперативную память системы.
Рис.3. Внутренняя структура блока демультиплексирования ТП
В состав блока входят несколько функциональных подсистем. Подсистема AXI_INPUT служит для чтения данных (ТП и ЧТП) из общей системной памяти по шине AMBA 3 AXI. Фильтрацию, демультиплексирование и дешифрацию транспортных потоков осуществляет подсистема обработки в реальном времени DEMUX_CORE. Подсистема AXI_OUTPUT записывает обработанные данные в общую системную оперативную память по шине AMBA 3 AXI. Подсистема CONF_REGS нужна для управления программируемыми параметрами по шине AMBA 3 APB. Переходники AXI-2-DEMUX CORE и DEMUX CORE-2-AXI необходимы для интеграции в состав блока демультиплексирования ТП унифицированных подсистем AXI_INPUT и AXI_OUTPUT соответственно. Коммутаторы SPI_MUX служат для коммутации входных данных внутри блока демультиплексирования ТП.
Разработанный СФ-блок обладает несколькими стандартными внешними интерфейсами. Один из них – интерфейс AMBA 3 AXI Master с разрядностью 64 бита по данным, который полностью соответствует спецификации компании ARM, за исключением поддержки режима Overlapping [5]. Есть также интерфейс AMBA 3 APB Slave с разрядностью 32 бита по данным, который полностью соответствует спецификации компании ARM [6]. Поддерживаются два входных интерфейса Serial Parallel Interface SPI [7] для приема ТП от тюнера (разрядность 8 бит по данным, поддержка частот от 0 до 13,5 МГц), а также один выходной интерфейс SPI для передачи транспортного потока внешнему устройству (например, модулю условного доступа CAM) для дешифрации.
Внутренние подсистемы
Каждая из подсистем разработанного блока представляет собой сложное устройство, выполняющее целый ряд функций. В данном разделе рассмотрены особенности функционирования некоторых подсистем, а также проблемы, возникшие при разработке, и методы их решения.
Подсистема DEMUX_CORE
Данная подсистема реализует весь тракт обработки транспортного потока (рис.4).
При поступлении ТП в блок в первую очередь производится поиск синхробайта (Sync Byte) – начала пакета в потоке. Эта процедура называется синхронизацией потока. В блоке DEMUX_CORE предусмотрено несколько регулируемых механизмов синхронизации. Затем ТП поступает в FIFO-буфер размером 376 байт (2 транспортных пакета). Как только в буфер поступает полный пакет (188 байт), начинается его считывание и обработка. Так как данные поступают непрерывно, второй пакет буферизуется одновременно с обработкой первого. Поскольку система должна уметь обрабатывать два транспортных потока одновременно, то для каждого ТП работает отдельный FIFO-буфер, при этом тракт обработки транспортных пакетов один. Непрерывную обработку двух потоков одним трактом обеспечивает специальный арбитр, который попеременно выбирает один из двух входных буферов в качестве основного. Для этого он последовательно опрашивает состояние FIFO-буферов и меняет при каждом опросе приоритет (если при первом опросе состояния сначала опрашивался первый буфер, то при последующем опросе первым будет опрашиваться второй буфер).
После поступления пакета на обработку анализируется его заголовок: сначала определяется значение счетчика непрерывности, затем считывается значение идентификатора PID. После этого пакет проходит через PID-фильтры. Каждый из PID-фильтров представляет собой ячейку памяти, объединенную со схемой сравнения. В подсистеме DEMUX_CORE предусмотрено 48 PID-фильтров. Таким образом, DEMUX_CORE обеспечивает возможность фильтрации пакетов двух независимых ТП по 48 различным идентификаторам PID.
Если пакет прошел PID-фильтрацию, анализируется необходимость его дешифрации. В подсистему DEMUX_CORE встроено два потоковых дешифратора, один из которых реализует алгоритм CSA (для обеспечения совместимости с европейским стандартом DVB), а второй – алгоритм 3DES (для обеспечения совместимости с американским стандартом ATSC). При этом остается возможность легко встроить в структуру блока любой другой алгоритм потоковой дешифрации (например, AES). Таким образом, достигается максимальная совместимость с любой существующей системой условного доступа.
В подсистеме DEMUX_CORE также реализован алгоритм корректировки системной тактовой частоты по частоте передатчика PCR. Для реализации данного алгоритма используется программируемый генератор импульсов ШИМ.
Поддержка алгоритма корректировки системной частоты реализована полностью в соответствии со стандартом, однако в использовании данной функции в современных системах часто нет необходимости. Как уже было указано, частоту необходимо корректировать для предотвращения переполнения либо опустошения буферов аудио- и видеоданных, что важно при малом размере этих буферов. Поскольку объемы оперативной памяти в современной приемной аппаратуре существенно возросли, появилась возможность избежать переполнений и опустошений буферов, просто увеличивая их объем.
Рис.4. Этапы обработки транспортного потока
Подсистема AXI_INPUT представляет собой специализированный двухканальный ПДП-контроллер, который получает данные из системной оперативной памяти по 64-битному интерфейсу AMBA 3 AXI и передает их по специальным внутренним интерфейсам подсистеме DEMUX_CORE (рис.5).
Один из основных элементов подсистемы – генератор адресов ПДП DMA_ENG. Он может работать в трех режимах генерации адресов. Первый, самый простой – режим конечных буферов, когда на каждый ПДП-канал выделяется один буфер в системной оперативной памяти (задается начальный и конечный адрес области в памяти – буфера). При достижении конечного адреса этого буфера ПДП останавливается, сигнализируя об окончании буфера прерыванием. Второй режим – режим кольцевого буфера – аналогичен первому, но ПДП не останавливается по достижению конца буфера, а загружает начальный адрес этого буфера и использует его снова. При этом также реализована возможность сигнализировать прерыванием о достижении конца сегмента буфера (до 64 Кбайт). Третий режим – режим "карусели" – когда каждому ПДП-каналу ставится в соответствие два буфера в памяти, работа с которыми происходит поочередно. При работе в таком режиме достигается максимальная производительность за счет того, что обеспечивается непрерывность поступления данных.
Рис.5. Внутренняя структура подсистемы AXI_INPUT
В подсистему AXI_INPUT также входит сложный интерфейсный блок AXI_R_IF, который в полном объеме реализует возможности современной шины AMBA 3 AXI Master [5]. По адресам, за генерацию которых ответственен блок DMA_ENG, по шине AXI поступают данные из оперативной памяти системы. Затем с помощью арбитра эти данные разделяются (в соответствии с адресами, по которым они были считаны) и записываются в два буфера данных FIFO (по одному буферу на каждый канал ПДП). Эти данные попадают в тракт обработки транспортного потока блока демультиплексирования ТП с помощью переходников AXI-2-DEMUX CORE (см. рис.3).
Подсистема AXI_OUTPUT
Подсистема AXI_OUTPUT реализует функцию прямой записи в системную память. Ее основной элемент – генератор адресов ПДП DMA_ENG, аналогичный тому, что используется в подсистеме AXI_INPUT, но расширенный до 48 независимых каналов ПДП. Таким образом, каждому PID-фильтру подсистемы DEMUX_CORE соответствует один канал ПДП. При записи в память для обеспечения непрерывности буфера в памяти оптимален режим работы ПДП "карусель", описанный выше. В состав подсистемы AXI_OUTPUT входит также интерфейсный блок, который в полном объеме реализует шину записи AMBA 3 AXI Master (кроме поддержки режима Overlapping [5]). Функциональной особенностью этого блока является полная поддержка побайтовой адресации. Поскольку шина AXI 64-разрядная (8 байт), а транспортный поток поступает по 8-разрядному интерфейсу (1 байт), то часто возникает необходимость писать в память неполные слова (меньше 8 байт). Поэтому поддержка побайтовой адресации при записи в оперативную память – необходимое условие корректного функционирования блока демультиплексирования транспортного потока.
Разработанный блок демультиплексирования транспортного потока соответствует всем предъявленным требованиям и обеспечивает быструю, гибкую и стабильную обработку любых транспортных потоков, требуя при этом минимальной программной поддержки.
RTL-модель блока прошла полноценное функциональное тестирование как на специальном наборе искусственно разработанных транспортных потоков, так и на реальных транспортных потоках различной сложности. Тестирование RTL-модели проводилось в среде Cadence NC-Verilog. Также был реализован прототип разработанного СФ-блока на базе ПЛИС типа Xilinx Virtex 4 LX200 и универсальной платы эмулятора ARM Emulation Baseboard HBI-0140. Он успешно прошел тестирование в составе платформы для разработки СБИС декодера ТВ-сигнала [8] в условиях работы с реальной коммутационной средой AMBA 3 AXI и центральным процессором типа ARM 1176JZ, работающим под управлением операционной системы Linux.
В результате работы с ПЛИС-прототипом СФ-блока был создан программный драйвер блока демультиплексирования транспортного потока для операционной систем Linux, который был успешно интегрирован в подсистему Linux DVB. Это позволяет легко встраивать разработанный блок в конвейер обработки данных MPEG для просмотра телевизионных программ.
Разработка СФ-блока проводилась при участии в Федеральной целевой программе "Научные и научно-педагогические кадры инновационной России".
Литература
1. ISO/IEC 13818-1 (ITU-T H.222.0), "Information technology – Generic coding of moving pictures and associated audio information: systems", 2002.
2. Шевченко П., Шкуренко А. Декодер цифрового телевизионного сигнала высокой четкости: система на кристалле. – ЭЛЕКТРОНИКА: НТБ, 2007, №8, с.62.
3. EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", 2005.
4. ETSI TS 101 154, "Digital Video Broadcasting (DVB). Implementation Guidelines for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream.", 2009
5. ARM, "AMBA 3 AXI Version 1.0 Protocol Specification", 2004.
6. ARM, "AMBA 3 APB Version 1.0 Protocol Specification", 2004.
7. EN 50083-9, "Cable networks for television signals, sound signals and interactive services Part 9: Interfaces for CATV/SMATV head ends and similar professional equipment for DVB/MPEG-2 transport streams", 2002.
8. Шевченко П. Платформа для разработки СБИС декодера ТВ-сигнала. – ЭЛЕКТРОНИКА: НТБ, 2010, №3, с.60.
Отзывы читателей
