Структура mpeg-таблицы
Изобретение относится к системам цифрового телевидения, и в частности, к структуре данных, MPEG-таблице и способам, связанным с этими данными и/или MPEG-таблицами. Техническим результатом является обеспечение универсальности структуры данных, используемых для передачи информации в системах цифрового телевидения. Технический результат достигается тем, что предложен транспортный поток данных для передачи по каналу связи, приема и обработки приемником-декодером, содержащий таблицу, содержащую заголовок (400) и информационную часть, отличающийся тем, что информационная часть таблицы включает в себя дескрипторы (406), соответствующие первому циклу (408) дескрипторов, и переменной длины цикл (410) с элементами (412) данных, каждый из которых включает в себя идентификатор элемента данных и цикл (414) дескрипторов, содержащий дескрипторы (416), уникальные для данного элемента данных (412), причем информационная часть таблицы включает в себя второй заголовок (404) и вторую информационную часть, и этот второй заголовок (404) включает в себя, по меньшей мере, одно из следующего: информацию, касающуюся сжатия данной таблицы; информацию, касающуюся шифрования данной таблицы; информацию, касающуюся приоритета; информацию, касающуюся формата синтаксического анализа; поле расширения фильтра. 5 з.п. ф-лы, 11 ил., 42 табл.
Аспекты настоящего изобретения относятся к структуре данных, MPEG-таблице и способам, связанным с этими данными и/или MPEG-таблицами, к устройству для осуществления таких способов, синтаксическому анализатору, приемнику-декодеру, передатчику, системе вещания, машиночитаемому носителю и сигналу.
Аспекты настоящего изобретения относятся к процессору универсальных MPEG-таблиц для обработки пакетов транспортного потока. Изобретение находит особое применение в приемнике-декодере для системы передачи цифровых данных, в частности, для использования в системе цифрового телевидения.
Термин "система цифрового телевидения", как он используется в данном тексте, охватывает любую спутниковую, наземную, кабельную или другую систему.
Термин "приемник-декодер", как он используется в данном тексте, может означать приемник для приема как закодированных, так и незакодированных сигналов, например, телевизионных и/или радиосигналов, которые могут транслироваться или передаваться какими-либо другими средствами. Данный термин может также обозначать декодер для декодирования принятых сигналов. Варианты исполнения таких приемников-декодеров могут включать в себя декодер, совмещенный с приемником, для декодирования принимаемых: сигналов, как, например, в "телевизионной приставке" (set-top box, STB), декодер, функционирующий в сочетании с физически отдельным приемником, или декодер, снабженный дополнительными функциями, такими как Web-браузер, видеомагнитофон или телевизор.
Термин MPEG относится к стандартам передачи данных, разработанным рабочей группой "Экспертная группа по кинематографии" Международной организации стандартизации и, в особенности, но не исключительно, к стандарту MPEG-2, разработанному для приложений цифрового телевидения и изложенному в документах ISO 13818-1, ISO 13818-2, ISO 13818-3 и ISO 13818-4. В контексте настоящей патентной заявки данный термин охватывает все варианты, модификации или усовершенствования форматов MPEG, применимые в области передачи цифровых данных.
Согласно первому аспекту настоящего изобретения предлагается структура данных для включающей в себя информационную часть секции приватной MPEG-таблицы, включающая спецификатор размера, характеризующий размер упомянутой секции или упомянутой информационной части, причем информационная часть содержит по меньшей мере один блок данных, и каждый из блоков данных включает в себя отдельный спецификатор размера, характеризующий размер данного блока.
Используя дополнительно к спецификатору, обычно предусматриваемому в секции таблицы, отдельный спецификатор размера, характеризующий размер конкретного блока данных, можно избежать необходимости каждый раз предусматривать различную структуру секции приватной MPEG-таблицы, поскольку становится возможным определить универсальную структуру данных. Кроме того, может быть обеспечена обратная совместимость секции таблицы, поскольку обычный спецификатор размера может быть сохранен.
Как известно, предусмотренный стандартом MPEG спецификатор размера, упомянутый выше, задает размер секции, определяемый как количество байтов секции, следующих за спецификатором размера. Однако другие характеристики размера секции или информационной части также охватываются объемом данного изобретения.
В частности, информационная часть предпочтительно включает в себя несколько блоков данных, каждый из которых включает в себя один из таких отдельных спецификаторов размера. Благодаря этому становится возможной реализация более сложных структур данных.
Согласно еще одному аспекту изобретения предлагается структура данных для включающей в себя информационную часть секции приватной MPEG-таблицы, включающая несколько блоков данных, каждый из которых включает в себя спецификатор размера, характеризующий размер своего блока.
Предлагаемая структура предпочтительно дополнительно включает список блоков.
Благодаря этому становится возможной реализация еще более сложных структур данных. Список может содержать один блок, или несколько (или даже множество) блоков, или не содержать ни одного блока.
Предпочтительно такой список включает в себя спецификатор списка, характеризующий суммарный размер блоков в этом списке. Благодаря этому сможет быть сохранена возможность синтаксического анализа предлагаемой структуры данных. Спецификатор списка может, например, задавать количество соответствующих блоков или их суммарную длину.
Предлагаемая структура предпочтительно включает несколько таких списков. Благодаря этому становится возможной реализация еще более сложных структур данных.
Предпочтительно предлагаемая структура дополнительно включает по меньшей мере один блок, данные которого являются общими для таких нескольких списков. Благодаря этому может быть повышена универсальность структуры данных.
С этой же целью блок или каждый блок в таком списке содержит данные, уникальные для своего списка.
Разумеется, будет понятно, что в данном контексте ссылка на список включает ссылку на то, что этот список представляет.
Предлагаемая структура предпочтительно включает несколько блоков в таком списке.
Для расширения функциональных возможностей, обеспечиваемых с помощью структуры данных, предлагаемая структура данных предпочтительно дополнительно включает идентификатор, характеризующий содержимое соответствующего списка.
Для облегчения синтаксического анализа предлагаемой структуры данных упомянутый спецификатор размера размещен в заголовочной области блока.
Предпочтительно по меньшей мере один такой блок включает в себя тег, характеризующий содержимое данного блока.
Соответственно, является возможным выделение или фильтрование блока с требуемыми данными. В зависимости от требований, тег может содержать любую информацию, касающуюся содержимого блока.
Предпочтительный вариант осуществления структуры данных для приватной MPEG-таблицы включает только одну описанную выше структуру.
Альтернативный вариант осуществления структуры данных для приватной MPEG-таблицы включает несколько описанных выше структур.
Таким образом, можно определить две универсальные структуры данных, каждая из которых может иметь одну-единственную общую структуру. В зависимости от обстоятельств может использоваться та или иная из этих двух универсальных структур.
Предлагаемая структура предпочтительно включает стандартный MPEG-заголовок и дополнительный заголовок.
Предпочтительно упомянутый дополнительный заголовок включает в себя флаг, отражающий определенное состояние, относящееся к преобразованию данных. Например, флаг может указывать на определенное состояние, относящееся к сжатию или шифрованию данных.
В альтернативном варианте, или же дополнительно, упомянутый дополнительный заголовок может включать в себя флаг, отражающий разновидность преобразования, которому была подвергнута информационная часть.
Согласно еще одному аспекту изобретения предлагается способ компоновки приватной MPEG-таблицы, согласно которому берут информационную часть и добавляют флаг, отражающий определенное состояние, относящееся к преобразованию информационной части, или отражающий разновидность преобразования информационной части.
Описанные выше флаги можно впоследствии использовать в процессоре (таком как приемник-декодер) для определения такого состояния или разновидности преобразования. Например, такой флаг можно использовать для различения сжатых и несжатых таблиц, или для различения зашифрованных и нешифрованных таблиц. Использование флагов также позволит использовать различные алгоритмы преобразования. Благодаря этому обеспечивается большая гибкость, например, позволяя применять разные алгоритмы к данным различных видов.
Предпочтительно упомянутая информационная часть является преобразованной с применением такого преобразования как сжатие или шифрование. Предпочтительно упомянутый стандартный заголовок и дополнительный заголовок являются несжатыми и нешифрованными. Благодаря этому обеспечивается совместимость с имеющимся системным аппаратным и программным обеспечением.
Предпочтительно дополнительный заголовок включает в себя спецификатор фильтра, и/или поле для указания на разновидность синтаксического анализатора, и/или поле для указания приоритета, с которым должна обрабатываться данная секция приватной таблицы. Как правило, поле для указания на разновидность синтаксического анализатора является первым полем дополнительного заголовка.
Согласно еще одному аспекту изобретения предлагается структура данных для секции приватной MPEG-таблицы, включающая стандартный MPEG-заголовок, дополнительный заголовок и информационную часть.
Наличие стандартного MPEG-заголовка может обеспечить совместимость с применяемыми в настоящее время секциями приватной таблицы, тогда как наличие дополнительного заголовка обеспечивает возможность увеличения функциональных возможностей, обеспечиваемых при применении таких секций таблицы.
Дополнительный заголовок предпочтительно включает в себя флаг, отражающий определенное состояние, относящееся к преобразованию информационной части, или отражающий разновидность преобразования информационной части.
Дополнительный заголовок предпочтительно включает в себя флаг, отражающий определенное состояние, относящееся к сжатию данных. Таким образом, могут быть сокращены потребности в полосе пропускания. Предпочтительно стандартный заголовок и дополнительный заголовок находятся в несжатом виде.
Дополнительный заголовок может также включать в себя флаг, отражающий определенное состояние, относящееся к шифрованию данных. Соответственно, такая секция приватной таблицы может быть считана только теми лицами, которые обладают кодом шифрования. Предпочтительно стандартный заголовок и дополнительный заголовок находятся в незашифрованном виде.
Дополнительный заголовок предпочтительно дополнительно включает в себя спецификатор фильтра. Благодаря этому могут быть расширены функциональные возможности по фильтрованию данных.
Дополнительный заголовок предпочтительно включает поле для указания разновидности синтаксического анализатора. Благодаря этому может быть повышена универсальность.
Для облегчения синтаксического анализа поле, указывающее тип синтаксического анализатора, является первым полем дополнительного заголовка.
Также для расширения функциональных возможностей дополнительный заголовок включает поле для указания приоритета, с которым должна обрабатываться данная секция приватной таблицы. Например, если одновременно принимаются несколько таблиц одного вида, поле приоритета может быть использовано для определения порядка, в котором они будут обрабатываться.
Согласно еще одному аспекту изобретения предлагается способ преобразования приватной MPEG-таблицы, содержащей информационную часть, включающий сжатие информационной части, для формирования преобразованной информационной части.
Согласно еще одному аспекту изобретения предлагается способ преобразования приватной MPEG-таблицы, содержащей информационную часть, включающий декомпрессию информационной части, для формирования преобразованной информационной части.
Согласно еще одному аспекту изобретения предлагается способ преобразования приватной MPEG-таблицы, содержащей информационную часть, включающий шифрование информационной части для формирования преобразованной информационной части.
Согласно еще одному аспекту изобретения предлагается способ преобразования приватной MPEG-таблицы, содержащей информационную часть, включающий дешифрование информационной части для формирования преобразованной информационной части.
Предлагаемый способ дополнительно включает добавление флага, отражающего определенное состояние, относящееся к преобразованию, осуществленному с информационной частью, или отражающего разновидность преобразования, осуществленного с информационной частью.
Согласно еще одному аспекту изобретения предлагается способ преобразования нескольких блоков данных, включающий компоновку этих блоков данных для формирования промежуточного блока и преобразование этого промежуточного блока для формирования преобразованного блока.
Вместо преобразования каждого блока данных отдельно и независимо согласно этому аспекту изобретения упомянутые блоки данных обрабатывают совокупно как промежуточный блок. Благодаря этому могут быть сокращены необходимые вычислительные ресурсы. Примеры типичных процессов преобразования включают сжатие (компрессию), декомпрессию, шифрование и дешифрование.
Предпочтительно преобразование включает разбивку блока на несколько подблоков и, необязательно, добавление к каждому подблоку флага, отражающего определенное состояние, относящееся к преобразованию, или отражающего разновидность преобразования.
Преобразованный блок может передаваться получателю и/или приниматься от передатчика.
Как правило такой способ включает также еще одно преобразование упомянутого преобразованного блока, обычно обратное первому преобразованию.
Такое еще одно преобразование обычно включает компоновку подблоков для формирования дополнительного промежуточного блока и еще одно преобразование этого дополнительного промежуточного блока.
В каждый подблок может быть добавлен стандартный заголовок.
Обычно операция компоновки включает введение в промежуточный блок спецификаторов размера, каждый из которых указывает размер соответствующего блока данных. Благодаря этому обеспечивается возможность выделения блоков данных из промежуточного блока на следующей стадии обработки. Каждый спецификатор может предшествовать соответствующему ему блоку данных или может быть поставлен в соответствие соответствующему ему блоком данных каким-либо другим образом.
В альтернативном варианте спецификатор размера в преобразованном блоке может анализироваться для определения того, каким образом данный блок следует разбивать на подблоки. Благодаря этому может быть восстановлена исходная структура блока данных.
Такое преобразование может представлять собой сжатие (компрессию), декомпрессию, шифрование или дешифрование.
Обычно упомянутыми блоками данных являются информационные части приватной MPEG-таблицы.
Преобразованный блок обычно также используется для формирования части преобразованной приватной MPEG-таблицы.
Обычно приватная MPEG-таблица содержит несколько секций, каждая из которых включает в себя стандартный заголовок и информационную часть, а преобразованная приватная MPEG-таблица содержит несколько секций, каждая из которых включает в себя стандартный заголовок и преобразованную информационную часть, образуемую преобразованным блоком.
По меньшей мере часть заголовка в преобразованной приватной MPEG-таблице может быть по существу идентична части стандартного заголовка в приватной MPEG-таблице.
Предлагаемый способ может дополнительно включать введение в преобразованную приватную MPEG-таблицу некоторого значения, отражающего определенное состояние, относящееся к преобразованию, или отражающего разновидность преобразования.
Предлагаемый способ предпочтительно включает операцию добавления адресной информации, идентифицирующей приемник-декодер или группу приемников-декодеров, который(ые) является(ются) запланированным получателем данных.
Адресная информация может идентифицировать конкретный приемник-декодер или группу приемников-декодеров непосредственно, например, путем перечисления номеров смарт-карт идентифицируемых приемников-декодеров. В альтернативном варианте, адресная информация может идентифицировать приемник(и)-декодер(ы) некоторым косвенным образом, например, идентифицируя программную или аппаратную платформу.
Согласно еще одному аспекту изобретения предлагается структура данных, включающая несколько сжатых блоков данных, причем эти сжатые блоки данных могут быть декомпрессированы для получения нескольких декомпрессированных блоков данных, каждый из которых будет содержать информационную часть и спецификатор размера, определяющий размер информационной части.
Как правило, количество декомпрессированных блоков данных превышает количество сжатых блоков данных. Благодаря этому снижаются вычислительные затраты.
Как правило, структура данных дополнительно включает заголовок, поставленный в соответствии каждому сжатому блоку данных.
Согласно еще одному аспекту изобретения предлагается структура данных, включающая несколько зашифрованных блоков данных, причем эти зашифрованные блоки данных могут быть дешифрованы для получения нескольких дешифрованных блоков данных, каждый из которых будет содержать информационную часть и спецификатор размера, определяющий размер информационной части.
Обычно такая структура данных дополнительно включает заголовок, поставленный в соответствии каждому дешифрованному блоку данных.
Как правило упомянутый заголовок представляет собой стандартный MPEG-заголовок.
Согласно еще одному аспекту изобретения предлагается сжатая секция приватной MPEG-таблицы и/или сжатая приватная MPEG-таблица. Сжатие стандартных приватных MPEG-таблиц позволяет экономно использовать память и полосу пропускания.
Согласно еще одному аспекту изобретения предлагается зашифрованная секция приватной MPEG-таблицы и/или зашифрованная приватная MPEG-таблица.
Согласно еще одному аспекту изобретения предлагается секция приватной MPEG-таблицы или приватная MPEG-таблица, содержащая адресную информацию, идентифицирующую приемник-декодер или группу приемников-декодеров, который(ые) является(ются) запланированным получателем данной секции приватной MPEG-таблицы.
Адресная информация может идентифицировать определенный приемник-декодер или группу приемников-декодеров непосредственно, например, путем перечисления номеров смарт-карт идентифицируемых приемников-декодеров. В альтернативном варианте, адресная информация может идентифицировать приемник(и)-декодер(ы) некоторым косвенным образом, например, идентифицируя программную или аппаратную платформу.
Согласно еще одному аспекту изобретения предлагается способ компоновки секции приватной MPEG-таблицы, включающий введение адресной информации, идентифицирующей приемник-декодер или группу приемников-декодеров, который(ые) является(ются) запланированным получателем данной секции приватной MPEG-таблицы.
Согласно еще одному аспекту изобретения предлагается устройство для компоновки приватной MPEG-таблицы, содержащее средство для выдачи преобразованной информационной части, являющейся результатом некоторого преобразования, и средство для добавления флага, указывающего разновидность преобразования.
Согласно еще одному аспекту изобретения предлагается устройство для преобразования приватной MPEG-таблицы, содержащей информационную часть, содержащее средство для сжатия, декомпрессии, шифрования и/или дешифрования информационной части для формирования преобразованной информационной части.
Согласно еще одному аспекту изобретения предлагается устройство для преобразования нескольких блоков данных, содержащее средство для компоновки блоков данных для формирования промежуточного блока и средство для преобразования этого промежуточного блока для формирования преобразованного блока.
Согласно еще одному аспекту изобретения предлагается устройство для компоновки секции приватной MPEG-таблицы, содержащее средство для введения адресной информации, идентифицирующей приемник-декодер или группу приемников-декодеров, который(ые) является(ются) запланированным получателем данной секции приватной MPEG-таблицы.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор для синтаксического анализа включающей в себя информационную часть секции приватной MPEG-таблицы, содержащий средство (например, в виде процессора с памятью) для выполнения синтаксического анализа данных с получением формата, предусматривающего спецификатор размера, характеризующий размер упомянутой секции или упомянутой информационной части, причем информационная часть включает в себя по меньшей мере один блок данных, каждый из которых включает в себя дополнительный спецификатор размера, характеризующий размер данного блока.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому информационная часть включает в себя несколько блоков данных, каждый из которых включает в себя один из таких дополнительных спецификаторов размера.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор для синтаксического анализа включающей в себя информационную часть секции приватной MPEG-таблицы, причем эта информационная часть включает в себя несколько блоков данных, каждый из которых, в свою очередь, включает в себя спецификатор размера, характеризующий размер соответствующего ему блока.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего также список блоков.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому такой список включает в себя спецификатор списка, характеризующий суммарный размер блоков в данном списке.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего несколько таких списков.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего также по меньшей мере один блок, имеющий данные, общие для таких нескольких списков.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому каждый блок в таком списке имеет данные, уникальные для своего списка.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных таким образом, что такие уникальные данные перекрывают такие общие данные.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего несколько блоков в таком списке.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего также идентификатор, характеризующий содержимое соответствующего списка.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому спецификатор размера размещается в заголовочной части блока.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому по меньшей мере один такой блок включает в себя тег, характеризующий его содержимое.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего только одну MPEG-секцию.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего несколько MPEG-секций.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, предусматривающего стандартный MPEG-заголовок и дополнительный заголовок.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор для синтаксического анализа секции приватной MPEG-таблицы, содержащий средство (например, в виде процессора с памятью) для выполнения синтаксического анализа данных с получением формата, предусматривающего стандартный MPEG-заголовок, дополнительный заголовок и информационную часть.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок включает в себя флаг, отражающий определенное состояние, относящееся к преобразованию, или отражающий разновидность преобразования.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок включает в себя флаг, отражающий определенное состояние, относящееся к сжатию данных.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок включает в себя флаг, отражающий определенное состояние, относящееся к шифрованию данных.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок включает в себя спецификатор фильтра.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок содержит поле для указания разновидности синтаксического анализатора.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому поле для указания разновидности синтаксического анализатора является первым полем дополнительного заголовка.
Предпочтительно синтаксический анализатор выполнен с возможностью выполнения синтаксического анализа данных с получением формата, согласно которому дополнительный заголовок включает в себя поле для указания приоритета, с которым должна обрабатываться данная секция приватной таблицы.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор для синтаксического анализа включающей в себя стандартный MPEG-заголовок и информационную часть секции приватной MPEG-таблицы, причем стандартный MPEG-заголовок включает в себя поле расширения идентификатора таблицы (TID), содержащий средство (например, в виде процессора с памятью) для вывода значения поля расширения TID. В существующих системах поле расширения TID игнорировалось.
Согласно еще одному аспекту изобретения предлагается устройство для обработки данных, содержащее средство (например, в виде процессора с памятью) для преобразования данных из некоторого заданного формата в формат, соответствующий описанной выше структуре данных, и наоборот.
Согласно еще одному аспекту изобретения предлагается устройство для компоновки приватной MPEG-таблицы, содержащее средство (например, в виде процессора с памятью) для выдачи информационной части и средство (например, в виде процессора с памятью) для добавление флага, отражающего определенное состояние, относящееся к преобразованию информационной части, или отражающего разновидность преобразования информационной части.
Предпочтительно упомянутая информационная часть является преобразованной информационной частью, подвергнутой некоторому преобразованию.
Согласно еще одному аспекту изобретения предлагается устройство для преобразования приватной MPEG-таблицы, содержащей информационную часть, содержащее средство (например, в виде процессора с памятью) для сжатия (компрессии), декомпрессии, шифрования или дешифрования информационной части для получения преобразованной информационной части.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для добавления флага, отражающего определенное состояние, относящееся к преобразованию преобразованной информационной части.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для добавления флага, отражающего разновидность преобразования преобразованной информационной части.
Согласно еще одному аспекту изобретения предлагается устройство для выполнения некоторого преобразования над несколькими блоками данных, содержащее средство (например, в виде процессора с памятью) для компоновки этих блоков данных с формированием промежуточного блока и средство (например, в виде процессора с памятью) для преобразования этого промежуточного блока для получения преобразованного блока.
Предпочтительно упомянутое средство для преобразования содержит средство (например, в виде процессора с памятью) для разбивки блока на несколько подблоков.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для добавления флага, отражающего определенное состояние, относящееся к преобразованию данных в подблок.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для добавления флага, указывающего разновидность преобразования в подблок.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для передачи преобразованного блока получателю.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для приема преобразованного блока.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для выполнения над преобразованным блоком еще одного преобразования.
Предпочтительно упомянутое еще одно преобразование обратно упомянутому первому преобразованию.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для компоновки упомянутых подблоков с формированием еще одного промежуточного блока и средство (например, в виде процессора с памятью) для выполнения еще одного преобразования над этим еще одним промежуточным блоком.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для добавления в каждый подблок стандартного заголовка.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для введения в упомянутый промежуточный блок спецификаторов размера, каждый из которых задает размер соответствующего блока данных.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для анализа спецификатора размера в блоке для определения того, каким образом данный блок следует разбивать на подблоки.
Предпочтительно упомянутым преобразованием является сжатие (компрессия), декомпрессия, шифрование или дешифрование.
Предпочтительно упомянутыми несколькими блоками данных являются информационные части приватной MPEG-таблицы.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для формирования преобразованной приватной MPEG-таблицы, имеющей по меньшей мере одну преобразованную информационную часть, представленную таким преобразованным блоком.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для включения в преобразованную приватную MPEG-таблицу значения, указывающего на разновидность преобразования.
Предпочтительно устройство дополнительно содержит средство (например, в виде процессора с памятью) для включения в преобразованную приватную MPEG-таблицу значения, отражающего определенное состояние, относящееся к преобразованию преобразованной информационной части.
Предпочтительно предлагается приемник-декодер, включающий в себя вышеописанный синтаксический анализатор. Однако настоящее изобретение не ограничено приемником-декодером и может быть реализовано, например, в ПК.
Данные могут передаваться в вещательном потоке. Эти данные затем могут извлекаться из вещательного потока на приемной стороне.
В предпочтительно варианте осуществления предлагаемый способ реализуется в системе, включающей в себя центр цифрового вещания и множество приемников-декодеров.
Упомянутые данные затем могут применяться для разнообразных целей. Например, они могут включать в себя данные уведомления о действиях, предназначенные для управления какой-либо функцией приемника-декодера. В альтернативному варианте эти данные могут включать в себя данные ключа, предназначенные для применения приемником-декодером для получения доступа к системе условного доступа.
В альтернативном варианте упомянутые данные могут включать в себя информацию о программах для ее использования в системе "видео по запросу".
Предпочтительно упомянутые информационные части или блоки данных включают в себя информацию о программах, касающуюся по меньшей мере одного ресурса заданной категории, и эти информационные части или блоки данных сопровождаются спецификатором фильтра, содержащим идентификатор категории, указывающий такую категорию. Ресурс предпочтительно является телевизионной программой или другим коммерческим предложением, доступным в системе "видео по запросу", и ресурсы предпочтительно распределяются по категориям в соответствии с их содержимым; например, это может быть спортивная категория, фильмовая категория и так далее. Возможны также и подкатегории. Таким образом, по идентификатору категории можно выполнить фильтрование, что облегчит извлечение информации о ресурсах желаемой категории.
В альтернативном варианте, или же дополнительно, информационные части или блоки данных включают в себя информацию о программах, касающуюся некоторого ресурса, и информационные части или блоки данных сопровождаются спецификатором фильтра, включающим в себя идентификатор ресурса, идентифицирующий данный ресурс. Благодаря этому облегчается выделение информации по конкретному ресурсу.
Предпочтительно спецификатор фильтра представляет собой поле расширения TID секции MPEG-таблицы. Поскольку многие приемники-декодеры имеют средства для фильтрации секций MPEG-таблицы в соответствии с несколькими полями заголовка, в том числе - полем расширения TID, и поскольку такие средства часто реализуются в аппаратном обеспечении, такие приемники-декодеры смогут легче и быстрее выделять соответствующую информацию при таком использовании поля расширения TID.
Приемник-декодер предпочтительно содержит средство (например, в виде процессора с памятью) для приема значения поля расширения TID и для обработки такого значения.
Упомянутое средство для приема и обработки предпочтительно выполнено с возможностью обработки такого значения как уведомления для пользователя приемника-декодера.
Упомянутое средство для приема и обработки предпочтительно выполнено с возможностью обработки такого значения как данных, касающихся контента, принимаемого приемником-декодером.
Предпочтительно предлагается приемник-декодер, выполненный с возможностью приема и/или декодирования данных, имеющих структуру данных, описанную выше, или структуру данных, скомпонованную, обработанную или преобразованную как описано выше.
Передатчик выполнен с возможностью передачи данных в виде структуры данных, описанной выше, или структуры данных, скомпонованной, обработанной или преобразованной как описано выше.
Кроме того, предлагается система вещания, включающая в себя описанные выше приемник-декодер и передатчик.
Упомянутые данные в этой системе вещания предпочтительно являются данными условного доступа, причем система выполнена с возможностью передачи и приема таких данных на отдельном канале.
Предлагается также способ обработки данных, включающий преобразование таких данных из некоторого заданного формата в формат, соответствующий описанной выше структуре данных, и наоборот. Упомянутый заданный формат может быть любым форматом, в который (или из которого) может быть желаемо преобразовывать данные из формата, соответствующего (в формат, соответствующий) упомянутой выше структуре данных.
Согласно еще одному аспекту изобретения предлагается способ передачи приватной MPEG-таблицы, включающий преобразование приватной MPEG-таблицы с использованием описанного выше способа и передачу преобразованной таблицы.
Согласно еще одному аспекту предлагается способ приема приватной MPEG-таблицы, включающий прием приватной MPEG-таблицы и преобразование принятой таблицы с использованием описанного выше способа.
Предпочтительно упомянутые информационные части или блоки данных включают в себя данные уведомления о действиях, предназначенные для приема приемником-декодером и управления какой-либо функцией приемника-декодера.
Предпочтительно информационные части или блоки данных включают в себя информацию о программах для ее использования в системе "видео по запросу".
Предпочтительно информационные части или блоки данных содержат информацию о программах, касающуюся по меньшей мере одного ресурса заданной категории, и эти информационные части или блоки данных сопровождаются спецификатором фильтра, включающим в себя идентификатор категории, указывающий упомянутую категорию.
Предпочтительно информационные части или блоки данных включают в себя информацию о программах, касающуюся некоторого ресурса, и информационные части или блоки данных сопровождаются спецификатором фильтра, включающим в себя идентификатор ресурса, идентифицирующий данный ресурс.
Предпочтительно спецификатор фильтра представляет собой поле расширения TID секции MPEG-таблицы.
Предпочтительно информационные части или блоки данных включают в себя данные ключа, предназначенные для применения приемником-декодером для получения доступа к системе условного доступа.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор, содержащий средство (например, в виде процессора с памятью) для выполнения синтаксического анализа приватной MPEG-таблицы или секции таблицы, описанной выше, или для выполнения синтаксического анализа данных, соответствующих описанной выше структуре данных, или для выполнения синтаксического анализа данных, обработанных, скомпонованных или преобразованных описанным выше способом.
Согласно еще одному аспекту изобретения предлагается передатчик, выполненный с возможностью передачи приватной MPEG-таблицы или секции таблицы, описанных выше, или обработанных, скомпонованных или преобразованных описанными выше способами.
Согласно еще одному аспекту изобретения предлагается синтаксический анализатор, выполненный с возможностью осуществления описанного выше способа.
Согласно изобретению предлагается также способ, по существу как он описан в данном тексте со ссылками на прилагаемые графические фигуры, и устройство по существу как оно описано в данном тексте со ссылками на прилагаемые графические фигуры, будучи иллюстрируемым ими.
Изобретение распространяется на компьютерный программный продукт, выполненный с возможностью выполнения упомянутого выше способа.
Кроме того, изобретение распространяется на машиночитаемый носитель, заключающий в себе описанный выше синтаксический анализатор или описанное выше устройство.
Кроме того, изобретение распространяется на сигнал, являющийся материальным воплощением описанного синтаксического анализатора или устройства.
Согласно настоящему изобретению предлагается также компьютерная программа и компьютерный программный продукт для осуществления любого из описанных способов и/или для воплощения любого из описанных выше признаков устройства, а также машиночитаемый носитель с записанной на нем программой для осуществления любого из описанных способов и/или для воплощения любого из описанных признаков устройства.
Согласно изобретению предлагается также сигнал, заключающий в себе компьютерную программу для осуществления любого из описанных способов и/или для воплощения любого из описанных признаков устройства, способ передачи такого сигнала и компьютерный продукт, имеющий операционную систему, которая поддерживает компьютерную программу для осуществления любого из описанных способов и/или воплощения любого из описанных признаков устройства.
Признаки, реализованные аппаратно, обычно могут быть реализованы программно, и наоборот. Это следует учитывать при упоминании программных и аппаратных признаков и истолковывать такие упоминания соответствующим образом.
Любой признак одного аспекта изобретения может быть применен в других аспектах изобретения в любом подходящем сочетании. В частности, аспекты, касающиеся способов, могут быть применены в аспектах, касающихся устройств, и наоборот.
Ниже исключительно в качестве примера будут описаны предпочтительные особенности изобретения, со ссылками на прилагаемые графические фигуры, на которых:
фиг.1 - общая архитектура системы цифрового телевидения;
фиг.2 - архитектура системы условного доступа;
фиг.3 - общая форма сообщения EMM;
фиг.4 - типичная конфигурация системы SAS;
фиг.5 - подробная схема приемника-декодера;
фиг.6 - пять программных уровней приемника-декодера;
фиг.7а - иллюстрация связей между несколькими компонентами MPEG-потока;
фиг.7b - изображение того, как можно составить приложение из модулей/таблиц, которые, в свою очередь, могут быть составлены из секций;
фиг.7с - модуль каталога;
фиг.8 - структура данных в соответствии с одним вариантом осуществления изобретения;
фиг.9 - место синтаксического анализатора в телевизионной приставке;
фиг.10 - выбор таблицы уведомления о действиях;
фиг.11a - сжатие приватной таблицы;
фиг.11b - декомпрессия сжатой приватной таблицы.
Обзорное описание системы
На фиг.1 показана в общем виде система 1 цифрового телевидения. Настоящее изобретение предусматривает в основном обычную систему 2 цифрового телевидения, в которой для передачи сжатых цифровых сигналов используется известная система сжатия, соответствующая стандарту MPEG-2. Конкретнее, MPEG-2-компрессор 3 в центре вещания принимает поток цифровых сигналов (обычно поток видеосигналов). Компрессор 3 подключен к мультиплексору-скремблеру 4 посредством соединения 5.
Мультиплексор 4 получает множество других входных сигналов, компонует транспортный поток и передает сжатые цифровые сигналы в передатчик 6 центра вещания через соединение 7, которое, разумеется, может принимать самые разнообразные формы, включая телекоммуникационные каналы связи. Передатчик 6 передает электромагнитные сигналы по каналу 8 "Земля-спутник" на спутниковый транспондер 9, где их подвергают электронной обработке и вещают по виртуальному каналу 10 "спутник-Земля" в наземный приемник 12, обычно имеющий форму тарелки, принадлежащий или арендуемый конечным пользователем. Возможны, разумеется, и другие транспортные каналы для передачи данных, такие как наземное вещание, кабельная передача, комбинированные кабельно-спутниковые каналы, телефонные сети и т.п.
Сигналы, принятые приемником 12, передаются в совмещенный приемник-декодер 13, принадлежащий или арендуемый конечным пользователем и подключенный к телевизору 14 конечного пользователя. Приемник-декодер 13 декодирует сжатый MPEG-2 сигнал в телевизионный сигнал для телевизора 14. Хотя на фиг.1 показан отдельный приемник-декодер, он в равной степени может входить в состав интегрированного цифрового телевизора. Термин "приемник-декодер", как он применяется в данном тексте, охватывает и отдельный приемник-декодер, такой как приставка для телевизора (STB), и телевизор со встроенным приемником-декодером.
В многоканальной системе мультиплексор 4 обрабатывает аудио- и видеоинформацию, принимаемую из нескольких параллельных источников, и взаимодействует с передатчиком 6 для вещания этой информации по соответствующему количеству каналов. Дополнительно к аудиовизуальной информации в некоторые или во все эти каналы могут вводиться сообщения, или приложения, или цифровые данные любого другого рода, перемежаемые с передаваемой цифровой аудио- и видеоинформацией.
К мультиплексору 4 и приемнику-декодеру 13 подключена система 15 условного доступа, размещенная частично в центре вещания и частично в приемнике-декодере. Она позволяет конечному пользователю получать доступ к передачам цифрового телевидения одного или нескольких провайдеров вещания. В приемник-декодер 13 может устанавливаться смарт-карта, способная дешифрировать сообщения, относящиеся к коммерческим предложениям (т.е. одной или нескольким телевизионным программам, продаваемым провайдером вещания). С помощью приемника-декодера 13 и смарт-карты конечный пользователь может покупать коммерческие предложения либо в режиме подписки, либо в режиме оплаты за отдельный просмотр (PPV).
Как упоминалось выше, передаваемые в упомянутой системе программы скремблируются мультиплексором 4, причем условия и ключи шифрования, применяемые к конкретной передаче, определяются системой 15 условного доступа. Передача скремблированных данных этим способом хорошо известна в области систем платного телевидения. Обычно скремблированные данные передают вместе с управляющим словом, предназначенным для дескремблирования этих данных, причем само управляющее слово шифруют с помощью так называемого рабочего ключа и передают в зашифрованной форме.
Скремблированные данные и зашифрованное управляющее слово затем принимаются приемником-декодером 13, имеющим доступ к эквиваленту рабочего ключа, сохраненному на смарт-карте, установленной в приемнике-декодере, чтобы дешифрировать упомянутое зашифрованное управляющее слово и после этого дескремблировать переданные данные. Оплативший подписку абонент получит, например, в передаваемом ежемесячно EMM (сообщении условного доступа), рабочий ключ, необходимый для дешифрирования зашифрованного управляющего слова, без чего невозможен просмотр передачи.
Интерактивная система 16, также подключенная к мультиплексору 4 и приемнику-декодеру 13 и также размещенная частично в центре вещания и частично в приемнике-декодере, позволяет конечному пользователю в интерактивном режиме взаимодействовать с различными приложениями через обратный модемный канал 17. Упомянутый обратный модемный канал может быть, например, каналом коммутируемой телефонной сети общего пользования (PSTN) (например, модемным обратным каналом) или внеполосным каналом (ООВ). Этот обратный модемный канал может также использоваться для обмена информацией, используемого системой 15 условного доступа.
Система условного доступа
Как показано на фиг.2, в общем, система 15 условного доступа включает в себя систему санкционирования подписчиков (SAS - Subscriber Authorisation System) 30. SAS 30 соединена с одной или несколькими системами управления подписчиками (SMS - Subscriber Management Systems) 32, по одной SMS для каждого провайдера вещания, посредством соединения 34, которое может быть TCP/IP-каналом или каналом другого типа. В альтернативном варианте одна SMS может использоваться совместно двумя коммерческими операторами, либо один оператор может использовать две SMS и т.п.
Первые шифрующие устройства в виде блоков шифрования 36, использующих "материнские" смарт-карты 38, подключены к SAS посредством соединения 40. Вторые шифрующие устройства, также в виде блоков шифрования 42, использующих материнские смарт-карты 44, подключены к мультиплексору 4 посредством соединения 46. В приемник-декодер 13 устанавливается "дочерняя" смарт-карта 48. Приемник-декодер подключен непосредственно к SAS 30 через серверы 50 связи и модемный обратный канал 17. Наряду с другими сигналами SAS передает в дочернюю смарт-карту права подписки по запросу.
Смарт-карты содержат конфиденциальную информацию от одного или нескольких коммерческих операторов. "Материнская" смарт-карта зашифровывает сообщения различных видов, а "дочерние" смарт-карты дешифрируют эти сообщения, если у них есть на это права.
Как показано на фиг.2, в центре вещания цифровой видеосигнал сначала сжимается (или скорость передачи битового потока снижается) с помощью MPEG-2-компрессора 3. Этот сжатый сигнал затем передается в мультиплексор-скремблер 4 для мультиплексирования с другими данными, такими как другие сжатые данные.
Скремблер генерирует управляющее слово, используемое в процессе скремблирования и включаемое в MPEG-2-поток в мультиплексоре 4. Это управляющее слово генерируется внутри системы и позволяет приемнику-декодеру 13 конечного пользователя дескремблировать программу.
В MPEG-2-поток также вводят критерии доступа, указывающие на режим, в котором данная программа предлагается потребителю. Программа может предлагаться в одном из нескольких режимов "подписки" и/или одном из нескольких режимов "оплаты за отдельный просмотр" (PPV). В режиме подписки конечный пользователь подписывается на одно или несколько коммерческих предложений, или групп ("букетов") каналов, получая тем самым право смотреть любой канал, входящий в эти группы каналов. В PPV-режиме конечному пользователю предоставляется возможность покупать передачи по желанию.
И управляющее слово, и критерии доступа используются для формирования сообщения управления правами (ЕСМ); это сообщение передается для какой-либо одной скремблированной программы. ЕСМ содержит управляющее слово (позволяющее дескремблировать данную программу) и критерии доступа к этой вещаемой программе. Критерии доступа и управляющее слово передаются в упомянутый второй блок шифрования 42 через соединение 46. В этом блоке ЕСМ генерируется, шифруется и передается назад в мультиплексор-скремблер 4.
Каждый сервис, вещаемый провайдером вещания в потоке данных, включает в себя несколько отдельных компонент; например, телевизионная программа включает в себя видеокомпоненту, звуковую компоненту, компоненту субтитров и т.п. Каждая из этих компонент сервиса скремблируется и шифруется для последующего вещания отдельно. Для каждой скремблированной компоненты сервиса требуется отдельное ЕСМ.
Мультиплексор 4 получает электрические сигналы, содержащие зашифрованные EMM из SAS 30, зашифрованные ЕСМ из второго блока шифрования 42 и сжатые программы из компрессора 3. Мультиплексор 4 скремблирует программы и передает скремблированные программы, зашифрованные EMM и зашифрованные ЕСМ как электрические сигналы в систему 54 вещания, которая может быть, например, спутниковой системой, показанной на фиг.1, или иной системой вещания. Приемник-декодер 13 демультиплексирует эти сигналы, чтобы получить скремблированные программы, зашифрованные EMM и зашифрованные ЕСМ.
Приемник-декодер принимает этот вещательный сигнал и извлекает поток MPEG-2 данных. Если программа скремблирована, приемник-декодер 13 извлекает соответствующее ЕСМ из MPEG-2 потока и передает это ЕСМ в "дочернюю" смарт-карту 48 конечного пользователя. Она устанавливается в корпус приемника-декодера 13. Дочерняя смарт-карта 48 контролирует, имеет ли данный конечный пользователь право на дешифрирование этого ЕСМ и доступ к данной программе. Если не имеет, в приемник-декодер 13 передается отрицательный ответ, указывающий на то, что данную программу нельзя дескремблировать. Если конечный пользователь имеет соответствующие права, ЕСМ дешифрируется и извлекается управляющее слово. Декодер 13 может тогда дескремблировать эту программу, используя это управляющее слово. MPEG-2 поток подвергается декомпрессии и преобразуется в видеосигнал для передачи в телевизор 14.
Если программа нескремблирована, сообщения ЕСМ в MPEG-2 потоке не передаются, и приемник-декодер 13 подвергает данные декомпрессии и преобразует принятый сигнал в видеосигнал для передачи в телевизор 14.
Система управления подписчиками (SMS) 30 включает в себя базу данных 52, которая управляет, помимо прочего, всеми файлами конечных пользователей, коммерческими предложениями (такими как тарифы и стимулирование потребления), подпиской, сведениями по PPV и данными, касающимися потребления конечными пользователями и санкционирования. SMS может быть физически удалена от SAS.
SMS 32 передает в SAS 30 сообщения, которые инициируют изменение или создание сообщений условного доступа (EMM), предназначающихся для передачи конечным пользователям. SMS 32 также передает в SAS 30 сообщения, которые не предполагают ни изменения, ни создания EMM, но лишь инициируют изменение статуса конечного пользователя (относительно прав, предоставляемых данному конечному пользователю при заказе продукта, или суммы, которая будет списана со счета данного конечного пользователя). SAS 30 также передает сообщения (обычно запрашивающие информацию, такую как информация обратного вызова или биллинговая информация) в SMS 32, из чего явствует, что соединение между двумя этими системами является двухсторонним.
Сообщения условного доступа (EMM)
EMM - это сообщение, соответствующее отдельному конечному пользователю (подписчику, или абоненту) или некоторой группе конечных пользователей, в отличие от ЕСМ, которое соответствует одной скремблированной программе или группе скремблированных программ, входящих в состав одного и того же коммерческого предложения.
Возможны различные типы EMM. Индивидуальные EMM предназначаются отдельным подписчикам, и они, как правило, используются при предоставлении PPV-сервисов; такие EMM содержат идентификатор группы и указатель положения данного подписчика в этой группе. Так называемые "групповые" EMM предназначаются группам, скажем, из 256 отдельных пользователей, и, как правило, используются при администрировании тех или иных подписных сервисов. Аудиторные EMM предназначаются для всей аудитории. "Аудитория" - это все подписчики, обладающие смарт-картами с одинаковым идентификатором оператора (OPI). И, наконец, "уникальные" EMM предназначаются смарт-картам с конкретным идентификатором.
Ниже, со ссылками на фиг.3, будет описана общая структура EMM, используемого в предпочтительных вариантах осуществления. По сути, EMM, которое представляет собой последовательность битов цифровых данных, включает в себя заголовок 60, собственно EMM 62 и подпись 64. В свою очередь заголовок 60 включает в себя идентификатор 66 типа, указывающий тип данного EMM, идентификатор 68 длины, указывающий длину данного EMM, необязательный адрес 70 для данного EMM, идентификатор 72 оператора и идентификатор 74 ключа. Наконец, подпись 64, которая также является необязательной, обеспечивает возможность осуществления ряда проверок для обнаружения повреждения остальных данных, содержащихся в EMM. Упомянутый идентификатор типа в заголовке идентифицирует данное сообщение как EMM.
Система санкционирования подписчиков (SAS)
Сообщения, сформированные SMS 32, передаются через соединение 34 в систему санкционирования подписчиков (SAS) 30, которая, в свою очередь, генерирует сообщения, подтверждающие прием сообщений, сформированных SMS 32, и передает эти подтверждения в SMS 32. Сообщения, которые могут передаваться в SAS, включают в себя приостановку подписки некоторого подписчика, вследствие, например, отсутствия оплаты; изменения в отношении подписчика, например, добавление или удаление определенных коммерческих предложений; предоставление права, например, на конкретную программу (событие) в PPV-режиме.
SAS 30 ведет и поддерживает базы данных, в которых хранится статус всех подписчиков, определенный SMS 32. В соответствии с этим статусом и на основании различных сообщений, передаваемых SMS, SAS формирует EMM для смарт-карт подписчиков. Эти EMM зашифровываются блоками шифрования 36 SAS и передаются в мультиплексор 4. Чтобы обеспечить гарантированный прием сообщений EMM подписчиком, SAS передает эти сообщения циклически. Периодичность передачи зависит от типа EMM, но обычно составляет от 30 секунд до 30 минут.
Типичная конфигурация SAS 30 показана на фиг.4. В общем, SAS 30 включает в себя область ветви подписки 100, для предоставления прав в режиме подписки и ежемесячного автоматического обновления этих прав, область ветви PPV 102, для предоставления прав на PPV-передачи, и инжектор 104 EMM, для подачи сообщений EMM, формируемых областью ветви подписки и областью ветви PPV, в мультиплексор-скремблер 4, таким образом вводя сообщения EMM в MPEG-поток. Если должны предоставляться другие права, например, PPF-права (PPF - Pay Per File, пофайловая оплата) для случая загрузки компьютерного программного обеспечения в персональный компьютер пользователя, предусматриваются также другие подобные области.
Одна из функций SAS 30 состоит в управлении правами доступа к телевизионным программам, предлагаемым в качестве коммерческих предложений в режиме подписки или продаваемых как PPV-передачи в соответствии с различными режимами продажи (режим предварительного заказа, режим импульсной покупки). В соответствии с этими правами и информацией, полученной из SMS 32, SAS 30 формирует сообщения EMM для соответствующего подписчика.
Область ветви подписки 100 содержит интерфейс 106 для приема команд (CI - Command Interface), сервер 108 технического управления подписчиками (STM - Subscriber Technical Management), генератор 110 сообщений (MG - Message Generator) и блок шифрования 36. Область ветви PPV 102 содержит сервер 112 санкционирования (AS - Authorisation Server), серверы 114, 116 баз данных (DBAS), содержащие реляционные базы данных для хранения соответствующих сведений о конечных пользователях, сервер 118 централизованной обработки заказов (OCS - Order Centralized Server), сервер 120 вещателя программ (SPB - Server for Programme Broadcaster), генератор 122 сообщений (MG), функции которого, в сущности, такие же, как и у генератора сообщений области ветви подписки, и блок шифрования 36.
Инжектор 104 EMM содержит несколько блоков выдачи сообщений (ME - Message Emitters) 124, 126, 128 и 130 и программных мультиплексоров (SMUX - Software Multiplexers) 132 и 134. В предпочтительном варианте осуществления предусматриваются два ME, 124 и 126, для генератора 110 сообщений, и два ME, 128 и 130, для генератора 122 сообщений. ME 124 и 126 подключены к SMUX 132, тогда как ME 128 и 130 подключены к SMUX 134.
Генераторы 110 и 122 сообщений преобразуют команды, выдаваемые, соответственно, STM 108 и OCS 118, в сообщения EMM. Эти генераторы сообщений определяют продолжительность и частоту выдачи сообщений EMM. Эти генераторы сообщений также зашифровывают сообщения EMM с помощью их собственных блоков шифрования. Затем они передают зашифрованное EMM в соответствующие блоки выдачи сообщений, которые циклически передают эти EMM. Как показано на фиг.4, к одному генератору сообщений может быть подключено несколько блоков выдачи сообщений, причем соответствующий блок выдачи сообщений определяется генератором сообщений в зависимости от оператора, указанного в EMM. На протяжении жизненного цикла данного EMM генератор сообщений сохраняет его в собственной базе данных. Это EMM удаляется из этой базы данных, как только истекает время, отведенное для его выдачи. Эта база данных обеспечивает согласованность работы MG и ME.
Блоки 124, 126, 128, 130 выдачи сообщений получают сообщения EMM из соответствующих генераторов сообщений вместе с несколькими параметрами, такими как дата начала вещания, дата прекращения вещания и периодичность вещания. Затем генераторы сообщений управляют вещанием сообщений EMM в соответствии с этими параметрами.
Приемник-декодер
Ниже со ссылками на фиг.5 в терминах функциональных блоков будут описаны различные элементы приемника-декодера 13.
Приемник-декодер 13, который может быть, например, цифровой приставкой для телевизора (DSTB), содержит центральный процессор 220, снабженный соответствующими элементами памяти и выполненный с возможностью приема данных от последовательного интерфейса 221, параллельного интерфейса 222, модема (подключенного к модемному обратному каналу 17, показанному на фиг.1) и переключающих контактов 224 на передней панели декодера.
Приемник-декодер дополнительно выполнен с возможностью приема входных сигналов от инфракрасного пульта 225 дистанционного управления через блок 226 управления, а также снабжен двумя устройствами 227, 228 считывания смарт-карт, выполненными с возможностью считывания соответственно банковской или абонентской смарт-карт 242, 240. Устройство 228 считывания абонентских смарт-карт взаимодействует с установленной абонентской картой 240 и блоком 229 условного доступа, чтобы передать необходимое управляющее слово в демультиплексор-дескремблер 230, чтобы сделать возможным дескремблирование зашифрованного вещаемого сигнала. Декодер также содержит обычный тюнер 231 и демодулятор 232 для приема и демодулирования переданных со спутника данных перед их фильтрацией и демультиплексированием блоком 230.
В контексте настоящего описания приложение предпочтительно является фрагментом машинного кода для управления высокоуровневыми функциями предпочтительно приемника-декодера 13. Например, когда конечный пользователь располагает фокус пульта 225 дистанционного управления на объекте-кнопке, отображаемом на экране телевизора 14, и нажимает клавишу подтверждения, выполняется соответствующая этой кнопке последовательность команд.
По запросу конечного пользователя интерактивное приложение предлагает меню и исполняет команды, а также предоставляет данные, соответствующие назначению данного приложения. Приложения могут быть либо резидентными, т.е. сохраненными в ПЗУ (или флэш-памяти, или иной энергонезависимой памяти) приемника-декодера 13, либо передаваться путем вещания и загружаться в ОЗУ или флэш-память приемника-декодера 13.
Приложения хранятся в ячейках памяти в приемнике-декодере 13 и представляются в виде файлов ресурсов. К файлам ресурсов могут, например, относиться файлы библиотек описаний графических объектов, файлы библиотек блоков переменных, файлы последовательностей команд, файлы приложений и файлы данных, как описано более подробно в вышеупомянутых патентных описаниях.
Приемник-декодер содержит память, разделенную на том ОЗУ, том флэш-памяти и том ПЗУ, но эта физическая организация отличается от логической организации. Память может быть дополнительно разделена на тома памяти, ассоциированные с различными интерфейсами. С одной стороны, память можно рассматривать как часть аппаратного обеспечения; с другой стороны, память можно рассматривать как поддерживающую или содержащую в себе всю систему, показанную отдельно от аппаратного обеспечения.
Архитектура приемника-декодера
Приемник-декодер имеет пять программных уровней, организованных таким образом, чтобы программное обеспечение можно было реализовать в любом приемнике-декодере и с любой операционной системой. Как показано на фиг.6, этими различными программными уровнями являются уровень 250 приложений, уровень 252 интерфейса прикладных приложений (уровень API), уровень 254 виртуальной машины, уровень 256 устройств и уровень 258 системного программного/аппаратного обеспечения.
Уровень 250 приложений охватывает приложения, которые либо являются резидентными в приемнике-декодере, либо загружаются в него. Это могут быть используемые пользователями интерактивные приложения, написанные, например, на Java, HTML, MHEG-5 или других языках, или это могут быть приложения, используемые приемником-декодером для выполнения таких приложений. Этот уровень основан на множестве API-интерфейсов, обеспечиваемых уровнем виртуальной машины. Эта система позволяет загружать приложения во флэш-память или ОЗУ приемника-декодера оперативно (по мере необходимости) или по требованию. Код приложения может передаваться в сжатом или несжатом виде с использованием таких протоколов, как DSMCC, NSF или других протоколов.
Интерактивные приложения - это приложения, с которыми пользователь взаимодействует, например, чтобы получить товары, услуги или сервисы, такие как электронный гид по программам (EPG), приложения, для осуществления банковских операций (telebanking) и игры. Для управления интерактивными приложениями используются следующие резидентные приложения:
- Загрузка. Загрузочное приложение 260 - это первое приложение, запускаемое после включения приемника-декодера: Загрузочное приложение запускает различные "менеджеры" виртуальной машины, первым из которых является менеджер 262 приложений.
- Менеджер приложений. Менеджер 262 приложений управляет интерактивными приложениями, выполняемыми в приемнике-декодере, т.е. запускает, завершает, приостанавливает, возобновляет, обрабатывает события и организует обмен данными между приложениями. Он позволяет одновременно выполнять несколько приложений и, таким образом, участвует в распределении ресурсов между ними. Это приложение полностью прозрачно для пользователя.
- Настройка. Предназначение приложения 264 настройки состоит в конфигурировании приемника-декодера, главным образом при первом его использовании. Оно выполняет такие действия, как сканирование частот для нахождения телевизионных каналов, установка даты и времени, установка пользовательских параметров-предпочтений и т.п. Однако в любое время приложение настройки может быть использовано пользователем для изменения конфигурации приемника-декодера.
- Переключение каналов. Приложение 268 переключения каналов используется для переключения каналов с использованием клавиш "на программу вверх", "на программу вниз" и цифровых клавиш. При использовании другой формы переключения каналов, например, с помощью баннерного (пилотного) приложения (banner, pilot application), выполнение приложение переключения каналов завершается.
- Обратный вызов. Приложение обратного вызова используется для извлечения значений различных параметров, хранящихся в памяти приемника-декодера, и возврата этих значений коммерческому оператору через модемный обратный канал 17 или с помощью других средств.
Уровень 252 API предоставляет высокоуровневые утилиты для разработки интерактивных приложений. В него входит несколько пакетов (packages), образующих этот высокоуровневый API. Эти пакеты предоставляют все функции, необходимые для выполнения интерактивных приложений. Эти пакеты доступны для обращения к ним приложений.
В одном из предпочтительных вариантов осуществления настоящего изобретения упомянутый уровень API приспособлен для выполнения приложений, написанных на языке программирования Java. Кроме того, он может интерпретировать HTML и другие форматы, такие как MHEG-5. Помимо этих интерпретаторов, в него входят также другие пакеты и служебные модули, которые можно при необходимости отключать и расширять.
Уровень 254 виртуальной машины состоит из языковых интерпретаторов и различных модулей и систем. Он включает в себя все необходимое для приема и выполнения в приемнике-декодере интерактивных приложений.
Уровень 256 устройств включает в себя менеджер устройств и устройства. Устройства - это программные модули, состоящие из логических ресурсов, необходимых для работы с внешними событиями и физическими интерфейсами. Уровень устройств управляет каналами передачи данных между драйверами и приложениями и обеспечивает улучшенную систему предотвращения ошибок. Вот некоторые примеры поддерживаемых устройств:
устройства считывания карт, модемы, сеть, PCMCIA-платы, светодиодные индикаторы и т.п. Программистам нет необходимости обращаться непосредственно к этому уровню, поскольку уровень API управляет устройствами сверху.
Уровень 258 системного программного/аппаратного обеспечения предоставляется производителем приемника-декодера. Благодаря модульности системы и тому, что служебные функции, которые предоставляет ОС (такие как планирование событий и управление памятью), являются частью виртуальной машины, верхние уровни не привязываются к какой-либо определенной операционной системе реального времени (RTOS) или какому-либо определенному процессору.
MPEG-системы
В обычных системах цифрового телевещания данные передают в виде отдельных пакетов транспортного потока или транспортных пакетов, причем каждый пакет имеет заранее заданную длину и содержит заголовок и полезную нагрузку. Стандарт MPEG является в настоящее время наиболее распространенным стандартом в этой области и устанавливает, среди прочего, фиксированный формат таких пакетов.
Заголовок пакета содержит общие описательные данные, касающиеся пакета, тогда как полезная нагрузка содержит данные, предназначенные для обработки в приемнике-декодере. Заголовок пакета включает в себя по меньшей мере идентификатор пакета (PID), идентифицирующий пакет. Полезная нагрузка пакета может содержать звуковые, видео- или другие данные, такие как данные приложений, или, в частности, данные системы условного доступа.
Обычно входящий поток данных фильтруется приемником-декодером в соответствии со значением PID каждого пакета. Данные, требующие немедленный обработки, такие как звуковые или визуальные данные, направляются в соответствующий процессор в виде того, что обычно называют пакетным элементарным потоком (PES). Этот непрерывный поток данных, образованный в результате компоновки полезных нагрузок транспортных потоков, в свою очередь включает последовательность пакетов, причем каждый пакет PES содержит заголовок и полезную нагрузку.
В полезные нагрузки транспортных пакетов могут быть также инкапсулированы другие данные, не требующие немедленной обработки. В отличие от данных PES, которые немедленно обрабатываются процессором для формирования выходных данных в реальном времени, такого рода данные обычно обрабатываются процессором приемника-декодера асинхронно. В этом случае данные форматируются в одну таблицу или несколько секций таблиц, причем каждая содержит заголовок и тело, и заголовок секции или таблицы включает в себя идентификатор таблицы (TID).
Различные аспекты обычного потока MPEG-данных будут описаны ниже со ссылками на фигуры 7а, 7b и 7с, имеющиеся также в заявке WO 98/43431, включенной в данный документ посредством ссылки.
Обратимся к фиг.7а. Как известно, битовый поток MPEG-2 включает в себя таблицу программ (PAT) 310 с идентификатором пакета (PID), равным 0. PAT содержит ссылки на идентификаторы PID таблиц структур программ (РМТ) 312 ряда программ. Каждая РМТ содержит идентификаторы PID потоков аудио MPEG-таблиц 314 и видео MPEG-таблиц 316 для данной программы. Пакет с PID, равным 0, т.е. таблица 310 программ, представляет собой точку входа для доступа ко всем MPEG-данным.
Для того чтобы загружать приложения и данные к ним, определяются два новых типа потоков, и соответствующие РМТ также определяют PID потоков MPEG-таблиц 318 (или их секций) приложений и MPEG-таблиц 320 (или их секций) данных.
Обратимся к фиг.7b. Для того чтобы загрузить приложение 322, его разбивают на модули 324, каждый из которых образован MPEG-таблицей, некоторые из которых состоят всего из одной секции 318, а другие могут состоять из нескольких секций 318. Типичная секция 318 имеет заголовок 326, который включает в себя однобайтовый идентификатор 328 таблицы (TID), номер 330 данной секции в таблице и указатель 332 количества секций в таблице, а также двухбайтовое расширение 334 TID. Каждая секция также включает в себя информационную часть 336 и CRC 338. Для одного модуля/таблицы 324 все составляющие его секции 318 имеют одинаковый TID 328 и одинаковое расширение 334 TID. Для одного приложения все таблицы 324, составляющие это приложение 322, имеют одинаковый TID 328, но разные соответствующие расширения TID.
Для каждого приложения 322 есть одна такая MPEG-таблица 324, которая используется как каталог и которая более подробно представлена на фиг.7с. Таблица-каталог 340 включает в себя заголовок 326, тело каталога 342, идентификатор 344 ключа, зашифрованную подпись 346 и CRC 338. Как следует из сказанного выше, таблица-каталог 340 имеет в заголовке 326 такой же TID 328, как и другие модули/таблицы 324, составляющие данное приложение. Однако у таблицы-каталога нулевое расширение TID, а у всех других модулей 324 расширения TID отлично от нуля. Заголовок также включает в себя номер 348 версии таблицы-каталога 340. Тело каталога 342 включает в себя, для каждого из остальных модулей/таблиц 324, составляющих приложение 322, имя 350 данного модуля, расширение TID 334 для данного модуля и подпись 352. Тело каталога 342 может также включать в себя, для каждого из остальных модулей/таблиц 324, длину модуля и номер версии модуля.
Вернемся к фиг.7а. В рабочем режиме PAT 310, РМТ 312, а также потоки 318, 320 приложений и данных передают циклически, обновляя их по мере необходимости. Каждое передаваемое приложение имеет соответствующий заранее заданный TID 328. Для загрузки приложения в приемник-декодер 13 загружают MPEG-таблицу с соответствующим TID и нулевым расширением TID. Таким образом, это будет таблица-каталог 40 для требуемого приложения. Данные каталога затем обрабатываются приемником-декодером 13 для определения расширений 334 модулей/таблиц, составляющих требуемое приложение, после чего можно загрузить любой модуль/таблицу с таким же TID, как и у таблицы-каталога, и расширением TID, определенным по каталогу.
Приемник-декодер 13 выполнен с возможностью проверки появления обновленной таблицы-каталога. Это может быть выполнено путем периодической загрузки таблицы-каталога, например, через каждые 30 секунд, или через 1-5 минут, и сравнения номера версии новой загруженной таблицы-каталога с номером версии ранее загруженной таблицы-каталога. Если новый загруженный номер версии более поздний, тогда модули, связанные с прежней таблицей-каталогом, или же такие модули, для которых имеются более поздние номера версии, деинсталлируют, а более поздние модули загружают и устанавливают. В альтернативном варианте входящий битовый поток фильтруют с использованием маски, соответствующей идентификатору TID, расширению TID и номеру версии, с установкой их значений равными идентификатору TID приложения, нулевому расширению TID и номеру версии, на единицу большему, чем номер версии загруженного на текущий момент каталога. Соответственно, становится возможным обнаружение увеличения номера версии, и как только обнаруженный каталог загружается, приложение обновляется, как описано выше. Более подробно такая фильтрация описана в патентной заявке WO 98/43415. Если приложение необходимо завершить, передают пустой каталог со следующим номером версии, но без упоминания в нем каких-либо модулей. Приемник-декодер 13 запрограммирован деинсталлировать приложение в ответ на прием такого пустого каталога.
В том случае, если необходимо ограничить доступ к передаваемой информации, например, в системе платного телевидения, в таблицу или секцию, вещаемую в транспортном потоке одновременно с такой передачей такой информации, могут быть включены данные условного доступа. Эти данные условного доступа фильтруются декодером и передаются в портативный защитный модуль, такой как смарт-карта, устанавливаемый в декодер. Эти данные затем обрабатываются смарт-картой, чтобы сгенерировать, например, управляющее слово, впоследствии используемое декодером для дескремблирования передачи.
Одна проблема заключается в объеме данных, принимаемом и обрабатываемом декодером, и, особенно, объеме данных условного доступа, в конечном счете направляемых в защитный модуль. В частности, обрабатывающие способности процессора защитного модуля и пропускная способность канала обмена данными между декодером и защитным модулем могут быть недостаточными, чтобы справиться с соответствующим объемом сообщений. Эта проблема усугубляется растущей тенденцией передачи программ с несколькими сообщениями условного доступа, позволяющими доступ к одной и той же программе (например, футбольному матчу или тематическому телевизионному каналу) через разных операторов. Следовательно, сейчас будет рассмотрен способ сокращения вещаемой информации или по меньшей мере повышения эффективности работы с ней.
Ниже, в Таблице 1, показана секция приватной MPEG-таблицы. Этот формат используется исключительно для помещения данных обычной структуры в MPEG-секции. Максимальное количество секций зависит от величины section_syntax_mdicator.
| Таблица 1 | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| privatesection() { | |||
| table_id | 8 | uimsbf | |
| section_syntax_indicator | 1 | bslbf | |
| private_indicator | 1 | bslbf | |
| Зарезервировано | 2 | bslbf | |
| private_section_length | 12 | uimsbf | |
| if(section_syntax_indicator=='0'){ | |||
| For(i=0; i<N; I++){ | |||
| Private_data_byte | 8 | bslbf | |
| } | |||
| } | |||
| else { | |||
| Table_id_extension | 16 | uimsbf | |
| Зарезервировано | 2 | bslbf | |
| Version_number | 5 | uimsbf | |
| Current_next_mdicator | 1 | bslbf | |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| For (i=0; i<private_section_length-9; i++){ | |||
| private_data_byte | 8 | bslbf | |
| } | |||
| CRC_32 | 32 | rpchof | |
| } | |||
| } |
Таблица 1 представляет как структуру данных длинной таблицы, так и структуру данных короткой таблицы, как варианты, представленные условным оператором (if/else). Другими словами, если section_syntax_indicator равен 0, то таблица будет иметь структуру данных короткой таблицы, в противном случае таблица будет иметь структуру данных длинной таблицы. Короткая таблица состоит только из одной секции, тогда как длинная таблица может состоять из нескольких секций.
В двух вариантах реализации изобретения, описанных ниже, информационные части с данными обычной структуры, соответствующие структурам данных секций как длинной, так и короткой таблиц заменяются специальным образом структурированной информацией, так что для обеих получаются новые форматы данных. Информационная часть с данными обычной структуры представлена в Таблице 1 циклом с полями private_data_byte и будет именоваться также "телом" секции. Структура этих вариантов реализации показана как универсальная структура данных на фиг.8.
Эта структура данных включает обычный заголовок 400 секции приватной MPEG-таблицы. Поле table_id_extension 402 обычного заголовка 400 используется в некоторых вариантах осуществления для реализации фильтрующих функций, ориентированных на конкретные приложения. Например, оно может использоваться как идентификатор содержимого таблицы, чтобы обеспечить возможность быстрого выделения соответствующего контента с использованием аппаратного фильтрования. Как и обычно, присутствует CRC-информация 420.
Информационная часть с данными обычной структуры (тело) стандартной секции приватной MPEG-таблицы заменяется дополнительным заголовком 404, включающим в себя дополнительные поля заголовка и структурированную информационную часть. Эти дополнительные поля заголовка в дополнительном заголовке 404 включают в себя информацию, касающуюся сжатия и шифрования таблиц, приоритета, формата синтаксического анализа, а также поле расширения фильтра. Они также включают поле, задающее размер списка 408 общих атрибутов. Список 408 общих атрибутов содержит атрибуты 406, общие для всех элементов 412 данных, входящих в список 410 элементов данных. Структурированная информационная часть также включает в себя переменной длины список 410 с элементами 412 данных, каждый из которых включает в себя идентификатор элемента данных обычной структуры и переменной длины список 414 атрибутов, уникальных для данного элемента данных. Длина списка 414 уникальных атрибутов задается в элементе 412 данных. Атрибуты 416 из списка 414 уникальных атрибутов элементов данных могут перекрывать аналогичные общие атрибуты 406 из списка 408 общих атрибутов.
Такая структура позволяет задавать атрибуты, общие для всех элементов данных, только один раз. Более того, атрибуты, общие для некоторых элементов данных, могут указываться в списке общих атрибутов, а те элементы данных, для которых соответствующие значения отличаются от этих общих атрибутов, включают в себя перекрывающие уникальные атрибуты. Благодаря этому может быть минимизировано пространство, требуемое для форматированных данных.
В соответствии со стандартной терминологией MPEG атрибуты ниже будут именоваться также "дескрипторами". Аналогичным образом, списки будут именоваться также "циклами", поскольку для формального определения списков в приводимых ниже определениях форматов конкретных таблиц будут использоваться циклы. Таким образом, списки 408 и 414 будут также именоваться "циклами дескрипторов" или "циклами общих и уникальных дескрипторов", соответственно. Цикл 410 будет именоваться также "циклом идентификаторов".
В конкретных примерах любые элементы структур данных могут также иметь специальные имена.
Сам по себе дескриптор может быть произвольной структурой данных, в зависимости от представляемого атрибута. Предпочтительно он будет включать в себя простой заголовок, содержащий тег дескриптора и значение размера дескриптора, для обеспечения возможности автоматического синтаксического анализа дескриптора.
Благодаря инкапсуляции дополнительного заголовка и структурированных данных в информационную часть с данными обычной структуры, или тело, известной табличной структуры (см. табл.1) сохраняется совместимость с известной структурой. Это также обеспечивает совместимость с имеющимся аппаратным и программным обеспечением для обработки MPEG-таблиц.
Секции приватной таблицы обычно формируются в центре вещания, где информация форматируется в соответствии с описанной выше структурой. После компоновки структур данных в памяти в центре вещания их вводят в MPEG-поток и передают путем вещания в приемники-декодеры. Приемник-декодер может выделять эту информацию из MPEG-потока и восстанавливать структуры данных в своей памяти перед их передачей в синтаксический анализатор для последующей обработки, как будет описано ниже.
Конкретный пример секции длинной приватной таблицы представлен в приведенной ниже Таблице 2. Такая длинная таблица может содержать до 256 секций. В Таблице 2 даны имена полей, размеры полей в битах, двоичный формат данных и значения по умолчанию, двоичный формат данных приведен с использованием мнемонических обозначений, принятых в стандарте MPEG.
| Таблица 2 | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Long_Private_C+_section(){ | |||
| Table_id | 8 | Uimsbf | |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | максимальное значение=OxFFD |
| Tid_extension | 16 | Uimsbf | Tidext |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Private_filter_extension | 16 | uimsbf | |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Descriptor_info_length | 12 | uimsbf | N1 |
| for (i=0, i<N1, i++){ | |||
| Descriptor() | |||
| } | |||
| for (i=0, i<N2, i++){ | |||
| Extra_Identifier_length | 8 | uimsbf | N |
| Extra_Identifier | 8*N | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Extra_Identifier_descriptor_le ngth | 12 | uimsbf | N3 |
| For (i=0, i<N3, i++){ | |||
| DescriptorO | |||
| } | |||
| } | |||
| CRC_32 | 32 | Rpchof | |
| } |
Максимальное количество секций: 256
Максимальный размер каждой секции: 4096
Поля, находящиеся между полями last_section_number и CRC_32 (не включая их самих), заменяют информационную часть с неформатированными данными обычной структуры известного формата таблицы, показанного в Табл.1. Ниже описываются новые поля, за исключением полей "зарезервировано".
Private_Filter_extension: Чтобы оптимизировать использование аппаратных фильтров, это 16-битовое поле может использоваться для расширения возможностей приватного фильтрования путем включения дополнительных критериев в часть заголовка, по которому производится фильтрование, например, при вызовах MLOAD_table, MLOAD_group или MLOAD_section.
Data_Parsing_Format: Это 8-битовое поле указывает формат синтаксического анализа данных, расположенных ниже в таблице. Это помогает выполнять автоматический синтаксический анализ в случае изменения формата данных, расположенных ниже в таблице, в последующих версиях. Это поле может интерпретироваться как эквивалент остатка от деления номера версии формата таблицы на 256, в том случае, если требуется более 256 форматов синтаксического анализа. В этом случае для целей определения формата синтаксического анализа в новым формате таблицы может быть предусмотрено еще одно поле заголовка.
Data_Cyphered_flag: Этот флаг указывает, зашифрованы или нет данные в информационной части, или теле, т.е. данные между дополнительным заголовком и полем CRC_32 (не включая их самих). Если данные зашифрованы, с помощью поля Data_Cyphering_Algorithm производится выбор алгоритма шифрования.
Data_Compressed_flag: Этот флаг указывает, сжаты или нет данные в информационной части или теле, т.е. данные между дополнительным заголовком и полем CRC_32 (не включая их самих). Если данные сжаты, с помощью поля Data_Compression_Algorithm производится выбор алгоритма сжатия.
Если оба флага Data_Cyphered_flag и Data_Compressed_flag установлены, то после сжатия данных выполнено шифрование. На приемной стороне приемник-декодер 13 выполняет дешифрование перед декомпрессией.
Data_Cyphering_Algorithm: Это 2-битовое поле позволяет задать один из четырех различных алгоритмов для использования при шифровании/дешифровании данных в теле секции.
Data_Compressing_algorithm: Это 2-битовое поле позволяет задать один из четырех различных алгоритмов для сжатия данных в теле секции.
Priority: В этом 2-битовом поле могут задаваться четыре уровня приоритета, что позволяет присваивать приватным данным уровень приоритета. Значение 0 соответствует наивысшему приоритету, а значение 3 соответствует самому низкому приоритету.
Common_Descriptor_info_length: Указывает длину следующего далее списка дескрипторов, как размер в байтах (хотя для определения этой длины может также использоваться количество элементов).
Список дескрипторов: Это список элементов-дескрипторов. Элементы-дескрипторы могут иметь различную внутреннюю структуру и представлять атрибуты элементов данных. Список представлен в Таблице 2 циклом.
Список дополнительных идентификаторов: Этот список представлен в Таблице 2 циклом. Он может содержать нулевое количество или несколько идентификаторов, каждый со списком дескрипторов. Каждый элемент - дополнительный идентификатор содержит следующие поля:
Extra_Identifier_length: Это 8-битовое поле указывает количество (N) байтов, отведенных под поле Extra_identifier переменной длины.
Extra_Identifier: Это 8*N-битовое поле определяет идентификатор или группу идентификаторов, описывающих следующий ниже цикл дескрипторов дополнительного идентификатора.
Цикл дескрипторов дополнительного идентификатора: Это список элементов-дескрипторов. Элементы-дескрипторы могут иметь различную внутреннюю структуру и представлять атрибуты элементов данных. Этот список представлен в Таблице 2 циклом.
В представленной выше Таблице 1 поле private_section_length указывает размер остальной части приватной секции, от следующего поля до конца секции. Такую же функцию выполняет поле Section_length в Таблице 2. В Таблице 2 длины двух циклов дескрипторов (в виде размеров в байтах, хотя также может выражаться в количестве дескрипторов) дополнительно указываются полями Common_Descriptor_info_length (значение по умолчанию N1) и Extra_Identiner_descriptor_length (значение по умолчанию N3).
Вариант осуществления короткой приватной таблицы представлен в приведенной ниже Таблице 3. Короткая приватная таблица состоит только из одной секции.
| Таблица 3 | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Short_Private_C+section(){ | |||
| Table_id | 8 | Uimsbf | |
| Section_syntax_indicator | 1 | Bslbf | 0b |
| Private_Syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbl | максимальное значение - OxFFD |
| Private_Filter_Extension | 56 | uimsbl | |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyrphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Descriptor_info_length | 12 | uimsbf | N1. |
| for (i=0, i<N1, i++){ | |||
| Descriptor() | |||
| } | |||
| for (i=0, i<N2, i++){ | |||
| Extra_Identifier_length | 8 | uimsbf | N |
| Extra_Identifier | 8*n | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Extra_Identifier_descriptor_length | 12 | uimsbf | N3 |
| for (i=0, i<N3, i++){ | |||
| Descriptor() | |||
| } | |||
| } | |||
| } |
Максимальное количество секций: 1
Максимальный размер секции: 4096
Поля, находящиеся между полями Section_length и CRC_32 (не включая их самих), заменяют информационную часть с неформатированными данными обычной структуры (тело) известного формата таблицы. Ниже описываются новые поля, за исключением полей "зарезервировано" и полей, описанных выше со ссылкой на Таблицу 2.
Private_Filter_extension: Чтобы оптимизировать использование аппаратных фильтров, это 56-битовое поле может быть использовано для расширения возможностей приватного фильтрования путем включения дополнительных критериев в часть заголовка, по которой выполняется аппаратное фильтрование при вызовах MLOAD_table, MLOAD_group или MLOAD_section. Это поле расширения фильтра длиннее, чем эквивалентное поле при длинном формате (см. Таблицу 2). Это сделано для того, чтобы сделать оба формата одинаковыми по длине, что облегчает синтаксический анализ таблицы.
Priority: В этом 2-битовом поле могут задаваться четыре уровня приоритета, что позволяет присваивать приватным данным уровень приоритета. Значение 0 соответствует наивысшему приоритету, а значение 3 соответствует самому низкому приоритету.
Common_Descriptor_info_length: Указывает длину следующего далее списка дескрипторов, как размер в байтах (хотя для определения этой длины может также использоваться количество элементов).
Список дескрипторов: Это список элементов-дескрипторов. Элементы-дескрипторы могут иметь различную внутреннюю структуру и представлять атрибуты элементов данных. Список представлен в Таблице 3 циклом.
Список дополнительных идентификаторов: Этот список представлен в Таблице 3 циклом. Он может содержать нулевое количество или несколько идентификаторов, каждый со списком дескрипторов. Каждый элемент-дополнительный идентификатор содержит следующие поля:
Extra_Identifier_length: Указывает количество байтов, отведенных под поле Extra_identifier переменной длины.
Extra_Identifier: Определяет идентификатор или группу идентификаторов, описывающих следующий ниже цикл дескриптора.
Цикл дескрипторов дополнительного идентификатора: Это список элементов-дескрипторов. Элементы-дескрипторы могут иметь различную внутреннюю структуру и представлять атрибуты элементов данных. Этот список представлен в Таблице 3 циклом.
Приведенные выше примеры форматов длинной и короткой секций предусматривают дополнительные поля заголовка, касающиеся сжатия или шифрования. Они обеспечивают возможность как шифрования, так и сжатия форматированной информационной части и части информации дополнительного заголовка. Сжатие и шифрование тел секций описывается ниже. Кроме того, предусматривается поле приоритета (Priority), позволяющее ранжировать информацию, содержащуюся в секциях приватных таблиц, по приоритетам.
Описанные форматы приватной таблицы могут использоваться во многих различных приложениях, например, для передачи команд в телевизионную приставку, в приложениях "видео по запросу", в системе условного доступа. Некоторые из этих примеров будут описаны более подробно ниже.
Синтаксический анализатор
Для синтаксического анализа, или интерпретации, универсальной структуры таблицы, описанной выше, предусматривается синтаксический анализатор как часть системного программного обеспечения телевизионной приставки. Построение такого синтаксического анализатора, при условии, что определены структуры данных, может быть легко осуществлено специалистом в данной области техники. Поэтому будут обозначены только основные требования.
Роль синтаксического анализатора показана на фиг.9. Уровень 506 синтаксического анализатора, включающий в себя синтаксический анализатор, представляет собой уровень абстракции между уровнем приложений 508 и уровнем 504 приема и фильтрации MPEG-таблиц, который выделяет информацию, переданную системой вещания 500 посредством потока 502 данных.
Смысл этой абстракции заключается в том, что различные приложения не приходится специально приспосабливать к большому количеству различных форматов таблиц для разнообразных типов данных, с которыми они имеют дело. Синтаксический анализатор обрабатывает принятые секции таблиц и извлекает соответствующую информацию, передавая ее затем приложению на уровень приложений.
Описанный выше универсальный формат таблицы позволяет размещать данные различных типов в таблице одной и той структуры. Отдельные фрагменты данных, сохраняемые в секции таблицы в виде наборов общих и уникальных атрибутов-дескрипторов, содержат информацию, которая необходима для того или иного приложения. Дескрипторы могут иметь разные форматы; предусматривается, простой заголовок, для приведенных выше примеров включающий в себя тег, указывающий тип информации, и атрибут размера, для того чтобы обеспечить синтаксическому анализатору возможность должным образом извлекать информацию и передавать ее приложению.
Кроме того, предусматривается указание размеров списков дескрипторов, в полях Common_Descriptor_info_length и Extra_Identifier_descriptor_length, чем синтаксическому анализатору обеспечивается возможность их корректного извлечения. Для самого синтаксического анализатора не играет роли смысл или назначение тех или иных фрагментов данных - он просто передает данные в приложение. Соответственно, синтаксическому анализатору не нужно понимать различные типы информации, которую он может получать - интерпретация информации выполняется приложением. Синтаксический анализатор просто отделяет служебную информацию, используемую для передачи и содержащуюся в заголовке, и направляет содержащиеся в таблицах полезные данные приложению в подходящей универсальной форме.
Таким образом, синтаксический анализатор способен обрабатывать таблицы переменной длины и различных типов. Строение синтаксического анализатора определяется только строением универсальных таблиц, а не различными типами информации, используемой различными приложениями.
Чтобы сделать возможными дополнительные форматы секций таблиц, в текущем формате предусматривается поле формата синтаксического анализа (Data_Parsing_Format). Часть заголовка, предшествующая этому полю, сохраняет постоянный размер для всех форматов таблиц, так что синтаксический анализатор может корректно идентифицировать это поле, которое он использует для определения формата секции приватной таблицы и, тем самым, для выбора подходящей стратегии его синтаксического анализа.
Сжатие (компрессия) и шифрование приватных таблиц
Описанный выше формат таблицы также предусматривает сжатие и/или шифрование приватных таблиц. Сжатие приватных таблиц может быть полезным в тех случаях, когда эти таблицы используются для транспортировки больших объемов информации, например, каталога программ для приложения "видео по запросу". Полоса пропускания в системах цифрового вещания часто дорогая, и поэтому уменьшение потребности в полосе пропускания может оказаться полезным. Шифрование таблиц может быть полезным в тех случаях, когда информация в таблицах имеет конфиденциальный характер, например, в случае информации условного доступа.
Перейдем к описанию сжатия приватных таблиц.
Дополнительный заголовок, определенный выше (см. Таблицу 2), включает в себя два поля, касающихся сжатия. Для указания того, сжаты или нет данные в секции приватной таблицы, используется флаг Data_Compressed_flag. Кроме того, поле Data_Compressing_Algorithm дополнительного заголовка позволяет указать алгоритм, использованный для сжатия. Соответственно, в системе могут одновременно использоваться несколько алгоритмов сжатия. В варианте осуществления, представленном Таблицей 2, это поле является 2-битовым; соответственно, можно определить 4 алгоритма.
В описанном ниже предпочтительном варианте осуществления стандартные заголовок и концевая часть, а также дополнительный заголовок, включающий в себя вышеназванные поля, не сжаты, так что сжатая таблица может быть обработана и передана с использованием стандартного аппаратного и программного обеспечения MPEG, и приемник может определить, была ли таблица сжата, и какой алгоритм был использован для ее сжатия. Сжимается только тело (или информационная часть) приватной MPEG-таблицы. В других примерах сжимается вся информация, размещенная между полями дополнительного заголовка, касающихся сжатия, и концевой частью (не включая их самих), включая некоторые поля дополнительного заголовка.
В некоторых вариантах осуществления тела секций просто сжимают по отдельности. Тогда после сжатия в таблице количество секций остается прежним.
Однако в предпочтительном варианте осуществления тела всех секций таблицы извлекают из секций таблицы и компонуют их вместе, с формированием крупного блока данных. Для обеспечения возможности восстановления секций таблицы после сжатия каждому телу в таком блоке предшествует спецификатор, указывающий его длину.
Этот промежуточный блок данных, содержащий все тела секций вместе с указателями их соответствующих длин, затем сжимают для получения нового сжатого блока данных. Затем из этого блока создается новая приватная MPEG-таблица путем разбивки его на несколько сегментов, каждый из которых помещают в тело секции этой новой таблицы. Флаги сжатия в дополнительных заголовках каждой секции новой таблицы устанавливают соответствующим образом. За исключением этих флагов и полей, касающихся количества и размеров секций, стандартный MPEG-заголовок и дополнительные заголовки остаются такими же, как и в первоначальной таблице. Соответственно, со сжатой таблицей можно обращаться так же, как и с исходной несжатой таблицей.
Обычно в сжатой таблице будет (в зависимости от достигнутой степени сжатия) меньше секций, чем в исходной, так как количество подлежащих передаче данных благодаря сжатию было уменьшено.
Сжатую приватную таблицу затем передают по обычному каналу. Флаг Data_Compressed_flag в принятой таблице указывает на то, что таблица сжата, тогда как поле Data_Compressing_Algorithm указывает алгоритм, использованный для сжатия, и таким образом указывает приемнику-декодеру, какой алгоритм следует использовать для декомпрессии.
Приемник-декодер затем извлекает тела секций из всех секций сжатой таблицы и заново компонует ее для получения исходного сжатого блока данных. Этот блок подвергается декомпрессии и затем с помощью спецификаторов длины разбирается на составляющие - тела секций. Эти декомпрессированные тела секций затем используют для воссоздания исходных секций приватной таблицы и, соответственно, исходной приватной таблицы.
Преимущество, обеспечиваемое при сжатии крупного блока данных, составленного из всех тел секций, по сравнению со сжатием тела каждой секции отдельно, состоит в возможности достижения большей степени сжатия. Кроме того, можно сократить количество передаваемых секций. Таким образом, можно уменьшить как требуемую полосу пропускания, так и затраты на обработку данных, требуемые для передачи сжатой приватной таблицы.
Опишем теперь сжатие и декомпрессию более подробно, со ссылками на фигуру 11a и фигуру 11b.
Обратимся сначала к фиг.11a. Приватная MPEG-таблица 700 содержит N секций 702-704. Каждая секция включает в себя стандартный заголовок А секции приватной MPEG-таблицы, дополнительный заголовок В, тело С1-Cn и концевую часть D. В некоторых вариантах осуществления структура секций таблицы соответствует определенной ранее в Таблице 2 или Таблице 3, хотя возможны и другие конкретные структуры. В других вариантах дополнительный заголовок включает в себя другие поля помимо полей, указанных в Таблицах 2 и 3, или вместо таковых, либо таковые поля вовсе опущены. Кроме того, в варианте осуществления с форматом длинной таблицы концевая часть содержит контрольную сумму CRC. В формате короткой таблице концевая часть опущена.
Чтобы сжать таблицу 700, тела С1-Cn секций извлекают из секций 1-N. Определяется длина каждого тела, и путем компоновки тел и введения перед каждым телом спецификатора размера, определяющего длину данного тела, создается блок 706 данных. Полученный блок данных содержит тела С1-Cn секций, каждому из которых предшествует соответствующий ему спецификатор размера C1_length-Cn_length. Благодаря введению спецификаторов размера становится возможным корректное выделение тел секций после декомпрессии. Так как поля длины секции как в формате длинной, так и в формате короткой таблицы (как описано выше в Таблице 2 и Таблице 3) являются 12-битовыми полями, в этом примере достаточно двухбайтовых спецификаторов длины. Четыре неиспользованных бита каждого двухбайтового спецификатора длины устанавливают равными 1.
Блок 706 данных затем сжимается с использованием любого подходящего алгоритма сжатия. В результате получается сжатый блок 708.
Затем из сжатого блока 708 получают сжатую приватную таблицу MPEG 710. Сжатый блок 708 разбивают на несколько сегментов С'1-С'р. Каждый сегмент затем помещают в секцию таблицы 710 как тело секции. После этого сжатая таблица 710 состоит из Р секций 712-714, содержащих сегменты С'1-С'р сжатого блока 708 данных.
Сжатую таблицу 710 можно затем передать или сохранить. Эта сжатая таблица совместима не только со стандартной приватной MPEG-таблицей, но и с универсальным форматом таблицы, описанным выше, и поэтому может обрабатываться таким же образом.
Обычно (хотя это и не обязательно будет так) в сжатой таблице 710 будет меньше секций, чем в исходной несжатой таблице 700, так как количество данных в сжатой таблице сокращено сжатием и, кроме того, сжатые данные были перераспределены, предпочтительно равномерно. Таким образом, передача таблицы становится более эффективной не только благодаря сокращению общего количества передаваемых данных, но и благодаря сокращению количества передаваемых секций. Кроме того, благодаря сжатию тел всех секций вместе, а не отдельно, можно достичь более высокой степени сжатия.
Обратимся теперь к фиг.11b. Сжатую приватную MPEG-таблицу 710 декомпрессируют следующим образом. Тела С'1-С'р извлекают и компонуют с формированием сжатого блока 716 данных, который затем декомпрессируют с использованием соответствующего алгоритма декомпрессии. В результате получается исходный несжатый блок 718 данных, содержащий исходные тела С1-Cn секций с соответствующими спецификаторами их размера. Используя спецификаторы размера, блок 718 данных затем разбивают на исходные составляющие, а именно, тела С1-Cn секций, и из этих тел секций воссоздают исходную несжатую приватную MPEG-таблицу 720 с секциями 722-724.
Такая же процедура, как была описана выше для сжатия таблиц, используется для шифрования приватных таблиц. Для этой цели в дополнительном заголовке предусматриваются два поля Data_Cyphered_Flag и Data_Cyphering_Algorithm. Они аналогичны полям со схожими именами, касающимся сжатию; первое является флагом, указывающим, зашифрована таблица или нет, тогда как второе можно (но не обязательно!) использовать для указания на примененный алгоритм шифрования и алгоритм дешифрования, который должен быть применен для дешифрования (в других вариантах реализации это поле можно было бы также использовать для указания на один из нескольких ключей шифрования, ранее переданных в приемник). Можно использовать любой подходящий алгоритм шифрования, например, DES или RSA. Как и в случае сжатия, в некоторых вариантах осуществления секции таблицы шифруются отдельно, но в описываемом предпочтительном варианте осуществления шифруется блок данных, включающий все тела секций таблицы со спецификаторами размера. Такая методика может обеспечить более высокую степень защиты, так как не сохраняется структура таблицы. После этого процедура шифрования аналогична описанному выше способу сжатия. Фактически аналогичный подход может использоваться с применением любой операции или любого преобразования. Преобразования в виде сжатия и шифрования описаны лишь в качестве примеров.
Более того, таблицы могут быть как зашифрованными, так и сжатыми. В этом случае блок 706, показанный на фиг.11a, сначала сжимают, а затем шифруют. В приемнике сжатую и зашифрованную таблицу сначала дешифруют, а затем декомпрессируют (в другом примере таблицу сначала шифруют, затем сжимают, а в приемнике шифрованную сжатую таблицу сначала декомпрессируют, затем дешифруют).
В приемнике-декодере декомпрессию и дешифрование выполняют как первый этап обработки модулем синтаксического анализа. В альтернативном варианте осуществления их выполняют отдельно и до того, как таблица будет передана в синтаксический анализатор. Поскольку в результате декомпрессии и дешифрования на основе переданной сжатой и/или шифрованной приватной таблицы формируется вторая приватная таблица, память, занимаемая переданной таблицей, освобождается сразу же после формирования декомпрессированной/дешифрованной таблицы, так как сжатая/шифрованная таблица тогда больше не нужна. При приеме таблицы приемник-декодер генерирует дескриптор таблицы, содержащий информацию о структуре таблицы и указатели на секции таблицы. Этот дескриптор таблицы используется для удаления сжатой/шифрованной таблицы из памяти. Затем для декомпрессированной/дешифрованной таблицы создается новый дескриптор таблицы, который можно, например, передать в другой программный модуль для обеспечения программному модулю возможности доступа к декомпрессированной/дешифрованной таблице.
Модуль декомпрессии/дешифрования определяет, сжата и/или зашифрована ли таблица, путем проверки флагов Data_Compressed_flag и Data_Cyphered_flag. Если какой-либо из них установлен, на основе значения полей Data_Compressing_Algorithm и Data_Cyphering_Algorithm выбирается подходящий алгоритм декомпрессии и/или дешифрирования. Затем выполняется декомпрессия и/или дешифрирование перед выполнением дальнейшего синтаксического анализа.
Таким образом, сжатие и шифрование являются прозрачными для приложений и, в значительной мере, если не полностью, для синтаксического анализатора. Поскольку в сжатой и/или зашифрованной таблице стандартный MPEG-заголовок остается прежним, таким образом, сохраняется структура стандартной секции приватной MPEG-таблицы, сжатие/шифрование также прозрачно для MPEG-совместимых модулей низкого уровня, занимающихся передачей, приемом и фильтрованием MPEG-таблиц. В приемнике-декодере сжатые и/или зашифрованные таблицы выделяются из входящего потока с использованием стандартных способов фильтрования, например, фильтрования по полям идентификатора таблицы и расширения идентификатора таблицы. Соответственно, сохраняется простота доступа к сжатой/зашифрованной информации в MPEG-потоках.
Сжатие/шифрование было описано для случая универсальной структуры приватной MPEG-таблицы, рассмотренной выше на примере Таблиц 2 и 3. Однако они также применимы к стандартным приватным MPEG-таблицам, которые можно сжимать и шифровать, используя такие же методы. В некоторых таких примерах атрибуты-флаги, такие как описанные выше, просто добавляют в начало тел секций приватной таблицы. В других примерах такие флаги не требуются, если между отправителем и получателем существует предварительная договоренность о сжатом или шифрованном состоянии тел секций приватных таблиц. Такие подходы также применимы к другим подобным структурам данных, не являющимся приватными MPEG-таблицами.
Примеры приложений
Описанные выше варианты осуществления могут быть использованы в ряде различных приложений. Ниже будут приведены некоторые примеры таких приложений.
Первый пример предлагает средство для уведомления телевизионной приставки (известной как set top box, STB) о действиях, которые она должна выполнить.
Пример приложения: таблица уведомления о действиях
В основе таблицы уведомления о действиях (ANT) лежит универсальная структура таблицы, рассмотренная выше. Она может использоваться для передачи телевизионной приставке или группе телевизионных приставок команды выполнить определенное действие.
Примерами таких действий, выполняемых приемником-декодером, являются загрузка программного обеспечения, автоматическое сканирование каналов, перезагрузка приемника-декодера, обновление каталогов программ (такого как каталог "видео по запросу") и показ пользователю телевизионной приставки сообщений (широковещательные - аудиторные - сообщения). Для идентификации запрашиваемого действия в ANT используется поле расширения идентификатора таблицы.
ANT может адресоваться телевизионным приставкам определенного вида (например, какого-либо конкретного производителя), или даже отдельным телевизионным приставкам посредством адресных дескрипторов. Последние могут, например, помещаться в цикл общих дескрипторов таблицы ANT. Путем обработки адресных дескрипторов из цикла общих дескрипторов телевизионная приставка может определить, выполнять ли ей данное действие. Эту обработку адресной информации и информации о действиях может, например, производить прикладная программа, выполняемая в телевизионной приставке.
ANT представляет собой таблицу, в которую можно включить списки дескрипторов и циклы для поддержки действий и критериев выбора любого типа. Никаких ограничений в том, что касается создания новых дескрипторов, не существует. Соответственно, при таком подходе возможны любые модификации. Ниже описывается базовая структура таблицы ANT, а также некоторые основные дескрипторы, которые являются основными для целей загрузки.
Возможны два формата таблицы: длинная таблица с дополнительными полями заголовка, в которой может быть много секций, и короткая версия, допускающая в таблице только одну секцию. Это соответствует вариантам осуществления изобретения, описанным выше. Формат длинной таблицы показан ниже в Таблице 4а.
| Таблица 4а | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Action_Notification_section(){ | |||
| Table_id | 8 | Uimsbf | 0×91 |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_lengthf | 12 | Uimsbf | максимальное значение - OxFFD |
| Action_Identifier | 16 | Uimsbf | см. объяснение ниже |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Filter_extension | 16 | uimsbf | Following action_id |
| Data_Parsmg_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Descriptor_info_length | 12 | uimsbf | N1 |
| for (i=0, I<N1, i++){ | |||
| Descriptor() | |||
| } | |||
| for (i=0, I<N2, i++){ | |||
| Extra_Identifier_length | 8 | uimsbf | N |
| Extra_Identifier | 8*N | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Extra_Identifier_descriptor_lengt h | 12 | uimsbf | N3 |
| for (i=0, i<N3, i++){ | |||
| Descriptor() | |||
| } | |||
| } | |||
| CRC_32 | 32 | Rpchof | |
| } |
Action_Identifier: Поле расширения идентификатора таблицы (Tid_ext) используется здесь для иной цели, а именно - как идентификатор действия. Примеры действий и их коды указаны в приведенной ниже Таблице 4b.
| Таблица 4b | |
| Значение | Комментарий |
| 0×0000 | CDNT MediaOne & Jupiter |
| 0×0001 | Загрузка кода V2 |
| 0×0002 | Автоматическое сканирование |
| 0×0003-0×FFFF | Зарезервировано для будущего использования |
Filter_extension: Интерпретация этого поля зависит от значения поля Action_identifier. Примеры возможных значений и интерпретаций приведены в Таблице 4с:
| Таблица 4с | ||
| Action_identifier | Filter_extension | Комментарий |
| 0×0000 | >0×0000 | Message_index |
| 0×0001 | 0×FFFF | Зарезервировано для проекта автоматической загрузки |
| 0×0002 | Подлежит определению | Зарезервировано для будущего использования |
| 0×0003...0×FFFF | Подлежит определению | Зарезервировано для будущего использования |
Аналогично может быть построена таблица уведомления о действиях в формате короткой таблицы - на основе формата короткой таблицы, описанного выше.
Некоторые примеры основных дескрипторов описаны ниже со ссылками на Таблицы 4d-4k.
Code_download_descriptor
Для каждого имеющегося загрузчика кода предусматривается один дескриптор.
Этот дескриптор размещается в таблице ANT и определяет время загрузки кода.
| Таблица 4d | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Code_download_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | Подлежит определению |
| Descriptor_length | 8 | Uimsbf | |
| Download_flag | 1 | Bslbf | 0:автоматическая |
| 1:ручная | |||
| Type | 2 | Bslbf | 0:в запланированное время |
| 1: немедленно | |||
| 2, 3:зарезервировано для будущего использования | |||
| Periodicity | 2 | Bslbf | 0:не периодично |
| 1:ежедневно | |||
| 2:еженедельно | |||
| 3:ежемесячно | |||
| Зарезервировано | 3 | Bslbf | 1111b |
| UTC_Date_Time_start | 40 | Uimsbf | |
| UTC_Date_Time_estimated_stop | 40 | Uimsbf | |
| } |
Описание полей:
Download_flag:
| Таблица 4е | |
| Значение | Комментарий |
| 0 | Загрузчик не должен запускаться при следующей перезагрузке системы, но параметры загрузки в ЭСППЗУ должны быть обновлены |
| Принять во внимание, загрузка должна быть запущена вручную | |
| - Клавишей на передней панели телевизионной приставки | |
| - из меню "Настройка" | |
| Значение | Комментарий |
| 1 | Загрузка кода должна быть выполнена при следующей перезагрузке системы. |
Type: Это поле определяет поведение телевизионной приставки при начале процесса загрузки.
| Таблица 4f | |
| Значение | Комментарий |
| 0 | Немедленная загрузка |
| 1 | Загрузка в запланированное время |
| 2 | Зарезервировано для будущего использования |
| 3 | Зарезервировано для будущего использования |
Планируемое на определенное время действие позволяет запрограммировать STB на периодическую автоматическую загрузку программного обеспечения (например, раз в день в течение месяца в 3 часа ночи) до успешного завершения этой операции.
Periodicity: Это поле определяет поведение STB при начале процесса загрузки в случае планируемого на определенное время действия. Периодичное выполнение планируемого на определенное время действия возможно лишь в интервале времени между UTC_date_time_start и UTC_date_time_estimated_stop.
UTC_date__tnne_start: Это поле указывает дату и время, на которые запланирована принудительная перезагрузка STB. Оно закодировано в формате UTC - в том же формате, который определяется стандартом DVB для таблиц TDT и ТОТ.
UTC_date_time_estimated_stop: Это поле указывает дату, до которой код будет доступен для загрузки.
Расширение таблицы ANT
Таблица ANT может быть использована для уведомлений о событиях других типов. Не предусматриваются никакие ограничения; в приведенных ниже примерах описано использование этого решения для другой цели:
Scanning_Descriptor
С помощью этого дескриптора телевизионной приставке можно дать команду выполнить сканирование. Это предполагает получение карты сервисов, содержащей, например, информацию о доступных каналах. Сканирование может запрашиваться немедленно или в запланированное время.
| Таблица 4g | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Scanning_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | Подлежит определению |
| Descriptor_length | 8 | Uimsbf | |
| Зарезервировано | 3 | bslbf | |
| Service_map_version_number | 5 | uimsbf | n |
| Origmal_Network_id | 16 | Uimsbf | |
| Transport_stream_id | 16 | Uimsbf | |
| Scanning_flag | 1 | Bslbf | 0:автоматическая |
| 1:ручная | |||
| Type | 2 | Bslbf | 0:в запланированное время |
| 1:немедленно | |||
| 2, 3:зарезервировано для будущего использования | |||
| Periodicity | 2 | Bslbf | 0:не периодично |
| 1:ежедневно | |||
| 2:еженедельно | |||
| 3:ежемесячно | |||
| Зарезервировано | 3 | Bslbf | 111b |
| UTC_Date_Time_start | 40 | Uimsbf | |
| UTC_Date_Time_estimated_stop | 40 | Uimsbf | |
| } |
Описание полей:
Service_map_version_number: Это поле указывает номер версии используемой карты сервисов.
Original_network_id, Transport_stream_id: Эти DVB-значения идентифицируют транспортный поток, в котором вещают информацию сканирования.
Scannmg_flag:
| Таблица 4h | |
| Значение | Комментарий |
| 0 | Принять во внимание, сканирование должно быть запущено вручную из меню "Настройка" |
| 1 | Сканирование должно быть выполнено при следующей перезагрузке. |
Type: Это поле определяет поведение STB при начале процесса сканирования
| Таблица 4i | |
| Значение | Комментарий |
| 0 | Немедленное сканирование |
| 1 | Сканирование в запланированное время |
| 2 | Зарезервировано для будущего использования |
| 3 | Зарезервировано для будущего использования |
Планируемое на определенное время действие позволяет запрограммировать периодическое выполнение автоматического сканирования (например, раз в день в течение месяца в 3 часа ночи) до успешного завершения этой операции.
Periodicity: Это поле определяет поведение STB при начале процесса сканирования в случае планируемого на определенное время действия. Периодичное выполнение планируемого на определенное время действия возможно лишь в интервале времени между UTC_date_time_start и UTC_date_time_estimated_stop.
UTC_date_time_start: Это поле указывает дату и время, на которые запланирована принудительная перезагрузка STB. Оно закодировано в формате UTC - в том же формате, который определяется стандартом DVB для таблиц TDT и ТОТ.
UTC_date_time_estimated_stop: Это поле указывает дату, до которой данные карты сервисов будут доступны для загрузки.
Таблица ANT может быть использована, например, чтобы дать телевизионной приставке команду загрузить информацию.
Для загрузки данных требуются три механизма: механизм сигнализации, механизм загрузки и механизм начальной загрузки. В последующем описании механизм сигнализации основан на использовании дескриптора связи внутри таблицы NIT или таблицы ВАТ с таблицей РМТ. РМТ (обсуждалась выше, см. фиг.7а) - это таблица, содержащая всю информацию, необходимую для загрузки данных и выявления местонахождения загружаемого потока.
Для процесса загрузки может потребоваться широкий спектр различных типов информации, в зависимости от оператора, сети и производителя телевизионной приставки (STB). Соответственно, требуется концепция таблицы с высокой степенью открытости и гибкости.
На первом уровне уникальным идентификатором OUI идентифицируется платформа. Идентификатор OUI указывает конкретного изготовителя STB. На втором уровне способ точной адресации не фиксируется жестко, чтобы использовать различные параметры, такие как серийный номер, МАС-адрес, номер смарт-карты, привязанный к CAS_ID, и т.д. Допускаются дополнительные версии и подверсии аппаратного или программного обеспечения. Описанное ниже решение позволяет использовать для фильтрования любой тип различительного дескриптора.
Как показано на фиг.10, сигнализация сервиса загрузки основана на дескрипторе связей в NIT или ВАТ 602 с РМТ 606. В поле service_descriptor таблицы SDT, а также в поле service_list_descriptor таблицы NIT, тип сервиса определяется как "DOWNLOAD" (чтобы избежать появления сервисов загрузки на экране, как программ), чтобы объявить этот конкретный сервис.
РМТ 606 обращается к ANT 608 путем определения типа потока "Уведомление". В РМТ 606 используется OUI-селектор, чтобы сделать возможным первый выбор таблицы ANT 608, которая будет использоваться, поскольку могут поддерживаться несколько таблиц ANT. Если приемник-декодер 13 находит правильный OUI и соответствующую ANT, он проверяет в ANT 608, отвечают ли дескрипторы различным критериям выбора, а затем получает точку входа к "data-carousel".
РМТ 606 содержит дескриптор выбора, подобно таблице AIT, чтобы иметь возможность немедленно определить, транспортирует ли ANT 608 сервис загрузки или какой-либо другой дескриптор уведомления.
На этом уровне производится фильтрация по OUI. Определяется зарезервированное значение OUI, таким образом чтобы можно было выбрать любого производителя STB.
Структура данных OUI показана ниже в таблице 4j:
| Таблица 4j | |||
| Синтаксис | Размер (в битах) | Формат | Код |
| Action Notification list descriptor (){ | |||
| descnptor_tag | 8 | Uimsbf | |
| descriptor_length | 8 | Uimsbf | |
| OUI | 32 | Uimsbf | 0×FFFFFFFF - для всех OUI |
| for (1=0; i<N; i++){ | |||
| Action_Identifier | 16 | uimsbf | |
| Зарезервировано_futur_use | 3 | bslbf | |
| ANT version number | 5 | uimsbf | |
| } |
Поле Action_Identifier равно значению кода действия в таблице ANT, т.е. полю TID_Ext таблицы ANT.
Так как во все таблицы включен номер версии, путем фильтрации по номеру версии РМТ можно увидеть, изменился ли номер версии ANT, и если да, то какой, без необходимости проверять каждую ANT отдельно.
Структура дескриптора связей таблицы NIT или ВАТ показана в таблице 4k:
| Таблица 4k | |
| linkage_descriptor (){ | длина (в битах) |
| descriptor_tag | 8 |
| descnptor_length | 8 |
| transport_stream_id | 16 |
| original_network_id | 16 |
| service_id | 16 |
| linkage_descriptor (){ | длина (в битах) |
| linkage_type for(i=0; i<N:i++){ private_data | Определенная DVB "сигнализация загрузки" |
| } | |
| } |
Этот дескриптор связей указывает на сервис загрузки, в котором РМТ указывает на один или несколько компонентов ANT.
На первом этапе цель состоит в том, чтобы достигнуть сервиса, транспортирующего все описания имеющихся уведомлений. На втором этапе выполняется анализ таблицы РМТ этого сервиса. Каждая таблица уведомления составлена для конкретного действия, включая конкретные селекторы, позволяющие затрагивать только желаемые STB. Так что, чтобы сделать возможным фильтрацию по OUI, обязательно наличие дескриптора Action_Notification_List_descriptor под каждым PID таблицы ANT. PID таблицы ANT может транспортировать несколько ANT sub_table, соответствующих уведомлениям о различных действиях от обладателя одного и того же OUI. Каждая ANT отличается своим полем TID_Extension. Если "загрузка" указывается как возможное действие и код OUI совпадает с кодом данного приемника, тогда STB загружает ANT. После загрузки анализ ANT помогает более точно описать совпадающую загрузку, доступную на данный момент. Возможно планирование определенного времени, так что становится возможным ссылка и программирование загрузки в будущем, без наличия загружаемого кода в потоке во время программирования.
При выявлении соответствия между описанием загрузки и характеристиками STB в различном имеющемся описанном коде, STB может перейти к точке входа (entry_pomt), описанной тегом 610 связи (association_tag), или, если в другом сервисе, отложенным тегом 612 связи (deferred_association_tag), или, если код еще не доступен, STB должен запомнить время начала и местонахождение. После этого поставщику STB предстоит проанализировать и использовать данные, указанные запомненной точкой входа (entry_pomt) (ON_ID, TS_Id, SV_ID или association_tag). Загружаемые данные может иметь любой формат, по желанию поставщика.
Тем не менее, данные упорядочиваются таким образом, что даже при первой фильтрации перед выполнением загрузки должна выполняться сверка характеристик STB и загрузочного кода ⇒ необходимо четко идентифицировать код
способность транспортировать в одном PID несколько загрузочных кодов - например, по одному на каждую версию аппаратного обеспечения - означает обеспечение возможности различения данных для каждой версии, среди всего разнообразия имеющихся данных (выбор модулей в data_carousel)
Таблица ANT и связанные с ней механизмы обеспечивают развитие обычных способов сигнализации, указывающее одной или нескольким телевизионным приставкам место в данном транспортном потоке или в других транспортных потоках, в котором можно найти новую версию загрузчика, а именно, новую загружаемую версию программного кода.
Описанная выше структура таблицы особенно полезна в случае загрузки в запланированное время.
Пример приложения: адресованные таблицы
Как описано выше при рассмотрении таблицы ANT, адресация таблиц возможна путем включения адресных дескрипторов в циклы дескрипторов. Ниже приведены два примера адресных дескрипторов. Первый, Target_RSM_Descriptor, используется для адресации конкретных смарт-карт. Второй, Target_Platform_Decriptor, используется для адресации определенных аппаратных и/или программных платформ.
Target_RSM_Descriptor
Этот дескриптор, описанный в приведенной ниже Таблице 5, позволяет выполнить действие для списка идентификаторов смарт-карт, и помещается в цикл общих дескрипторов таблицы ANT. В таблице могут присутствовать несколько последовательных дескрипторов.
| Таблица 5 | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Taiget_RSM_descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | Подлежит определению |
| Descriptor_length | 8 | uimsbf | |
| Ca_system_id | 16 | uimsbf | |
| Number_of_tester | 8 | uimsbf | N |
| For (1=0, i<N; i++){ | |||
| RSM_serial_number | 48 | uimsbf | |
| QEV | 8 | uimsbf | |
| } | |||
| } |
Описание полей
Number_of_tester: Указывает количество RSM, затрагиваемых загрузкой.
RSM_serial_number: Qui etes Vous (для смарт-карт Mediaguard)
Qev: Qui etes Vous (для смарт-карт Mediaguard)
Target_Platform_Descriptor
Этот дескриптор, описанный в приведенной ниже Таблице 6, позволяет выполнить некоторое действие для списка идентификаторов платформ. Он помещается в цикл общих дескрипторов таблицы ANT. В таблице могут присутствовать несколько последовательных дескрипторов, по одному на каждую платформу.
| Таблица 6 | |||
| Имя | Размер (в битах) | Формат | Значение по умолчанию |
| Target_Platform_descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | Подлежит определению |
| Descriptor_length | 8 | uimsbf | |
| Hardware_version_number | 32: | bslbf | |
| Number_of_versions_concemed | 8 | uimsbf | N |
| For (i=0, i<n; i++){ | |||
| Global_soft_id | 16 | uimsbf | |
| } | |||
| } |
Описание полей:
Hardware_yersion_number: Идентифицирует аппаратную платформу какого-либо производителя.
загрузкой Numbei_of_versions_concerned: Идентифицирует количество программных платформ, затрагиваемых.
Global_soft_id: Это поле идентифицирует версии программного обеспечения STB для соответствующей аппаратной платформы, затрагиваемые загрузкой кода.
Target_RSM_Descroptor (Таблица 5) и Target_Platform_Descroptor (Таблица 6) используются для адресации таблиц и секций таблиц конкретным смарт-картам и/или платформам. Как таковые, они могут использоваться и в других приложениях, помимо описанной выше таблицы уведомления о действиях и описанного ниже приложения "видео по запросу". Такая адресация может быть особенно полезна при тестировании новых приложений, путем адресации приложения и относящейся к нему информации определенной группе устройств, задействованных в тестировании. В описанном ниже приложении "видео по запросу" адресация может быть использована также для обеспечения, например, разных языков или разных цен для разных клиентов. Путем использования адресных дескрипторов при организации многоязыковых сервисов можно обеспечить рациональное использование полосы пропускания, так как дублировать придется только звуковую компоненту программы - компонента изображения остается одинаковой, независимо от языка. Адресные дескрипторы по существу развивают возможности обычных способов фильтрования таблиц.
Адресные дескрипторы можно помещать как в циклы общих, так и в циклы уникальных дескрипторов. Использование первого цикла общих дескрипторов соответствует первому уровню фильтрования, предоставляя общие параметры фильтрования, применяемые во всех возможных фильтрах. В этот цикл общих дескрипторов можно включить другую общую информацию об этой таблице.
Тогда этот цикл идентификаторов можно интерпретироваться как условие ИЛИ, тогда как внутренние циклы уникальных дескрипторов вводят условие И. Например, если объявлены три фильтра, у каждого из которых два связанных условия, цикл идентификаторов будет содержать три элемента, в каждом из которых по два дескриптора.
Пример приложения: приложение "видео по запросу"
Второй пример приложения предполагает использование и формата секции длинной таблицы, и формата секции короткой таблицы для передачи в приемник-декодер информации, имеющей отношение к предложению сервисов "видео по запросу".
В контексте приложения "видео по запросу" (VoD) каталог ресурсов (ресурс - это конкретное VoD-предложение, например, фильм) составлен из метаданных. Эти метаданные поступают от провайдера контента (в формате XML) и вставляются в секции приватных MPEG-таблиц. Эти секции передают в STB путем вещания в режиме "карусель" ("carousel"),
С использованием VoD-системы может предлагаться большое количество ресурсов. Соответственно, необходимо предусмотреть формат данных, который можно будет использовать для большого количества ресурсов, скажем, например, десятков или сотен тысяч.
С учетом объема данных, отводимых на каждый ресурс, предусматривается два уровня информации:
Первый уровень: название, рейтинг и категория ресурса.
Второй уровень: краткий обзор, перечень актеров, информация о языках и субтитрах и другая информация, имеющая отношение к программе.
На первом уровне может предоставляться некоторое множество таблиц, в которых перечисляются ресурсы, например, телевизионные программы. Для обеспечения простого доступа к этим таблицам все они имеют одинаковые идентификаторы таблиц (TID) и различные расширения TID. Расширения TID используются для ранжирования ресурсов по категориям. Например, в одной таблице могут перечисляться фильмы, тогда как в другой - спортивные программы. Благодаря этому обеспечивается возможность простого выделения из MPEG-потока таблиц, относящихся к ресурсам требуемой категории, с использованием аппаратного фильтрования. Пользователь может, например, запросить просмотр перечня спортивных передач. Путем сочетания TID, соответствующего таблицам ресурсов, с соответствующим спортивным передачам кодом категории в поле расширения TID можно легко выделить соответствующую таблицу ресурсов.
Эта таблица будет содержать перечень всех ресурсов в данной категории, т.е., в данном примере, всех спортивных передач. Затем этот перечень может быть показан пользователю. Если пользователь запросит дополнительную информацию об одной из программ, извлекается таблица второго уровня, содержащая дополнительную информацию, касающуюся этого конкретного ресурса, такую как стоимость программы и ее описание. При этом как расширение TID используется идентификатор ресурса, чтобы обеспечить возможность аппаратного фильтрования по идентификатору ресурса и, таким образом, быстрого выделения соответствующей информации о ресурсе.
Предлагаемые категории передаются в другой MPEG-таблице приватных данных.
Перечень имеющихся ресурсов образует каталог программ. Для обновления каталога предусматриваются дополнительные таблицы, описанные ниже.
В основе рассматриваемых ниже форматов лежат описанные выше универсальные форматы приватных таблиц, так что обеспечивается возможность многократного (широкого) применения модулей синтаксического анализа. В этих форматах используется то обстоятельство, что модуль фильтрации секций, применяемый в декодерах, основан на использовании аппаратной 8-байтовой маски (table_id+7 байтов из поля tid_ext, включая tid_ext).
Следует учесть, что приоритет категорий и ресурсов в следующих таблицах понимается так, что меньшему значению соответствует более высокий приоритет, чтобы при сортировке информации по полю tid_ext сначала извлекались данные с наибольшим приоритетом.
Categories_Description_Table
Categories_Description_Table (см. Таблицу 7 ниже) является первой таблицей, извлекаемой из входящего потока - эта таблица предоставляет перечень имеющихся категорий. В ее основе лежит ранее описанный универсальный формат секции длинной таблицы. Category_id - это 2-байтовое поле, идентифицирующее категорию, дополнительная информация по которой предоставляется в определяемом ниже списке дескрипторов. Диапазон значений поля Category_id позволяет определять категории и подкатегории, как более подробно описано ниже.
Старший байт поля Category_id определяет категорию. Младший байт поля Category_id определяет подкатегорию. Так, например, Category_id 0×1200 определяет категорию 0×12 и подкатегорию 0х00. Аналогично, Category_id 0×1234 определяет категорию 0×12 и подкатегорию 0×34.
Например, дескриптор category__name_descriptor, следующий за Category_id 0×1200, может представлять отображаемое название категории, а, следуя за Category_id 0×1234, category_name_descriptor может представлять название другой подкатегории этой же категории.
Категория 0×00 является зарезервированным значением, позволяющим использовать универсальное определение sub_category. Например, если необходимо определить универсальную подкатегорию (sub_category) "передача в прямой трансляции" (live_event) подкатегорией 0×01 во всех возможных категориях, то можно будет определить значение 0×0001 как category_id, a дескриптор с "live_event" как текстовое содержимое.
| Таблица 7 | |||
| Имя | Размер (в битах) | Формат | Значение/комментарий |
| Categories_Descnption_section (){ | |||
| Table_id | 8 | Uimsbf | 0×90 |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | Максимальное значение - O×FFD |
| Tid_extension | 16 | Uimsbf | He используется - 0×0000, но может измениться в будущем |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Зарезервировано | 16 | bslbf | 0×FFFF |
| Data_Parsing_Format | 8 | uimsbf | См. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_fiag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | См. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | См. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_category_info_length | 12 | uimsbf | N1=0 |
| for (i=0; i<N1; i++){ | |||
| Descriptor() | |||
| } | |||
| For (i=0; i<N2; i++){ | |||
| Category_Id_length | 8 | uimsbf | N=2 |
| Category_id | 8*N | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Category_descriptor_length | 12 | uimsbf | N3 |
| for (j=0; j<N3; j++){ | |||
| Descriptor() | |||
| } | |||
| } | |||
| CRC_32 | 32 | Rpchof | |
| } |
Дескрипторы, сохраняемые в цикле category_descriptor_loop, описаны в Таблице 8.
Category_name_descriptor
| Таблица 8 | |||
| Название | Размер (в битах) | Формат | Значение/ комментарий |
| Category_name_descriptor(){ | |||
| descriptor_tag | 8 | Uimsbf | 0×C9 |
| descriptor_length | 8 | Uimsbf | |
| Category_code | 8 | Uimsbf | |
| ISO_639_Language_Code | 24 | Uimsbf | |
| Category_name_length | 8 | Uimsbf | |
| for (1=0; i<N; i++){ | |||
| Category_name_char | 8 | Uimsbf | |
| } | |||
| } |
Таблицы ресурсов
Первый уровень информации о ресурсах основан на синтаксисе длинного формата для приватных секций (Section_syntax_indicator=1).
Каждая таблица соответствует определенной категории и подкатегории, идентифицируемой соответствующими идентификаторами. В таблице может описываться более 10000 ресурсов, так как она может состоять из 256 секций по 4 кбит каждая.
Рейтинги категории и подкатегории (заменяющие поле tid_ext) помещены вглубь аппаратного фильтра, чтобы обеспечить быстрое фильтрование группы ресурсов на основе значений рейтинга. Рейтинги кодируются восемью битами для соответствия дескриптору DVB parental_ratmg_descriptor, используемому, например, в обычных приложениях с оплатой за каждый просмотр (PPV- приложениях).
Каждая таблица образована циклом asset_id. Первый цикл дескрипторов содержит общие атрибуты, применимые ко всем asset_id.
Второй цикл дескрипторов содержит специфические атрибуты, применимые к конкретному ресурсу.
Когда какой-нибудь атрибут определяется в первом и втором цикле, второе определение перекрывает общее определение.
Структура секции таблицы информации о ресурсах показана в Таблице 9.
| Таблица 9 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Asset_information_section (){ | |||
| Table_id | 8 | Uimsbf | 0×91 |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | максимальное значение - 0×FFD |
| Category_id | 8 | Uimsbf | |
| Sub_category_id | 8 | Uimsbf | Tid_ext |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Category_rating | 8 | uimsbf | |
| Sub_category_Rating | 8 | uimsbf | |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Asset_info_length | 12 | uimsbf | N1 |
| for (i=0; i<N1; i++){ | |||
| Descriptor() | |||
| } | |||
| for (i=0; i<N2; i++){ | |||
| Asset_Id_length | 8 | uimsbf | N |
| Asset_id | 8*N | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Asset_descriptor_length | 12 | uimsbf | N3 |
| for (j=0; j<N3, j++){ | |||
| Descriptor() | |||
| } | |||
| } | |||
| CRC_2 | 32 | Rpchof | |
| } |
Asset_id_length: количество байтов, используемое для определения поля значений.
Asset_id: идентификатор или группа идентификаторов, описывающих следующий цикл дескрипторов.
Второй уровень информации о ресурсах основан на синтаксисе короткого формата для приватных секций (Section_syntax_indicator=0).
При соответствующей глубине аппаратного фильтра можно настроить фильтр таким образом, чтобы обращаться к определенному asset_id. 24-битовое поле "зарезервировано" предусматривается для того, чтобы соответствовать универсальному формату синтаксиса секции короткой таблицы. Фактически оно дополняет маску аппаратного фильтра.
Цикл дескрипторов используется для кодирования атрибутов, относящихся к ресурсу.
Структура такой секции описана в Таблице 10.
| Таблица 10 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Asset_more_information_section (){ | |||
| Table_id | 8 | Uimsbf | 0×92 |
| Section_syntax_indicator | 1 | Bslbf | 0b |
| Private_Syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | максимальное значение - 0×FFD |
| Asset_id | 32 | Uimsbf | |
| Зарезервировано | 24 | Uimsbf | 0×FFFFFF |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Asset_info_length | 12 | uimsbf | N1 |
| for (1=0; i<N1; i++){ | |||
| Descriptor() | |||
| } | |||
| } |
Рассмотрим теперь несколько возможных дескрипторов, которые могут включаться в циклы дескрипторов секции Asset_information_section или Asset_more_mformation.
Asset_name_descriptor
Этот дескриптор помещают в цикл ресурсов таблицы информации о ресурсах. Его структура описана в Таблице 11.
| Таблица 11 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Asset_name_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×C1 |
| Descriptor_length | 8 | uimsbf | |
| Start_date | 40 | Bslbf | |
| And_date | 40 | Bslbf | |
| Asset_rating | 8 | Uimsbf | |
| ISO_639_Ianguage_Code | 24 | Uimsbf | См. норму |
| Title_length | 8 | Uimsbf | максимально 0×3С |
| For (i-0; i<N; i++){ | |||
| Title_char | 8 | Uimsbf | |
| } | |||
| } |
Рассматриваемые ниже дескрипторы обычно помещают в Asset_more_information_table. Однако некоторые из них могут также использоваться как атрибуты в Asset_Information_Table.
source_descriptor
Этот дескриптор, определенный в приведенной ниже таблице 12, предоставляет информацию об особенностях вывода ресурса.
| Таблица 12 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Source_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×C2 |
| Descriptor_length | 8 | Uimsbf | |
| Зарезервировано | 6 | Bslbf | 111111b |
| Surround (объемное звучание) | 1 | Bslbf | |
| Widescreen (широкий экран) | 1 | Bslbf | |
| Language (язык) | 24 | Bslbf | |
| Subtitle_language (язык титров) | 24 | Bslbf | |
| } |
Asset_more_info_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 13, предоставляет различную информацию о ресурсе.
| Таблица 13 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Asset_more_info_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×С3 |
| Descriptor_length | 8 | uimsbf | |
| Duration (продолжительность) | 24 | bslbf | |
| Retail_price (цена) | 48 | bslbf | |
| Year (год выпуска) | 32 | bslbf | |
| Provider_Country_Code (код страны выпуска) | 24 | Uimsbf | |
| Provider_name_length (длина наименования компании, выпустившей фильм) | 8 | Uimsbf | максимально 0×10 |
| for (i=0; i<N; i++){ | |||
| Provider_name_char (буква наименования компании, выпустившей фильм) | 8 | uimsbf | |
| } | |||
| } |
Asset_description_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 14, предоставляет текстовое описание ресурса.
| Таблица 14 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Asset_description_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×C5 |
| Descriptor_length | 8 | uimsbf | |
| ISO_639_Language_Code | 24 | uimsbf | |
| For (j=0; j<N; j++){ | |||
| Description_char (буква описания) | 8 | uimsbf | |
| } | |||
| } |
Actors_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 15, предоставляет информацию об актере, принимающем участие в ресурсе, например, фильме.
| Таблица 15 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Actors_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×С6 |
| Descriptor_length | 8 | Uimsbf | |
| ISO_639_language_Code | 24 | Uimsbf | |
| for (j=0; j<N; j++){ | |||
| Actors_char (буква информации об актере) | 8 | uimsbf | |
| } | |||
| } |
Package_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 16, предоставляет информацию, касающуюся пакета ресурсов.
| Таблица 16 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Package_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×C7 |
| Descriptor_length | 8 | Uimsbf | |
| ISO_639_language_Code | 24 | Uimsbf | |
| for (i=0; i<N; i++){ | |||
| Package_char | 8 | uimsbf | |
| } | |||
| } |
Рассматриваемые ниже дескрипторы касаются всех ресурсов, так что их следует размещать в цикле дескрипторов таблицы информации о ресурсах, или, если необходимо перекрыть определенный ресурс, его можно повторить в asset_loop.
Checkout_Length_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 17, предоставляет информацию о контрольной длительности (checkout length). Он обеспечивает механизм прерывания соединений с VoD-сервером по лимиту времени.
| Таблица 17 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Checkoutlength_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×C4 |
| Descriptor_length | 8 | uimsbf | |
| CheckoutLength | 16 | uimsbf | |
| } |
Stream_control_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 18, предоставляет управляющую информацию для потока. Он определяется ниже как вариантная структура данных, с использованием условных операторов.
| Таблица 18 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Stream_control_descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | 0×C8 |
| Descriptor_length | 8 | uimsbf | |
| Control_flags | 8 | uimsbf | см. объяснение |
| If (Pause_Control=='1'){ | |||
| PauseLimitSeconds | 16 | uimsbf | |
| ActionOnPauseLimits | 8 | uimsbf | |
| } | |||
| If(Fast_Fonvard_Control=='1'){ | |||
| PauseLimitSeconds | 16 | uimsbf | |
| ActionOnPauseLimits | 8 | uimsbf | |
| } | |||
| If (Rewind_Control=='1') { | |||
| PauseLimitSeconds | 16 | uimsbf | |
| ActionOnPauseLimits | 8 | uimsbf | |
| } | |||
| } |
Атрибут Control_flags описан в приведенной ниже Таблице 19.
| Таблица 19 | ||
| Бит | Описание | Комментарий |
| 0 | Пауза | 0:отключено / 1:включено |
| 1 | Ускоренная перемотка вперед | 0:отключено / 1:включено |
| 2 | Ускоренная перемотка назад | 0:отключено / 1:включено |
| 3-7 | Зарезервировано |
Обновление каталога
При запуске приложения VoD таблицы информации о ресурсах загружаются, для отображения предлагаемых ресурсов (при этом учитываются категорийные рейтинги, чтобы скрыть категории с неразрешенными кинофильмами).
Когда абоненту необходима дополнительная информация о каком-либо ресурсе, он загружает соответствующую Asset_more_information_table.
Для обновления информации о ресурсах может передаваться Catalog_Update_table, описанная в Таблице 20, которая указывает категорию и подкатегорию, которую следует обновить.
| Таблица 20 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Catalog_update_section (){ | |||
| Table_id | 8 | Uimsbf | 0×93 |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_section_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | Максимальное значение - 0×FFD |
| Зарезервировано | 16 | Uimsbf | 0×FFFF |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Updatecounter | 8 | uimsbf | |
| Зарезервировано | 4 | Bslbf | 1111b |
| Current_Action_flags | 4 | bslbf | |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 7 | uimsbf | см. объяснение |
| Data_Compressing_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | bslbf | |
| Counter_descriptor_loop_length | 12 | uimsbf | |
| For (i=0; i<N; i++){ | |||
| Category_descnptors() | |||
| } | |||
| CRC_32 | 32 | Rpchof | |
| } |
update_counter: Этот счетчик приращивается на единицу после каждого полного обновления каталога. Когда производятся только некоторые изменения, этот счетчик приращивается на единицу.
Первое значение поля Update_counter равно 0. При сбросе экстрактора базы данных этот счетчик может быть сброшен на 0, но поле Current_Action_Flags будет установлено на 0001, чтобы указывать на полное обновление всей базы данных. Поскольку размер поля ограничен 8 битами, его значение понимается телевизионной приставкой (STB) как выраженное по модулю 256. Счетчик обновлений позволяет STB определить, когда необходимо загрузить новую информацию.
Category_counter_descriptor: Дескриптор счетчика определяет счетчик версий для таблицы информации о ресурсах. Он позволяет STB определять, когда была обновлена информация о ресурсах, чтобы можно было загрузить свежую информацию.
Curreiit_action_flags: Одновременно могут устанавливаться различные флаги, соответствующие дескрипторам category_descriptors, имеющимся во внутреннем цикле. Отдельные флаги перечислены в Таблице 21.
| Таблица 21 | |
| Бит | Комментарий |
| 0 | Full_update_action {полное обновление) |
| 1 | Partial_Add_update_action (частичное обновление - добавление) |
| 2 | Partial_Change_update_action (частичное обновление - изменение) |
| 3 | Partial_Remove_Update_Action (частичное обновление - удаление) |
Рассмотрим теперь несколько дескрипторов, которые могут применяться в циклах дескрипторов секции Catalog_update_section.
Category_Counter_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 22, представляет собой счетчик обновлений категорий/подкатегорий.
| Таблица 22 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Category_counter_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×CB |
| Descriptor_length | 8 | Uimsbf | |
| Category_id | 8 | Uimsbf | |
| Sub_category_id | 8 | Uimsbf | |
| Counter | 8 | uimsbf | |
| } |
counter: В этом 8-битовом поле подсчитываются обновления Asset_Infonnation_Table и соответствующей Asset_more_mforamtion_table для конкретной категории и подкатегории.
Category_Action_descriptor
Этот дескриптор, определенный в приведенной ниже Таблице 23, предоставляет информацию о разновидности обновления для указанного сочетания категории и подкатегории.
| Таблица 23 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Category_Action_descriptor ()} | |||
| Descriptor_tag | 8 | Uimsbf | 0×CC |
| Descriptor_length | 8 | Uimsbf | |
| Action | 8 | uimsbf | |
| For (i=0; i<n; i++){ | |||
| Category_id | 8 | Uimsbf | |
| Sub_category_id | 8 | Uimsbf | |
| } | |||
| } |
Action: Это 8-битовое поле определяет действие, которое должно быть выполнено во время обновления каталога над списком категорий и подкатегорий, содержащихся к цикле. Возможные действия приведены в таблице 24.
| Таблица 24 | |
| Значение | Действие |
| 0×00 | Обновить все (никакого цикла Tidext после) |
| 0×01 | Добавить некоторые категории |
| 0×02 | Изменить некоторые категории |
| 0×03 | Удалить некоторые категории |
Механизм Plant_Id
Механизм plant_id используется для установления соединения с выбранным сервером, предназначенного для VOD-сеанса. Сначала приемник-декодер 13 извлекает файл инициализации, определенный в приведенной ниже Таблице 25, и сканирует все частоты, имеющиеся в цикле lookup_frequency_list_descriptor, показанном в Таблице 27, пока не сможет настроиться на одну из таких частот. Когда частота найдена, необходима фильтрация по PID, описанном в этом же самом дескрипторе таблицы определения Plant_Id с tidext, равным полю Plant_id_selection (всегда в одном и том же дескрипторе), чтобы извлечь правильный Service_Group_Id. Параллельно приложение подключается к http-серверу, используя дескриптор routing_ip, имеющийся в цикле common_descriptor_loop таблицы VOD_initialization_table, чтобы извлечь IP-адрес VOD-сервера.
Синтаксис VOD_initialization_section показан в приведенной ниже Таблице 25.
| Таблица 25 | |||
| Название | Размер (в битах) | Формат | Значение/ комментарий |
| VOD_Initialization_section (){ | |||
| Table_id | 8 | Uimsbf | 0×94 |
| Section_syntax_indicator | 1 | Bslbf | 0b |
| Private_Syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | Максимальное значение - 0×FFD |
| Private_Filtering_Extension | 56 | uimsbf | |
| Data_Parsing_Fonnat | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressmg_algorithm | 2 | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Descriptor_info_length | 12 | uimsbf | |
| for (i=0, i<Nl, i++){ | |||
| Descriptor () | |||
| } | |||
| For (i=0, i<N2, i++){ | |||
| Plant_Id_length | 8 | uimsbf | N |
| Plant_Id | 8*N | uimsbf | |
| Зарезервировано | 4 | bslbf | 1111b |
| Plant_id_descriptor_length | 12 | uimsbf | N3 |
| for (i=0, i<N3, i++){ | |||
| Descriptor () | |||
| } | |||
| } | |||
| } |
Private_FiIteriiig_JExtension: Для максимально эффективного использования аппаратных фильтров это 56-битовое поле можно использовать для расширения возможностей приватного фильтрования при вызовах MLOAD_table, MLOAD_group и MLOAD_section.
Plant_id_length: Количество байтов, используемых для определения поля Extra identifier.
Plant_id: Один идентификатор или группа идентификаторов, описанных в следующем цикле дескрипторов.
Ниже описываются дескрипторы, используемые в VOD_initialisation_section (см. Таблица 25).
Cable_delivery_system_descriptor
Cable_delivery_system_descriptor, описанный в приведенной ниже таблице 26, может быть помещен в цикл common_descriptor_loop при установке поля frequency_field на 0000,0000 МГц. Это поможет установить параметры модуляции по умолчанию для всех следующих частот.
| Таблица 26 | |||
| Синтаксис | Размер (в битах) | Формат | Значение/ комментарий |
| Cable_delivery_system_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×44 |
| Descriptor_length | 8 | Uimsbf | |
| Frequency | 32 | bslbf | |
| Зарезервировано для использования в будущем | 12 | bslbf | |
| FEC_outer | 4 | bslbf | |
| Modulation | 8 | Bslbf | |
| Symboljrate | 28 | Bslbf | |
| FEC_inner | 4 | Bslbf | |
| } |
Возможными дескрипторами в цикле plant_id_descriptor являются следующие:
Lookup_Frequency_List_descriptor
Этот дескриптор определен в Таблице 27.
| Таблица 27 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| LookUp_Frequency_List_Descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | 0×CD |
| Descriptor_length | 8 | uimsbf | |
| For (i=0; i<n; I++){ | |||
| Frequency | 32 | bslbf | |
| Зарезервировано | 3 | bslbf | 111b |
| Plant_Id_PID | 13 | uimsbf | |
| Plant_id_Selection | 16 | uimsbf | Необязательное |
| } | |||
| } |
Frequency: Это 32-битовое поле, предоставляющее 4-битовые двоично-десятичные значения, определяющие 8 символов значения частоты. Частота представляется в МГц, с десятичной запятой после четвертого символа.
Plant_Id_PID: Значение PID, где приемник-декодер 13 может найти файлы plant_ID.
Plant_id_SeIection: Это 16-битовое поле может быть значением Tid_ext, для фильтрации по PID, тогда как значение TID остается статическим, чтобы извлечь нужную Plant_Id_Defmition_Table. Это поле необязательно и предназначено для будущих расширений. Если оно не используется, его значение устанавливается на 0×FFFF.
В еще одном примере поле "зарезервировано" и поле Plant_Id_PID могут сливаться, предоставляя значение тега ассоциирования, которое поможет найти действительное значение PID, поскольку систему со статическими PID всегда трудно использовать.
В цикл общих дескрипторов следует помещать три следующих дескриптора как Http-ODA-сервер.
Connection_data_descriptor
Этот дескриптор определен в таблице 28.
| Таблица 28 | |||
| Синтаксис | Размер (в битах) | Формат | Значение/ комментарий |
| Connection_data_descriptor (){ | |||
| Descriptor_tag | 8 | Uimsbf | 0×Е8 |
| Descriptor_length | 8 | Uimsbf | |
| Login_name_length | 8 | Uimsbf | |
| for (i=0; i<N; i++){ | |||
| Login_name | 8*n | Uimsbf | |
| } | |||
| Password_length | 8 | Uimsbf | |
| for (1=0; i<N; i++){ | |||
| Password | 8*n | uimsbf | |
| } | |||
| } |
Routing_Ipv4_descriptor
Этот дескриптор определен в Таблице 29
| Таблица 29 | |||
| Синтаксис | Размер (в битах) | Формат | Значение/комментарий |
| routing_descriptor_ipv4 (){ | |||
| descriptor_tag | 8 | uimsbf | 0×06 |
| descriptor_length | 8 | uimsbf | |
| for (i=0; i<N; i++){ | |||
| component_tag | 8 | uimsbf | |
| Address | 32 | uimsbf | |
| port_number | 16 | uimsbf | |
| address_mask | 32 | uimsbf | |
| } | |||
| } |
В этом примере поле Component_tag не используется. Его значение установлено на 0.
Routing_ipv6_descriptor
Этот дескриптор определен в Таблице 30
| Таблица 30 | |||
| Синтаксис | Размер (в битах) | Формат | Значение/комментарий |
| Routirig_descriptor_ipv6 (){ | |||
| Descriptor_tag | 8 | uimsbf | 0×07 |
| Descriptor_lenqth | 8 | uimsbf | |
| for (i=0; i<N; i++){ | |||
| Component_tag | 8 | uimsbf | |
| Address | 128 | uimsbf | |
| port_number | 16 | uimsbf | |
| address_mask | 128 | uimsbf | |
| } | |||
| } |
В этом примере поле Component_tag не используется. Его значение установлено на 0.
В таблице 31 определяется синтаксис секции Plant_ID_Definition_Section
| Таблица 31 | |||
| Имя | Размер (в битах) | Формат | Значение/ комментарий |
| Plant_Id_Demiition_section (){ | |||
| Table_id | 8 | Uimsbf | 0×95 |
| Section_syntax_indicator | 1 | Bslbf | 1b |
| Private_syntax_indicator | 1 | Bslbf | 1b |
| Зарезервировано ISO | 2 | Bslbf | 11b |
| Section_length | 12 | Uimsbf | Максимальное значение=0×РРО |
| Plant_Id_Selection | 16 | Uimsbf | Tid_ext |
| Зарезервировано | 2 | Bslbf | 11b |
| Version_number | 5 | uimsbf | |
| Current_next_indicator | 1 | Bslbf | 1b |
| Section_number | 8 | uimsbf | |
| Last_section_number | 8 | uimsbf | |
| Filter_extension | 16 | uimsbf | |
| Data_Parsing_Format | 8 | uimsbf | см. объяснение |
| Priority | 2 | Bslbf | 11b |
| Data_Cyphered_flag | 1 | bslbf | |
| Data_Compressed_flag | 1 | bslbf | |
| Data_Cyphering_Algorithm | 2 | uimsbf | см. объяснение |
| Data_Compressmg_algonthm | i | uimsbf | см. объяснение |
| Зарезервировано | 4 | Bslbf | 1111b |
| Common_Descriptor_info_length | 12 | uimsbf | N1 |
| for (i=0; i<Nl; i++){ | |||
| Descriptor () | |||
| } | |||
| CRC_32 | 32 | Rpchof | |
| } |
VOD_Service_Group_Descriptor
Этот дескриптор, описанный в приведенной ниже Таблице 32, используется в секции Plant_Id_defmition_section.
| Таблица 32 | |||
| Название | Размер (в битах) | Формат | Значение/ комментарий |
| VOD_Service_Group_Descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | 0×CE |
| Descnptor_length | 8 | uimsbf | |
| Service_group_Identifier | 32 | uimsbf | |
| } |
Использование сигнализации VOD
В этом разделе рассматривается, как использовать стандартную и приватную С+ сигнализацию для выделения из потока VOD-таблиц.
Сначала необходимо объявить сервис VOD-портала. Это выполняется с помощью типа сервиса, равного приватному значению OxDO, указывающему, что этот сервис является VOD-сервисом. Об этом типе сервиса необходимо сообщать в дескрипторе service_list_descriptor таблицы CNIT и дескрипторе service_descriptor таблицы SNT.
Чтобы активизировать приложение VOD, этот сервис должен найти необходимое объявление; для достижения этого может быть достаточно объявления типа VOD-сервиса.
Затем, в цикле компонентов таблицы РМТ этого сервиса будет найден цикл элементарных потоков Приватных данных с stream_type 0×C1 и соответствующим PID. Каждый поток этого streamjype содержит appli_list_descriptor для определения, какие из этих данных вещают с использованием данного PID.
Синтаксис appli_list_descriptor дан в приведенной ниже Таблице 33.
| Таблица 33 | |||
| Синтаксис | Размер (в битах) | Формат | Значение/ комментарий |
| Appli_list_descriptor (){ | |||
| Descriptor_tag | 8 | uimsbf | 0×С2 |
| Descriptor_length | 8 | uimsbf | |
| for (i=0; i<N; i++){ | |||
| appli_name | 64 | uimsbf | 8 символов |
| } | |||
| } |
Appli_name может принимать следующие значения (ограничение - до 8 символов):
VODJNIT - для VOD_Imtialization_Table;
ASSET - для Asset_Information_Table (имя с заполнением до 8 символов);
DETAILS - Asset_More_Information_Table;
CATEGORY - Categories_Defmition_Table;
UPDATE - Catalog_Update_Table (имя с заполнением до 8 символов).
Заметим, что при вещании ASSET и CATEGORY могут вкладываться в один и тот же PID, так что в этом PID будут присутствовать два appli_list_descnptors и разбиение в будущем будет проще.
DETAILS, из-за объема данных и периода циклической передачи, должно быть в другом PID, чем ASSET и CATEGORY.
Приложение VOD, будучи запущенным, сначала отображает категории, и, если пользователь потребует, показывает сведения из таблиц ASSET. Как только будет определен PID данных, разрешается использовать непосредственное назначенное значение TID для выполнения фильтрования, вместо полного механизма DMT, чтобы ускорить доступ к информации. (DMT все равно вещают, чтобы обеспечить разрешение между TID и table_name - также как в aplli_Hst_descriptor).
Во время синтаксического анализа каталога таблица UPDATE должна проверяться на изменения в категориях или ресурсах.
Затем, как только пользователь сделает выбор, приложение VOD использует данные VOD_INIT для сканирования частоты своего центрального узла. Более подробную информацию см. в описании Plant_Id_mechanism.
Как только будет выявлена подходящая частота и станет возможной настройка, по меньшей мере одна Plant_Id_Dennition_Table должна быть передана с PID, определенным в первой РМТ транспортного потока. Под первой РМТ понимается первый сервис, описанный в PAT, который должен содержать один элементарный поток типа stream_type=0×C1 с дескриптором appli_list_descriptor, в котором содержится имя PLANT_ID. Этот PID является также значением PID, описанным в дескрипторе lookup_frequency_list_descriptor таблицы VOD_initialization_table для данной частоты. Этот механизм предусмотрен из соображений совместимости со стандартом DVB и во избежание появления "фантомного" PID (ghost PID).
Затем с этим PID вещают таблицу plant_Id_definition со значением TIDExt, равном значению Plant_Id_selection, уже определенном в дескрипторе lookup_frequency_list_descriptor таблицы VOD_mitialization_table для текущей настроенной частоты. Если это фильтрование не даст положительного результата, то осуществляется попытка поиска другой частоты. Более того, лимит времени для выделения таблицы Plant_Id_Defimtion_Table для любой заданной частоты предполагает переход к следующей описанной частоте из текущего дескриптора lookup_frequency_list_descriptor таблицы VOD_mitialization_table.
Если после завершения полного цикла не будет найдено соответствия, то отображается сообщение о явной ошибке, или же предпринимается новая попытка поиска по всему имеющемуся списку частот.
Явная ошибка означает один из следующих вариантов:
не обнаружено никакой частоты
не обнаружено никакой таблицы Plant_id для настроенной частоты
нет РАТ-сигнализации на найденной частоте
нет РМТ-сигнализации на найденной частоте
В противном случае, с помощью дескрипторов IP_descriptors из VOD_initialization_Table находится адрес сервера для установления соединения для VOD-сеанса.
В приведенном выше описании определена структура приватной таблицы, при этом описание построено на следующем:
модель для короткой секции;
модель для длинной секции; и
примеры дескрипторов для различных применений и приложений.
Описанная выше система обеспечивает следующие стратегические преимущества:
делает возможной более эффективную разработку приложений;
делает возможной создание приложений, независимых от производителя приемника-декодера 13 и производителя системы условного доступа;
увеличивает объем данных, которые можно использовать без повышения затрат - это осуществляется посредством сжатия данных; и
упрощает разработку обновлений продуктов.
Система также предоставляет следующие преимущества в том, что касается вещания приложений:
универсальный синтаксического анализатор таблиц;
модификация синтаксического анализатора не оказывает существенного влияния на существующие приложения;
определение приватной таблицы стандартизовано;
разработчик может сосредоточиться на фильтровании данных и конкретных требуемых дескрипторах;
облегчение обработки содержимого таблиц;
выделение данных выполняется синтаксическим анализатором;
поддерживается обратная совместимость с форматами данных;
интеграция с существующими форматами - в приватных секциях могут использоваться существующие DVB-дескрипторы, тогда как в DVB-таблицах могут использоваться приватные дескрипторы;
гарантированное отсутствие регрессии;
ассоциирование объектного метода с дескриптором;
упрощенные тестирование и интеграция;
упрощенная оперативная интеграция (на месте, без негативного воздействия на вещание в реальном времени); и
сокращение времени, необходимого для разработки приложения.
Совершенно очевидно, что настоящее изобретение было описано на примере исключительно иллюстративных вариантов реализации, и в рамках данного изобретения возможны различные изменения и модификации.
Каждый признак, раскрытый в описании и (в соответствующих случаях) формуле изобретения и графических фигурах, может быть реализован независимо от других признаков или в любом подходящем сочетании с ними.
1. Транспортный поток данных для передачи по каналу связи, содержащий таблицу, содержащую заголовок (400) и информационную часть, отличающийся тем, что информационная часть таблицы включает в себя дескрипторы (406), соответствующие первому циклу (408) дескрипторов, и переменной длины цикл (410) с элементами (412) данных, каждый из которых включает в себя идентификатор элемента данных и цикл (414) дескрипторов, содержащий дескрипторы (416), уникальные для данного элемента данных (412), причем информационная часть таблицы включает в себя второй заголовок (404) и вторую информационную часть, и этот второй заголовок (404) включает в себя по меньшей мере одно из следующего:
информацию, касающуюся сжатия данной таблицы;
информацию, касающуюся шифрования данной таблицы;
информацию, касающуюся приоритета;
информацию, касающуюся формата синтаксического анализа;
поле расширения фильтра.
2. Транспортный поток данных по п.1, отличающийся тем, что второй заголовок (404) содержит данные, задающие размер первого цикла (408) дескрипторов.
3. Транспортный поток данных по п.1, отличающийся тем, что упомянутые дескрипторы (406), уникальные для одного элемента данных (412), являются общими для элементов данных (412) из переменной длины цикла (410).
4. Транспортный поток данных по п.1, отличающийся тем, что размер цикла (414) дескрипторов определен в элементах данных (412).
5. Транспортный поток данных по п.1, отличающийся тем, что дескрипторы (416) из циклов (414) уникальных дескрипторов элементов данных перекрывают аналогичные общие дескрипторы (406) из первого цикла (408) общих дескрипторов.
6. Транспортный поток данных по любому из предшествующих пунктов, отличающийся тем, что он представляет собой поток сжатой цифровой видеоинформации.
