ГОСТ Р 56455-2015 Телевидение вещательное цифровое. Система TV-Anytime. Службы вещания и интерактивные. Описание системы. Основные параметры

ГОСТ Р 56455-2015

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

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

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

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

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

ОКС 33.170

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

Предисловие

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

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-2 V1.4.1 (2007-11)* "Телевидение вещательное цифровое. Службы вещания и интерактивные: поиск, выбор и законное использование контента на персональных системах хранения ("TV-Anytime"). Часть 2. Этап 1. Описание системы" [ETSI TS 102 822-2 V1.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 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Февраль 2020 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

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

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

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

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

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

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

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

ГОСТ Р 53528 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации 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): Процесс ассоциирования маркера с частью контента, который отображает его расположение (локацию), в котором контент может быть приобретен.

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-C и 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);

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);

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

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

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

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

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

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

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

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

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

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

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

Функции PDR:

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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 соответственно.

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

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

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

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

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

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

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

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

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

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

Метаданные описания пакета позволяют использовать механизм, отображающий варианты применения в зависимости от используемого устройства и предпочтений пользователя. Эта возможность более подробно рассмотрена в 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 нe имеет доступных ресурсов для выполнения необходимых записей, то спецификация дистанционного программирования позволяет ему использовать сетевой цифровой рекордер (Network Digital Recorder; NDR) для записи одной из программ и сделать ее доступной для воспроизведения позднее.

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

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.

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 группы может быть использован для представления любой произвольной группы, примером которой может быть целая серия. 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

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 передаются записи разрешения органа, одна из которых включает перенаправление записи, в которой имя органа и поставщика разрешения службы различны. В этом примере представлено разрешение записи органа (Resolving Authority Record; RAR), где имя органа - "moviestudio.com" и имя поставщика разрешения "broadcaster.com".

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

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

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

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

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

CRID://documaker.com/lncredibleDocumentary

Третьей стороной может быть служба EPG. Третья сторона вставляет таблицы разрешения расположения в поток вещания. Одна из вставленных в поток вещания RAR содержит имя органа "documaker.com" и поставщика разрешения служб "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 Ever" от киностудии. Киностудия как создатель контента вполне может иметь свой 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

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

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 Ever". Механизм разрешения CRID ищет в таблице RAR и находит запись с именем полномочного органа, которое соответствует имени полномочного органа в CRID (в этом примере "broadcaster.com"), который разрешается, в свою очередь, получением "res-service.ecg.com". Механизм разрешения использует эту информацию разрешения, чтобы найти фактические таблицы разрешения расположения, которые предусмотрены "res-service.ecg.com". В этом случае CRID разрешен и получен локатор для CRID. Контент может быть записан.

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

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

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

CRID://StarJourneyAggregator.com/AIIEpisodesOfStarJourney

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

CRID://broadcaster.com/StarJourneyEpisode1

CRID://broadcaster.com/StarJourneyEpisode2

CRID://broadcaster.com/StarJourneyEpisode3

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

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

transport:channel9~2130

transport:channel5~0915

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

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

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

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

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

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

CRID://Aggregator.com/AIINatureDocumentaries

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

CRID://Aggregator.com/FoxeslnTheWild

CRID://Aggregator.com/OceansOfTheWorld

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.

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":

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

- описания экземпляра;

- пользователя;

- сегментации;

- информации о происхождении метаданных;

- промежуточные и целевые.

Диаграмма на рисунке 6 иллюстрирует эту структуру.

Рисунок 6 - Документы TV-Anytime с корневым элементом "TVAMain"

6.3.2 Характеристики метаданных в системе TV-Anytime на этапе 1

6.3.2.1 Метаданные описания контента

Метаданные описания контента разделяются на четыре области:

- область, содержащую описания элементов контента, например, телевизионных программ. Эти описания сохраняются в ProgramlnformationTable. Они включают:

- заголовок программы;

- резюме;

- жанры, под которые подпадает программа;

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

Пример представления ProgramlnformationTable, содержащий единственный элемент Programlnformation - в соответствии с [15] (6.3.2.1);

- область, содержащую описания группы связанных элементов контента, например, всех эпизодов "Foxes in the Wild". Эти описания сохранены в GrouplnformationTable. Пример представления GrouplnformationTable, содержащий единственный элемент Programlnformation - в соответствии с [15] (6.3.2.1);

- область, содержащую отображения элементов изобразительного ряда на уникальные идентификаторы. Идентификаторы могут использоваться в других случаях при создании экземпляров метаданных для облегчения поиска. Эти описания сохранены в CreditslnformationTable;

- область, содержащую информацию о приобретении (использовании платных служб). Эти описания сохранены в PurchaselnformationTable.

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

6.3.2.2 Метаданные описания экземпляра

Метаданные описания экземпляра разделены на две области.

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

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

ProgramLocationTable содержит записи (элементы), которые получены из ProgramLocationType. Это базовый тип, он не реализует экземпляры непосредственно (см. [6], [7]). Пример выполнения ProgramLocationTable в соответствии с [15] (6.3.2.2).

Вторая область содержит описания служб в границах системы. Эти описания содержатся в ServicelnformationTable. Каждое описание инкапсулируется элементом Servicelnformation. Пример в соответствии с [15] (6.3.2.2).

6.3.2.3 Метаданные пользователя

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

