Параметром name для идентификатора контента должна быть строка "ContentID", а параметром value должен быть идентификатор контента.
Параметр value должен быть представлен в виде строки ASCII-символов. Значение параметра должно соответствовать кодировке URI. В частности, если какие-либо символы параметра value попадают в зарезервированный набор символов (независимо от контекста), они должны быть закодированы с помощью символа "%" и двух последующих шестнадцатеричных цифр в верхнем регистре. Символы, попадающие в незарезервированный набор символов, не должны быть закодированы.
HTTP-заголовки ответа MRS должны включать в себя заголовок "Expires".
HTTP-заголовки ответа MRS должны также включать в себя заголовки CORS, как определено в таблице 2.
Таблица 2
Тело ответа MRS представляет собой JSON-документ, состоящий из объекта ответа MRS, описываемого корневым объектом схемы JSON. Пример шаблона для объекта JSON:
5.4.1 Общие положения
Информация материала (MI) или ее части, возвращаемые MRS, могут измениться во время просмотра контента и поэтому могут потребовать обновления.
Если массив updateMaterial присутствует и заполнен, то это означает, что обновления могут происходить, но не обязательно для материалов, определенных в свойствах материалов. Если массив updateTimelineSync присутствует и заполнен, это означает, что обновления могут происходить, но не обязательно для информации временной шкалы синхронизации, определенной в свойстве syncTimelineInformation.
Свойства updateMaterial и updatedTimelineSync являются массивами размещений, из которых могут быть получены или извлечены обновления. Размещение кодируется как URL и частично идентифицирует используемый протокол обновления. Для каждого размещения также передается MIME-тип, который завершает идентификацию протокола обновления. Данные массивы могут также содержать размещение MIME-типов для других механизмов, которые не определены в настоящем стандарте.
CSA осуществляет механизм длительного опроса, определенный в 5.4.4. CSA должно реализовывать механизм веб-сокета, определенный в 5.4.5, и механизм событий передачи сервера, определенный в 5.4.6. CSA может реализовать механизм BOSH/XMPP, определенный в 5.4.7.
Если массивы присутствуют, то элемент массива 0 должен содержать размещение и идентификацию службы длительного опроса, как определено в 5.4.4. Все другие элементы массива являются опциональными.
Порядок элементов в массиве указывает на порядок размещений, где самый высокий индекс указывает на наиболее предпочтительный вариант. CSA должно использовать элементы массива в порядке убывания, начиная с самого старшего элемента. CSA может игнорировать любой элемент массива, чей URL и mimeTYPE оно не распознает или не поддерживает. Если CSA не удается установить соединение, используя данный элемент массива, то CSA должно продолжать попытки, используя остальные элементы в порядке убывания. После того как CSA устанавливает успешное соединение, оно должно продолжать его использовать для обновления, за исключением случаев:
- возникновения состояния ошибки;
- если получен новый массив обновления, не содержащий используемое в настоящее время размещение обновления.
При возникновении таких событий CSA в любом случае должно повторить процесс выбора размещения обновления.
5.4.2 Синтаксис JSON для обновления элемента массива
Объекты, входящие в состав массива updateMaterial и массива updateTimelineSync, должны соответствовать следующему шаблону:
Объект JSON, возвращаемый протоколами обновления, передает изменения в материал или в информацию временной шкалы синхронизации. Объект JSON должен соответствовать 5.3.4, но все его свойства, кроме свойства "type", являются опциональными. Он должен иметь дополнительные свойства, которые определены в настоящем пункте. Свойство "type" должно иметь значение "update".
Объект JSON должен иметь дополнительные свойства в соответствии со следующим шаблоном:
Длительный опрос является обычным запросом, посылаемым на определенный URL, когда ответ соответствует 5.3.4, а объект JSON в ответе соответствует семантике, определенной в 5.4.3, в зависимости от обстоятельств.
Ответ обычно не приходит немедленно, и сервер держит соединение открытым, возвращая ответ, когда происходит обновление. Как правило, сети закрывают соединение после истечения определенного периода времени, поэтому CSA должно повторно отправить команду на соединение, если оно оказалось неожиданно закрытым.
Когда соединение закрывается неожиданно или в результате завершения получения обновления, новый запрос выдается не ранее, чем указано в наименьшем из значений в свойстве repollInterval объекта JSON в ответах, или в обновлениях (считая с начала последнего запроса), или в заголовке "Expires" последнего успешного HTTP ответа.
Объект mimeTYPE должен иметь формат application/json для массива updateMaterial или формат application/json-patch для массива updateTimelineSync. Компонент протокола URL должен быть "http" или "https".
Объект mimeTYPE должен иметь формат application/json для массива updateTimelineSync. Компонент протокола URL должен быть "ws" или "wss". Данный URL должен ссылаться на серверную часть протокола WebSocket версии 13.
Все отправленные сообщения должны быть кадрами данных WebSocket (в соответствии с требованиями спецификации протокола WebSocket) с полезной нагрузкой в текстовом формате.
CSA не должно направлять никаких данных на сервер через WebSocket.
Сервер может посылать ответы с обновлениями в соответствии с 5.4.3.
Объект mimeTYPE должен иметь формат "ext/event-stream". Компонент протокола URL должен быть "http" или "https".
Тип события, которое фиксируется строкой "event:" потока событий, должен быть установлен в "MIupdate" (т.е. строка "event: MIupdate" должна предшествовать данным события) для обновлений материала или в "TSupdate" (т.е. строка "event:TSupdate" должна предшествовать данным события) для обновления синхронизации временной шкалы.
Данные должны быть посланы как поле данных с именем (т.е. строка "data:" должна предшествовать данным события).
Данные события должны быть объектом JSON для событий "MIupdate" и объектом JSON Patch для событий "TSupdate". Для того чтобы обеспечить правильную передачу, кодировка объекта JSON не должна включать в себя символы конца строки.
Объект mimeTYPE должен иметь формат "ext/event-stream". Компонент протокола URL явно не определен, но обычно должен быть "http" или "https".
Свойство protocolSpecificData должно присутствовать и содержать XML-строфу в формате base64, которая должна быть отправлена от клиента к серверу, чтобы подписаться на обновления.
Возвращенный элемент тела сообщения должен содержать объект JSON для обновления информации материала или объект JSON для обновления syncTimelineInformation.
Представление JSON в теле элемента должно быть закодировано в формате base64, чтобы избежать риска повреждения XML-документа.
Для компенсации задержек в сети связи между ТВ-устройством и CSA в процедуре синхронизации временной шкалы с привязкой к системным часам производится обмен временными метками, обеспечивая тем самым синхронизацию ТВ-устройства и CSA. Синхронизация системных часов обеспечивает соответствие показаний системных часов ТВ-устройства и CSA.
В данном разделе описаны протокол, используемый для синхронизации системных часов через интерфейс WC, и требования для включения оконечных узлов службы синхронизации системных часов в элементарную функцию ТВ-устройства - сервер системных часов (WC сервер). В разделе также описаны предполагаемые протокол взаимодействия и роль элементарной функции CSA - клиента системных часов (WC клиент).
Элементарная функция ТВ-устройства WC сервера должна реализовывать системные часы и поддерживать службу синхронизации системных часов.
Системные часы ТВ-устройства должны быть монотонными, энергонезависимыми (на время отключения питания от ТВ-устройства) и выполнять свою роль в синхронизации системных часов. Часы должны быть стабильными в пределах допусков практической реализации (например, на основе кварцевого генератора).
6.2.1 Введение в протокол
Протокол должен передавать следующую информацию:
- значение времени, используемое для оценки смещения между системными часами WC сервера и системными часами WC клиента;
- точность измерения, представляющую максимальную величину точности, обеспечиваемую в процессе считывания WC сервером значения из системных часов;
- максимальную погрешность частоты, представляющую максимальную величину, на которую частота системных часов WC сервера может отклоняться от номинального значения с течением времени.
6.2.2 Значения времени и оценка смещения системных часов
WC клиент записывает значение времени T1 в момент, когда сообщение с запросом подготовлено и направлено на WC сервер, и значение времени T4 в момент, когда принимает сообщение с ответом. Аналогично WC сервер должен записывать значения T2 и T3 своих собственных системных часов в момент, когда ответное сообщение подготовлено и отправлено. Процесс синхронизации системных часов показан на рисунке 1.
![]() T1 - исходное значение времени; T2 - значение времени
приема; T3 - значение времени передачи; T4 - значение
времени ответа
Если предположить, что сообщение с запросом и ответное сообщение занимают равное количество времени для передачи между WC клиентом и WC сервера, для WC клиента возможно оценить смещение offset
. (1)Также для WC клиента возможно оценить общее время, потраченное на сообщения запроса и ответа, известное как время запроса туда-обратно round_trip_time
. (2)Границы неопределенности оценки смещения (известные как дисперсии) больше или равны плюс или минус половине времени запроса туда-обратно.
Когда WC сервер посылает свой ответ, он может отправить и последующий ответ, который обновляет данные WC клиента значением времени, более точным, чем время передачи T3. Если WC клиент получает последующий ответ, он должен заменить значение времени, полученное ранее, значением времени из этого сообщения.
6.2.3 Точность измерения
Точность измерения является существенной ошибкой, которая может возникнуть в процессе измерения времени системных часов. Она обусловлена дискретностью отсчета системных часов, а также временем, которое требуется, чтобы измерить их значение.
Если принять наименьшее регулярное приращение системных часов за N тактов при номинальной скорости M тактов в секунду, то показания системных часов в любой момент времени ограничены точностью в пределах N/M секунд.
Если процесс снятия показаний занимает p секунд, то точность измерения measurement precision (mp) рассчитывается по формуле
mp = p + N/M. (3)
6.2.4 Максимальная ошибка частоты
По ряду причин WC могут изменять частоту с течением времени (отклонение от номинальной частоты).
Ошибка частоты измеряется в миллионных частях (ppm). Ошибка частоты N ppm означает, что период времени T секунд может быть неточным на +/- T·N/1 000 000 секунд.
Опорный генератор устройства характеризуется максимальной ожидаемой погрешностью частоты F ppm для установленных условий эксплуатации устройства.
Система, где используется процесс управления синхронизацией (например, клиент NTP), может намеренно смещать тактовую частоту. Максимальное смещение частоты, которое может быть достигнуто с помощью такого процесса, равно +/- L ppm и также должно учитываться при определении максимальной погрешности частоты.
Если процесс управления синхронизацией (например, в клиенте NTP) предназначен для компенсации частотной погрешности опорного генератора, то можно предположить, что эффект смещения частоты благодаря процессу управления синхронизацией позволит снизить ошибку частоты. Тогда максимальная ошибка частоты (ppm) будет определена по формуле
ppm = max(F, L). (4)
Синтаксис сообщений синхронизации системных часов приведен в таблице 2.
Таблица 2
Поле message_type определяет тип сообщения и принимает одно из значений, указанных в таблице 3.
Таблица 3
Сообщение синхронизации WC должно быть передано в качестве полезной нагрузки одиночного UDP пакета.
WC сервер должен обслуживать оконечный узел службы синхронизации системных часов. WC сервер должен прослушивать сообщения запроса протокола синхронизации системных часов от CSA на IP-адресе и номере порта, соответствующих оконечному узлу службы.
Оконечный узел службы синхронизации системных часов должен представляться в виде URL формата "udp://<ip-address>:<port-number>", где <ip-address> и <port-number> являются IP-адресом и номером порта, на котором WC сервер представляет оконечный узел службы.
Синхронизация временной шкалы представляет собой процесс, с помощью которого элементарная функция CSA SC и элементарная функция MSAS ТВ-устройства обмениваются информацией о метках времени через интерфейс TLS для того, чтобы координировать синхронизацию процесса презентации контента по расписанию.
MSAS должен обеспечить нескольким CSA возможность сохранять открытые сеансы с оконечными узлами служб TLS одновременно. MSAS должен обеспечить CSA возможность иметь несколько открытых сеансов с одним оконечным узлом службы TLS.
Когда CSA начинает сеанс, MSAS может отклонить начало сеанса, если количество SC, общающихся с MSAS, превысило некоторый предел, наложенный MSAS. MSAS также может отклонить начало сеанса, если функция синхронизации временной шкалы в настоящее время не доступна.
Элементарная функция MSAS ТВ-устройства должна содержать оконечный узел службы TLS. Данная функция реализуется серверной частью протокола WebSocket версии 13. Оконечным узлом службы, предоставляемым функцией MSAS, в сообщении CII является WebSocket URL сервера WebSocket.
CSA получает уведомления о переключающем событии из ТВ-устройства для того, чтобы обеспечить CSA обнаружением событий в медиаданных, демонстрируемых ТВ-устройством в настоящее время. Уведомление о переключающем событии и опциональные данные, которые оно несет, позволяют CSA реагировать на это событие соответствующим образом.
В зависимости от количества сеансов, не превышающего ограничений, которые ТВ-устройство может налагать, ТВ-устройство должно обеспечить нескольким CSA возможность иметь одновременно несколько открытых сеансов с оконечным узлом службы TE, а для каждого CSA несколько одновременно открытых сеансов с оконечными узлами TE. В зависимости от количества подписок на события, не превышающего ограничений, которые ТВ-устройство может налагать, ТВ-устройство должно обеспечить несколько одновременных подписок на события в каждом сеансе.
ТВ-устройство может отклонить начало сеанса, если функциональность переключающего события в настоящее время не доступна.
ТВ-устройство, которое предоставляет оконечный узел службы TE, должно реализовывать серверную часть протокола WebSocket версии 13. Оконечным узлом службы TE, предоставляемым ТВ-устройством, является WebSocket URL.
В данном разделе определены два процесса передачи временной шкалы в заголовке адаптации пакетов транспортного потока:
- процесс, при котором временные шкалы несут байты данных частного характера в полях адаптации транспортного потока (TSAP) (см. 9.2);
- процесс, опубликованный MPEG в апреле 2014 года в качестве информационной технологии (см. 9.3).
9.2.1 Общие положения
Поле tsap_timeline является кодировкой полей данных в байтах данных частного характера поля адаптации пакета транспортного потока. Оно передает данные временной шкалы, описывающие поток временной шкалы для аудио- или видеослужб.
В данном разделе определены поле tsap_timeline, его селектор временной шкалы и требования, которым ТВ-устройство должно отвечать, если оно поддерживает его использование, чтобы передавать временную шкалу.
9.2.2 Селектор временной шкалы для временной шкалы TSAP
Формат селектора временной шкалы для поля tsap_timeline должен соответствовать следующему шаблону:
tsap-timeline-selector = "urn:dvb:css:timeline:tsap:" component-tag ":" timeline-id
9.2.3 Соотношение с PTS
Информация временной шкалы кодируется с использованием tsap_timeline в соответствии с моментом презентации медиаданных, указанным PTS, расположенной в первом заголовке PES, который начинается в полезной нагрузке, передаваемой в текущем или последующем пакете транспортного потока с таким же PID. В заголовке PES должно содержаться значение PTS.
9.2.4 Синтаксис
Синтаксис поля tsap_timeline должен соответствовать таблице 4.
Таблица 4
9.2.5 Интерпретация данных временной шкалы
ТВ-устройство должно декодировать данные временной шкалы с timeline_type, равным 1.
Значение такта временной шкалы и скорость тактов должны быть определены из последних полученных данных временной шкалы, согласно которой timeline_id соответствует значению, указанному в timelineSelector, и которая переносится в байтах данных частного характера поля адаптации adaptation_field для пакетов TS, определенных тегом компонент, указанным в timelineSelector.
Поле UnitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.
9.3.1 Общие положения
Дескрипторы полей адаптации для синхронизированной внешней медиа-информации (TEMI) определяют процесс для передачи временной шкалы в поле адаптации пакета транспортного потока, который в свою очередь содержит поток PES с PTS, объявленной в заголовке PES. Данный пункт определяет селектор временной шкалы и требования, которым ТВ-устройство должно соответствовать, если оно поддерживает использование временной шкалы TEMI.
9.3.2 Селектор временной шкалы для временной шкалы MPEG TEMI
Формат селектора временной шкалы MPEG TEMI должен соответствовать следующему шаблону:
temi-timeline-selector = "urn:dvb:css:timeline:temi:" component-tag ":" timeline-id
9.3.3 Интерпретация дескриптора temi_timeline_descriptor
Если поле has_timestamp дескриптора temi_timeline_descriptor равно 1 или 2, то величина такта временной шкалы берется из поля media_timestamp, а тактовая скорость определяется из поля timescale.
Поле unitsPerTick временной шкалы должно быть равно 1, поле unitsPerSecond временной шкалы должно быть равно значению поля tick_rate.
Если поле has_timestamp не равно 1 или 2, то тактовая скорость временной шкалы и значение такта не определены.
ТВ-устройство может игнорировать значение полей has_ntp, has_ptp и has_timecode.
Если поле paused равно 1, то тактовая скорость не изменяется, но ТВ-устройство должно рассчитывать метки времени, как будто презентация приостановлена.
ТВ-устройство и CSA, задействованные в синхронизированном воспроизведении, обычно используют интерфейс WC совместно с интерфейсами CII, TLS или TE. При определенных обстоятельствах они могут также использовать все четыре интерфейса параллельно. В таблице 5 приведена комбинация активных состояний соединений сети CSS.
Таблица 5
11.1.1 Введение
Протокол Universal Plug and Play (UPnPTM) является принятым протоколом для поиска и идентификации UPnPTM устройств в сети. UPnPTM используется для передачи информации, чтобы позволить CSA обнаружить и ассоциироваться с ТВ-устройством, как показано на рисунке 2, и таким образом установить связь.
![]() 11.1.2 Архитектура UPnPTM устройства
UPnPTM реализует модель клиент - сервер. В терминологии UPnPTM клиенты называются контрольными точками, а серверы - UPnPTM устройствами. Функциональность UPnPTM устройств и контрольных точек абстрагируется от транспортного механизма. Функциональность приводится в протоколах управления устройствами (DCP), которые определяют набор действий (RPC методы) и событий. Транспортный механизм описан в архитектуре UPnPTM устройства (UDA). Компоненты, которые составляют UDA, показаны на рисунке 3. UDA описывает:
- как контрольные точки могут обнаружить UPnPTM устройства в сети без предварительного знания IP-адреса устройства с помощью простого протокола обнаружения устройства (SSDP), который реализуется через UDP;
- какие возможности обнаруженных UPnPTM устройств реализованы посредством загрузки документа описания XML-устройства и документа описания XML-протокола управления службами с помощью HTTP;
- как контрольные точки взаимодействуют с открытой функциональностью, вызывая действия с использованием запросов SOAP через HTTP;
- как контрольные точки получают события, используя GENA через TCP.
В DCP описаны специфические функции каждого домена. DCP определяются как службы UPnPTM в UPnPTM устройстве.
11.1.3 Управление приложением UPnPTM
Служба DCP управления приложением UPnPTM используется для установления связи между CSA и ТВ-устройством. ТВ-устройство включает UPnPTM устройство, которое в свою очередь включает службу управления приложением, CSA реализует контрольную точку управления приложением. Этот процесс показан на рисунке 4.
![]() приложением во вспомогательном устройстве и службы
управления приложением UPnPTM в ТВ-устройстве
11.1.4 Отображение интерфейса CSS-CII при управлении приложением
CSA действует как контрольная точка управления приложением. Это позволяет CSA обнаружить ТВ-устройство, которое включает UPnPTM устройство, реализующее службу управления приложением DCP. Этот процесс показан на рисунке 5.
![]() приложением UPnPTM и связи приложения CII
11.1.5 Поведение CSA
Определение WebSocket адреса CII от CSA к ТВ-устройству достигается за счет последовательности команд, приведенных на рисунке 6:
1) обнаружение ТВ-устройства в домашней сети путем выдачи M-Search;
2) выбор ТВ-устройства с помощью фильтрации ответов M-Search;
3) загрузка DDD выбранного ТВ-устройства;
4) выполнение действий для:
а) определения существования или отсутствия приложения с matchingProtocolName путем вызова действия GetAppIDList ();
б) получения информации о приложении, которое содержит адрес WebSocket и runningState, путем вызова действия GetAppInfoByIDs();
5) установление WebSocket соединения CSS-CII.
![]() и ТВ-устройством для установления WebSocket соединения CII
ТВ-устройство должно реализовать UPnPTM устройство, которое в свою очередь реализует службу управления приложениями DCP.
Реализованное UPnPTM устройство должно соответствовать архитектуре UPnPTM устройств или последней версии UDA.
Интерфейс CII должен быть представлен в качестве приложения в службе управления приложением.
Приложение должно предоставлять элемент <apptoAppInfo> в XML-документе описания приложения, где:
- matchingProtocolName должен быть определен как "CSS-CII.TVDevice.CSS.DVB.org_v1";
- протокол должен быть определен как "WebSocket";
- значение атрибута требования протокола должно быть определено как "1";
- connectionAddress должен быть действительным адресом WebSocket;
- connectionAddress должен указывать на оконечный узел WebSocket и должен передавать протокол CII.
Приложение всегда должно иметь значение runningState, равное "Running".
Приложение не должно быть остановлено, когда вызывается действие StopApp(). Эта функция должна возвращать код ошибки 710.
XML-документ, описывающий применение в качестве результата вызова действия GetAppInfoByIDs(), должен всегда включать свойства:
- runningStatus;
- apptoAppInfo.
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/30/gost_40835.html
На правах рекламы:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||