ФОРМАТ ПОЛЕЗНЫХ ДАННЫХ ТРАНСПОРТНОГО ПРОТОКОЛА РЕАЛЬНОГО ВРЕМЕНИ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

Приводимое ниже описание предполагает, что читатель знаком со стандартом, содержащимся в запросе на комментарий (RFC) 1889 целевой группы по инженерному обеспечению Интернета (IETF): "RTP: Транспортный протокол для прикладных систем реального времени" (далее именуемым как стандарт RFC 1889 IETF), и со стандартом, содержащимся в запросе на комментарий (RFC) 1890 целевой группы по инженерному обеспечению Интернета: "Параметры протокола RTP для использования в аудио- и видеоконференциях с минимальным управлением" (далее именуемым как стандарт RFC 1890 IETF).

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

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

Типичное применение протокола RTP относится к потоковым данным, где пакеты аудиовизуальных (AB) данных в формате перспективных (усовершенствованных) систем (ASF) посылаются в пакетах, созданных по протоколу RTP (RTP-пакетах), по сети от сервера к клиенту или от одного однорангового устройства к другому одноранговому устройству. Аудио- и видеоданные, представленные в формате ASF, могут хранится вместе в одном пакете формата ASF (ASF-пакете). В силу этого, RTP-пакет может содержать как аудиоданные, так и видеоданные.

Протоколу RTP согласно тому, как он определен в стандарте RFC 1889, недостает гибкости в том, что касается объединения многих модулей полезных данных в единый RTP-пакет и разделения некоего модуля полезных данных между многими RTP-пакетами. Также стандарт RFC 1889 не определяет формат, в котором вместе с каждым модулем полезных данных в RTP-пакете могут доставляться метаданные. Другим недостатком стандарта RFC 1889 является отсутствие механизма потоковой передачи зашифрованных блоков данных по сети при сохранении границы блока каждого зашифрованного блока, таком, чтобы получатель этих блоков мог бы расшифровать зашифрованные блоки данных. Обеспечение такого рода гибкости путем усовершенствования механизма потоковой передачи данных по протоколу RTP явилось бы шагом вперед в развитии данной области техники. Следовательно, существует потребность в усовершенствованных способах, машиночитаемом носителе информации, структурах данных, устройствах и вычислительных устройствах, которые могут обеспечить такого рода гибкость.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

В одном варианте осуществления изобретения пакеты аудиовизуальных (AB) данных в формате перспективных систем (ASF) повторно пакетируются в пакеты транспортного протокола реального времени (RTP-пакеты) и в ответ на запрос о потоковой передаче AB-данных посылаются по сети от сервера к клиенту или посредством сетевых коммуникаций от одного однорангового устройства другому одноранговому устройству. AB-данные шифруются для формирования секций шифрования. Процесс повторного пакетирования включает в себя пакетирование секций шифрования в RTP-пакеты, каждый из которых содержит заголовок RTP-пакета, один или несколько модулей полезных данных общего потока данных и заголовок формата полезных данных, пересылаемых по протоколу RTP (далее заголовок формата полезных данных RTP или заголовок ФПД RTP), для каждого модуля полезных данных. Заголовок ФПД RTP содержит границу модуля полезных данных для соответствующих секций шифрования. Модулем полезных данных в RTP-пакете может быть одна или несколько секций шифрования или фрагмент секции шифрования. После того как RTP-пакеты пересланы по сети, секции шифрования, содержащиеся в принятых RTP-пакетах, пересобираются. Процесс пересборки использует модули полезных данных, содержащиеся в RTP-пакетах, и соответствующую границу, содержащуюся в соответствующем заголовке ФПД RTP. Пересобранные секции шифрования могут быть расшифрованы с целью последующего воспроизведения. Каждый заголовок ФПД RTP может иметь в своем составе атрибуты для соответствующего ему модуля полезных данных, и эти атрибуты могут быть использованы при воспроизведении полезных данных.

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

В еще одном варианте осуществления изобретения предусматривается формат проводной связи для потоковой передачи по сети в составе RTP-пакетов зашифрованных блоков данных, защищенных с помощью протокола управления цифровыми правами в средах Windows® (WM DRM) (например, для потоковой передачи защищенного с помощью WM DRM контента). Каждый RTP-пакет содержит входящие в заголовок данные, предназначенные для сохранения границ блоков шифрования, так чтобы каждая секция шифрования могла быть дешифрована ее получателем. После дешифрования с использованием протокола WM DRM потоковые данные могут быть воспроизведены их получателем.

ПЕРЕЧЕНЬ ФИГУР

Фиг.1 - пример иллюстративного процесса, соответствующего варианту осуществления данного изобретения, для преобразования двух (2) пакетов аудиовизуальных (AB) данных, представленных в формате перспективных систем (ASF), в четыре (4) RTP-пакета, причем аудиоданные и видеоданные пакетируются в результирующие RTP-пакеты отдельно друг от друга, а границы блоков каждого модуля полезных данных сохраняются таким образом, что исходные выборки (выбранные для пересылки порции) AB-информации, которые были зашифрованы и пакетированы в два ASF-пакета, могут быть воссозданы при помощи алгоритма дешифрования.

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