- область, содержащую детализированные предпочтения пользователя или профиля. Эта информация доставляется в соответствии со схемой описания UserPreferences, которая позволяет выполнить множество представлений определенных типов контента, предпочтительных или затребованных пользователем. Эти описания близко коррелированы с описаниями медиа и разрешают пользователям поиск, фильтрацию, выбор и использование требуемого контента. В примере, представленном в [15] (6.3.2.3), пользователь "Robert" предпочитает новостную программу на английском языке в то время, когда он находится в Японии. Кроме того, пользователь предпочитает фильмы комедийного жанра, рассмотренные и оцениваемые определенным кинокритиком, а также фильмы, имеющие конкретный рейтинг;

- область, содержащую подробности "данных щелчка (клика)" пользователя, например, фактическая история использования действий пользователя. Схема описания UsageHistory содержит список действий, выполненных пользователем за период наблюдения. Эта информация может впоследствии использоваться аналитическими методами, чтобы формировать предпочтение пользователя. Пример приведен в [15] (1.4.1, приложение А).

6.3.3 Характеристики метаданных в системе TV-Anytime на этапе 2

6.3.3.1 Описание схемы

Схема метаданных TV-Anytime на этапе 2 является обратно совместимым расширением схемы на этапе 1. Это позволяет расширить типы данных этапа 1 для описания контента и пользователя и позволяет использовать типы данных, импортированных из MPEG-21, для создания новых областей функциональных возможностей. Обратная совместимость расширяет корневой тип документа TV-Anytime - TVAMainType, разрешающий публикации описанных метаданных при использовании новых типов данных.

Все новые типы данных объявлены в единственном пространстве имен (с идентификатором "tva2"). Схема для этого пространства имен импортирует все фазы схемы (для "xml", "tva" и "mpeg7"), так же как для MPEG-21 (идентификатор пространства имен обозначен "mpeg21"). Эта схема импортирует пространство имен ("rmpi") для спецификации TV-Anytime в соответствии с [2] для управления правами и информации защиты (Rights Management and Protection Information; RMPI).

Важно отметить, что:

- расширения в пространстве имен "tva2" являются модульными;

- эта модульность при реализации потенциально обеспечивает большую гибкость.

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

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

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

Описание купона представляет провайдерам контента инструменты для связывания конкретных предложений контента со специальными предложениями ценообразования. Объединение описания купона и таргетинга инструментов представляет возможность создания новых бизнес-моделей.

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

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

6.3.3.2 Расширения инструментов метаданных этапа 1 для применения на этапе 2

Расширения инструментов метаданных этапа 1 для применения на этапе 2 являются модульными. Они являются дополнениями к панели инструментов метаданных TV-Anytime. Поэтому отсутствует необходимость развития реализации этапа 1 одним скачком к полному соответствию на этапе 2. Прецедентом этого случая является практика MPEG-7, в которой установка инструментов схемы выполняется с помощью профилей и уровней в пределах профилей.

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

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

2) расширенное описание оборудования пользователя. В значительной степени это прерогатива производителей оборудования и разработчиков прикладного программного обеспечения;

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

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

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

Части документа TV-Anytime связаны через CRID. Метаданные могут быть распределены по нескольким документам TV-Anytime, но их соответствующие части всегда можно связать через CRID.

6.4.1 Группирование программ

Программы могут принадлежать к группам, входящим в состав других групп. Связь описания программ с описанием группы при использовании CRID отражает эту взаимосвязь в метаданных, которая показана на рисунке 7.

Рисунок 7 - Описания программ, связанные с описаниями группы через CRID

Подробности взаимосвязей описания программ с описанием группы в соответствии с [15] (6.4).

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

Пример, иллюстрирующий структуру допустимого документа TV-Anytime, в соответствии с [15] (6.5).

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

Схема XML TV-Anytime содержит элементы, которые могут быть или опциональными, или обязательными. Схема XML TV-Anytime, содержащая обязательные части ProgramInformation, в соответствии с [15] (6.6).

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

Форум TV-Anytime определил универсальное решение для передачи метаданных по однонаправленным средам. Однонаправленные среды определены как среды, в которых контент и метаданные поставляются от передающего устройства (головная станция) к конечному устройству (PDR) по однонаправленному каналу, в котором передача данных от PDR до головной станции невозможна. Решение TV-Anytime не является конкретным для конкретного транспортного уровня и разработано для использования в любой однонаправленной системе доставки. Требования к такой системе в соответствии с приложением А.

Решение TV-Anytime было разработано для поддержки следующих методов сбора метаданных TV-Anytime, передаваемых по сети с установлением соединений в одном направлении:

- метод 1: получение из потока метаданных и кэширование данных на диск приемника при условии навигации собственными методами;

- метод 2: использование решений индексации TVA, разрешающей онлайновую навигацию потока метаданных;

- метод 3: кэширование и индексация информации TVA и данных на диске, обеспечивающие улучшенную версию метода 2.

Процесс поставки описания TV-Anytime от определенного провайдера метаданных, которые будут отосланы в определенное время, состоит из пяти различных процессов. На рисунке 8 показаны процессы, связанные с предоставлением метаданных.

Рисунок 8 - Процессы, связанные с предоставлением метаданных

Фрагментация является универсальным механизмом разложения описания метаданных TVA в фрагменты TVA.

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

- он должен быть способен к обновлению независимо от других фрагментов;

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

- декодирование фрагмента и его дополнение к описанию части должны создавать допустимое описание схемы TV-Anytime.

Примечание - Описание части должно иметь как минимум фрагмент, предоставляющий корневой элемент (TVAMain).

Нормируются следующие типы фрагментов TVA:

фрагмент TVAMain, который содержит корневой элемент описания;

фрагмент Programlnformation, содержащий метаданные для данного контента;

фрагмент Grouplnformation, содержащий метаданные для данной группы контента;

фрагменты OnDemandProgram и OnDemandService, содержащие описания экземпляров контента по требованию;

фрагмент BroadcastEvent, фрагмент Schedule и фрагмент Servicelnformation, содержащие описания передаваемых экземпляров контента и служб, где они доступны;

фрагменты для метаданных Creditlnformation, PersonName и фрагментов OrganizationName;

фрагмент Review, содержащий обзор данного контента;

фрагмент Purchase Information, содержащий информацию о ценах;

фрагменты метаданных ClassificationSchemes, CSAIias и ClassificationScheme;

фрагменты метаданных Segmentation, Segmentlnformation и фрагмент SegmentGrouplnformation.

Процесс кодирования обеспечивает эффективную (с точки зрения пропускной способности) устойчивость к мешающим воздействиям и возможность обновления поставки данных в однонаправленной среде. Процесс кодирования предоставляет фрагменты метаданных TVA в двоичном формате. Предпочтительным методом кодирования в TVA, обеспечивающим многофункциональную совместимость, является метод BIM MPEG-7, определенный в [18]. Однако для работы в некоторых управляемых средах TVA допускает поставку метаданных при использовании альтернативных систем кодирования.

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

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

TVA не определяет путь, которым нужно переносить эти контейнеры, поскольку путь определяет система доставки. Однако спецификация контейнера разрешает применять контейнер, который будет легко согласовываться со стандартными способами доставки. Например, в среде MPEG-2 контейнеры могут передаваться, используя секции, объекты в карусели объектов U-U DSM-CC или модули карусели данных DSM-CC.

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

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

Такое расширение схемы TVA может быть достигнуто обратной совместимостью с использованием методов стандартных схем XML. В [7] определено подмножество методов схем XML, которые применимы в контексте схемы TVA.

Объявление новых типов данных должно происходить в отдельном документе схемы и иметь свое собственное уникальное пространство имен.

6.8.1 Полиморфизм существующего типа с наследованием при расширении

Для расширения существующего типа данных TVA используют схемы XML, порождающие механизм расширения. Так, например, если поставщик хочет добавить новый элемент под названием MyData к стандартному ProgramlnformationType TVA, он будет определять новый тип схемы в соответствии с [15] (6.8.1).

Для использования нового типа данных в экземпляре документа используют атрибут xsi:type для того, чтобы объявить фактический тип данных в соответствии с [15] (6.8.1).

Если ни один "type" не объявлен расширенным типом, то система предполагает, что это тип базовый, в данном случае - ProgramlnformationType.

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

6.8.2 Полиморфизм существующего типа при наследовании с ограничением типа данных

Для ограничения применения существующего типа данных TVA используют схемы XML, чтобы получить механизм ограничения. Так, например, если поставщик хочет создать новый тип данных под названием MyDataType, который удаляет все дополнительные элементы из стандартного TVA ProgramlnformationType, то он будет определять новый тип схемы в соответствии с [15] (6.8.2).

Для использования нового типа данных в экземпляре документа используют атрибут xsi:type для объявления фактического типа данных в соответствии с [15] (6.8.2).

Если ни один "type" не объявлен, то система предполагает, что это базовый тип, в данном случае - ProgramlnformationType.

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

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

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

Процессы, происходящие в системе TV-Anytime, и последовательность их выполнения изображены на рисунке 9.

В 7.2-7.13 представлены примеры, показывающие процессы, выполняющиеся в системе TV-Anytime.

Рисунок 9 - Процессы, происходящие в системе TV-Anytime, и последовательность их выполнения

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

Этот пример показывает, как существующая система TV-Anytime может работать при использовании спецификаций [5]-[7]. Пример дает общее представление о системе. На стадии процесса "Публикование" провайдер служб контента издает CRID, который представляет группу программ и те CRID, которые представляют составляющие программы этой группы. Тот же самый или другой провайдер служб опубликует метаданные, которые описывают эту группу и эпизоды, ее составляющие. Тот же самый или другой провайдер служб опубликует данные разрешения расположения, которые описывают, где и когда эпизоды, составляющие эту группу, могут быть приобретены. Группа и составляющие ее эпизоды могут быть доступны от нескольких провайдеров служб контента.

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

Канал между группой и эпизодами образован системой ссылок контента. Если группа CRID "//hbc/foxes/all" помещена в механизм разрешения в PDR, то она возвратится с обеими программами CRID.

Канал между программами и группой выполняется элементом <memberOf> в таблице Programlnformation в соответствии с [15] (7.2).

Для создания в PDR путеводителя EPG или информирования пользователя о расписании передачи могут использоваться метаданные экземпляра. С этой же целью используется таблица BroadcastEvent в метаданных экземпляра. Пример фрагмента таблицы XML BroadcastEvent в соответствии с [15] (7.2).

Аналогично изложенному, описание процессов:

- поиск;

- выбор;

- расположение;

- приобретение;

- просмотр;

- окончание представлено в [15] (7.2).

На рисунке 10 дано графическое представление динамического поведения этих процессов в системе TV-Anytime.

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

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

Альтернативой этому варианту является использование PDR информации из таблиц Programlnformation и ProgramLocation для визуализации EPG и при использовании сегментации метаданных на этапах "Поиск", "Выбор", "Расположение", "Приобретение", "Просмотр", "Окончание" описана в [15] (7.3).

