ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Телевидение вещательное цифровое

СИСТЕМА TV-ANYTIME. СЛУЖБЫ ВЕЩАНИЯ И ИНТЕРАКТИВНЫЕ. ОПИСАНИЕ СИСТЕМЫ

Основные параметры

ETSI TS 102 822-2 V1.4.1 (2007-11)

(NEQ)

Издание официальное

Москва

Стандартинформ

2015

Предисловие

1    РАЗРАБОТАН Автономной некоммерческой организацией «Научно-технический центр информатики» (АНО «НТЦИ»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 июня 2015 г. № 676-ст

4    Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-2 VI .4.1 (2007-11) «Телевидение вещательное цифровое. Службы вещания и интерактивные: поиск, выбор и законное использование контента на персональных системах хранения («TV-Anytime»). Часть 2. Этап 1. Описание системы» [ETSI TS 102 822-2 VI .4.1 «Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems («TV-Anytime»); Part 2: Phase 1 — System description», (NEQ)]

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2015

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

ГОСТ Р 56455-2015

-    метаданные; -    управление; -    контент

Рисунок 2 — Полная интерактивная модель системы TV-Anytime

Управление правами и поддержка визуализации (презентации контента), показанные на рисунке 2, рассматриваются в [2] — [4].

4.2    Пояснения к процессу поиска контента по ссылкам

Поиск контента по ссылкам (см. [5]) обеспечивает приобретение конкретного экземпляра конкретного элемента контента. Например, если пользователь видит объявление на экране телевизора о том, что на Рождество будет показана новая серия на «Foxes in the cold», он может поручить своему PDR запись целой серии этого фильма. Однако фактическое время вещания эпизодов и канал вещания для PDR могут быть неизвестны. Тем не менее зритель хочет быть уверенным, что он не упустит возможности приобретения этого контента.

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

4.3    Назначение метаданных в системе TV-Anytime на этапе 1

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

Раздел 5 описывает процесс поиска контента по ссылке и участвующих субъектов этого процесса. Раздел 6 приводит доступные инструменты метаданных и их использование. Примеры руководств и конкретных пояснений, описывающих динамические характеристики системы в различных процессах жизненного цикла служб TV-Anytime, описаны в разделах 7 и 8 соответственно.

7

В дополнение к описательным метаданным метаданные RMPI содержат для пользователя сведения о правах, связанных с контентом до его покупки. Метаданные RMPI не содержат фактических прав, связанных с контентом, но являются точной транскрипцией (перезаписью) этих прав.

В таблице 1 приведен набор функций, соответствующих [5], [6] и выполняемых на этапе 1 системы TV-Anytime.

Таблица 1 — Набор функций, соответствующих [5], [6] и выполняемых на этапе 1 системы TV-Anytime

№ Функции Степень поддержки Основные функции модели 1 (вещания) 1 Применение EPG для поиска и записи контента вещания Полная 2 Поиск и выбор контента по требованию с сопутствующей информацией о ценообразовании Полная 3 Запись и воспроизведение аудио-, видео и данных (audio, video and data; AVD) Полная 4 Сшивание аудио-видео контентов в связанный контент Частичная (примечание 1) 5 Поддержка предпочтений пользователя Полная 6 Возможность обновления контента с заменой на более новые или ближайшие версии Частичная (примечание 2) 7 Поддержка нескольких типов контента вещания Частичная (примечание 3) 8 Поддержка всех механизмов доставки вещания Полная 9 Поддержка предпочтений нескольких пользователей Полная Элементы функций модели 2 10 Обновленные данные листинга могут вещаться аналоговыми персональными рекордерами (через обратный канал или использование другого механизма) Полная 11 Обновленные данные листингов/захвата (записи), доставленных в «вещающие» PDR Полная 12 Проверка использования контента на PDR Частичная (примечание 4) 13 Возможность сбора данных об использовании Полная Примечания 1    Различные типы контента могут быть сшиты с использованием MediaLocator (см. [6]). Метаданные программ не содержат CRID для сшивания с другими программами. 2    Целые программы могут быть перезаписаны, но сегменты программ не могут быть перезаписаны. 3    Список поддерживаемых типов контента в соответствии с [6]. 4    Параметры процесса доступа к данным об использовании в настоящем стандарте не нормируются.

4.4 Назначение метаданных в системе TV-Anytime на этапе 2

4.4.1    Новые типы контента

Система TV-Anytime на этапе 2 поддерживает в дополнение к программам аудио/видео, обрабатываемым последовательно, обработку новых типов контента, таких как игры, веб-страницы, музыкальные файлы, графика, данные и многие другие приложения. Эти новые типы контента обрабатываются по собственным правилам, не так, как программы аудио/видео, и не так, как компоненты пакета, описанные в 4.4.2.

4.4.2    Пакетирование

Система TV-Anytime на этапе 2 определяет технологию пакетирования ([8]), что позволяет сочетать различные типы элементов контента (такие, как игры, приложения) и контент, содержащий аудио, видео, фотографии и текст, создающие для пользователя новый опыт, новую практику.

ГОСТ Р 56455-2015

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

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

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

Метаданные описания пакета содержат параметры временной синхронизации и информацию о пространстве между элементами контента, необходимые для создания контента, соответствующего исходному, выполненному создателем контента. Благодаря информации о синхронизации многопотоковый контент (например, просмотр многокамерного отображения спортивных состязаний или просмотр альтернативных аудио- и видео документальных фильмов) может быть представлен компоновкой контента в пакете.

4.4.3    Ориентация (таргетинг) профилей пользователей

Ориентация (таргетинг) профилей пользователей ([8]) может быть определена как автоматическая доставка контента, соответствующего профилям (интересам) пользователей. Существует два типа таргетинга: таргетинг проталкивания и таргетинг вытягивания. В случае таргетинга проталкивания вещатели передают контент с соответствующими метаданными для использования при целевом замещении, на основе профиля пользователя, его предпочтений, истории использования, используемого им оборудования и другие условия. В случае таргетинга вытягивания интеллектуальный агент в PDR использует предпочтения пользователя и другие атрибуты для выборочного воспроизведения и записи контента.

В обоих случаях профили пользователей, их предпочтения, история использования и описания среды должны быть доступны или в PDR, или на сервере.

4.4.4    Интерстициальный контент

Система TV-Anytime на этапе 2 [9] ориентирована на использование современных технологий, в том числе на выполнение интерстициальных (промежуточных) замен контента (например, рекламными объявлениями, появляющимися в всплывающих окнах между веб-страницами) во время воспроизведения на основании ряда критериев. Критерии, используемые для управления заменой контента, должны выполняться в соответствии со схемами, определенными в [9].

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

4.4.5    Обмен метаданными между пользователями

При приобретении контента или метаданных пользователи:

-хотят рассказать другим пользователям об интересном контенте, который они нашли;

-    сконфигурировать другие устройства так, чтобы они были персонализированы для них;

-    могут захотеть передавать контент на устройства других пользователей.

Спецификации TV-Anytime на этапе 2 содержат некоторые конкретные расширения поддержки обмена метаданными.

Спецификации TV-Anytime в явном виде поддерживают обмен профилями пользователей [10] и передачу метаданных, связанных с контентом [11]. Спецификации не охватывают все возможные варианты совместного использования контента.

4.4.6    Удаленное программирование

Целью удаленного программирования [12] является обеспечение пользователя возможностями программирования записи контента от другого устройства.

Например, если пользователь заинтересован в двух программах, которые перекрываются во времени, и его PDR не имеет доступных ресурсов для выполнения необходимых записей, то спецификация дистанционного программирования позволяет ему использовать сетевой цифровой рекордер (Network Digital Recorder; NDR) для записи одной из программ и сделать ее доступной для воспроизведения позднее.

Это решение будет полезным и в тех случаях, когда пользователь находится вне дома и не имеет возможности получить извне доступ к своему домашнему PDR.

9

4.4.7 Формат данных обмена

На рисунке 3 показан формат обмена данными. Спецификация формата обмена данными [11] должна обеспечивать передачу метаданных TV-Anytime от устройства, расположенного за пределами среды TV-Anytime, к совместимому устройству TV-Anytime.

Рисунок 3 - Формат обмена данными

Например, если пользователь может просмотреть электронный путеводитель по программам (Electronic Programme Guide; EPG), доступный с веб-сайта, и выбрать конкретный контент для приобретения, то было бы удобно получить часть или все метаданные, связанные с выбранным контентом, в формате, который может легко интегрироваться с метаданными TV-Anytime, уже имеющимися в PDR.

Кроме того, формат обмена данными позволяет отображать действия, проделанные PDR в соответствии с переданными метаданными.

Например, если пользователь выбирает контент из EPG, используя свой компьютер в офисе, персональный цифровой ассистент (Personal Digital Assistant; PDA) или мобильный телефон, он может быть заинтересован в том, чтобы отправить информацию, связанную с контентом, в его домашний PDR с указанием одного из действий, которое PDR должен выполнить при приеме:

-    «запись», при котором выбирается контент и метаданные;

-    «только запись метаданных» и «напомнить» позже;

-    «рекомендовать» соответствующий контент другу.

4.4.8 Купоны

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

Метаданные купона TV-Anytime [8] обеспечивают возможность сигнализации о существовании купона, объясняют назначение купона (величина, метод, предмет скидки, текстовое объяснение и т.д.) и сообщают о методе получения купона. Фактическая реализация купона выполняется по стандартам производителей оборудования или по правилам поставщиков служб.

Метаданные купона поддерживают большинство существующих методов купона, таких как: «скидка», «два за цену одного», «покупай три — получай один бесплатно» и т.д. Кроме того, метаданные купона могут отображать купоны, предназначенные для использования после покупки контента, который распространяется вне среды TV-Anytime.

ю

ГОСТ Р 56455-2015

5 Сценарии поиска контента по ссылке TV-Anytime

Настоящий раздел дает понятие процесса поиска контента по ссылке — расширения эталонной модели, представленной в разделе 4, моделирования операций от третьих лиц — и возможные сценарии выдачи и разрешения ссылок на элементы контента.

5.1 Поиск контента по ссылке. Основные понятия

Ключевой концепцией поиска контента по ссылке [5] является отделение ссылок на элемент контента CRID от информации расположения (локатора), необходимой для получения элемента контента.

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

Синтаксис CRID:

CRID://<authority>/<data> , где <authority> — имя Полномочного Органа имеет вид:

<DNS name> .

<DNS Name> является зарегистрированным доменным именем сети Интернет или делегированным субдоменом в таком домене.

Имя <DNS Name> должно быть полным именем в соответствии с правилами, приведенными в

[13].

CRID зарегистрирован в официальном реестре IANA схем URI, имеющемся на сайте www.iana. org/assignments/uri-schemes. CRID описан в [14].

Примерами имен полномочных органов являются: www.broadcaster.com,ISP.net, www.commerce.com.

Синтаксис локатора:

transport mechanism>:<transport system specific».

Механизм поиска контента по ссылке использует две основные таблицы. Первой из них является таблица записи разрешения полномочного органа (Resolving Authority Record; RAR), в которой указан полномочный орган, который опубликовал CRID к разрешению провайдера служб. Вторая таблица — это таблица реальных разрешений, которая отображает CRID на другие CRID или на расположения (локации). В таблице реальных разрешений может также содержаться информация о связи локатора с метаданными, описывающими этот экземпляр. В [5] представлено детальное объяснение концепции и таблиц.

5.2 Поиск контента по ссылке и уникальная идентификация контента

Процесс поиска контента по ссылке отличается от процесса идентификации контента, который создает идентификатор, не зависящий от локации (расположения) контента.

Ссылка контента является маркером, который используется PDR для приобретения части контента после того, как пользователь (или агент, работающий от его имени) эту часть выбрал.

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

В системе TV-Anytime в качестве маркера используется CRID для представления расположения контента. CRID могут быть преобразованы в другие CRID или в фактические расположения (локации) в процессе выполнения разрешения расположения, как показано на рисунке 4.

Рисунок 4 - Процесс разрешения расположения

Возможность CRID ссылаться на другие CRID дает ему возможность представлять группу контента. Это недоступно идентификатору контента. CRID группы может быть использован для представле-

11

ния любой произвольной группы, примером которой может быть целая серия. CRID группы для целой серии позволяет PDR приобретать целую серию программ простым выбором одного CRID.

CRID системы TV-Anytime содержит информацию о процессе выполнения разрешения расположения. Все CRID содержат две части. Первая часть называется именем полномочного органа, создавшего этот CRID. Вторая часть — данные, созданные полномочным органом. Часть информации, называемая записью разрешения полномочного органа, обеспечивает отображение разрешения полномочий к месту, определенному разрешением расположения.

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

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

5.3 Полномочный орган, выпускающий CRID и провайдеры разрешения

Создателем CRID является полномочный орган, который создает CRID и присваивает ему значение ссылки на элемент контента. Провайдер разрешения обеспечивает возможность разрешения (локации) физического расположения CRID в пространстве и времени. В этих операциях может участвовать и третья сторона, не показанная на рисунке 1. Однако эта модель может быть расширена для инициализации третьей стороны.

5.3.1 Третья сторона в расширенной статической эталонной модели

На рисунке 5 показаны агенты, участвующие в операциях выпуска и разрешения идентификаторов CRID. Два агента уже были представлены в модели вещания, показанной на рисунке 1, — это создатель контента и поставщик услуг (служб) контента.

Функция инициализации службы контента в модели, показанной на рисунке 6, разделена на несколько частных функций:

-    предоставления разрешения расположения;

-    предоставления метаданных;

-    предоставления контента.

.............- метаданные; ------разрешение расположения; - контент Рисунок 5 - Расширенное представление функций провайдера услуг (служб) контента

Например, в службе вещания XYZ, где XYZ представляет собой переупакованный контент, могли быть метаданные от третьей стороны с более полным описанием контента XYZ. Эти метаданные также могли быть связаны с CRID, описывающими другую группу контента, например все эпизоды серии с участием в них определенной актрисы. Та же сторона может предоставить также сопутствующие данные разрешения расположения для этих CRID.

5.4 Создание CRID и сценарии разрешения

В самом простом случае создатель CRID является также и полномочным органом, выдающим разрешение для этого CRID. Существует ряд сценариев, где создатель CRID не выдает разрешения этому CRID. В таблице 2 показаны сценарии с участием всех возможных создателей CRID и всех возможных полномочных органов, выдающих разрешение CRID для случая чистого вещания. Сценарий «вряд ли» подразумевает принципиальную возможность реализации.

Таблица 2 — Сценарии выполнения разрешения CRID

Создатели CRID Полномочные органы, выдающие разрешения CRID Производитель контента разрешает CRID Провайдер служб контента разрешает CRID Разрешает CRID третья сторона Производитель контента создает CRID «скорее всего» (примечание 1) «скорее всего» (примечание 2) «скорее всего» (примечание 3) Провайдер служб контента создает CRID «вряд ли» «скорее всего» (примечание 4) «скорее всего» (примечание 5) Третья сторона создает CRID «вряд ли» «вряд ли» (примечание 6) «скорее всего» (примечание 7)

Примечания 1    Детализированное описание сценария представлено в 5.4.1. 2    Детализированное описание сценария представлено в 5.4.2. 3    Детализированное описание сценария представлено в 5.4.3. 4    Детализированное описание сценария представлено в 5.4.4. 5    Детализированное описание сценария представлено в 5.4.5. 6    Детализированное описание сценария представлено в 5.4.6. 7    Детализированное описание сценария представлено в 5.4.7.

5.4.1    Производитель контента создает и разрешает CRID

В этом сценарии производитель контента создает контент и идентификатор ссылки (CRID) на эту часть контента. Производитель контента предоставляет информацию о разрешении на поиск этой конкретной части контента. Для случая вещания в качестве примера можно предположить:

-    создателем контента является не вещатель;

-    рассматриваемый контент является драмой с названием «Most Moving Drama Ever».

В этом случае синтаксис полномочного органа может быть представлен как content.com.

Сам CRID может принять форму:

CRID://content.com/drama/MostMovingDramaEver.

Строка «drama/MostMovingDramaEver» имеет значение полномочного органа, который при необходимости может разрешать этот CRID.

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

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

В случае, когда вещатель является и производителем контента, сценарий будет более простым в соответствии с 5.4.4.

5.4.2    Производитель контента создает CRID, провайдер служб контента разрешает CRID

В этом сценарии производитель контента создает контент с соответствующим CRID. Провайдер службы контента является провайдером разрешения служб. Если производителем контента является киностудия и контентом является боевик под названием «Best Action Movie Ever», а провайдером контента является вещатель, то в этом случае провайдер службы контента по отношению к производителю контента выступает в качестве полномочного представителя (прокси). Производитель контента создает CRID, который может выглядеть следующим образом:

CRID://moviestudio.com/movies/BestActionMovieEver

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

13

шения службы различны. В этом примере представлено разрешение записи органа (Resolving Authority Record; RAR), где имя органа — «moviestudio.com» и имя поставщика разрешения «broadcaster.com».

В однонаправленной сети разрешение расположения происходит в PDR. Пользователь выбирает «Best Action Movie EveD> во время процесса навигации или поиска. Механизм разрешения расположения ищет соответствующий RAR, разрешает CRID, полномочия которого записываются как «moviestudio. сот» при использовании разрешения провайдера службы «broadcaster.com». Служба разрешения, предоставленная «broadcaster.com», разрешает CRID к фактическому расположению (каналу вещания и времени) в контексте провайдера служб.

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

5.4.3    Производитель контента создает CRID, разрешает CRID третья сторона

В этом сценарии производитель контента создает контент и устанавливает в нем связанный CRID. Третья сторона разрешает CRID.

Предположим, что создатель контента — студия документальных фильмов, рассматриваемый контент — документальный фильм, названный «Incredible Documentary». Несколько вещателей передадут этот документальный фильм по каналам вещания в течение некоторого времени. В терминах разрешения расположения третья сторона для создателя контента действует как прокси. CRID, созданный студией документальных фильмов, может выглядеть следующим образом:

CRID://docu maker.com/lncredibleDocumentary

Третьей стороной может быть служба EPG. Третья сторона вставляет таблицы разрешения расположения в поток вещания. Одна из вставленных в поток вещания RAR содержит имя органа «documaker. сот» и поставщика разрешения служб «res-service.ecg.com».

В однонаправленной сети разрешение расположения происходит в PDR. В результате выполнения процессов навигации или поиска пользователь выбирает фильм «Incredible Documentary». Поток вещания переносит таблицы RAR, одна из которых содержит имя полномочного органа (в данном примере «documaker.com») и имя провайдера службы разрешения «res-service.ecg.com». Механизм разрешения расположения выполняет поиск таблицы с записями (RAR) и находит в CRID имя полномочного органа (в данном примере «documaker.com»). После этого механизм разрешения расположения использует URL, содержащийся в записи, для поиска фактических таблиц разрешения расположения. В конечном счете CRID разрешен в локаторе (расположении):

transport:channel5~0800

При передаче контента по каналу вещания он может быть записан на локальном устройстве хранения для использования в будущем и может просматриваться в процессе вещания. Детализированное описание представленного сценария в соответствии с [15] (5.4.3).

5.4.4    Провайдер служб контента создает CRID, провайдер служб контента разрешает CRID

В этом сценарии провайдер приобретает контент и присваивает ему свой собственный CRID для

ссылок на этот контент. Провайдер службы контента является также поставщиком разрешения службы.

Провайдером службы контента может быть вещатель, а контентом, о котором идет речь, — фильм «Best Action Movie EveD> от киностудии. Киностудия, как создатель контента, вполне может иметь свой CRID собственного фильма, но провайдер контента и службы принимает решение не использовать его. В этом случае CRID вещателя может выглядеть следующим образом:

CRID://broadcaster.com/movies/BestActionMovieEver

Вещатель вставляет таблицы разрешения расположения в поток вещания, а также вводит в поток вещания записи разрешения, название органа «broadcaster.com» и провайдера разрешения «broadcaster.com».

В однонаправленной сети разрешение расположения выполняется в PDR. Пользователь в результате процесса поиска выбирает фильм «Best Action Movie Ever». Механизм разрешения расположения выполняет поиск таблицы с записями (RAR) и находит в CRID имя полномочного органа, в данном случае — «broadcaster.com». После этого механизм разрешения расположения использует URL, содержащийся в записи, для поиска фактических таблиц разрешения расположения.

В конечном счете CRID разрешен в локаторе (расположении):

transport:channel9~2130

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

14

ГОСТ Р 56455-2015

5.4.5    Провайдер служб контента создает CRID, разрешает CRID третья сторона

В этом сценарии провайдер службы контента создает CRID, связанный с контентом, но CRID разрешает третья сторона. Провайдер службы контента может быть вещателем. В качестве примера рассматривается контент — фильм «Best Comedy Movie Ever». Киностудия — создатель контента фильма — может иметь свой собственный CRID, ссылающийся на этот фильм. Но провайдер службы контента — вещатель — решает его не использовать. Вещатель создает CRID, представленный ниже:

CRID://broadcaster.com/movies/BestComedyMovieEver

Третьей стороной может быть доверенный агент, такой как поставщик служб EPG. Вещатель или третья сторона может создать таблицы разрешения расположения, а также записи RAR, одна из которых содержит имя органа «broadcaster.com» вместе с именем провайдера разрешения службы «res-service.ecg.com». Эти RAR могут быть вставлены в вещательную передачу. Таким образом, в терминах расположения третья сторона действует для провайдера служб контента «broadcaster.com» как прокси (посредник). В однонаправленной сети разрешение расположения выполняется в PDR, а в двунаправленной сети разрешение расположения может выполняться на стороне сервера. Пользователь в результате процесса поиска выбирает «Best Comedy Movie EveD>. Механизм разрешения CRID ищет в таблице RAR и находит запись с именем полномочного органа, которое соответствует имени полномочного органа в CRID (в этом примере «broadcaster.com»), который разрешается в свою очередь получением «res-service.ecg.com». Механизм разрешения использует эту информацию разрешения, чтобы найти фактические таблицы разрешения расположения, которые предусмотрены «res-service.ecg. сот». В этом случае CRID разрешен и получен локатор для CRID. Контент может быть записан.

5.4.6    Третья сторона создает CRID, провайдер служб контента разрешает CRID

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

При условии, что третья сторона обеспечивает CRID, ссылающийся на все эпизоды научно-фантастического сериала «Star Journey», CRID может быть записан, как показано ниже:

CRID://StarJourneyAggregator.com/AIIEpisodesOfStarJourney

Вещатель предоставляет запись разрешения полномочного органа (RAR), содержащую имя полномочного органа «StarJourneyAggregator.com» и провайдера разрешения «broadcaster.com». Пользователь в процессе поиска и навигации находит элемент «АП Episodes of Star Journey». PDR ищет имя полномочного органа, которое он находит в CRID для этого элемента. Он находит, что поставщик службы разрешения является «broadcaster.com» и использует URL, чтобы найти таблицы разрешения. Таблицы разрешения разрешают CRID в списке других CRID:

С RID ://b road caste г. со m/Sta rJourneyEpisodel С RID ://b road caste г. со m/Sta rJourneyEpisode2 CRID://broadcaster.com/StarJourneyEpisode3

В этом примере вещатель выпустил возвращенные CRID, однако третья сторона может иметь свои собственные CRID для этих эпизодов, которые вещатель может разрешить самостоятельно.

Зрителю на выбор представлены различные эпизоды, из которых он выбирает «StarJourney» эпизод 2, и снова запускается механизм поиска имени полномочного органа в таблице RAR. Он находит, что имя полномочного органа «broadcaster.com» отображает провайдера разрешения «broadcaster, сот», а затем разрешает CRID в списке альтернативных расположений, например:

transport:channel9~2130 transport:channel5~0915

Наиболее подходящее расположение выбирается в зависимости:

- от того, как скоро зритель желает смотреть программу;

-от наличия конфликтов при записи, если программа будет сохранена в локальном хранилище;

-стоимости одного расположения места в сравнении с другим и т.д.

5.4.7    Третья сторона создает CRID, третья сторона разрешает CRID

В этом сценарии третья сторона создает, например, CRID группы, которая ссылается на другие CRID, ссылающиеся на фактический контент. Третья сторона является агрегатором некоторого описания.

15

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

CRID://Aggregator.com/AIINatureDocumentaries

Третья сторона обеспечивает разрешение записи полномочного органа (RAR), содержащей имя полномочного органа «Aggregator.com» и провайдера разрешения «Aggregator.com». Эти имена транслируются в PDR вместе с таблицами разрешения, которые третья сторона собирает из записи метаданных, полученной от всех создателей контента в мультиплексе.

CRID://Aggregator.com/FoxeslnTheWild CRID:// Aggregator.com/OceansOfTheWo rid CRID://Aggregator.com/TheMapleTree

Зрителю для выбора представлены различные программы.

Зритель выбирает «океаны мира», и снова запускается механизм поиска имени полномочного органа в таблице RAR. Он находит, что имя полномочного органа — «Aggregator.com», отображающего провайдера разрешения — «Aggregator.com», а затем разрешает CRID в список альтернативных расположений, например:

transport:channel2~1730 transport:channel7~2100

Наиболее подходящее расположение выбирается в зависимости:

-    от того, как скоро зритель желает смотреть программу;

-    от наличия конфликтов при записи, если программа будет сохранена в локальном хранилище;

-    стоимости одного расположения в сравнении с альтернативными и т.д.

5.5    Пример кодирования ISAN при использовании CRID

Пример кодирования аудиовизуальной продукции в соответствии с требованиями стандарта ISAN при использовании CRID представлен в [15] (5.4.7).

5.6    Связь между CRID и метаданными экземпляра

Метаданные описания экземпляра описывают существенные различия между конкретными экземплярами одного и того же контента, т.е. использующими один и тот же CRID. Например, для двух экземпляров одного и того же фильма метаданные описания этих экземпляров указывают, что один находится в формате 16:9, а другой находится в формате 4:3. Метаданные описания экземпляра связываются с конкретным событием соответствующего экземпляра контента. Полная спецификация метаданных описания экземпляра представлена в [6], [7].

CRID TV-Anytime используется для выбора и приобретения элемента контента независимо от его конкретного расположения (места и времени). Приобретение расположения зависимой версии части контента, например версии фильма в формате 16:9, выполняется включением дополнительной функциональности — спецификации ссылок контента — в соответствии с [5], определяющим необязательный идентификатор, называемый идентификатором метаданных экземпляра. Этот идентификатор будет гарантированно уникальным только в пределах CRID, которому он был присвоен.

Примеры использования PDR идентификатора метаданных экземпляра приведены в [15] (5.6).

5.7    Жизненный цикл CRID

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

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

При повторном использовании CRID для обозначения различных частей контента существует ряд проблем, которые могут возникнуть в процессе выполнения сценария. Сценарии, демонстрирующие некоторые из этих проблем, представлены в [15] (5.7).

В целом на коротких интервалах времени рекомендуется проявлять осторожность при назначении повторных CRID.

16

ГОСТ Р 56455-2015

Содержание

1    Область применения....................................................................................................................................1

2    Нормативные ссылки....................................................................................................................................1

3    Термины, определения и сокращения........................................................................................................1

4    Архитектура системы TV-Anytime................................................................................................................5

4.1    Общее описание.....................................................................................................................................5

4.2    Пояснения к процессу поиска контента по ссылкам............................................................................7

4.3    Назначение метаданных в системе TV-Anytime на этапе 1.................................................................7

4.4    Назначение метаданных в системе TV-Anytime на этапе 2.................................................................8

5    Сценарии поиска контента по ссылке TV-Anytime...................................................................................11

5.1    Поиск контента по ссылке. Основные понятия..................................................................................11

5.2    Поиск контента по ссылке и уникальная идентификация контента.................................................11

5.3    Полномочный орган, выпускающий CRID и провайдеры разрешения.............................................12

5.4    Создание CRID и сценарии разрешения............................................................................................12

5.5    Пример кодирования ISAN при использовании CRID........................................................................16

5.6    Связь между CRID и метаданными экземпляра................................................................................16

5.7    Жизненный цикл CRID.........................................................................................................................16

5.8    Согласование спецификаций стандартов..........................................................................................17

6    Метаданные................................................................................................................................................17

6.1    Введение...............................................................................................................................................17

6.2    Расширяемый язык разметки XML — стандартный формат представления...................................17

6.3    Документы метаданных TV-Anytime высокого уровня.......................................................................17

6.4    Документы, связанные через CRID.....................................................................................................20

6.5    Структура документа TV-Anytime........................................................................................................21

6.6    Обязательные и опциональные элементы.........................................................................................21

6.7    Поставка метаданных по однонаправленной среде..........................................................................21

6.8    Примечания к расширению схемы......................................................................................................23

7    Система TV-Anytime на этапах 1 и 2. Примеры руководств по программированию и сценариев........23

7.1    Динамические процессы в TV-Anytime................................................................................................23

7.2    Система TV-Anytime на этапе 1. Пример сценария записи эпизодов серии программы

для случая вещания.............................................................................................................................24

7.3    Система TV-Anytime на этапе 1. Пример сценария записи основных моментов футбольного

матча через EPG..................................................................................................................................24

7.4    Система TV-Anytime на этапе 1. Пример выбора из EPG конкретной программы

для просмотра (в случае вещания).....................................................................................................24

7.5    Система TV-Anytime на этапе 1. Пример сценария разрешения пользователю выбора

контента по требованию из предложений с информацией о ценообразовании.............................24

7.6    Система TV-Anytime на этапе 1. Пример уведомления пользователя об интересующей

его службе.............................................................................................................................................25

7.7    Система TV-Anytime на этапе 1. Пример сценария службы персонального канала

в личном PDR.......................................................................................................................................25

7.8    Система TV-Anytime на этапе 1. Пример сценария: программа состоит из сегментов

от нескольких провайдеров и поддерживает последние новости на персональном PDR.............27

7.9    Система TV-Anytime на этапе 1. Пример сценария при двунаправленном

транспорте метаданных.......................................................................................................................28

7.10    Система TV-Anytime на этапе 1. Пример сценария: профиль 1. EPG нескольких

провайдеров.......................................................................................................................................28

7.11    Система TV-Anytime на этапе 1. Пример сценария:    записи связанного    материала......................28

7.12    Система TV-Anytime на этапе 1. Пример: сценарий    формирования    профиля    пользователя......29

7.13    Система TV-Anytime на этапе 1. Пример сценария: описательные метаданные RMPI................29

8    Примеры руководств по программированию RMPI    и сценариев............................................................29

8.1    Введение...............................................................................................................................................29

8.2    Системные зависимости RMP.............................................................................................................30

8.3    Концепции RMP....................................................................................................................................30

8.4    Жизненный цикл RMPI.........................................................................................................................30

ГОСТ Р 56455-2015

5.8 Согласование спецификаций стандартов

В [5] определены требования для однонаправленного и двунаправленного разрешения ссылок контента.

В [5] обеспечивается привязка HTTP для двунаправленного разрешения по сетям на основе IP. Стандарты [16], [17] отвечают всем требованиям [5], а также предоставляют набор вариантов запросов метаданных. Стандарт [16] обеспечивает поддержку всех особенностей HTTP, связанных в [5] с использованием привязки к протоколу SOAP

Разработчикам новых серверов и клиентских решений, использующим сети IP, рекомендуется использовать протоколы, определенные в [16], [17] в предпочтении к [5]. Следует помнить, что эта рекомендация не относится к базовому открытию DNS серверов поиска контента по ссылке.

6 Метаданные

6.1    Введение

Метаданные в целом определяются как «данные о данных». В среде TV-Anytime наиболее заметными частями метаданных являются аттракторы/дескрипторы или гиперссылки, используемые в электронных руководствах по программам (EPG) или на веб-страницах. Метаданные являются информацией, на основе которой пользователь или агент будут принимать решение о приобретении конкретной части контента.

Система метаданных TV-Anytime позволяет пользователю находить, выбирать и управлять контентом от различных внутренних и внешних источников, включая, например, расширенное вещание, интерактивное телевидение, Интернет и локальные устройства хранения. Это обеспечивается стандартизацией способа описания профилей пользователей, включая поиск предпочтения для облегчения автоматической фильтрации и приобретения контента агентами от имени пользователя.

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

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

6.2    Расширяемый язык разметки XML — стандартный формат представления

В системе TV-Anytime XML является общим форматом представления для документирования метаданных. XML имеет ряд преимуществ:

-    допускает расширяемость;

-    поддерживает разделение данных из приложения;

-    широко используется.

Кроме того, теперь доступны такие мощные инструменты XML, как XSL, XQL и базы данных XML, которые могут использоваться для обработки и управления данными XML. Представление XML документа TVA — это возможное, но не единственное представление метаданных. Метаданные могут быть представлены в оптимизированном двоичном формате, чтобы сохранить пропускную способность и помочь быстрой обработке и отображению базы данных. Рекомендуется при использовании XML в качестве синтаксиса обмена для метаданных TVA обеспечивать соответствие этого XML схеме TVA.

6.3    Документы метаданных TV-Anytime высокого уровня

Все метаданные экземпляра документов TV-Anytime сгруппированы по корневым элементам, имеющим название «TVAMain».

6.3.1 Структура метаданных

Существует шесть основных видов метаданных групп корневого элемента «TVAMain»:

-    описания контента;

17

системы сертификации........................................................................................................................31

8.6 Сценарии вещания контента...............................................................................................................31

9    Проблемы нормирования процессов, выполняемых в системе TV-Anytime..........................................37

10    Система TV-Anytime на этапе 2. Примеры. Руководства по программированию и сценарии............37

10.1 Система TV-Anytime на этапе 2. Пример: новый тип контента — пакетирование.......................37

10.2 Система TV-Anytime на этапе 2. Пример: таргетинг......................................................................38

10.3    Система TV-Anytime на этапе 2. Пример: сигнализация о возможности замены

элементов контента..........................................................................................................................38

10.4    Система TV-Anytime на этапе 2. Пример: обмен метаданными...................................................38

10.5    Система TV-Anytime на этапе 2. Пример: дистанционное программирование

с использованием сетевого цифрового рекордера (NDR)............................................................38

10.6    Система TV-Anytime на этапе 2. Пример: применение купонов...................................................39

11    Система TV-Anytime на этапе 2. Проблемы технологии этапа 2...........................................................39

11.1    Совместное использование контента и обмена метаданными......................................................39

11.2    Удаленное программирование.........................................................................................................40

Приложение А (обязательное) Требования к транспортной среде...........................................................41

Библиография................................................................................................................................................42

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Телевидение вещательное цифровое СИСТЕМА TV-ANYTIME. СЛУЖБЫ ВЕЩАНИЯ И ИНТЕРАКТИВНЫЕ. ОПИСАНИЕ СИСТЕМЫ

Основные параметры

Digital video broadcasting. The system of TV-Anytime. Broadcast and on-line services. System description. Basic

parameters

Дата введения — 2015—09—01

1    Область применения

Система TV-Anytime (TVA) обеспечивает поиск, выбор, сбор и законное использование контента местными или удаленными системами хранения, получаемого от служб вещания и интерактивных (онлайн) служб.

Настоящий стандарт содержит предпочтительные решения системы TV-Anytime.

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52210-2004 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 52591-2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные положения

ГОСТ Р 53528-2009 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины, определения и сокращения

3.1    В настоящем стандарте применены термины по ГОСТ Р 52210, ГОСТ Р 52591, ГОСТ Р 53528, а также следующие термины с соответствующими определениями:

3.1.1    агрегатор (aggregator): В контексте настоящего стандарта — объект (организация), собирающий и агрегирующий информацию о контенте, службах и их поставщиках.

Издание официальное

3.1.2    аттрактор (attractor): Элемент метаданных, который доступен пользователю для помощи в процессе выбора контента с целью привлечения пользователя к предлагаемому контенту. Аттрактор может включать, например, заголовок программы и имя актера.

3.1.3    вещатель (broadcaster): Объект, который агрегирует и распространяет контент аудио/видео.

3.1.4    видео по запросу (Video on Demand; VOD): Система индивидуальной доставки абоненту телевизионных программ и фильмов по цифровой кабельной, спутниковой или наземной (эфирной) телевизионной сети с мультимедиасервера.

3.1.5    грант (предоставление) (grant): Сочетание одного принципала, не менее одного права и разрешения выполнения операции.

3.1.6    группа программ (programme group): Одна или несколько программ, сгруппированные вместе.

3.1.7    дескриптор (descriptor): Элемент метаданных, например аттрактор или другая информация о контенте, индекс ключевого кадра части видео.

3.1.8    захват (capture): Перевод в персональное устройство хранения аудиовизуальных потоков и/ или файлов данных.

3.1.9    идентификатор ссылки контента (Content Reference IDentifier; CRID): Идентификатор контента, который не зависит от его расположения.

3.1.10    идентификатор типа пакета (packet identifier; PID): Тринадцатибитовый указатель в заголовке транспортного пакета, определяющий принадлежность пакета тому или иному потоку данных.

3.1.11    интерстициальный (промежуточный) контент (interstitial content): Дополнительный контент, который может быть вставлен внутрь, в начале или в конце основного элемента контента.

Примечание — Этот дополнительный контент включает, например, рекламные ролики и графику.

3.1.12    интерстициальный перерыв («pod»): Набор рекламных вставок или пятен, образующих

коммерческий перерыв.

3.1.13    контент (content): Видео- и аудиофайлы, к которым пользователь хотел бы получить доступ и которые могут быть сохранены на персональном цифровом рекордере (Personal Digital Recorder; PDR).

3.1.14    листинг (listing): Составление списка.

3.1.15    локатор (расположение) (locator): Время и место, в котором элемент контента может быть получен.

3.1.16    метаданные (metadata): Данные о контенте, например название, жанр и резюме телевизионной программы.

Примечание — В контексте TV-Anytime метаданные также включают данные профиля и истории потребителя.

3.1.17    «мировая паутина» (сеть Интернет) (World-Wide Web; WWW): Система сетевых интерфейсов для передачи данных по сети Интернет.

3.1.18    описание TV-Anytime: Фактический документ, содержащий все метаданные TV-Anytime.

3.1.19    подкастинг (podcasting): Процесс создания и распространения звуковых или видеофайлов (подкастов) в стиле радио- и телепередач в Интернет (вещание в Интернет). Технологической базой подкастинга является формат RSS или Atom.

3.1.20    приложение (application): Конкретный набор функций, выполняемых на PDR. Некоторые приложения используют метаданные либо автоматически, либо под управлением пользователя.

3.1.21    провайдер контента (content provider): Объект, который действует как агент и является главным эксплуататором контента.

3.1.22    провайдер службы (service provider): Агрегатор и поставщик контента, который может выполнять функции шлюза и функции управления поставкой контента.

3.1.23    программа (programme): Отредактированная, логически целостная (связанная) часть контента.

Примечание — Как правило, программа приобретается PDR в целом.

3.1.24    производитель (создатель) контента (content creator): Объект, который создает контент.

3.1.25    простой протокол доступа к объектам (Simple Object Access Protocol; SOAP): Протокол обмена структурированными сообщениями в распределенной вычислительной среде.

3.1.26    профиль пользователя (consumer profile): Данные, представляющие интересы и предпочтения пользователя.

3.1.27    процесс поиска контента по ссылке (content referencing): Процесс ассоциирования маркера с частью контента, который отображает его расположение (локацию), в котором контент может быть приобретен.

2

ГОСТ Р 56455-2015

3.1.28    пятно («spot»): Индивидуальный (отдельный) элемент контента на интервале паузы интерстициального перерыва («pod»).

3.1.29    разрешение расположения (location resolution): Процесс установления адреса (места нахождения и времени) конкретного экземпляра контента по его идентификатору ссылки контента (Content Reference IDentifier; CRID).

3.1.30    режим бесплатного (свободного) вещания в эфире (free-to-air; FTA): Режим, используемый для цифровых бесплатных, не закодированных и открытых для приема каналов телевизионного и радиовещания, без применения системы условного доступа цифрового наземного телевидения в стандартах DVB-T, DVB-T2, цифрового спутникового телевидения в стандартах DVB-S, DVB-S2 и цифрового кабельного телевидения в стандартах DVB-С и DVB-C2.

3.1.31    синтаксис (syntax): Часть языка программирования, которая описывает структуру программ как наборов символов.

3.1.32    система метаданных (metadata system): Набор правил, описывающих синтаксис и семантику метаданных.

3.1.33    сниппет (snippet): Фрагмент, отрывок в практике программирования, являющийся небольшим фрагментом исходного кода или текста, пригодным для повторного использования.

3.1.34    ссылка контента (content reference): Указатель конкретного элемента контента.

3.1.35    схема метаданных (metadata schema): Идентификатор, ассоциированный с набором схем XML, который глобально идентифицирует эти схемы.

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

3.1.36    транспортный поток (transport stream; TS): Набор из нескольких программных потоков данных цифрового вещательного телевидения, сформированный из программных пакетов постоянной длины с коррекцией ошибок и независимым тактированием от своих источников синхронизации.

3.1.37    усовершенствованный авторский формат (Advanced Authoring Format; AAF): Формат файла, используемый при обмене данными между приложениями. Может содержать либо видео-, аудио- и метаданные, либо только метаданные со ссылками или указателями на ассоциированные внешние источники данных. Может использоваться совместно с MXF.

3.1.38    формат RSS (Really Simple Syndication): Семейство форматов XML, предназначенных для описания лент новостей, анонсов, статей, изменений в публикациях. Информация из различных источников, представленная в формате RSS, может быть собрана, обработана и представлена пользователю в удобном для него виде специальными программами-агрегаторами.

3.1.39    фрагменты TVA: Последовательные модули данных.

3.1.40    элемент контента (content item): Объект, который может быть приобретен как единое целое, например файл аудио-видео, аудиопоток.

3.2 В настоящем стандарте применены следующие сокращения:

AAF — усовершенствованный авторский формат (Advanced Authoring Format);

АСАР — расширенная общая платформа приложений (Advanced Common Application Platform);

AVD — аудио-, видео и данные (audio, video and data);

AVI — аудио — видео интерфейс (Audio-Visual Interface);

BIM — двоичный формат MPEG-7 представления фрагментов метаданных TVA;

СА — условный доступ (Conditional Access);

CGMS — система управления формированием копий (Copy Generation Management System);

CRID — идентификатор ссылки контента (Content Reference IDentifier);

CSP — провайдер служб контента (Content Service Provider);

DB — цифровое вещание (Digital Broadcast);

DNS — система доменных имен (Domain Name System);

DRM — цифровое управление правами (Digital Rights Management);

DS — схема описания (Description Scheme);

DSM-CC — система команд и управления для средств цифровой записи (Digital Storage Media — Command and Control);

DVB — цифровое телевизионное вещание (Digital Video Broadcasting);

DVB-C — стандарт кабельного цифрового телевизионного вещания (Digital Video Broadcasting-Cable);

DVB-C2 — стандарт кабельного цифрового телевизионного вещания второго поколения (Digital Video Broadcasting-Cable 2);

3

DVB-S — стандарт спутникового цифрового телевизионного вещания (Digital Video Broadcasting-Satellite);

DVB-S2 — стандарт спутникового цифрового телевизионного вещания второго поколения (Digital Video Broadcasting-Satellite 2);

DVB-T — стандарт наземного цифрового телевизионного вещания DVB (DVB Terrestrial transmission standard);

DVB-T2 — стандарт наземного цифрового телевизионного вещания второго поколения (Digital Video Broadcasting-Terrestrial 2);

DVD — цифровой видеодиск (digital video disc);

EPG — электронный путеводитель по программам (Electronic Programme Guide);

ETSI — Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);