Фигуры 3a-3b - соответственные модули полезных данных структур данных, соответствующих варианту осуществления настоящего изобретения, для заголовка RTP-пакета и соответствующего заголовка модуля полезных данных.

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

Формат проводной связи в своих различных вариантах осуществления расширяет возможности стандарта RFC 1889 IETF, обеспечивая доставке данных по протоколу RTP более высокую степень гибкости. Варианты осуществления изобретения предоставляют механизм для потоковой передачи находящихся в RTP-пакетах аудиоданных, которые отделены от находящихся RTP-пакетах видеоданных. Варианты осуществления изобретения также предоставляют формат проводной связи, в котором вместе с каждым модулем полезных данных в RTP-пакетах могут быть доставлены метаданные, причем метаданные поставляют обширную информацию, описывающую модуль полезных данных. Другие же варианты осуществления изобретения предоставляют механизм для потоковой передачи по сети зашифрованных блоков данных при сохранении границы блока для каждого зашифрованного блока в таком виде, что получатель блоков способен дешифровать зашифрованные блоки данных. В другом варианте осуществления изобретения формат проводной связи обеспечивает доставку данных, защищенных при помощи протокола управления цифровыми правами в средах Windows® (WM DRM), в таком виде, что доставленные данные могут быть расшифрованы для их воспроизведения.

Различные варианты осуществления изобретения, раскрываемые в данном документе, обеспечивают повторную упаковку данных в последовательность мультимедийных пакетов, которые включаются в поток битов системного уровня. Эти данные пакетируются в RTP-пакеты, совместимые со стандартом RFC 1889, хотя и расширяющие его возможности, поэтому поток битов системного уровня преобразуется (имеет поразрядную карту RTP) в RTP. В преобразованных к такой форме данных каждый мультимедийный пакет содержит в себе один или несколько модулей полезных данных. В некоторых потоках битов системного уровня могут находиться пакеты разнородных мультимедийных данных, имеющие в своем составе такие данные, как аудиоданные, видеоданные, программные данные, данные в формате объединенной группы экспертов по фотографии (JPEG), данные языка разметки гипертекста (HTML), данные цифрового интерфейса музыкальных инструментов (MIDI) и т.д. Пакет разнородных мультимедийных данных представляет собой мультимедийный пакет, в котором два или более из его модулей полезных данных принадлежат к различным мультимедийным потокам.

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

Фиг.1-2 изображают иллюстративные варианты осуществления изобретения, в которых потоки битов системного уровня включают в себя последовательность пакетов в формате перспективных систем (ASF), каждый из которых имеет в своем составе данные. Эти данные пакетированы в RTP-пакеты, совместимые со стандартом RTP 1889, хотя и расширяющие его возможности. По существу, потоки битов системного уровня включают в себя последовательность мультимедийных пакетов, являющихся ASF-пакетами, а модуль полезных данных в каждом ASF-пакете является модулем полезных данных ASF. Хотя в иллюстративных целях используются ASF-пакеты, в других вариантах осуществления изобретения, раскрытых в данном документе, создание RTP-пакетов не ограничивается использованием данных в формате ASF, но, напротив, может использовать другие форматы, в которых хранятся данные, предназначенные для потоковой передачи. Эти другие форматы, также как и формат ASF, обобщенно описываются в данном документе как потоки битов системного уровня, которые включают в себя множество мультимедийных пакетов, каждый из которых имеет в своем составе данные, и при этом эти данные преобразуются к разрядной карте RTP в различных вариантах реализации.

На фиг.1 изображены потоковые аудиовизуальные (AB) данные 100 в формате ASF. Потоковые AB-данные 100 в формате ASF, которые включают в себя аудиоданные 102 и видеоданные 104, были пакетированы в ASF-пакет А 106 и ASF-пакет B 108. ASF-пакет A 106 включает в себя первый заголовок ASF-пакета, заголовок модуля полезных данных ASF, аудиоданные 102, второй заголовок ASF и фрагмент А видеоданных из состава видеоданных 104. ASF-пакет В 108 включает в себя заголовок ASF-пакета, заголовок модуля полезных данных ASF и фрагмент B видеоданных из состава видеоданных 104.