7.4 Система TV-Anytime на этапе 1. Пример выбора из EPG конкретной программы для просмотра (в случае вещания)

Пример выбора просмотра конкретной программы из EPG (в случае вещания) описан в [15] (7.4).

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

Пример разрешения пользователю выбора контента по требованию из предложений, связанных с информацией о ценообразовании, или поиск предложений низкой стоимости описан в [15] (7.5).

Рисунок 10 - Пример динамического поведения процессов в системе TV-Anytime

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

Пример уведомления пользователя об интересующей его службе, лежащей в рамках его профиля, описан в [15] (7.6).

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

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

Кроме того, зритель хочет, чтобы PDR генерировал собственный график зрителя, настроенный на его предпочтения и образ жизни. Эта процедура генерации может быть выполнена в PDR автоматически на основе истории просмотров, выполненных зрителем, и информации об его предпочтениях. В этом случае создается персональный канал, а его информационная программа предоставляет руководство для EPG, например:

- на понедельник с 20:00 до 21:00 - новостной канал;

- на понедельник с 21:00 до 22:00 - специальный боевик от НТВ и т.д.

PDR объединяет программы, предпочитаемые пользователем, в предпочтительные для пользователя даты и создает один персональный канал.

Для такого персонального канала в PDR пользователя должны выполняться операции в следующей последовательности:

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

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

- формирование нового канала для пользователя;

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

- формирование новых персонализированных метаданных описания экземпляра InstanceDescriptionMetadata для информирования пользователя о том, что экземпляр новой программы включен в персональном канале.

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

Рисунок 11 - Концептуальная схема персонального канала

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

Рисунок 12 - Операции взаимодействия между провайдером служб и пользователем

Детализированное описание функционирования службы персонального канала представлено в [15] (7.7).

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

7.8 Система TV-Anytime на этапе 1. Пример сценария: программа состоит из сегментов от нескольких провайдеров и поддерживает последние новости на персональном PDR

Этот пример может выполняться в двух вариантах:

- программа была предварительно записана, она поставляется в запланированное время и связана с CRID группы. Эта программа состоит из нескольких программ, имеющих свои собственные CRID, объединенные под эгидой groupCrid общей программы. Службе, учитывающей интересы пользователя, известны элементы программ, интересующих пользователя, CRID которых будет использоваться, для выполнения записи и обновления желаемых элементов программы;

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

Сценарий второго варианта при компиляции (преобразовании) обновленных сегментов от нескольких провайдеров представлен на рисунке 13.

Пример решения программы, состоящей из сегментов от нескольких провайдеров и поддерживающей последние новости в личном PDR, описан в [15] (7.8).

Последние новости и новости спорта

Рисунок 13 - Компиляция обновленных сегментов от нескольких провайдеров

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

В этом примере обеспечение сценария выполняется при транспорте метаданных с использованием существующей спецификации TV-Anytime. Протоколы HTTP и TCP/IP используются как протоколы транспорта метаданных на сети IP. Двунаправленная транспортировка метаданных показана на рисунке 14.

Рисунок 14 - Двунаправленная транспортировка метаданных

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

Пример сценария при двунаправленном транспорте метаданных с использованием существующей спецификации TV-Anytime описан в [15] (7.9).

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

Это приложение показывает этапы выполнения технологии TV-Anytime, объединяющей метаданные TVA из наборов EPG от нескольких провайдеров метаданных.

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

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

Пример сценария использования EPG от нескольких провайдеров описан в [15] (7.10).

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

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

Пример сценария записей связанных материалов описан в [15] (7.11).

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

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

- о количестве зрителей, месте проживания, датах рождения;

- желании получать рекомендации о контенте от устройства TVA.

После передачи этих сведений пользователь выбирает:

- предпочтительные типы программ (контента). Например, новости, спорт (легкая атлетика) и телевикторины;

- типы программ (атмосфера программ). Например, альтернативные, захватывающие дух, вызывающие вдохновение;

- диапазон исполнителей, которые ему нравятся (ключевой признак - талант). Например, Шон Коннери, Хамфри Богарт, Клинт Иствуд, Мэг Райан, Николай Крючков, Любовь Орлова.

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

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

Детализированный пример профилирования сценария описан в [15] (7.12).

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

7.13.1 Введение

Этот раздел содержит три примера описания контента с применением метаданных RMPI для случаев:

- FTA;

- Pay-Per-View (PPV);

- Video-On-Demand (VoD).

Примеры показывают только метаданные RMPI-MB (т.е. до фазы приобретения доменного имени). Для того чтобы получить соответствующий RMPI-M (в фазе после приобретения доменного имени), флаг типа RMPI должен измениться и должны быть установлены идентификатор домена и идентификатор единой точки управления (если они применимы для использования).

7.13.2 Контент бесплатного вещания

Пример, показывающий возможные комбинации прав, предоставленных заданной части контента при бесплатном вещании, описан в [15] (7.13.2).

7.13.3 Контент системы с трафиком при оплате за показ

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

7.13.4 Контент видео по запросу

Пример, показывающий возможные сочетания прав, предоставленных заданной части контента, если провайдер контента использует технологию DRM, описан в [13] (7.13).

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

8.1 Введение

В разделе показано, каким образом спецификация RMPI TVA ([2]) может быть использована или в качестве спецификации для автономного применения, или в качестве технологии, интегрированной с другими технологиями для применения в качестве ключевых бизнес-сценариев. Эти примеры не являются исчерпывающими и не охватывают все возможные комбинации настроек поля RMPI. Предполагается существование других бизнес-моделей, которые в настоящем стандарте не проиллюстрированы, и других комбинаций настроек поля RMPI.

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

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