FTA— режим бесплатного (свободного) вещания в эфире (free-to-air);

HD — высокое разрешение (High Definition)

HTTP — протокол передачи гипертекста (HyperText Transfer Protocol);

IANA— центр по присвоению имен (номеров) в Интернете (Internet Assigned Number Authority);

ID — идентификатор (Identifier);

IEC — Международная электротехническая комиссия; МЭК (International Electrotechnical Commission); IETF — комитет по инженерным вопросам Интернет (Internet Engineering Task Force);

IP — Интернет протокол (Internet Protocol);

ISAN — Международный стандартный аудиовизуальный номер (International Standard Audiovisual Number);

ISO — Международная организация по стандартизации (International Standards Organization); MCDI — интерфейс описания мультимедийного контента (Multimedia Content Description Interface); MPEG — группа экспертов по движущимся изображениям (Motion Pictures Expert Group);

MPEG-2 — стандарт МЭК, разработанный MPEG, определяет правила цифрового сжатия и кодирования изображения и звука;

MPEG-7 — стандарт МЭК, разработанный MPEG, определяет интерфейс описания мультимедийного контента (Multimedia Content Description Interface; MCDI);

MPEG-21 —стандарт мультимедийной платформы, разработанный MPEG;

MXF — формат для обмена данными (Material exchange Format);