Потоковые AB-данные 100 в формате ASF, представленные в виде ASF-пакета А 106 и ASF-пакета B 108, в одном варианте осуществления изобретения могут быть пакетированы во множество RTP-пакетов. Как видно на Фиг. 1, эти пакеты включают в себя RTP-пакет А 110, пакеты с RTP-пакета 112 (1) и по RTP-пакет 112 (N) включительно и RTP-пакет D 116. Каждый RTP-пакет в соответствии со стандартом RFC 1889 имеет заголовок RTP-пакета, модуль полезных данных и заголовок формата полезных данных (ФПД) RTP. Заголовок ФПД RTP в том значении, в каком он используется в данном документе, представляет собой заголовок модуля полезных данных в RTP-пакете. В RTP-пакете содержится только один (1) тип мультимедийных данных. Иначе говоря, RTP-пакет не содержит модулей полезных данных с разнородными мультимедийными данными. В варианте осуществления изобретения, изображенном на Фиг.1, видеоданные A из ASF-пакета А 106 слишком велики для того, чтобы уместиться в одном RTP-пакете. В силу этого видеоданные A из ASF-пакета A-106 разделены между пакетами: от RTP-пакета 112(1) и по RTP-пакет 112 (N) включительно. Размер RTP-пакета может быть функцией физической характеристики используемой сети, по которой должны передаваться RTP-пакеты, или административной политики в отношении размера пакета, которую может установить администратор используемой сети, или оценки ширины полосы пропускания используемой сети.

В соответствии с процессом пакетирования в RTP-пакеты, изображенном на Фиг.1, аудиоданные 102 включаются в состав RTP-пакета А 110, а видеоданные B из ASF-пакета B 108 включаются в состав RTP пакета D 116. Каждый заголовок ФПД протокола RTP каждого RTP-пакета может содержать информацию, относящуюся к разделению аудио- и видеоданных в соответственно отдельные RTP-пакеты. Таким образом, данные потоковой выборки A/B-информации 124 могут быть воссозданы из аудиоданных, содержащихся в RTP-пакете A 110, видеоданных, начиная с фрагмента 1 видеоданных А и по фрагмент N видеоданных А включительно, содержащихся соответственно в RTP-пакетах со 112(1) и по 112(N) включительно, и видеоданных B, содержащихся в RTP-пакете D 116. Как только воссоздание данных потоковой выборки A/B-информации завершено, содержащиеся в ней данные выборки аудиоинформации 120 и данные выборки видеоинформации A+B 122 могут быть воспроизведены в потоковом контексте. С учетом вышесказанного Фиг.1 иллюстрирует формат проводной связи, в котором более мелкие RTP-пакеты создаются из более крупных ASF-пакетов, причем пакетирование помещает полезные данные различных потоков данных в отдельные пакеты, каждый из которых имеет свой собственный заголовок ФПД RTP. Фиг.1 также иллюстрирует вариант осуществления формата проводной связи, в котором границы блоков для каждого модуля полезных данных сохраняются таким образом, что исходные выборки аудио- и видеоинформации, которые были зашифрованы и пакетированы в ASF-пакеты, могут быть воссозданы при помощи алгоритма дешифрования, производящего операции над RTP-пакетами.

На Фиг.2 изображены потоковые AB-данные 200 в формате ASF. Потоковые AB-данные 200 в формате ASF, включающие в себя видеоданные 202, были пакетированы в ASF-пакет A 208 и в ASF-пакет B 210. ASF-пакет A 208 включает в себя заголовок ASF-пакета, заголовок модуля полезных данных ASF и видеоданные A 204. ASF-пакет B 210 включает в себя заголовок ASF-пакета, заголовок модуля полезных данных ASF и видеоданные B 206. Фиг.2 показывает два (2) альтернативных варианта пакетирования потоковых AB-данных 200, представленных в формате ASF, в RTP-пакеты, совместимые со стандартом RFC 1889, хотя и расширяющие его возможности.

В первом альтернативном варианте, следуя стрелке 250, видеоданные А 204 и видеоданные B 206 пакетируются в единый RTP-пакет альтернативы A 212, имеющий заголовок RTP-пакета. Каждому из модулей: модулю видеоданных А 204 и модулю видеоданных В 206, предшествует заголовок ФПД RTP. Пакет протокола RTP альтернативы А 212 согласно стандарту RFC 1889 имеет в своем составе заголовок RTP-пакета, многочисленные модули полезных данных и соответствующие заголовки ФПД RTP.

Во втором альтернативном варианте, также следуя стрелке 250, видеоданные А 204 и видеоданные В 206 из соответствующих ASF-пакетов пакетируются в RTP-пакет альтернативы В 214, имеющий заголовок RTP-пакета. Видеоданные А 204 и видеоданные В 206 собираются вместе в качестве непрерывного модуля полезных данных в RTP-пакете альтернативы В 214. Модулю полезных данных предшествует заголовок ФПД RTP. RTP-пакет альтернативы В 214 в соответствии со стандартом RFC 1889 имеет в своем составе заголовок RTP-пакета, модуль полезных данных и один заголовок ФПД RTP.