8.3 Концепции RMP

8.3.1 Управление копированием и управление воспроизведением

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

8.3.2 Таргетинг потребления контента при использовании управления правами и информации защиты

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

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

Согласно настройкам RMPI использование контента может быть ограничено теми доменами, которые получили исходную вещательную передачу. Настройки RMPI могут также разрешить использование общего контента между совместимыми доменами RMP.

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

8.3.3 Права экспорта и право воспроизведения

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

Передача права использования контента от RMP TVA системам, не совместимым с RMP, решается использованием прав экспорта ("Право экспорта аналогового ТВ", "Право экспорта цифрового ТВ с HD", "Право экспорта цифрового ТВ с SD").

RMPI включает в себя информацию для управления выпуском управляемого контента для систем, которые не распознают RMPI. Параметры реализации этих прав обеспечиваются через права экспорта.

8.3.4 Функциональная совместимость устройств, совместимых с RMP, и устройств, не совместимых с RMP

Целью предоставления права экспорта является разрешение взаимодействия с системами, не совместимыми с RMP. Если право экспорта не предоставляется, то выделение контента от совместимой системы RMP запрещен. Например, право проигрывания, предоставленное без права экспорта, разрешает визуализацию контента только дисплею, совместимому с RMP. В качестве альтернативы "Право экспорта аналогового ТВ" разрешило бы поставку контента устройству воспроизведения устаревшего контента.

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

RMPI может существовать в двух последовательных стадиях:

- RMPI-MB;

- RMPI-M.

RMPI-MB передается вместе с сигналом вещания. При приеме в домене конечного пользователя RMP TVA он преобразуется в RMPI-M. Права, которые предоставляются "Принимающему домену" и "Единой точке управления" (при наличии) в RMPI-MB, переносятся в RMPI-M. Универсальные ссылки на "Принимающий домен" и "Единую точку управления" (если имеется) в RMPI-MB преобразуются в конкретные ссылки с четкой формулировкой идентификаторов в RMPI-M. В целях поддержания сохранности (персистентности) прав, присвоенных вещателю или провайдеру контента, совместимый приемник RMP TVA не должен изменять значения в RMPI. Права, предоставляемые любому домену, всегда переносятся без изменений от RMPI-MB до RMPI-M.

8.5 Условия контроля соответствия правил управления и поддержки TV-Anytime требованиям системы сертификации

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

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

Полномочные органы, обеспечивающие соответствие, определяют:

- правила функционирования;

- параметры устойчивости;

- одобренное поведение устройств;

- применяемую торговую марку;

- наличие лицензированного логотипа;

- наличие сертификации, выполненной зарегистрированными аккредитованными органами.

Так как проблемы соответствия могут обрабатываться отдельными исполнителями, ожидается, что соответствие будет обеспечиваться субъектами, предлагающими выполнение сертификации соответствия, на региональной основе или на основе, специфичной для рынка. Полномочный орган должен установить возможности устройства RMP. Например, аналоговый дисплей в составе цифрового PDR все еще может считаться устройством RMP в соответствии с заданным режимом соответствия.

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

Ниже рассматривается 12 возможных сценариев вещания контента.

8.6.1 Сценарий 1: вещание контента FTA. Управление перераспределением и просмотром не выполняется

Контент FTA транслируется без ограничений использования при условиях:

- восстановление контента вещателем не выполняется;

- контент может экспортироваться из доверяемой платформы;

- контент изначально может поставляться из Интернета.

Семантика функций для грантов, осуществляемых в RMPI-MB для сценария 1, приведена в таблице 3.

Таблица 3 - Семантика функций для грантов, осуществляемых в RMPI-MB для сценария 1

Грант RMPI-M аналогичен гранту RMPI-MB за исключением двух полей:

- Id домена будет выполнять идентификацию "Принимающего домена";

- Флаг типа RMPI будет установлен в 1 (т.е. имеет место RMPI-M).

Права на экспорт предоставляются для устаревших устройств, например для цифровых/аналоговых дисплеев, которые не являются RMP совместимыми.

"Расширение права" не предоставляется, так как все права уже предоставлены.

Грант для "Принимающего домена" может не приниматься во внимание и в RMPI-MB, и в RMPI-M, так как бизнес-модель не делает различия между "Принимающим доменом" и "Любым доменом".

Управление скремблированием предусматривает режим "сохранить оригинальное скремблирование". Это означает, что приемник RMP TVA не выполняет операции дескремблирования в момент приобретения. В поле "алгоритм шифрования" установлено "не шифруется", потому что контент изначально не был зашифрован и сохранен в исходном состоянии.

8.6.2 Сценарий 2: бесплатное вещание контента с ограничениями перераспределения через Интернет

Контент FTA транслируется с ограничениями перераспределения. Пользователю не разрешается перераспределение контента через Интернет. Контент может свободно распространяться в домашних условиях.

Сценарий 2 аналогичен сценарию 1 за исключением того, что копирование контента между членами таргетированной аудитории или между членами таргетированной и нетаргетированной аудитории не допускается, хотя разрешается хранение информации на личном внешнем съемном носителе. В таком случае съемная копия не связана с доменом, в котором она была создана.

Семантика функций для грантов, осуществляемая в RMPI-MB для сценария 2, представлена в [15] (таблица 5).