NDR — сетевой цифровой рекордер (Network Digital Recorder);

NPT — нормальное время воспроизведения (Normal Play Time);

Pay-TV — платное телевидение;

PDA — персональный цифровой ассистент (Personal Digital Assistant);

PDR — персональный цифровой рекордер (Personal Digital Recorder);

PID — идентификатор типа пакета (Packet Identifier);

PPV — система с трафиком при оплате за показы (Pay-per-View);

RAR — запись разрешения полномочного органа (Resolving Authority Record);

RFC — предложение для обсуждения (Request for Comments);

RMP — управление правами и защита (Rights Management and Protection);

RMPI — управление правами и информация защиты (Rights Management and Protection Information); RMPI-M — управление правами и информация защиты микро (Rights Management and Protection Information Micro);

RMPI-MB — управление правами и информация защиты микро для вещания (Rights Management and Protection Information Micro for Broadcast);

RSS — семейство форматов XML (Realy Simple Syndication);

SD — стандартное разрешение (видео) (Standard Definition (video));

SOAP — простой протокол доступа к объектам (Simple Object Access Protocol);

TCP/IP — стек (набор) протоколов сетевого и транспортного уровня (Transmission Control Protocol (TCP) и Internet Protocol (IP));

TS — транспортный поток (transport stream);