В соответствии с процессом пакетирования в пакеты RTP, изображенным на Фиг.2, видеоданные А и В (204, 206) включаются либо в состав RTP-пакета альтернативы А 212, либо в состав RTP-пакета альтернативы В 214. Каждый заголовок ФПД RTP может содержать в себе информацию, относящуюся к соответствующему модулю полезных данных. Каждый из альтернативных RTP-пакетов 212, 214 содержит достаточно данных для воссоздания ASF-пакета А 208 и ASF-пакета В 210 таким образом, чтобы получить в них видеоданные А и В (204, 206). Как только их воссоздание завершено, данные выборки видеоинформации 222 могут быть воспроизведены в потоковом контексте. С учетом вышесказанного Фиг. 2 иллюстрирует формат проводной связи протокола RTP, в котором более крупные RTP-пакеты создаются из малых ASF-пакетов и где границы блоков для каждого модуля полезных данных сохраняются таким образом, что данные исходных выборок видеоинформции, которые были зашифрованы и пакетированы в два ASF-пакета, могут быть воссозданы при помощи алгоритма дешифрования, производящего операции над RTP-пакетами.

Фиг.3а изображает модуль полезных данных структур данных для полей заголовка протокола RTP. Заголовок RTP пакета более полно описан в стандарте RFC 1889. Поле временной метки в заголовке RTP-пакета должно быть установлено на времени представления выборки, содержащейся в пакете протокола RTP. В одном варианте осуществления изобретения частота синхронизации равна 1 кГц, если средствами, независимыми от протокола RTP, не установлено другое значение.

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

Фиг.3b изображает один вариант осуществления заголовка формата полезных данных (ФПД) RTP или заголовка модуля полезных данных. Заголовок ФПД RTP имеет часть с фиксированной длиной размером в шестнадцать (16) битов, за которой следует часть с переменной длиной. Поля заголовка ФПД RTP, изображенные на Фиг.3b, включают в себя восьмибитовую строку, обозначенную как символьные поля "SGLRTDXZ", поле длины/смещения, поле относительной временной метки, поле времени сжатия (декомпрессии), поле длительности, поле длины расширения полезных данных (РПД) и соответствующее поле данных РПД, каждое из которых объясняется ниже.

Поле S имеет длину один (1) бит и устанавливается в единицу ("1"), если соответствующий модуль полезных данных (например, выборка, фрагмент выборки или комбинация выборок) является ключевой выборкой, то есть интракодированной выборкой или I-кадром. В противном случае он устанавливается в ноль. Бит S во всех заголовках ФПД RTP, предшествующих фрагментам одной и той же выборки, должен быть установлен в одно и то же значение.

Поле G имеет длину один (1) бит и используется для группировки подвыборок информации в соответствующем модуле полезных данных, который составляет единую выборку. Протокол управления цифровыми правами в средах Windows® (WM DRM) шифрует контент, отсчитываемый от границ "модуля полезных данных формата ASF". Для того чтобы сделать возможным правильное дешифрование этого контента, границы подвыборок могут быть сообщены клиенту, который должен получить этот модуль полезных данных. Например, секция шифрования может быть пакетирована таким образом, что окажется разбитой на множество секций передачи (например, размещенных в отдельных пакетах), которые должны будут передаваться. Прежде чем разрозненное множество секций передачи может быть дешифровано у клиента-получателя, они должны быть пересобраны в исходную зашифрованную форму. Как и в других методологиях и алгоритмах дешифрования, для того чтобы надлежащим образом воссоздать зашифрованные секции шифрования при подготовке к дешифрованию зашифрованного контента, клиент может воспользоваться границами. В качестве такой границы каждому "модулю полезных данных формата ASF" должен предшествовать рассматриваемый здесь заголовок ФПД RTP.

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

Поле L имеет длину один (1) бит и устанавливается в единицу ("1") в случае, если поле "Длина/Смещение" содержит длину. В противном случае оно устанавливается в ноль ("0") и поле "Длина/Смещение" содержит смещение. Бит L должен быть установлен в единицу ("1") во всех заголовках ФПД RTP, предшествующих полной (нефрагментированной) выборке в соответствующем модуле полезных данных, и должен быть установлен в ноль во всех заголовках ФПД RTP, которые предшествуют модулю полезных данных, содержащему фрагментированную выборку.

Поле R имеет длину один (1) бит и устанавливается в единицу ("1"), если заголовок ФПД RTP содержит относительную временную метку. В противном случае оно устанавливается в ноль. Бит R во всех заголовках, предшествующих фрагментам одной и той же выборки, должен быть установлен в одно и то же значение.

Поле T имеет длину один (1) бит и устанавливается в единицу ("1") в случае, если заголовок ФПД RTP содержит время декомпрессии. В противном случае оно устанавливается в ноль. Бит T во всех заголовках ФПД RTP, которые предшествуют модулю полезных данных, содержащему фрагмент одной и той же выборки, должен быть установлен в одно и то же значение.

Поле D имеет длину один (1) бит и устанавливается в единицу ("1") в случае, если заголовок ФПД RTP содержит продолжительность выборки. В противном случае оно устанавливается в ноль. Бит D во всех заголовках ФПД RTP, которые предшествуют модулю полезных данных, содержащему фрагмент одной и той же выборки, должен быть установлен в одно и то же значение.