8.6.3 Сценарий 3: бесплатное вещание контента, ограниченного географической зоной

Контент FTA транслируется с ограничениями географической зоны. Контент не разрешается употреблять вне данной географической зоны.

Семантика функций грантов с ограничениями географической зоны, осуществляемая в RMPI-MB для сценария 3, представлена в [15] (таблица 6).

8.6.4 Сценарий 4: бесплатное вещание контента с управлением просмотром и перераспределением

В этом сценарии рассматривается случай управления вещанием контента при ограниченном времени вещания.

Семантика функций грантов с ограничениями времени вещания, осуществляемая в RMPI-MB для сценария 4, представлена в [15] (таблица 7).

8.6.5 Сценарий 5: бесплатное вещание без поддержки устаревших приемников

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

Семантика функций грантов без поддержки устаревших устройств, применяемая в RMPI-MB для сценария 5, представлена в [15] (таблица 8).

8.6.6 Сценарий 6: бесплатная прямая потоковая передача

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

Семантика функций грантов бесплатной прямой потоковой передачи, применяемая в RMPI-MB для сценария 6, представлена в [15] (таблица 9).

8.6.7 Сценарий 7: скремблированный контент FTA

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

Семантика функций грантов скремблированного контента FTA, применяемая в RMPI-MB для сценария 7, представлена в [15] (таблица 10).

8.6.8 Сценарий 8: платное телевидение, подписка с ограниченным количеством одновременных потреблений

Контент транслируется под контролем системы СА, и приемник pay-TV управляет передачей в системе RMP TV-Anytime для включения постоянной защиты контента в "Принимающем домене".

Контракт между провайдером pay-TV и абонентом, который обслуживается через систему СА, предусматривает, что количество одновременных просмотров служб ограничивается конкретным количеством устройств (в примере, представленном в [15] (таблица 11), рассмотрено два устройства). Система RMP используется для обеспечения соблюдения этого правила в "Принимающем домене".

Семантика функций грантов с ограничением количества одновременных потреблений, применяемая в RMPI-MB для сценария 8, представлена в [15] (таблица 11).

8.6.9 Сценарий 9: проталкивание контента

Контент ("Игра", "Экспорт аналогового ТВ", "Экспорт цифрового ТВ с HD", "Экспорт цифрового ТВ с SD") провайдером служб спекулятивным способом продвигается к "Принимающему домену" без права просмотра. "Расширение прав" предоставляется так, чтобы пользователь мог приобрести те права, которые разрешат просмотр на индивидуальной основе.

Если пользователь примет решение о просмотре контента, то выполняется реализация "Расширение прав". Подсистема RMP в PDR связывается с источником дополнительных прав (системы СА) так, чтобы транзакция для приобретения новых прав была выполнена через пользовательский интерфейс устройства.

Система СА дает разрешение пользователю и генерирует новые гранты, выраженные в новом экземпляре RMPI-M.

Семантика функций грантов с продвижением контента, осуществляемая в RMPI-MB для сценария 9, представлена в [15] (таблица 12).

8.6.10 Сценарий 10: плата за предоставление контента в формате "купить, чтобы сохранить"

Контент поставляется под управлением системы СА как часть службы платы за просмотр. Пользователь покупает право сохранить контент без ограничения времени для употребления в своем частном домене.

Управление контентом передано от системы СА системе TVA-RMP при оплате пользователем просмотра.

Семантика функций грантов с платой за предоставление контента в формате "купить, чтобы сохранить", осуществляемое в RMPI-MB для сценария 10, представлена в [15] (таблица 13).

8.6.11 Сценарий 11: импорт защищенного от копирования контента аналогового ТВ

Программа аналогового ТВ подается к PDR, совместимого с RMP TVA, с соответствующими сигналами управления копированием (например, CGMS-A). Соответствующее правило управления копированием указывает: "однократное копирование". Совместимое устройство TVA-RMP генерирует RMPI-M, используя поступающую информацию управления копированием согласно правилам соответствия, определенным полномочным органом.

Семантика функций грантов при импорте защищенного от копирования аналогового контента, осуществляемая в RMPI-M для сценария 11, представлена в [15] (таблица 14).

8.6.12 Сценарий 12: формат видео по запросу

Контент приобретается пользователем в формате видео по запросу. Контент защищен собственной системой DRM между сервером VoD и сервером, совместимым с RMP TVA. Контроль за контентом передается системе RMP TVA для решения RMP TVA о включении дисплеев. В соответствии с бизнес-моделью VoD права предоставляются только для отдельных записей.

Семантика функций грантов для формата видео по запросу, осуществляемых в RMPI-M для сценария 12 согласно [15] (таблица 15), представлена в таблице 4.

Таблица 4 - Гранты, осуществляемые в RMPI-MB для сценария 12

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

Рекомендации по решению проблем, возникающих при реализации процессов TV-Anytime: "Публикование", "Поиск", "Выбор", "Расположение", "Приобретение", "Просмотр" и "Окончание", к настоящему времени не нормированных в системе TV-Anytime, представлены в [15] (раздел 9).

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

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

10.1.1 Программа с ассоциированным пакетом

В [15] (10.2.1) описана спортивная программа с ассоциированным пакетом, который включает интерактивное приложение. Таблица пакета содержит информацию (в примере: промежуточное программное обеспечение и аудио), которая может использоваться для определения компонентов пакета, которые должны быть получены. Экземпляр документа представлен в [15] (10.2.1).

10.1.2 Образовательный пакет

