ГОСТ Р 54994—2012
Опционально версия сегмента может быть определена в запросе, что позволит серверу опреде-
лить текущую версию сегмента, которую имеет HNED.
Детализированная процедура обмена сообщениями между HNED и сервером по запросу HNED
открытия службы service_discovery_request должна быть в соответствии с ETSI [12] (5.4.2.2).
5.4.5 Сигнализация об изменениях в предложении провайдера или в информации для поиска
провайдера должна выполняться постепенным увеличением номера версии информации для поиска
провайдера. Информация для поиска службы, описывающая предложение провайдера, разделена на
сегменты по типам службы. Изменение в предложении влечет за собой изменение в связанном сегмен-
те. Любые изменения в данных, которые переносятся в сегменте, должны сигнализироваться увеличе-
нием номера версии сегмента. HNED должно постоянно контролировать записи открытия провайдера
для того, чтобы обнаружить любое изменение в номерах версий. После обнаружения новой версии за-
писи открытия провайдера HNED должно проверить необходимость обновления описания провайдера
и проверить наличие любых изменений в предложении службы.
HNED должно определить измененные части предложения службы проверкой номера версии сег-
мента каждого сегмента, который HNED хочет контролировать. В режиме «pull» запись открытия SP
должна проверяться не менее двух раз на интервале максимального времени цикла.
В случае, когда список сегментов дан в записи открытия провайдера (обязательный в режиме
«pull» и опциональный в режиме «push»), HNED должно обнаруживать дополнение или удаление сег-
ментов с учетом перечня ID, допустимых для провайдера сегментов.
В режиме «pull» в случае, когда перечень сегментов в записи открытия SP и изменениях инфор-
мации для поиска SP отсутствует (при отсутствии изменений в предложении), HNED должно проверить
номер версии всех ID сегмента, присоединяясь к соответствующему многоадресному адресу.
В режиме «pull», в случае отсутствия перечня сегментов в записи открытия SP, сегмент должен
считаться удаленным, если пакет не был получен для этого сегмента дважды в течение минимального
периода на интервале максимального времени цикла.
5.5 Кодирование
5.5.1 Допускается кодирование сегментов SD&S в формате BiM согласно ISO/IEC [20]. Однако
сетевой провайдер должен обеспечивать доступность для HNED, не имеющих реализации BiM, полу-
чение незакодированных сегментов SD&S в режиме «pull» или «push» или обоих режимах.
5.5.2 Требования к параметрам формата BiM при кодировании сегментов SD&S и к параметрам
кодека BiM должны быть в соответствии с ETSI [12] (5.5.2).
6 Протокол RTSP
6.1 Использование протокола RTSP для служб DVB
21
6.1.1 В этом подразделе определяются возможности использования для HNED потокового прото-
кола реального времени (RTSP) при воспроизведении служб DVB. Возможности использования HNED
для записи служб DVB не нормируются.
RTSP является протоколом уровня приложения для управления доставкой данных в реальном
времени. Предусматривается использование протокола RTSP для двух случаев:
- для служб «вещания медиа»;
- для служб «видео по требованию».
6.1.2 В соответствии с разделом 5 настоящего стандарта доступ HNED к необходимой информа-
ции запрашиваемой службы обеспечивается средствами протокола RTSP. В зависимости от количества
потоков, образующих службу, в записях SD&S могут использоваться множественные URL RTSP в сле-
дующих случаях:
- если URL управления присутствует для потоков FEC, то агрегатный URL /BroadcastDiscovery/
ServiceList/SingleService/ServiceLocation/RTSPURL применяется для всей службы за исключением по-
тока повторной передачи. В тех случаях, когда служба образована единственным потоком, этот URLис-
пользуется для всех сообщений RTSP: SETUP (запрос установки транспортного механизма для медиа-
контента), PLAY (запрос начала вещания контента), TEARDOWN (остановка потока и освобождение
ресурсов). В любом случае, при необходимости извлечения описания, этот URLдолжен использоваться
для передачи сообщения DESCRIBE (запрос описания контента);