Поле X имеет длину один (1) бит и предназначено для факультативного неспецифицированного использования. Передатчик RTP-пакета должен устанавливать этот бит в нуль, а приемник этого пакета может игнорировать этот бит.

Поле Z имеет длину один (1) бит и устанавливается в единицу ("1") в случае, если заголовок ФПД RTP содержит данные расширения полезных данных (РПД), которые могут быть метаданными, относящимися к соответствующему модулю полезных данных. В противном случае поле Z устанавливается в ноль. Бит поля Z мог бы быть нулем для всех заголовков ФПД RTP, чей бит М в нуле, но он должен быть установлен для всех заголовков ФПД RTP, чей бит М установлен в единицу ("1") в случае, если соответствующий модуль полезных данных имеет связанные с ним данные РПД.

Поле "Длина/Смещение" имеет длину двадцать четыре (24) бита и определяет величину длины или смещения отдельной выборки, которая была разбита на фрагменты, размещенные во многих RTP-пакетах. Бит L устанавливается в ноль, и поле "Длина/Смещение" содержит байтовое смещение первого байта этого фрагмента от начала соответствующего модуля полезных данных (например, выборки или ее фрагмента). Если в пакете протокола RTP содержится одна или несколько полных выборок, то бит L устанавливается в единицу ("1") в каждом заголовке ФПД RTP и поле "Длина/Смещение" выборки содержит длину этой выборки (включая длину заголовка ФПД RTP).

Поле "Относительная Временная Метка" имеет длину тридцать два (32) бита и присутствует только в том случае, если бит R установлен в единицу ("1"). Оно содержит относительную временную метку для соответствующей выборки относительно временной метки в соответствующем заголовке RTP-пакета. Используемая при этом временная шкала является той же, что и временная шкала, используемая для временной метки в заголовке RTP-пакета. Поле "Относительная Временная Метка" определено как число длиной в 32 бита, имеющее знак, что позволяет задавать отрицательные сдвиги относительно временной метки заголовка RTP-пакета. В случае когда поле "Относительная Временная Метка" отсутствует, может использоваться относительная временная метка по умолчанию, равная нулю.

Поле "Время Декомпрессии" имеет длину тридцать два (32) бита и присутствует только в том случае, если бит T установлен в единицу ("1"). Оно содержит время декомпрессии относительно временной метки, входящей в заголовок RTP-пакета. Используемая при этом временная шкала является той же, что и временная шкала, используемая для временной метки, входящей в заголовок RTP-пакета. Это поле определено как число длиной в 32 бита, имеющее знак, что позволяет задавать отрицательные сдвиги относительно временной метки, входящей в заголовок RTP-пакета.

Поле "Продолжительность" имеет длину тридцать два (32) бита и присутствует только в том случае, если бит D установлен в единицу ("1"). Оно содержит продолжительность соответствующей выборки. Используемая при этом временная шкала является той же, что и временная шкала, используемая для временной метки, входящей в заголовок RTP-пакета. Поле "Продолжительность" во всех заголовках ФПД RTP, предшествующих фрагментам одной и той же выборки, должно устанавливаться в одно и то же значение. В случае когда это поле отсутствует, значение продолжительности по умолчанию берется в явном или неявном виде из данных самой выборки. Если это практически неосуществимо, то значение по умолчанию принимается равным разнице между временной меткой этой выборки и временной меткой следующей выборки.

Поле "Длина Данных Расширения Полезных Данных (РПД)" имеет длину шестнадцать (16) битов и присутствует только в том случае, если бит Z установлен в единицу ("1"). Оно содержит количество байтов данных РПД, содержащихся после фиксированной части заголовка ФПД RTP. Данные РПД имеют переменную длину и содержат один или несколько атрибутов, описывающих соответствующий модуль полезных данных, которому они предшествуют. Поле длины данных РПД следует непосредственно после фиксированной части заголовка полезных данных и указывает количество байтов, которые содержат реальные данные РПД. Структура данных РПД передается между клиентом и сервером (или от одного однорангового устройства другому одноранговому устройству), например, посредством описания SDP. В одном варианте осуществления изобретения для информации, защищенной при помощи протокола WM DRM, могут иметься, по крайней мере, 4 байта данных формата DUE, представляющих идентификатор полезных данных протокола WM DRM, связанный с каждой выборкой.

Хотя на Фиг. 3a-3b для заголовка RTP-пакета и заголовка ФПД RTP приводятся разнообразные поля, расположенные в различном порядке, не все поля являются обязательными, и порядок их расположения может быть изменен. В некоторых вариантах осуществления изобретения обязательные поля и порядок их следования, по этой причине, могут быть совместимы с гибкими возможностями стандарта RFC 1889, одновременно расширяя эти возможности. Хотя для иллюстраций на Фиг. 3a-3b используются ASF-пакеты, в других вариантах осуществления, раскрытых в данном документе, создание RTP-пакетов, заголовков ФПД RTP и модулей полезных данных для них не ограничено использованием данных в формате ASF, но, напротив, допускает использование других форматов, в которых хранятся данные, подлежащие потоковой передаче.