Пример описывает пакет учебных материалов для облегчения изучения английского языка, состоящий из анимации и приложения. Приложение может работать под ОС Linux с оперативной памятью не менее 16 Мбайт. Детали примера представлены в [15] (10.2.2).

10.1.3 Вещание данных

Службу вещания данных иллюстрируют сниппеты (фрагменты) XML, представленные в [15] (10.2.3), для программы под условным названием "Damo". Вещание данных и аудиовизуальной программы "Damo" происходит одновременно. Служба вещания данных с условным названием "Damo Plus" состоит из двух приложений. Одно из них под названием "Damo Story" дает информацию об актерах, расположении, резюме и т.д. Другое под условным названием "Damo Fan Cafe" представляет собой приложение интерактивного вещания данных, с помощью которого вы можете проголосовать, например, за любимого артиста.

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

В процессе "Публикования" провайдер служб контента производит программы аудиовидео и приложения вещания данных. Тот же провайдер или другой провайдер служб контента создает необходимые метаданные. Метаданные программы выражены в схеме метаданных TVA этапа 1. Аттрактор и информация о расположении программы описаны в таблицах Programlnformation и ProgramLocation соответственно [15] (6.3, 7.3).

Метаданные приложения выражаются схемой пакета этапа 2. Как и в случае телевизионных программ, информация о расположении приложения данных входит в таблицу локации (расположения) программы ProgramLocation. Дескриптор контента ContentDescription для пакета описывает общую информацию об аттракторе службы вещания данных.

Два приложения, которые состоят из данных службы, описаны дескриптором элемента. Элемент ContentDescription описывает общую информацию об аттракторе приложения вещания данных. Атрибуты контекста для применения данных описаны в DataBroadcastingContextAtributes. Как и ранее, провайдер служб публикует информацию в сниппете XML.

Процессы "Поиска" и "Выбора" на этапе 2 TVA подобны процессам поиска и выбора на этапе 1 TVA для обычного контента. Если служба данных связана со службой программ аудиовидео, то пользователь обычно применяет EPG, чтобы получить CRID программы аудиовидео. После этого пользователь использует метаданные пакета для поиска службы данных.

После выбора конкретной службы данных она должна быть разрешена для файлов, входящих в ее состав. Принимая во внимание CRID для службы данных, фактическое расположение необходимых файлов может быть разрешено аналогично [15] (5) по технологии поиска контента по ссылке на этапе 1 TVA. Эти файлы могут быть приобретены через вещательную передачу или через Интернет. Пример сниппета XML для службы вещания в соответствии с [15] (10.2.3).

CRID экземпляра XML для службы передачи данных имеет два связанных с ним идентификатора CRID. Это означает, что служба передачи данных передана через две Карусели.

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

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

10.2.1 Описание среды, используемой пользователем

Сниппет XML, в соответствии с [15] (10.3.1), соответствует случаю, когда пользователь в качестве клиентского терминала TV-Anytime использует PDA и для случая видео по запросу, и для случая формата "AVI", которые PDA может декодировать. В дополнение к терминальной информации сниппет также предоставляет информацию о текущих погодных условиях.

Опираясь на эти условия, PDA может либо выбрать контент в формате "AVI" из доступных форматов, либо провайдер служб может проталкивать контент в формате "AVI" в предположении, что это описание среды предоставлено провайдером служб. Кроме того, PDA или провайдер служб могут обеспечить контент, подходящий для текущих погодных условий ("дождь").

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

10.2.2 Персонализированная служба

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

В сниппете XML ([15] (10.3.2)) показан пример экземпляра документа с использованием запроса get_data и запрашиваемых полей RequestedFields. С их помощью клиенты могут запрашивать конкретный элемент или конкретные значения атрибутов метаданных TVA, а также информацию, определенную в табличном виде.

Детализация характеристик персонализированной службы в соответствии с [15] (10.3.2).

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

Пример возможности использования платформы для сигнализации о возможности замены элемента контента при воспроизведении записанного материала представлен в [15] (10.4).

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

Условия, при которых возникает целесообразность обмена метаданными, показаны в стандарте [15] (10.5).

10.4.1 Передача метаданных контента другу

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

10.4.2 Просмотр веб-страниц для выбора контента и сбора метаданных

Этот сценарий подразумевает выполнение следующих шагов:

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

- пользователь просматривает EPG и выбирает контент. Кнопка записи на странице EPG позволяет пользователю загрузить метаданные, связанные с выбранным контентом, для программирования записи контента;

- пользователь включает запись и получает метаданные (в соответствии с [15]), связанные с выбранным контентом в его PDR.

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

10.5 Система TV-Anytime на этапе 2. Пример: дистанционное программирование с использованием сетевого цифрового рекордера (NDR)

В этом подразделе рассмотрены сценарии применения сетевого цифрового рекордера (NDR) при решении следующих задач:

- программирование NDR для будущей записи;

- программирование NDR для немедленной записи;

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

10.5.1 Программирование NDR для будущей записи

Этот сценарий включает следующие этапы:

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

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

Детализированный сценарий выполнения этой задачи представлен в [15] (10.6.1).

10.5.2 Программирование NDR для немедленной записи

Этот сценарий включает следующие этапы:

- пользователь просматривает контент прямой записи, используя свой PDR;

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

- пользователь может запросить NDR немедленно записать контент вещательной передачи.

Детализированный сценарий программирования NDR для немедленной записи представлен в [15] (10.6.2).

10.5.3 Программирование NDR для потребления другим устройством