TVA — TV-Anytime;

URI — универсальный идентификатор ресурса (Universal Resource Identifier);

URL — унифицированный указатель (определитель расположения) ресурса (Uniform Resource Locator);

4

ГОСТ Р 56455-2015

U-U — Пользователь—Пользователь (User—User);

VOD — видео по запросу (Video on Demand);

Web — «мировая паутина» (сеть Интернет) (World-Wide Web; WWW);

XML — расширяемый язык разметки (язык XML) (Extensible Markup Language);

XQL — язык запроса XML (XML Query Language);

XSL — таблицы стилей XML (XML Stylesheets).

4 Архитектура системы TV-Anytime

4.1    Общее описание

В настоящем стандарте система вещания TV-Anytime описывается на двух этапах развития. На этапе 1 рассматривается система, в которой распределение контента для пользователей выполняется средствами вещания. На этапе 2 в дополнение к программам аудио/видео, обрабатываемым последовательно, добавляется обработка новых типов контента (таких как игры, веб-страницы, музыкальные файлы, графика, данные) с применением технологии пакетирования.

Система вещания TV-Anytime включает в себя три основных элемента:

-    провайдер службы, предоставляющий службы TV-Anytime;

-    провайдер транспорта, переносящий службы TV-Anytime;

-домашнее оборудование (например, персональный цифровой рекордер (PDR), в котором хранится и воспроизводится контент по запросу пользователя.

4.1.1    Модель системы вещания TV-Anytime на этапе 1 без защиты управления правами Модель системы вещания TV-Anytime на этапе 1 без защиты управления правами изображена на

рисунке 1. Показано группирование функций, характерное для случая вещания.

.............- потоки метаданных; ------поток разрешения расположения; - потоки контента

Рисунок 1 — Модель системы вещания TV-Anytime на этапе 1 без защиты управления правами

Каждый из блоков в составе модели обозначает конкретную функцию системы TV-Anytime и может быть реализован несколькими способами, несколькими провайдерами служб. Физические реализации

5

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

Модель вещания с узкополосным двунаправленным каналом поддерживает набор функций, перечисленных в [1]. Эта модель вещания связывает контент и соответствующие данные. В модели внешними по отношению к PDR являются следующие системные функции:

-    создание контента;

-    служба предоставления контента и доступа.

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

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

Службу предоставления контента и доступа представляют:

-    вещатель, который, как правило, выполняет функцию предоставления контента и обеспечивает переупаковку, добавление метаданных и вещание контента;

-    кабельный или спутниковый операторы, которые, как правило, обеспечивают доступ.

PDR может рассматриваться как реальное устройство, размещенное на территории пользователя, которое позволяет пользователю хранить и просматривать контент.

На рисунке 1 PDR размещен в поле, объединяющем функции поиска и навигации, разрешения расположения, взаимодействия с пользователем, презентации (представления) контента и управления местным устройством хранения.

Функции PDR:

-    взаимодействие с пользователем;

-    презентация контента;

-    управление местным устройством хранения.

Эта система позволяет пользователю выполнять процессы поиска, выбора контента, определения расположения контента и приобретения необходимого ему контента. Поиск и выбор, например, путеводителя EPG будут выполняться при использовании метаданных вещания, которые рекламируют доступный контент. Эти метаданные могут размещаться в передаче вещания вещателем, создателем контента или какой-либо третьей стороной. Третья сторона на рисунке 1 не показана. Расширение этой модели с участием третьей стороны описано в 5.3.1.

Процесс поиска и навигации в системе TV-Anytime заканчивается после того, как пользователь сделает выбор, или после автоматического выбора идентификатора ссылки контента (Content Reference ID; CRID). Функция разрешения в PDR, используя ранее полученный ID ссылки контента, выдает физическое расположение контента (например, конкретный канал и время вещания). Данные разрешения локации (расположения) передаются средствами вещания и разрешают PDR выполнить перевод ссылки ГО в адрес физического канала и величину времени. Параметры интерфейсов PDR, обеспечивающих поддержку управления правами и защиту, настоящим стандартом не устанавливаются.

4.1.2 Полная интерактивная модель системы TV-Anytime

Особенности полной интерактивной модели системы TV-Anytime описаны в [1]. Полная интерактивная модель системы TV-Anytime приведена на рисунке 2.

Пользователь (PDR пользователя) TV-Anytime имеет двунаправленный канал к таким системным функциям, как служба предоставления контента и доступа или поиск и навигация. В этом случае внешними по отношению к PDR могут быть следующие системные функции:

-    создание контента;

-    поиск и навигация;

-    разрешение локации (расположения);

-    служба предоставления контента и доступа.

Предоставление служб контента может быть сделано несколькими сторонами, например сетевыми вещателями, вещательными компаниями, провайдерами портала и т.д. Функция поиска и навигации может быть обеспечена компанией web-EPG или компанией ТВ портала. Разрешение расположения может быть обеспечено аналогичным образом. PDR совмещает функции хранения, презентации (представления) контента и функции взаимодействия с пользователем.

6