Общая структура сети

На Фиг.4 показана система 400 сети типа клиент/сервер и сетевая среда по данному изобретению. Обычно система 460 включает в себя один или несколько (m) сетевых мультимедийных серверов 402 и одного или нескольких (k) клиентов 404 сети. Компьютеры осуществляют связь друг с другом по сети передачи данных, которая на Фиг.4 включает в себя проводную или беспроводную сеть 406. Сеть передачи данных могла бы также включать сеть Интернет или локальные сети и частные глобальные сети. Серверы 402 и клиенты 404 осуществляют связь друг с другом посредством любого протокола из большого разнообразия известных протоколов, таких как протокол управления передачей данных (TCP) или протокол передачи пользовательских дейтаграмм (UDP).

Мультимедийные серверы/клиенты 402/404 имеют доступ к потоковой мультимедийной информации в виде различных мультимедийных потоков данных. Эти мультимедийные потоки данных могут быть индивидуальными мультимедийными потоками данных (например, аудио, видео, графическими, имитационными и т.д.) или, в качестве альтернативы, составными мультимедийными потоками данных, включающими в себя многие такие индивидуальные потоки данных. Некоторые мультимедийные потоки данных могли бы храниться в виде файлов 408 в базе данных (например, файлов формата ASF) или в другой файловой запоминающей системе в то время, как другие мультимедийные потоки 410 данных могли бы поставляться на мультимедийный сервер 402 или клиенту 404 "вживую" от других компонентов, являющихся источниками данных, через выделенные каналы связи или через саму сеть Интернет.

Мультимедийные потоки данных, полученные от серверов 402 или от клиентов 404, воспроизводятся у клиента 404 в виде мультимедийного представления информации, которое может включать в себя мультимедийные потоки данных от одного или нескольких серверов/клиентов 402/404. Эти различные мультимедийные потоки данных могут включать в себя один или несколько одинаковых или различных типов потоков мультимедийных данных. Например, представление мультимедийной информации может включать в себя два потока видеоинформации, один поток аудиоинформации и один поток графических изображений. Пользовательский интерфейс (ПИ) у клиента 404 может предоставлять пользователям разнообразные средства управления, например, предоставлять пользователю возможность увеличивать либо уменьшать скорость, на которой воспроизводится представление мультимедийной информации.

Иллюстративная компьютерная среда

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

Как показано на Фиг.4, сетевая система по данному изобретению включает в себя сетевой сервер (сетевые серверы) и клиента 402, 404, от которых возможно поступление множества мультимедийных потоков данных. В некоторых случаях мультимедийные потоки данных действительно хранятся на сервере (серверах) и/или у клиента 402, 404. В других случаях сервер (серверы) и/или клиент (клиенты) 402, 404 могут получать мультимедийные потоки данных от других сетевых источников или устройств. Обычно клиенты 404 сети реагируют на вводимый пользователем запрос о предоставлении мультимедийного потока данных, соответствующего выбранному мультимедийному контенту. В ответ на запрос о предоставлении мультимедийного потока данных, соответствующего мультимедийному контенту, сервер (серверы) и/или клиенты 402, 404 направляют запрашиваемые мультимедийные потоки данных запрашивающему клиенту 404 сети в соответствии с форматом проводной связи протокола RTP. Клиент 404 дешифрует модули полезных данных, находящиеся в соответствующих пакетах протокола RTP, и воспроизводит полученные в результате расшифрованные потоки данных для получения запрошенного мультимедийного контента.

Фиг.5 иллюстрирует ввод и хранение потоковых A/В-данных на сервере 402 или у клиента 404 (например, в одноранговом устройстве). Фиг.5 также иллюстрирует связи между сервером и клиентом (402-404) или между одноранговыми устройствами (404-404) согласно различным вариантам осуществления изобретения. Говоря в общих чертах, сервер или клиент 402, 404 получает вводимую потоковую A/В-информацию от устройства 502 ввода. Сервер или клиент 402, 404 кодируют вводимую информацию, используя кодер, входящий в кодек. Кодирование может, но не обязательно должно, осуществляться на данных в формате ASF. Если используются данные в формате ASF, то кодирование осуществляется на ASF-пакетах, каждый из которых включает в себя заголовок ASF-пакета и заголовок модуля полезных данных ASF и модуль полезных данных, содержащий AB-информацию (аудио и/или видео). Кодирование может включать в себя шифрование, как, например, там, где используется протокол WM DRM. ASF-пакеты хранятся сервером/клиентом для обслуживания будущих запросов на них.

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

