НАСЛЕДОВАНИЕ ПАРАМЕТРОВ УНИФИЦИРОВАННОГО ИДЕНТИФИКАТОРА РЕСУРСА (URI) Российский патент 2016 года по МПК H04N21/2343 H04N21/236 

Область техники, к которой относится изобретение

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

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

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

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

Уровень техники

Для того чтобы получить доступ к мультимедийному содержанию, терминал клиента обычно имеет ресурс, связанный с универсальным адресом или URI. Такой адрес обеспечивает как доступ к содержанию, так и показание об ассоциированном протоколе для его употребления (в качестве примера, когда содержание представляет собой видеосодержание, термин "употребление" используется для обозначения "просмотра"). URI представляет собой строку знаков, идентифицирующую физический или абстрактный ресурс, и соответствующую синтаксису набора стандартов, выработанных Целевой группой инженерной поддержки интернет (IETF), и, в частности, их спецификации RFC 3986 (спецификация: Uniform resource identifier (URI): generic syntax). Такой универсальный адрес может, например, иметь следующую форму dvb://contentl, rtsp://content2, HTTP://content3, ftp://content4 и т.д.

Доступ к мультимедийному содержанию может быть прямым (инициируемым по одиночному запросу, используя одиночный URI), или опосредованным с URI, так, что URI затем предусматривает параметры, которые позволяют получить доступ к услуге через второй запрос. Обычная иллюстрация представляет собой услугу "видео по требованию": первый этап состоит в том, что терминал загружает документ, который описывает параметры для доступа к услуге (протокол описания сеанса (SDP)), используя протокол транспортирования гипертекста (HTTP), то есть протокол для передачи данных между клиентом - сервером, разработанный для сетей Интернет и, в частности, для веб-сетей; на втором этапе фактически начинается услуга, то есть терминал - клиент может принимать и отображать видеоизображение, используя информацию, предоставляемую в документе (в данном примере SDP). Следует отметить, что документ может представлять собой компьютерный файл или данные, установленные так, что он описывает содержание, доступ к которому можно получить по определенному адресу. Ниже, в зависимости от содержания, используется термин "файл описания" или "документ". Следует отметить, что этот тип доступа к услуге может потребовать присутствия сервера (в частности, для обмена данными из точки-в-точку или "одноадресной передачи данных"), или в нем может не потребоваться присутствие сервера (для многоадресной передачи данных из одной точки типа "широковещательной передачи" или "многоадресной" передачи). В частности, протокол HTTP представляет собой протокол типа из точки-в-точку (или "одноадресный"), и, в результате, это подразумевает присутствие сервера для обработки запроса клиента, называемого "клиентом HTTP".

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

Существуют несколько решений для того, чтобы способствовать распределению такого содержания при потоковой передаче, таких, как, например, собственные решения, например, Microsoft Smooth Streaming, Apple HLS, Adobe Http Dynamic Streaming, или также стандарт MPEG DASH, которые описаны ниже. В этих способах предложена передача одного или больше промежуточных файлов описания в клиент, и эти файлы также могут называться документами или манифестами, или действительно ресурсами, и они содержат адреса различных сегментов для разных качеств мультимедийного содержания.

В качестве примера MPEG DASH (для динамической адаптивной потоковой передачи через стандарт http - ISO/IEC, 2309-1:2012 (Е)) представляет собой стандарт, разработанный организацией по стандартам ISO/IEC, который предназначен для потоковой передачи мультимедийного содержания через Интернет; он позволяет, в частности, для периферийных устройств, подключенных к сети (TV, планшетные устройства и т.д.) употреблять мультимедийное содержание, используя протокол HTTP. Запрос HTTP из устройства клиента, соответствующий стандарту MPEG DASH и переданный в сервер, содержит универсальный адрес или URI, например, тип унифицированного указателя ресурса (URL), где URL представляет собой конкретный пример URI, который предоставляет доступ к мультимедийному содержанию через сеть Интернет. Таким образом, при использовании MPEG DASH, доступ к содержанию обычно происходит в два этапа:

1) Получают документ описания, обычно путем загрузки файла, содержащего, в частности, адреса мультимедийных сегментов мультимедийного содержания, известные как мультимедийное описание мультимедийного представления (MPD). Такая загрузка обычно происходит, используя HTTP URL, однако она также может происходить путем использования универсального адреса (URI), описывающий некоторый другой протокол (например, ftp://mydescriptionfile).

2) Получают сегменты мультимедийных данных, обычно путем загрузки, используя адреса содержания в документе описания. Такая загрузка обычно происходит через HTTP URL, однако, она также может происходить через универсальный адрес (URI), описывающий некоторый другой протокол (например, dvb://mycontentsegment).

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

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

Изобретение направлено на обеспечение решения, в котором отсутствуют недостатки предшествующего уровня техники.

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

- получают, по меньшей мере, один параметр, ассоциированный с универсальным адресом документа, описывающего содержание;

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

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

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

На фиг. 3 показана временная диаграмма варианта воплощения изобретения.

На фиг. 4 показан вариант воплощения изобретения.

Осуществление изобретения

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

В представленном ниже примере, как пояснялось выше, содержание потоковой передачи подразумевает использование стандарта MPEG DASH.

Терминал (1) начинает работу путем опроса платформы (3) услуги, для получения адреса (здесь URL, но в более общем случае, универсальный адрес типа URI) для документа (у) описания мультимедийного содержания; ниже этот документ представляет собой файл типа MPD (y.mpd).

Платформа (3) услуги отвечает, путем предоставления на терминал адреса файла MPD, в данном примере, он представляет собой URL HTTP://x.com/y.mpd, представляющий файл у типа mpd, который может быть загружен (или передан в режиме потоковой передачи) с сайта "x.com".

Платформа (3) услуги может добавлять определенное количество параметров к UPJ для использования клиентом. В соответствии со спецификацией IETF RFC 3986, которая описывает обобщенный синтаксис URI, эти параметры вводят, используя символ "?". Для получения дальнейшей информации об этом механизме вставки параметров в URI, специалист в данной области техники должен обратиться к RFC 3986. Например, в контексте содержания, предназначенного для распределения, ассоциированного с аутентификацией, платформа услуги может добавлять метку аутентификации к URI, и в этом примере метка представлена строкой "s=abd", которая представляет собой параметр аутентификации для клиента, для использования платформой предоставления содержания. В ответ на ее запрос для файла описания, клиент, таким образом, принимает URL, HTTP://x.com/y.mpd?s=abd, содержащий одновременно:

- универсальный адрес самого файла (HTTP://x.com/y.mpd); и

- параметр аутентификации (abd).

На основе такого URI документ (4) описания может быть загружен из сервера (8) содержания, при этом параметр abd обеспечивает для сервера возможность аутентификации клиента.

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

Файл MPD позволяет генерировать адреса мультимедийного содержания, называемые здесь "первыми" универсальными адресами, для отличия их от адресов, которые генерируют в контексте изобретения и которые называются здесь как "вторыми" универсальными адресами; первые адреса, в соответствии с предшествующим уровнем техники по стандарту MPEG/DASH могут быть также сгенерированы либо:

- непосредственно (URL сегмента будет установлен непосредственно в файле); или

- опосредованно, через обработку для построения URL мультимедийного сегмента.

Такая конструкция позволяет использовать механизм перед разрешением универсальных адресов (URI), описанных в упомянутом выше RFC 3986. Терминал клиента должен интерпретировать определенные поля и модифицировать их, соответственно, для построения первого универсального адреса (URL или URI) мультимедийного сегмента.

Такую разрешающую способность URI выполняют, используя элемент BaseURL, который может присутствовать на различных уровнях в иерархии MPD.

В этом примере URL построены с помощью двух полей "BaseURL" ("HTTP://x.com/" и "video/") "SegmentTemplate".

"SegmentTemplate", установленный стандартом MPEG/DASH, представляет собой обобщенный способ для построения промежуточных адресов URI на основе различных идентификаторов, и в данном примере:

- $Time$: должно быть заменено временем в начале мультимедийного сегмента. Это время предоставляется строкой "SegmentTemplate", которая устанавливает в данном примере смещение 180180 для каждого начала нового сегмента;

- $Number$: должно быть заменено номером порядка требуемого мультимедийного сегмента; и

- $Bandwidth$: должно быть заменено значением атрибута "полоса пропускания" целевого представления.

Таким образом, первые два URL, предоставляющие доступ к первым двум видеосегментам для качества (или скорости передачи данных) 500 килобит в секунду (кбит/с), в этом примере представляют собой следующие:

1. HTTP://x.com/video500000/0.mp4v; и

2. HTTP://x.com/video500000/180180.mp4v.

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

По этой причине в изобретении предложено автоматически генерировать адреса сегмента (URI), которые называются здесь универсальными вторыми адресам, для отличия их от первых универсальных адресов, и которые могут включать в себя определенное количество параметров, которые могут соотноситься, например, с терминалом клиента. В этом примере параметр безопасности, установленный как параметр URL файла MPD (s=abd), вводят или передают при генерировании второго адреса сегмента. В дополнение к первым адресам, которые могут быть сгенерированы, используя предшествующий уровень техники, эти вторые адреса, таким образом, включают в себя персонализированный параметр безопасности. Другими словами, адреса второго сегмента адаптированы для каждого терминала клиента, даже при том, что они будут сгенерированы из простого файла описания MPD.

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

На фиг. 2 показан принцип системы потоковой передачи данных в соответствии с изобретением.

Первые этапы запроса и приема универсального адреса файла описания (y.mpd) из платформы (3) услуги и запроса и приема самого файла описания из платформы (8) содержания являются идентичными описанным со ссылкой на фиг. 1.

Однако в течение следующего этапа изобретение обеспечивает вставку параметра, ассоциированного с адресом URL файла описания (здесь метки "s=abd", которые были ранее переданы платформой услуги, как параметр URL), вставляют с помощью устройства клиента в каждом запросе, требующем мультимедийный сегмент, используя способ, который более подробно описан со ссылкой на фиг. 3.

Таким образом, первые два URL для доступа к первым двум сегментам видеоданных с качеством 500 кбит/с в этом примере становятся:

1. HTTP://x.com/video500000/0.mp4v?s=abd; и

2. HTTP://x.com/video500000/180180.mp4v?s=abd.

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

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

- Кроме того, больше нет необходимости генерировать файл описания (y.mpd) для каждого клиента, поскольку каждый клиент может персонализировать доступ к различным сегментам содержания путем пропуска параметров, которые клиент получил заранее в URL файла описания.

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

Он основан на обмене и использовании файла y.MPD, в том виде, как он будет модифицирован ниже (поля, представленные курсивом, представляют собой новые поля, в соответствии с изобретением).

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

Новое поле URLParameterTemplate используется для передачи параметров в адреса мультимедийного сегмента (URL, URI), которые должны быть сгенерированы. Поле URLParameterTemplate устанавливает, в частности, какие поля файла требуется повторно использовать в каждом мультимедийном сегменте. В этом примере только поле "метки" должно повторно использоваться, однако, естественно, возможно предусмотреть повторное использование большего количества параметров. Можно считать, что это поле является необязательным, причем его наличие или отсутствие тестируется с помощью модуля анализа файла XML, представленного в терминале клиента. Если оно отсутствует, параметр по умолчанию может аналогично быть ассоциирован с ним.

Во время этапа Е1, терминал 1 запрашивает описание файла y.mpd, и этот файл передают в него из сервера (8) содержания во время этапа Е10.

Во время этапа Е2 он генерирует первый универсальный адрес (HTTP://x.com/video/0.mp4v) сегмента содержания.

Во время этапа Е3 он генерирует второй универсальный адрес сегмента содержания (HTTP://x.com/video/0.mp4v?s=abd), путем вставки параметра аутентификации "s=abd", который был передан в него, как параметр адреса файла описания, во втором адресе сегмента, в соответствии с правилом (URLParameterTemplate), считанным в файле описания.

Во время этапа Е4 используется этот второй универсальный адрес, для запроса сегмента, который передает в него сервер содержания во время этапа Е12, после того, как сервер проверит параметры аутентификации (s=abd). Затем он может употребить содержание во время дополнительного этапа Е5.

Этап Е6 проверки обеспечивает для него возможность повторения этапов Е3-Е5 для другого сегмента содержания, если только остаются сегменты содержания, для обработки.

В этом первом примере параметры, которые должны быть переданы для генерирования второго универсального адреса сегмента, упомянуты в явном виде в правиле; пример синтаксиса представлен в файле для передачи параметра "сигнатура":

<URLParameterTemplate parameters="?$signature$"/>

В варианте параметры, которые должны быть переданы для генерирования второго универсального адреса, упомянуты по их порядку, например, используя следующий синтаксис, который означает, что первый параметр, который должен быть передан, имеет номер 2, после чего следует номер 1 и затем номер 3:

<URLParameterTemplate="2 1 3">

В другом варианте, описанном со ссылкой на фиг.4, контекст больше не представляет собой содержание распределения при потоковой передаче данных через http, но он представляет собой содержание потоковой передачи данных через протокол реального времени (RTP) с проверкой, с использованием протокола потоковой передачи в режиме реального времени (RTSP). В услуге "видео по требованию" (VOD), которая проверяет RTSP, установление видеосеанса по требованию передают через первый этап информации загрузки, обеспечивающий начало сеанса. Этот первый этап обычно основан на протоколе SDP (IETF RFC 4566), что позволяет, в частности, описать, какой протокол требуется использовать для сеанса VOD, характеристики содержания (скорость передачи данных, видео- и аудиосодержание) и т.д., как показано в таблице ниже. Эта информация может быть восстановлена через предварительную загрузку файла (называется файлом "sdp") и использоваться впоследствии для установки сеанса потоковой передачи данных между терминалом клиента и сервером:

Как показано на фиг. 4, изобретение может применяться непосредственно в этом контексте применения.

Предполагается, что терминал 1 получил файл описания SDP.

Параметры, используемые во время запроса загрузки файла SDP, затем используются для конструирования запроса, обеспечивающего установление сеанса. В частности, параметр "устройство = переносной компьютер" прикрепляют к универсальному адресу файла SDP и передают для восстановления аудиосегмента, использующего протокол rtsp. Запрос сегмента мультимедийных данных принимает следующую форму:

rtsp://movie.example.com/ost.wav&device=laptop

Таким образом, как и в примере Таблицы 2, является соответствующей вставка новых сигналов в этот файл sdp, что обеспечивает активацию изобретения.

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

Изобретение относится к области передачи мультимедийного содержания, используя универсальные адреса для содержания, например, унифицированный идентификатор ресурса (URI). Техническим результатом является генерирование одиночного описательного документа для содержания (манифест, файл описания и т.д.) для всех клиентов, при этом одновременное выполнение персонализации адреса ассоциированных сегментов содержания с параметрами, что упрощает адрес документа описания. Предложен способ доступа к содержанию (у), в котором по меньшей мере один сегмент данных (0.mp4v, 180180.mp4v), где доступ к этому сегменту данных выполняют через документ, описывающий содержание (y.mpd). Способ содержит первый этап (E1, E11) получения документа, описывающего содержание (y.mpd), из которого генерируют (Е2) документ по меньшей мере по первому универсальному адресу сегмента (HTTP://x.com/video/0.mp4v); второй этап получения по меньшей мере одного параметра (s=abd), ассоциированного с универсальным адресом (HTTP://x.com/video/y.mpd?s=abd) документа, описывающего содержание (y.mpd); этап считывания по меньшей мере одного правила генерирования адреса (URLParameterTemplate) в документе, описывающем содержание (y.mpd); и как функция правила генерирования адреса (URLParameterTemplate), первого универсального адреса сегмента (HTTP://x.com/video/0.mp4v), и параметра, который был получен (s=abd), последний этап (Е3) генерирования второго универсального адреса для сегмента (HTTP://x.com/y1.mp4v?s=abd). 4 н. и 2 з.п. ф-лы, 4 ил.

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

2. Способ генерирования документа описания (y.mpd) по п. 1, в котором правило генерирования универсального адреса описывает полученные параметры (сигнатуру), подлежащие учету, при генерировании второго универсального адреса для сегмента.

3. Способ генерирования документа описания (y.mpd) по п. 1, в котором правило генерирования адреса указывает порядок, в котором полученные параметры подлежат учету при генерировании второго универсального адреса, для сегмента.

4. Способ доступа к мультимедийному содержанию (у), содержащему по меньшей мере один сегмент данных, доступ к которому осуществляется посредством документа, описывающего содержание, причем указанный документ содержит первый универсальный адрес сегмента, при этом упомянутый доступ к сегменту осуществляют посредством второго универсального адреса сегмента, причем упомянутый способ доступа содержит этапы, на которых:
получают (E1, Е11) документ, описывающий содержание, и из указанного документа генерируют (Е2) по меньшей мере первый универсальный адрес сегмента;
получают по меньшей мере один параметр, ассоциированный с универсальным адресом документа, описывающего содержание;
считывают по меньшей мере одно правило генерирования адреса в документе, описывающем содержание; и
генерируют (Е3), в качестве функции правила генерирования адреса для универсального адреса сегмента и полученного параметра, второй универсальный адрес для сегмента.

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

6. Терминал, характеризующийся тем, что выполнен с возможностью доступа к мультимедийному содержанию (у), содержащему по меньшей мере один сегмент данных, подлежащему доступу посредством документа, описывающего содержание, причем указанный документ содержит первый универсальный адрес указанного сегмента, при этом упомянутый доступ выполняется посредством второго универсального адреса сегмента, причем терминал содержит:
модуль для получения документа, описывающего содержание, для которого из указанного документа сгенерирован по меньшей мере первый универсальный адрес сегмента;
модуль для получения по меньшей мере одного параметра, ассоциированного с универсальным адресом документа, описывающего содержание (y.mpd);
модуль для считывания по меньшей мере одного правила генерирования адреса в документе, описывающем содержание (y.mpd); и
модуль для генерирования второго универсального адреса для сегмента, в качестве функции правила генерирования адреса, первого универсального адреса сегмента и полученного параметра (s=abd).