Сценарий программирования NDR для записи необходимого контента с последующим проигрыванием этого контента на PDA представлен в [15] (10.6.3).

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

Примеры сценария с описанием двух вариантов применения купонов:

- приобретение контента с купоном вознаграждения;

- приобретение контента с купоном "купить три фильма, получить один бесплатно" представлены в [15] (10.7).

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

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

Существует несколько проблем, связанных с совместным использованием контента и метаданных:

- проблемы конфиденциальности, связанные с передачей персональной информации ([6]);

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

В [2] описывается информация об управлении правами на контент. В [4] определена информация о защите метаданных при передаче по двунаправленным каналам.

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

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

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

Допускается применение идентификаторов, отличных от CRID. Например, для идентификации бит-копий контента с целью определения прав и последующей идентификации контента в частных сетях. Спецификация метаданных разрешает Otherldentifiers получать эти дополнительные идентификаторы.

11.1.2 Совместный доступ к метаданным

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

11.1.3 Совместное использование метаданных и контента

Существующие спецификации не обеспечивают связывание метаданных и контента.

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

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

Для того чтобы обеспечить прямую связь метаданных с контентом, предпочтительно использовать форматы, такие как AAF или MXF. Эти форматы обеспечивают встраивание метаданных в контент и в случае MXF в состоянии отобразить модель данных TV-Anytime как свою собственную, а также для встраивания XML непосредственно. Это особенно важно, если контент будет экспортироваться в другую среду, например при записи на DVD.

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

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

Одним из ключевых вопросов удаленного программирования ([12]) через электронную почту является гарантия обработки только действительных электронных писем. При отсутствии защиты третья сторона могла бы удаленно управлять PDR (атака "отказ в обслуживании").

PDR может быть сконфигурирован со списком допустимых источников и полем "From:" в заголовке электронной почты. Это обеспечит базовый, но явно недостаточный уровень проверки. Было бы надежнее, если бы тело электронной почты могло бы быть подписано и/или каким-либо образом зашифровано.

Следует учитывать, что при обмене метаданными между друзьями безопасность будет понижаться.

Приложение А
(обязательное)

Требования к транспортной среде

А.1 Область нормирования технических характеристик

Технические характеристики системы TV-Anytime описывают информационные структуры поиска контента по ссылкам и метаданным и их совместную работу в контексте системы. Однако многие функции, необходимые для доставки служб TV-Anytime, в среде TV-Anytime не нормированы. Примерами таких функций являются:

- конкретные технологии передачи данных TV-Anytime;

- определения точного времени начала и окончания программ;

- перенос контента;

- связывание сроков (данных о времени) метаданных TV-Anytime с реальными сроками передачи и т.д.

Целью нормирования параметров транспортного интерфейса является определение требований, которые службы TV-Anytime предъявляют к нижним уровням. Наибольший интерес представляют требования к однонаправленному доступу, например в сетях вещания или в одноадресных или многоадресных IP-сетях.

А.2 Требования к однонаправленной системе доставки

Базовая система доставки должна:

- предусматривать возможность транспортировки достоверной информации программ TV-Anytime при использовании различных транспортных механизмов;

- обеспечивать метод локации (поиска) типа и места расположения переносимой информации TV-Anytime для выполнения следующих задач:

- для получения информации о разрешении контента, расположении RAR - в соответствии с [5];

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

- список доступных потоков фрагментов метаданных TVA;

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

- типы фрагментов или категории фрагментов TVA, которые переносятся в каждом потоке фрагментов метаданных TVA, и информация об их контексте (например, список каналов вещания, список конкретных CRID);

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

- параметры контейнеров каждого потока фрагментов метаданных, сообщаемых транспортным уровнем:

- идентификаторы каждого контейнера, его тип и его расположение;

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

- результаты контроля изменений версии контейнера в одной точке;

- предусмотреть локаторы (как указано в [5]) для идентификации и определения расположения экземпляров контента. Локаторам должен обеспечиваться доступ к фрагментам информации TV-Anytime;

- разрешить вставку некоторых типов данных TV-Anytime (CRID для поиска контента по ссылкам, информацию RMP и метаданные) вместе с аудиовизуальным контентом. TV-Anytime должна определять синтаксис и семантику таких данных;

- обеспечить механизм для сопоставления по линейной шкале, используемой информации сегментации TV-Anytime с позициями фактического контента, например при нормальном времени воспроизведения (Normal Play Time; NPT). Линейная шкала применяется на записанной части контента с целью сегментации для обеспечения произвольного доступа к сегментам контента;

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

- разрешить повторную передачу данных TV-Anytime. Должна быть предусмотрена возможность изменения частоты повторения для различных типов информации TV-Anytime. Начало декодирования данных TV-Anytime не должно ожидать повторения всего набора данных TV-Anytime в течение периода повторения;

- обеспечивать поддержку избирательного обновления информации TV-Anytime. Базовая система доставки не должна ограничивать размер данных TV-Anytime и должна допускать обновление типоразмеров для различных типов данных TV-Anytime. Обновления не должны вызывать несоответствия данных в приемнике, даже если предыдущие обновления были потеряны. Для эффективной работы системы доставка должна обеспечиваться сигнализацией об обновлении информации TV-Anytime;

- использовать в приемнике потенциально маломощные процессоры и память. Данные TV-Anytime должны инкапсулироваться таким образом, чтобы восстановление этих данных в условиях транспортных ошибок было бы по возможности оптимальным;

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

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

Электронный текст документа

и сверен по:

, 2020