На Фиг.5 показан поток данных между и среди блоков 504-530. В блоке 504 устройство ввода 502 предоставляет серверу/клиенту 402/404 входные данные, которые включают в себя потоковые А/В-данные. В качестве примера потоковые A/В-данные могли бы быть поставлены серверу/клиенту 402/404 устройством ввода 502 "вживую" через выделенные каналы связи или через сеть Интернет. Потоковая A/В информация в блоке 504 поступает в кодер для помещения данных в ASF-пакеты. В блоке 506 производится не являющееся обязательным шифрование по протоколу WM DRM, и ASF-пакеты сохраняются в памяти сервера/клиента 402/404. В результате шифрования по протоколу WM DRM и пакетирования может оказаться, что секция шифрования разбита на множество отдельных пакетов. Перед тем, как разбитое множество секций передачи может быть дешифровано у принимающего клиента, они должны быть пересобраны у этого клиента в исходные секции шифрования. В силу этого границы разбитых на части секций передачи сохраняются в блоке 506 в заголовках модулей полезных данных ASF.

В блоке 508 клиент 404 подает запрос о предоставлении потока A/В-данных, который передается серверу/клиенту так, как показывает стрелка 510 на Фиг.5. В блоке 512 сервер/клиент 402/404 получает этот запрос. Отыскиваются соответствующие ASF-пакеты, содержащие запрашиваемый поток A/В-данных. В блоке 514 модули полезных данных с аудио- и видеоинформацией, содержащиеся в ASF-пакетах, логически разделяются так, чтобы их можно было отдельно друг от друга пакетировать в RTP-пакеты. При этом определяются границы для каждого логически отдельного модуля полезных данных с аудиоинформацией и с видеоинформацией.

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

На этапе 516 каждый RTP-пакет укомплектовывается заголовком RTP-пакета, заголовком ФПД RTP и соответствующим модулем полезных данных. По сути, сформировано множество RTP-пакетов, которое представляет множество ASF-пакетов, причем ASF-пакеты содержат поток A/В-данных, запрошенный клиентом 404. RTP-пакеты передаются для воспроизведения у клиента 404 от сервера/клиента 402/404 посредством функции передачи, предусмотренной в блоке 518.

Стрелка 520 на Фиг.5 показывает передачу RTP-пакетов от сервера/клиента 402/404 клиенту 404. В блоке 522 клиент 404 принимает RTP-пакеты. В блоке 524 декодер протокола RTP, имеющийся у клиента 404, декодирует каждый принятый RTP-пакет, включая заголовок RTP-пакета и заголовок ФПД RTP. В блоке 526 процесс выполняет дефрагментацию и воссоздание ASF-пакетов, содержащих запрашиваемый поток A/В-данных. При дефрагментации и воссоздании пакетов используются границы, установленные в заголовке ФПД RTP для каждого соответствующего модуля полезных данных, содержащих, например, выборку или ее фрагмент.

В блоке 528 воссозданные ASF-пакеты дешифруются для воспроизведения в блоке 520. Заголовок ФПД RTP, входящий в RTP-пакет, может содержать данные расширения полезных данных (РПД), которые описывают соответствующий модуль полезных данных. Данные РПД могут, таким образом, предоставить метаданные, которые могут быть использованы при воспроизведении в блоке 530 модуля полезных данных, содержащихся в соответствующем RTP-пакете. Блоки 522-530 повторяются для каждого RTP-пакета, полученного у клиента 404, тем самым завершая потоковую передачу A/В-данных от сервера/клиента 402/404 для их воспроизведения.

На Фиг.6 показан общий пример компьютера 642, который может быть использован по данному изобретению. Компьютер 642 показан в качестве примера компьютера, способного выполнять функции любого из клиентов 402 или серверов 404, представленных на Фиг. 4-5. Компьютер 642 включает в себя один или несколько процессоров или процессорных устройств 644, системную память 646 и системную шину 648, соединяющую различные компоненты системы, включая системную память 646, с процессорами 644.

Шина 648 представляет собой одну или несколько шин, относящихся к любому из нескольких типов структур шины, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, использующие любую из множества архитектур шин. Системная память включает в себя постоянное запоминающее устройство (ПЗУ, ROM) 650 и оперативное запоминающее устройство (ОЗУ, RAM) 652. Кэш 675 имеет уровни L1, L2 и L3 и может быть включен в состав ОЗУ 652. Базовая система ввода/вывода (BIOS) 654, содержащая базовые процедуры, способствующие передаче информации между элементами внутри компьютера 642, например, при запуске хранится в ПЗУ 650. Кроме того, компьютер 642 включает в себя накопитель 656 на жестких магнитных дисках, предназначенный для считывания с жесткого магнитного диска (не показан) и записи на него, дисковод 658 для магнитного диска, предназначенный для считывания со съемного магнитного диска 660 и записи на него, и дисковод 662 для оптического диска, предназначенный для считывания со съемного оптического диска 664, такого как компакт-диск (CD ROM) или другие оптические носители информации, или записи на него.

Любое из устройств: жесткий магнитный диск (не показан), дисковод 658 для магнитного диска, дисковод 662 для оптического диска, съемный оптический диск 664, может быть носителем информации, имеющим записанную на него информацию. Носитель информации имеет область данных для записи потоковых данных с использованием потоковых пакетов, каждый из которых включает в себя некоторую область пакета, содержащую один или несколько пакетов данных. В качестве примера каждый пакет данных кодируется и декодируется посредством кодека, содержащегося в прикладных программах 672, исполняемого в процессоре 644. По сути, кодер распределяет поток данных по областям пакетов данных, входящим в потоковые пакеты так, что распределенные потоковые данные при помощи алгоритмов кодирования записываются в эти области пакетов данных. В качестве альтернативы, кодирование и декодирование пакетов данных может осуществляться как функция операционной системы 670, исполняемой в процессоре 644.

Накопитель 656 на жестких дисках, дисковод 658 для магнитного диска и дисковод 662 для оптического диска подсоединены к системной шине 648 посредством интерфейса SCSI 666 или какого-либо другого пригодного для этого интерфейса. Дисководы и соответствующие им машиночитаемые носители информации обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных. Хотя описанная здесь иллюстративная среда использует жесткий магнитный диск, съемный магнитный диск 660 и съемный оптический диск 664, специалистам в данной области техники следует признать, что в этой иллюстративной операционной среде могут также быть использованы и другие типы машиночитаемых носителей информации, которые могут хранить данные, доступные для компьютера, такие как магнитные кассеты, карточки флэш-памяти, цифровые видеодиски, оперативные запоминающие устройства (ОЗУ), постоянные запоминающие устройства (ПЗУ) и подобные им типы носителей информации.

На жестком магнитном диске, магнитном диске 660, оптическом диске 664, в ПЗУ 650, ОЗУ 652 может храниться некоторое количество программных модулей, включая операционную систему 670, одну или несколько прикладных программ 672 (которые могут включать в себя кодек), другие программные модули 674 и данные программ 676. Пользователь может вводить команды и информацию в компьютер 642 посредством устройств ввода, таких как клавиатура 678 и координатно-указательное устройство 680. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер или подобные им устройства. Эти и другие устройства ввода соединены с процессором 644 посредством интерфейса 682, подсоединенного к системной шине. Также к системной шине 648 посредством интерфейса, такого как видеоадаптер, может быть подсоединен монитор 684 или другой тип устройства 686 отображения. В дополнение к монитору персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры.

Компьютер 642 функционирует в сетевой среде, используя логические соединения с одним или несколько удаленными компьютерами, такими как удаленный компьютер 688. Удаленный компьютер 688 может быть персональным компьютером, сервером, маршрутизатором, сетевым ПК, одноранговым устройством или другим узлом общей сети и обычно содержит многие или все элементы, описанные выше в отношении компьютера 642, хотя на Фиг.6 проиллюстрировано только запоминающее устройство 690. Логические соединения, изображенные на Фиг.6, включают в себя локальную сеть (LAN) 692 и глобальную сеть (WAN) 694. Такие сетевые среды часто используются в офисах, компьютерных сетях масштаба предприятия, интрасетях и сети Интернет. В описанном варианте осуществления изобретения удаленный компьютер 688 выполняет программу Web-браузера сети Интернет, такую как Web-браузер Internet Explorer®, выпускаемый и распространяемый компанией "Microsoft Corporation" Редмонд, Вашингтон.

При использовании в сетевой среде LAN компьютер 642 соединен с локальной сетью 692 посредством сетевого интерфейса или адаптера 696. При использовании в сетевой среде WAN компьютер 642 обычно содержит модем 698 или другие средства для установления связи через глобальную сеть 694, такую как Интернет. Модем 698, который может быть внутренним или внешним, подсоединен к системной шине 648 посредством интерфейса 668 последовательного порта. В сетевой среде программные модули, показанные в отношении персонального компьютера 642, или их части могут храниться в удаленном запоминающем устройстве. Следует иметь в виду, что показанные сетевые соединения приведены в качестве примера и могут использоваться и другие средства установления линии связи между компьютерами.

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

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

Заключение

Раскрытые в данном документе варианты осуществления изобретения определяют формат проводной связи, который может быть использован для доставки мультимедийных данных между сервером и клиентом и от одного однорангового устройства другому одноранговому устройству посредством протокола RTP. Для доставки данных с использованием протокола RTP формат проводной связи обеспечивает более высокую гибкость, чем принятый в настоящее время стандарт RFC 1889 IETF. Варианты реализации формата проводной связи обеспечивают потоковую передачу зашифрованных данных, предоставляют механизм доставки посредством протокола RTP метаданных, относящихся к каждой выборке информации, и обеспечивают потоковую передачу данных, защищенных при помощи протокола WM DRM.

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