Область техники
Настоящее изобретение относится к передаче аудиовизуальной информации и данных, и конкретно к внедрению сообщения описания сеанса в сообщение RTCP.
Предшествующий уровень техники
Потоковая передача содержимого (контента), такая как потоковая передача аудио, видео и/или текста, становится все более и более популярным. Термин "потоковая передача" обычно используется для указания того, что данные, представляющие контент, передаются по сети на клиентский компьютер на основании запроса "по требованию" вместо его предварительной доставки целиком перед воспроизведением. Таким образом, клиентский компьютер воспроизводит передаваемое потоковое содержимое, когда оно принимается от сетевого сервера, вместо ожидания полного "файла", который должен быть доставлен.
Широко распространенная доступность потоковой передачи мультимедийного содержимого допускает множество типов информационного содержимого, которое не было ранее доступно по Интернет или другим компьютерным сетям. «Живое» содержимое (передающееся непосредственно с места действия) является одним из важных примеров такого содержимого. Используя потоковую передачу мультимедийного содержимого, аудио, видео, или аудио/визуальный обзор примечательных событий могут быть переданы по Интернет, когда разворачиваются события. Точно так же телевизионные и радиостанции могут передавать контент непосредственно с места действия по Интернет.
Протокол описания сеанса (SDP), документ «запрос на комментарии рабочей группы по сетям» (RFC) 2327, является основанным на тексте форматом, используемым для описания свойств мультимедийных представлений, называемых "сеансами", и свойств одного или более потоков аудиовизуальной информации, содержащихся в представлении. SDP был разработан как протокол прикладного уровня, предназначенный для описания мультимедийных сеансов с целью объявления сеанса, приглашения сеанса и других форм инициирования мультимедийного сеанса. SDP может использоваться в соответствии с другими протоколами, такими как Протокол потоковой передачи информации в реальном масштабе времени (RTSP) или протокол передачи гипертекстовых файлов (HTTP), для описания и/или согласования свойств мультимедийного сеанса, используемого для доставки передаваемых в виде потока данных.
Однако во многих ситуациях трудно получить информацию SDP от сетевого сервера на клиентский компьютер. Например, сетевой сервер может осуществлять потоковую передачу ряда мультимедийных представлений на клиентский компьютер, например представлений, перечисленных в списке воспроизведения. Когда сетевой сервер переключается от передачи потока одного представления к следующему, информацию SDP для следующего представления часто трудно сделать доступным клиентскому компьютеру. Таким образом, было бы полезно иметь дополнительный механизм, которым информация SDP может быть сделана доступной клиентскому компьютеру.
Передаваемый потоком контент (содержимое) может также быть передан на многие адреса (осуществлено мультивещание). Обычные подходы к мультивещанию передаваемого в виде потока содержимого обычно включают в себя обеспечение контента, подлежащего мультивещанию, на сервер, который затем осуществляет мультивещание контента по сети (то есть без обратной связи от клиентов, принимающих потоки). Сервер обычно осуществляет мультивещание контента в нескольких потоках, имеющих различные форматы (например, скорости передачи в битах, языки, схемы кодирования и т.д.). Клиенты, подключенные к сети, могут затем принимать поток(и), соответствующий(ие) их ресурсам. Чтобы разрешить клиентам выбирать, какой(ие) поток(и) принимать, один из подходов мультивещания требует, чтобы сервер выдал файл, который обеспечивает "информацию мультивещания", которая позволяет клиентам открывать потоки содержимого. Поддержание и публикация этого файла является обычно ручным процессом, который имеет относительно высокую стоимость администрирования. Далее, если не имеется должной поддержки и опубликования, клиенты могут сталкиваться с проблемами, которые могут привести к неудовлетворенности заказчика (пользователя). Другая проблема, связанная с этим подходом, состоит в том, что клиенты должны сохранить свою "информацию мультивещания" обновленной так, чтобы они могли должным образом обращаться к содержимому. Эта проблема усугубляется для клиентов, которые не имеют подходящего обратного канала для запроса обновления (например, клиенты с однонаправленными спутниковыми линиями связи).
Сущность изобретения
Описано внедрение сообщения описания сеанса в сообщение протокола управления передачей в реальном масштабе времени (RTCP). Внедренным в по меньшей мере некоторые из сообщений RTCP, посланных от источника аудиовизуального содержимого получателю, является сообщением описания сеанса, которое описывает аудиовизуальное представление, которое передают в виде потока получателю.
В соответствии с некоторыми аспектами сообщение RTCP, которое внедряет сообщение описания сеанса, включает в себя по меньшей мере три поля. Первое поле содержит данные, идентифицирующие сообщение RTCP как являющееся сообщением того типа, который внедряет сообщение описания сеанса. Второе поле содержит данные, которые являются сообщением описания сеанса для аудиовизуального представления. Третье поле содержит данные, идентифицирующие длину сообщения RTCP, сгенерированной посредством суммирования длины первого поля, длины второго поля и длины третьего поля.
В соответствии с другими аспектами сообщение RTCP создают в устройстве, например серверном устройстве. Сообщение описания сеанса, внедренное в сообщение RTCP, связано с одной из множества частей аудиовизуального содержимого в списке воспроизведения аудиовизуального содержимого, которое передают в виде потока от этого устройства получателю.
В соответствии с другими аспектами мультимедийные представления являются мультивещанием, использующим канал объявления, который включает в себя информацию описания представления наряду с множеством каналов для множества потоков мультимедийных данных для согласования (удовлетворения требований) клиентов различных мультимедийных ресурсов. Клиенты могут использовать этот канал объявления для выбора канала(ов), соответствующего(их) их мультимедийным ресурсам.
В соответствии с другими аспектами каналы создают заранее определенным образом (например, заранее выбранные логические адреса, заранее выбранные порты IP-адреса и т.д.) так, чтобы клиенты могли немедленно соединиться с каналом без (или одновременно с) подсоединения(ем) к каналу объявления, чтобы уменьшить задержку запуска.
В соответствие с другими аспектами может быть создан канал ускорения, который обеспечивает блоки данных, содержащих текущий блок мультимедийного представления наряду с заранее выбранным числом предыдущих блоков со скоростью передачи в битах, которая является "более быстрой, чем в реальном масштабе времени" (то есть со скоростью передачи в битах, которая является больше, чем скорость передачи в битах мультимедийных потоков). Эта особенность позволяет клиентам с соответствующими ресурсами более быстро буферизовать достаточное количество данных, чтобы начать представление мультимедийных данных пользователям. Альтернативно, канал ускорения не должен быть "быстрее, чем реальное время", так чтобы клиент мог одновременно соединяться и с каналом ускорения и другим каналом, который осуществляет мультивещание мультимедийных данных так, что в действительности клиент принимает мультимедийные данные со скоростью передачи в битах, которая является "быстрее, чем в реальном масштабе времени".
Краткое описание чертежей
Одинаковые ссылочные позиции используются в документе для ссылки на аналогичные компоненты и/или признаки.
Фиг. 1 иллюстрирует примерную сетевую среду, которая может использоваться для потоковой передачи аудиовизуальной информации, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже.
Фиг. 2 иллюстрирует примерные клиентское и серверное устройства, которые могут осуществлять потоковую передачу аудиовизуального контента с использованием сообщения описания сеанса, внедренного в сообщение RTCP, как описано ниже.
Фиг. 3 иллюстрирует пример клиентского и серверного устройств в среде мультивещания, которая может передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже.
Фиг. 4 иллюстрирует пример клиентского и серверного устройств в среде со списком воспроизведения на стороне сервера, которые могут осуществлять потоковую передачу аудиовизуального контента с использованием сообщения описания сеанса, внедренного в сообщение RTCP, как описано ниже.
Фиг. 5 иллюстрирует пример формата сообщения RTCP, имеющего внедренное сообщение описания сеанса.
Фиг. 6 иллюстрирует примерный формат сообщения описания сеанса.
Фиг. 7 иллюстрирует последовательность операций примерного процесса для внедрения сообщений описания сеанса в сообщение RTCP при использовании списка воспроизведения.
Фиг. 8 иллюстрирует последовательность операций примерного процесса для приема сообщений описания сеанса в сообщении RTCP при использовании списка воспроизведения.
Фиг. 9 - блок-схема, иллюстрирующая систему для мультивещания мультимедийных представлений, согласно одному варианту осуществления.
Фиг. 10 иллюстрирует последовательность операций сервера в системе согласно фиг. 9, согласно одному варианту осуществления.
Фиг. 11 - диаграмма, иллюстрирующая примерные каналы согласно одному варианту осуществления.
Фиг. 12 последовательность операций, иллюстрирующая последовательность операций на клиенте в системе по фиг. 9, согласно одному варианту осуществления.
Фиг. 12A последовательность операций, иллюстрирующая последовательность операций на клиенте в системе по фиг. 9, согласно другому варианту осуществления.
Фиг. 13 - последовательность операций, иллюстрирующая сервер по фиг. 9, согласно одному варианту осуществления.
Фиг. 14 - последовательность операций, иллюстрирующая последовательность операций контроллера конфигурации из фиг. 13, согласно одному варианту осуществления.
Фиг. 15 - блок-схема, иллюстрирующая сервер из фиг. 9, согласно другому варианту осуществления.
Фиг. 16 - последовательность операций, иллюстрирующая последовательность операций сервера с генератором ускоренного потока из фиг. 15, согласно одному варианту осуществления.
Фиг. 17 - последовательность операций, иллюстрирующая последовательность операций на клиенте при приеме ускоренного потока, согласно одному варианту осуществления.
Фиг. 17A - последовательность операций, иллюстрирующая последовательность операций на клиенте при приеме ускоренного потока, согласно другому варианту осуществления.
Фиг. 18 - блок-схема, иллюстрирующая пример вычислительной среды, подходящей для осуществления вышеупомянутых вариантов осуществления.
Подробное описание предпочтительного варианта осуществления
Ниже описано внедрение сообщения описания сеанса в сообщение протокола управления в реальном масштабе времени (RTCP). Мультимедийное представление или представление одного из видов аудиовизуальной информации передаются в виде потока от источника аудиовизуального контента, такого как серверное устройство, получателю, такому как клиентское устройство, используя пакеты Протокола транспортировки в реальном масштабе времени (RTP). Управляющая информация, относящаяся к представлению, которое передают в виде потока, также передается от источника аудиовизуального контента получателю, используя сообщения RTCP. В по меньшей мере некоторые из сообщений RTCP внедрено сообщение описания сеанса, которое описывает представление, которое передают в виде потока.
В приведенном описании сделана ссылка на мультимедийные представления, которые передают в виде потока от источника аудиовизуального контента (содержимого) получателю. Источником аудиовизуального контента может быть любой источник аудиовизуального контента, примером которого является серверное устройство. Получателем может быть любой получатель аудиовизуального контента, примером которого является клиентское устройство. Дополнительно, должно быть понятно, что хотя описание может относиться к мультимедийным представлениям, которые передают в виде потока, представления одного вида аудиовизуальной информации можно также передавать в виде потока таким же образом, как описано здесь относительно мультимедийных представлений.
Фиг. 1 иллюстрирует пример сетевой среды 100, которая может использоваться для потоковой передачи аудиовизуальной информации, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В среде 100 множество (a) клиентских вычислительных устройств 102(1), 102(2), …, 102(a) подсоединены к множеству (b) серверных вычислительных устройств 104(1), 104(2), …, 104(b) через сеть 106. Сеть 106 предназначена для представления любой из ряда обычных сетевых топологий и типов (включая проводные и/или беспроводные сети), используя любой из ряда обычных сетевых протоколов (включая открытые и/или составляющие собственность протоколы). Сеть 106 может включать в себя, например Интернет, а также, возможно, по меньшей мере части одной или более локальных сетей (локальных вычислительных сетей).
Вычислительные устройства 102 и 104 каждое могут быть любым из ряда обычных вычислительных устройств, включая настольные ПК, рабочие станции, универсальные компьютеры, Интернет-устройства, игровые консоли, карманные ПК, сотовые телефоны, персональные цифровые помощники (PDA) и т.д. Одно или более устройств 102 и 104 может быть устройствами одного и того же типа или, альтернативно, устройствами различных типов.
Серверные устройства 104 могут сделать любые из множества данных доступными для потоковой передачи к клиентам 102. Термин "потоковая передача" используется для указания того, что данные, представляющие аудиовизуальную информацию, передаются по сети на клиентское устройство и что воспроизведение содержимого (контента) может начинаться до доставки содержимого в его полноте (например, передавая данные на основе "по требованию", вместо предварительной доставки данных в их полноте перед воспроизведением). Эти данные могут быть публично доступны или, альтернативно, ограничены (в доступе) (например, ограничены только для некоторых пользователей, доступными только если внесена соответствующая плата и т.д.). Данные могут быть любыми из множества одного или более типов содержимого, например аудио, видео, текст, анимация и т.д. Дополнительно, данные могут быть предварительно записаны или, альтернативно, "живыми" (например, цифровое представление записываемого концерта, когда концерт дается и делается доступным для потоковой передачи вскоре после сбора данных).
Клиентское устройство 102 может принимать передаваемую в виде потока аудиовизуальную информацию от сервера 104, который сохраняет этот передаваемый в виде потока аудиовизуальный контент в виде файла или, альтернативно, от сервера 104, который принимает эту передаваемую в виде потока аудиовизуальную информацию из некоторого другого источника. Например, сервер 104 может принимать передаваемую в виде потока аудиовизуальную информацию от другого сервера, который сохраняет этот передаваемый в виде потока аудиовизуальный контент как файл или может принимать передаваемую в виде потока аудиовизуальную информацию из некоторого другого источника (например, кодирующее устройство, которое кодирует "живое" событие).
Используемый термин "передаваемая в виде потока аудиовизуальная информация" относится к потоку одного или более видов аудиовизуальной информации от одного устройства до другого (например, от серверного устройства 104 на клиентское устройство 102). Аудиовизуальные потоки могут включать в себя любой из множества типов содержимого (контента), например одно или более из аудио, видео, текста и т.д.
Фиг. 2 иллюстрирует пример клиентского и серверного устройств, которые могут передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. Множество различных протоколов обычно соблюдается и в клиентском устройстве 102, и серверном устройстве 104, чтобы направить в виде потока аудиовизуальное содержимое от серверного устройства 104 на клиентское устройство 102. Эти различные протоколы могут быть ответственны за различные аспекты процесса передачи в виде потока. Хотя и не показано на фиг. 2, одно или более дополнительных устройств (например, брандмауэры, маршрутизаторы, шлюзы, мосты и т.д.) могут быть расположены между клиентским устройством 102 и серверным устройством 104.
В примере на фиг. 2 протокол 150 прикладного уровня (уровня приложений), транспортный протокол 152 и один или более протоколов 154 канала доставки используются как часть процесса передачи в виде потока. Дополнительные протоколы, не показанные на фиг. 2, также могут быть использованы (например, могут быть дополнительный(е) протокол(ы) между протоколом 150 прикладного уровня и транспортным протоколом 152). Протокол 150 прикладного уровня - это протокол на уровне приложений для управления доставкой данных со свойствами в реальном масштабе времени. Протокол 150 прикладного уровня обеспечивает структуру, опционально расширяемую для обеспечения управляемой доставки «по требованию» в реальном масштабе времени данных, таких как передаваемый в виде потока аудио- и видеоконтент. Протокол 150 прикладного уровня является протоколом управления для инициализизации и направления доставки передаваемой в виде потока мультимедийной информации от серверов аудиовизуальной информации. Примеры протокола 150 прикладного уровня включают в себя Протокол потоковой передачи в реальном масштабе времени (RTSP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2326, апрель 1998, и протокол передачи гипертекстовых файлов (HTTP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 1945, Май 1996, или в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2068, январь 1997.
Протокол 150 прикладного уровня использует транспортный протокол 152 для доставки в реальном масштабе времени данных, таких как потоковое аудио и видео. Транспортный протокол 152 определяет формат пакета для потоков аудиовизуальной информации. Транспортный протокол 152 обеспечивает сквозные сетевые транспортные функции, подходящие для приложений, передающих данные в реальном масштабе времени, такие как аудио, видео или данные моделирования, для многоадресных (мультивещания) или одноадресных сетевых услуг. Примеры транспортного протокола 152 включают в себя Протокол транспортировки в реальном масштабе времени (RTP) и Протокол управления передачей в реальном масштабе времени (RTCP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 3550, июль 2003. Также могут использоваться другие версии, типа будущих черновых или стандартизированных, версий RTP и RTCP. RTP не направлен на резервирование ресурсов и не гарантирует "качество обслуживания" для услуг в реальном масштабе времени. Транспортировка данных расширяется в соответствии с протоколом управления (RTCP), чтобы позволить контролировать доставку данных способом, масштабируемым к большим многоадресным сетям (сетям мультивещания), и обеспечить некоторое управление и функциональные возможности идентификации.
Протокол RTCP группирует одно или более сообщений управления вместе в блок, называемый пакетом RTCP. В один или более пакетов RTCP внедрено сообщение управления, которое включает в себя сообщение описания сеанса. Сообщение описания сеанса описывает свойства мультимедийного представления, которое передают в виде потока от серверного устройства 104 на клиентское устройство 102. Передаваемые в виде потока аудиовизуальные данные от серверного устройства 104 на клиентское устройство 102, таким образом, включают в себя сообщение описания сеанса.
Транспортный протокол 152 использует протокол(ы) 154 канала доставки для соединений транспортировки. Протокол(ы) 154 канала доставки включает(ют) в себя один или более каналов для транспортировки пакетов данных от серверного устройства 104 на клиентское устройство 102. Каждый канал обычно используется для посылки пакетов данных для потока одного типа аудиовизуальной информации, хотя в альтернативных вариантах осуществления может использоваться одиночный канал для посылки пакетов данных для потоков множества типов аудиовизуальной информации. Примеры протоколов 154 канала доставки включают в себя пакеты Протокола управления передачей (TCP) и пакеты Протокола пользовательских дейтаграмм (UDP). TCP гарантирует доставку пакетов данных, в то время как UDP не гарантирует доставку пакетов данных. Как правило, доставка пакетов данных, используя TCP, более надежна, но также и требует больше времени, чем доставка пакетов данных, используя UDP.
Фиг. 3 иллюстрирует пример клиентского и серверного устройств в среде мультивещания, которые могут передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В некоторых вариантах осуществления протоколы 150, 152 и 154 согласно фиг. 2 включены в клиентское и серверное устройства согласно фиг. 3, но не проиллюстрированы. Кроме того, хотя не показано на фиг. 3, одно или более дополнительных устройств (например, брандмауэры, маршрутизаторы, шлюзы, мосты и т.д.) могут быть расположены между клиентским устройством 102 и серверным устройством 104.
Модуль 182 потоковой передачи из серверного устройства 104 передает в виде потока одно и то же мультимедийное представление к каждому из множества клиентских устройств 102(1), 102(2), …, 102(x). Каждое клиентское устройство 102 имеет проигрыватель 184 аудиовизуальной передаваемой в виде потока информации, который принимает потоковое мультимедийное представление и обрабатывает принятый поток в клиентском устройстве 102, обычно воспроизводя мультимедийное представление в клиентском устройстве 102. Те же самые данные передают в виде потока на каждое клиентское устройство 102 приблизительно в одно и то же время, позволяя серверному устройству 104 передавать в виде потока только один экземпляр одного и того же мультимедийного представления одновременно, при этом различные клиентские устройства 102 «прослушивают» наличие этого представления, которое передают в виде потока.
Передаваемая в виде потока аудиовизуальная информация 186 включает в себя сообщения RTCP, имеющие одно или более сообщений описания сеанса, внедренные в нее. Одно и то же сообщение описания сеанса может быть передано посредством вещания множество раз в течение потоковой передачи мультимедийного представления, таким образом разрешая новым клиентским устройствам 102 слушать передаваемую в виде потока аудиовизуальную информацию после того, как потоковая передача началась, но все еще принимать сообщение описания сеанса, описывающее мультимедийное представление. Посредством внедрения сообщения описания сеанса в сообщения RTCP потоковой аудиовизуальной информации 186 клиентским устройствам 102 нет необходимости прослушивать отдельный поток или вещание, потенциально от устройства, отличного от серверного устройства 182, чтобы принимать сообщения описания сеанса.
Еще не прошедшая экспертизу заявка на патент № 10/693,430, поданная 24 октября, 2003, "Methods and Systems for Self-Describing Multicasting of Multimedia Presentations", которая включена в настоящее описание посредством ссылки, описывает пример такой среды мультивещания.
Фиг. 4 иллюстрирует пример клиентского и серверного устройств в среде со списком воспроизведения на стороне сервера, которая может передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В некоторых вариантах осуществления протоколы 150, 152 и 154 из фиг. 2 включены в клиентское и серверное устройства согласно фиг. 4, но не проиллюстрированы. Кроме того, хотя не показано на фиг. 3, одно или более дополнительных устройств (например, брандмауэры, маршрутизаторы, шлюзы, мосты и т.д.) могут быть расположены между клиентским устройством 102 и серверным устройством 104.
Модуль 202 потоковой передачи из серверного устройства 104 передает в виде потока мультимедийное представление как передаваемую в виде потока аудиовизуальную информацию 204 проигрывателю 206 потоковой аудиовизуальной информации в клиентском устройстве 102. Проигрыватель 206 потоковой аудиовизуальной информации принимает потоковое мультимедийное представление и обрабатывает принятый поток в клиентском устройстве 102, обычно воспроизводя мультимедийное представление в клиентском устройстве 102.
Серверное устройство 104 включает в себя список 208 воспроизведения, который идентифицирует множество (y) частей аудиовизуального контента 210(1), 210(2), …, 210(y). В некоторых вариантах реализации список 208 воспроизведения включает в себя множество записей, причем каждая запись идентифицирует одну из множества частей аудиовизуального контента 210. Альтернативно, список 208 воспроизведения может идентифицировать одну часть аудиовизуального контента, хотя в таких ситуациях одна часть аудиовизуального контента может просто ссылаться на себя вместо использования списка воспроизведения. Клиентское устройство 102 способно выбрать одиночный ресурс для воспроизведения, при этом этот ресурс идентифицирует список 208 воспроизведения. Модуль 202 потоковой передачи обращается к идентифицированному списку 208 воспроизведения, и затем обращается к индивидуальным частям аудиовизуального контента 210, и передает в виде потока эти части 210 на клиентское устройство 102. Таким образом, клиентское устройство 102 способно обратиться к одиночному ресурсу и все же иметь множество различных частей аудиовизуального контента, передаваемых в виде потока от серверного устройства 104. Поскольку список 208 воспроизведения доступен и указан серверным устройством 104 для идентификации частей аудиовизуального контента, вместо клиентского устройства 102, список 208 воспроизведения может также быть назван как список воспроизведения на стороне сервера.
Каждая часть аудиовизуального контента 210 включает в себя один или более аудиовизуальных потоков. Различные части аудиовизуального контента 210 могут включать в себя различное число аудиовизуальных потоков. Каждая часть аудиовизуального контента 210 обычно является мультимедийным представлением. Способ, которым определена "часть" содержимого, может изменяться в зависимости от выполнения и быть основанным на типе аудиовизуальной информации. Например, для музыкального аудио- и/или видеоконтента каждая песня может быть частью контента. Контент может быть разделен на части по естественным границам (например, различные песни), или, альтернативно, другим произвольным образом (например, каждые пять минут содержимого (контента) - это часть). Для сохраненного контента различные части контента могут быть сохранены как множество файлов или, альтернативно, как один и тот же файл.
Хотя показаны как два отдельных рисунка на фиг. 3 и 4, должно быть понятно, что части аудиовизуального контента, названные списком воспроизведения на стороне сервера, как проиллюстрировано на фиг. 4, могут быть переданы посредством мультивещания, как показано на фиг. 3.
На Фиг. 2, 3 и 4 показано, что на транспортном уровне данные, которые нужно передавать в виде потока от серверного устройства 104 на клиентское устройство 102, внедрены в пакеты RTP. Управляющая информация, относящаяся к данным, которые передают в виде потока, и пакеты RTP внедряют в одно или более сообщений управления в пакете RTCP.
Как правило, пакет RTCP состоит из нескольких сообщений различных типов. Первое сообщение в пакете RTCP является или Отчетом приемника, или Отчетом отправителя. Второе сообщение является сообщением SDES (Описание источника). Сообщение SDES содержит один или более элементов текстовых мета-данных. Сообщение SDES содержит элемент CNAME (каноническое имя). Элемент CNAME является постоянным идентификатором источника аудиовизуального контента на транспортном уровне и обеспечивает отображение (соответствие) между номером источника синхронизации RTP (SSRC) и текстовой строкой. SSRC является источником потока пакетов RTP (и RTCP). CNAME используется так, чтобы отправитель или приемник, который участвует в множестве сеансов RTP, которые принадлежат одному и тому же представлению, могли использовать различные значения SSRC в каждом сеансе RTP, но сохранять значение CNAME одним и тем же.
Дополнительным типом сообщения, которое может быть включено в пакет RTCP, является сообщение управления, имеющее внедренное в него сообщение описания сеанса. Сообщение описания сеанса описывает свойства мультимедийного представления, которое передают в виде потока от серверного устройства 104 на клиентское устройство 102. Различные форматы аудиовизуальной информации или протоколы могут использоваться для таких сообщений описания сеанса. Пример такого формата аудиовизуальной информации является Протокол описания сеанса (SDP), описание «запроса на комментарии рабочей группы по сетям» (RFC) 2327, апрель 1998. В некоторых вариантах осуществления описанное здесь сообщение описания сеанса является сообщением в соответствии с форматом SDP, описанным в RFC 2327.
Хотя различные форматы могут использоваться для описания свойств мультимедийного представления, одно или более сообщений описания сеанса посылают от серверного устройства 104 на клиентское устройство 102, которые включают в себя идентификатор(ы) свойств. Одиночное сообщение описания сеанса может быть послано серверным устройством 104 для конкретного мультимедийного представления или, альтернативно, может быть послано множество сообщений описания сеанса. Если послано множество сообщений описания сеанса, это множество сообщений могжет включать в себя одну и ту же информацию, различную информацию или "перекрывающуюся" информацию.
Сообщение описания сеанса включает в себя, например, одно или более из следующего: идентификационная информация различных каналов, используемая для мультивещания мультимедийного представления; описания каждого аудиовизуального потока, доступного в мультимедийном представлении (например, указывая тип потока (например, видео или аудио), скорость передачи в битах каждого потока аудиовизуальной информации, язык, используемый в этом потоке, и т.д.); информация коррекции ошибок; информация защиты/аутентификации, информация кодирования; или информация цифрового управления правами (DRM) и т.д.
Следует отметить, что в некоторых ситуациях сообщение описания сеанса может быть разделено или фрагментировано по множеству сообщений управления RTCP. Такие ситуации могут возникать, например, когда сообщение описания сеанса очень большое. Каждое из этих сообщений RTCP управления включено в отдельный пакет RTCP, и каждый содержит часть или фрагмент полного сообщения описания сеанса. Клиентское устройство 102 после приема всех частей или фрагментов может объединять их вместе для восстановления сообщения описания сеанса.
Фиг. 5 иллюстрирует пример формата сообщения 250 управления RTCP, имеющего внедренное сообщение описания сеанса. Сообщение 250 RTCP описано ниже как включающее в себя множество полей (также называемых частями), причем каждое хранит различные данные. Должно быть понятно, что эти поля могут быть расположены в отличном порядке, чем порядок, в котором они описаны ниже и показаны на фиг. 5. Дополнительно, хотя размеры или длины этих полей (например, в битах) описаны ниже, должно быть понятно, что это является только примером, и поля альтернативно могут быть больше или меньше, чем эти примеры размеров или длины. В некоторых вариантах осуществления сообщение 250 RTCP включает в себя все поля, показанные на фиг. 5. В дополнительных вариантах осуществления сообщение 250 RTCP включает в себя меньшее количество, чем все поля, показанные на фиг. 5, или может включать в себя дополнительные поля, не показанные на фиг. 5.
Поля сообщения 250 RTCP могут быть рассмотрены как сгруппированные в три группы: заголовок 290, блок 292 RTP-состояния и сообщение 284 описания сеанса. Заголовок 290 включает в себя различную информацию о сообщении 250 RTCP. Блок 292 RTP-состояния является необязательным и когда включен, используется для идентификации RTP-специфической информации о потоке мультимедийного представления, которое описано в сообщении описания сеанса (например, для определения SSRC и начального номера RTP-последовательности потока в сообщении описания сеанса). Как правило, один блок 292 RTP-состояния связан с и включен в сообщение 250 RTCP для каждого потока аудиовизуальной информации в мультимедийном представлении. Сообщение 284 описания сеанса является сообщением описания сеанса, внедренным в сообщение 250 RTCP.
Поле 252 V (версия) - 2-битовое поле, которое идентифицирует версию используемого RTP, которое является тем же в пакетах RTCP, что и в пакетах RTP. Например, версия, определенная с помощью RFC 3550 - 2.
Поле 254 P (заполнение) - одиночный бит, который, если установлен (например, равным значению 1), указывает, что сообщение 250 RTCP содержит некоторое дополнительное заполнение в конце, которое не является частью информации управления. Это заполнение включено в поле 262 длины, но иначе должно игнорироваться. Величина заполнения включена непосредственно в заполнение. В некоторых вариантах реализации дополнительное заполнение задается в октетах, и последний октет заполнения является значением того, сколько заполняющих октетов включено (включая его самого) и, таким образом, должно игнорироваться.
Поле 256 C поле (сжатие) - одиночный бит, который, если установлен (например, равным значению 1), указывает, что данные в поле 284 данных SDP были сжаты. Различные типы сжатия могут использоваться, такие как использования сжатия Zlib, как описано в версии 3.3 Спецификации Формата ZLIB сжатых данных, в описании «запроса на комментарии рабочей группы по сетям» (RFC) 1950, Май 1996.
Поле 258 Res (зарезервировано) - 4-битовое зарезервированное поле. В некоторых вариантах реализации поле 258 Res должно быть установлено в ноль.
Поле 260 заголовка PT (тип полезных данных) - 7-битовое поле, установленное равным значению (например, 141), чтобы указать, что сообщение 250 RTCP внедряет сообщение описания сеанса.
Поле 262 длины - 16-битовое поле, которое идентифицирует длину сообщения 250 RTCP. Эта длина может быть сгенерирована, суммируя длины различных полей в сообщении 250 RTCP, включая любые заголовки и любое заполнение. В некоторых вариантах реализации длина идентифицируется в 32-битовых значениях минус один.
Поле 262 SDPMsgHash (хэш-функция сообщения SDP) - 16-битовое поле, используемое для идентификации сообщения описания сеанса, включенное в сообщение 250 RTCP, и адреса (например, IP-адрес) отправителя (например, серверное устройство 104). В некоторых вариантах реализации идентификатор в поле 264 вычисляется как контрольная сумма по сообщению описания сеанса и адресу так, чтобы при наличии любых изменений значения идентификатора в поле были также изменены. В некоторых вариантах реализации значение поля 264 SDPMsgHash вычисляется ,так же как поле "значение хэш-функции идентификатора сообщения", описанное в Протоколе Объявления Сеанса (SAP), в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2974, октябрь 2000. Если сообщение описания сеанса фрагментировано по множеству сообщений RTCP, как описано ниже, значения поля 264 SDPMsgHash каждого фрагмента должны быть идентичны.
Поле 266 F (более фрагментов) - одиночный бит, который, если установлен (например, имеет значение 1), указывает, что сообщение описания сеанса было фрагментировано во множество сообщений RTCP, и что текущее сообщение RTCP не содержит последнего фрагмента сообщения описания сеанса. Если поле 266 F не установлено (например, имеет значение 0), то сообщение описания сеанса не было фрагментировано (все сообщение описания сеанса включено в сообщение 250 RTCP), или сообщение описания сеанса было фрагментировано, и сообщение 250 RTCP содержит последний фрагмент сообщения описания сеанса.
Поле 268 FragSeqNum (порядковый номер фрагмента) - 15-битовое поле, используемое для идентификации различных фрагментов сообщения описания сеанса. Фрагментам сообщения описания сеанса назначают идентификаторы некоторым образом, известным и серверному устройству 104, и клиентскому устройству 102. Например, идентификаторы могут быть назначены последовательно, начиная со значения 0, так что первый фрагмент имеет значение 0, второй - значение 1, третий - значение 2 и т.д. Если сообщение 250 RTCP не содержит фрагмента сообщения описания сеанса (то есть сообщение 250 RTCP содержит все сообщение описания сеанса), то поле 268 FragSeqNum должно быть установлено в 0.
Поле 270 NumRtpState (номер RTP-состояния) - 16-битовое поле, используемое для определения числа блоков RTP-состояния, содержащихся в сообщении 250 RTCP. Каждый блок RTP-состояния имеет размер 14 байтов. Поле "NumRtpState" установлено в 0, когда блоки RTP-состояния не присутствуют. В иллюстрированном примере сообщения 250 RTCP имеется один блок 292 RTP-состояния. Если имеется множество блоков RTP-состояния, то поле 274, 276, 278, 280 и 282 включено для каждого из множества блоков RTP-состояния. Если сообщение описания сеанса фрагментировано на множество сообщений 250 RTCP, то только сообщение 250 RTCP, содержащее первый фрагмент сообщения описания сеанса, должно содержать блок(и) RTP-состояния.
Поле 272 - 1-битовое поле, которое не установлено (например, имеет значение 0), если поле 274 PT содержит допустимый номер типа полезных данных RTP. Если поле 272 не установлено, информация в блоке 292 RTP-состояния только применяется к номеру Типа Полезных данных RTP, идентифицированному в поле 274 PT и SDP Flow ID (идентификатору потока SDP), идентифицированному в поле 276 Flow ID. Если поле 272 установлено (например, имеет значение 1), то поле 274 PT должно игнорироваться, и блок 292 RTP-состояния применяют ко всем пакетам RTP для SDP Flow ID, идентифицированным в поле Flow ID, независимо от используемого Типа Полезных данных RTP.
Поле 274 РТ - 7-битовое поле, определяющее номер Типа Полезных данных RTP для информации в блоке 292 RTP-состояния. Если поле 272 установлено (например, имеет значение 1), то поле 274 PT не используется и должно быть установлено в 0.
Поле 276 Flow ID (идентификатор потока SDP) - 24-битовое поле, которое идентифицирует SDP Flow ID, к которому относится информация в блоке 292 RTP-состояния. Каждый поток аудиовизуальной информации передают в виде потока в различном сеансе RTP. Этим сеансам RTP назначают номер, используя атрибут "a=mid:", как описано в Группировке строк аудиовизуальной информации в Протоколе Описания Сеанса (SDP) в описании «запроса на комментарии рабочей группы по сетям» (RFC) 3388, декабрь 2002. Поле 276 Flow ID идентифицирует конкретную запись "м=" в сообщении описания сеанса, которая является той же, что и значение для атрибута "a=mid" (в соответствии с RFC 3388) записи "м=".
Поле 278 SSRC (источник синхронизации) - 32-битовое поле, которое задает значение поля SSRC RTP, используемое для потока аудиовизуальной информации, который идентифицирован полем 276 Flow ID. Если поле 272 не установлено (например, имеет значение 0), то поле SSRC только применяется к пакетам RTP для этого потока аудиовизуальной информации, которые используют Тип Полезных данных RTP, заданный полем 274 PT.
Поле 280 RtpTime (RTP-время) - 32-битовое поле, которое задает значение поля Timestamp RTP, которое пакет RTP имел бы, если бы пакет был послан точно в начале аудиовизуального потока, идентифицированного полем 276 Flow ID. Например, если временная шкала аудиовизуального представления начинается во время T, значение поля 280 RtpTime является значением поля Timestamp RTP пакета, который был бы послан точно в момент T, даже если такой пакет RTP фактически не существует для потока аудиовизуальной информации, идентифицированного блоком 292 RTP-состояния.
Поле 282 RtpSeq (RTP-последовательность) - 16-битовое поле, которое задает значение поля номера RTP-последовательности первого пакета RTP, который послан для потока аудиовизуальной информации, идентифицированного полем 276 Flow ID. Если поле 272 не установлено (например, имеет значение 0), то поле 282 RtpSeq применяется только к пакетам RTP для этого потока аудиовизуальной информации, которые используют Тип Полезных данных RTP, заданный полем 274 PT.
Поле 284 данных SDP - сообщение описания сеанса, внедренное в сообщение 250 RTCP. В ситуациях когда сообщение описания сеанса фрагментировано, поле 284 данных SDP содержит только часть сообщения описания сеанса (например, одиночный фрагмент сообщения описания сеанса). В некоторых вариантах реализации сообщение описания сеанса является полным описанием SDP в формате UTF-8.
Фиг. 6 иллюстрирует пример формата сообщения описания сеанса. Хотя проиллюстрировано как конкретный пример на фиг. 6, сообщение описания сеанса может иметь формат с полями или частями в различных порядках или, альтернативно, распределяться по различным сообщениям.
Сообщение 320 описания сеанса включает в себя часть 322 описания уровня сеанса и ноль или более частей 324 описания уровня аудиовизуальной информации. Часть 322 описания уровня сеанса включает в себя одно или более полей, имеющих данные, которые применяются к целому сеансу и всем потокам аудиовизуальной информации, которые являются частью сеанса. Каждая часть 322 описания уровня аудиовизуальной информации, с другой стороны, включает в себя одно или более полей, имеющих данные, которые применяются только к одиночному потоку аудиовизуальной информации.
Поля данных в части 322 описания уровня аудиовизуальной информации описывают свойства для конкретных потоков аудиовизуальной информации. Эти свойства могут быть в дополнение к свойствам, описанным в части 322 описания уровня сеанса, или вместо свойств, описанных в части 322 описания уровня сеанса. Например, одно или более свойств в конкретной части 322 описания уровня аудиовизуальной информации может отменять для конкретного аудиовизуальной информации, связанного с этой конкретной частью 322 описания уровня аудиовизуальной информации, свойства, идентифицированные в части 322 описания уровня сеанса.
Сообщение 320 описания сеанса и структура сообщения 320 описаны более подробно ниже со ссылками на SDP. Следует заметить, что эти конкретные структуры являются только примерами и что сообщение описания сеанса может принимать различные формы.
Часть 322 описания уровня сеанса начинается с конкретного поля, упомянутого как поле версии протокола. Аналогично, части 324 описания уровня аудиовизуальной информации каждое начинается со специфического поля, названного как поле имени и адрес транспортировки аудиовизуальной информации. В некоторых вариантах осуществления множество полей одного и того же типа могут быть включены в сообщение описания сеанса (например, одиночное сообщение описания сеанса может иметь два или более полей атрибутов).
Таблица I ниже иллюстрирует пример полей, которые могут быть включены в часть 322 описания уровня сеанса. Таблица I включает в себя имя для каждого поля примера, аббревиатуру или тип для каждого поля примера и краткое описание каждого поля примера. В некоторых вариантах осуществления требуются поле версии протокола, владельца/создателя и поле идентификатора сеанса, поле имени сеанса и поле описания времени, в то время как все другие поля в Таблице I необязательные.
Таблица II ниже более подробно иллюстрирует поле описания времени. Таблица II включает в себя имя для каждого поля в поле описания времени, аббревиатуру или тип для каждого поля в поле описания времени и краткое описание каждого поля в поле описания времени. Поле времени, в течение которого сеанс является активным, в то время как поле повторения ноль или более раз, является необязательным.
Таблица III ниже иллюстрирует пример полей, которые могут быть включены в часть 324 описания уровня аудиовизуальной информации. Таблица III включает в себя имя для каждого поля примера, аббревиатуру или тип для каждого поля примера и краткое описание каждого поля примера. В некоторых вариантах осуществления требуется поле объявления аудиовизуальной информации, в то время как все другие поля в Таблице III необязательные.
Фиг. 7 является последовательностью операций, иллюстрирующей пример процесса 350 для внедрения сообщений описания сеанса в сообщение RTCP при использовании списка воспроизведения на стороне сервера. Фиг. 7 показывает действия, выполненные источником контента аудиовизуальной информации, таким как серверное устройство 104 (например, фиг. 1, 2, 3 или 4).
Первоначально идентифицируют следующую часть контента аудиовизуальной информации в списке воспроизведения (действие 352). Когда начинается воспроизведение частей аудиовизуального контента, следующей частью является первая часть, идентифицированная в списке воспроизведения. Дополнительно, каждый раз, когда достигнут конец одной части содержимого (контента) (например, полная часть контента передана в виде потока на клиентское устройство 102, даже притом, что воспроизведение этой части в клиентском устройстве 102 наиболее вероятно еще не закончено), следующей частью контента аудиовизуальной информации является часть, которая следует за частью, конец которой был достигнут. Следует отметить, что эта следующая часть может следовать в порядке, определенном списком воспроизведения, или пользователь может быть способен осуществлять навигацию к различной части в пределах списка воспроизведения (например, пользователь может быть способен запросить, чтобы конкретная часть в списке воспроизведения была пропущена или "перепрыгнута").
Затем получают информацию, описывающую идентифицированную часть контента аудиовизуальной информации (действие 354). Эта информация может быть получена одним или более отличающимися способами. Одним из способов, которым эта информация может быть получена, является извлечение из файла или записи. В некоторых вариантах осуществления по меньшей мере часть информации сохранена в файле или записи, связанном(ой) с идентифицированной частью контента аудиовизуальной информации. К этому файлу или записи обращаются на этапе 354, чтобы извлечь сохраненную информацию.
Другой способ, которым эта информация может быть получена, - это прием от пользователя-человека. В некоторых вариантах осуществления по меньшей мере часть информации получают от пользователя-человека. Эти вводы от пользователя используются в действии 354 в качестве по меньшей мере части информации, которая должна быть включена в сообщение описания сеанса.
Другим способом, которым эта информация может быть получена является автоматическое обнаружение. В некоторых вариантах осуществления по меньшей мере часть информации может быть автоматически получена вычислительным устройством, анализируя источник идентифицированной части контента аудиовизуальной информации или саму идентифицированную часть контента аудиовизуальной информации. Эта автоматически обнаруженная информация используется в действии 354 в качестве по меньшей мере части информации, которая должна быть включена в сообщение описания сеанса.
Затем создается сообщение RTCP, имеющее сообщение описания сеанса, которое включает в себя полученную информацию (действие 356). В некоторых вариантах осуществления это сообщение RTCP находится в форме сообщения 250 RTCP на фиг. 5, описанной выше. Созданное сообщение RTCP затем посылают назначенному получателю следующей части контента аудиовизуальной информации (действие 358). Назначенный получатель следующей части контента аудиовизуальной информации - это устройство, на которое аудиовизуальный контент передают в виде потока (например, клиентское устройство 102 из фиг. 1, 2, 3 или 4). Созданное сообщение RTCP включено в пакет RTCP, который включен в качестве части аудиовизуальной информации, которую передают в виде потока назначенному получателю.
Следует отметить, что могут возникать ситуации, когда число потоков аудиовизуальной информации, которые передают в виде потока для двух различных частей контента аудиовизуальной информации, идентифицированного в списке воспроизведения, различно. Например, первая часть контента аудиовизуальной информации, идентифицированного в списке воспроизведения, может иметь два потока (например, поток аудио и поток видео), в то время как вторая часть контента аудиовизуальной информации, идентифицированного в списке воспроизведения, может иметь три потока (например, поток аудио, поток видео и поток текстового подзаголовка). Дополнительно, когда передают в виде потока данные аудиовизуальной информации, используя UDP, каждый поток аудиовизуальной информации обычно использует отличный канал UDP, который принимают в получателе на различный порт UDP. Если получатель открыл только два порта для первой части контента аудиовизуальной информации (например, один порт для потока аудио и один порт для потока видео), может не быть порта, доступного для получателя, чтобы принять поток текстового подзаголовка второй части контента аудиовизуальной информации.
Такие ситуации могут быть разрешены различными способами. В некоторых вариантах осуществления такие ситуации разрешают, передавая в виде потока дополнительный(е) поток(и) аудиовизуальной информации по открытому соединению HTTP, используя TCP. Индикацию включают в сообщение 250 RTCP (например, в качестве дополнительного блока 292 RTP-состояния для каждого дополнительного потока аудиовизуальной информации), которое дополнительный(е) поток(и) аудиовизуальной информации передает в виде потока этим способом.
В других вариантах осуществления такие ситуации разрешают при наличии у получателя открытых одного или двух дополнительных портов, часто называемых как групповые порты. Каждый из этих групповых портов может использоваться для приема любого потока аудиовизуальной информации, который серверное устройство посылает получателю. Индикацию включают в сообщение 250 RTCP (например, в качестве дополнительного блока 292 RTP-состояния для каждого дополнительного потока аудиовизуальной информации), указывающее, к какому из групповых портов дополнительный(е) поток(и) аудиовизуальной информации передают в виде потока.
В других вариантах осуществления такие ситуации разрешают серверным устройством, посылающим сообщение описания сеанса получателю (например, в сообщении 250 RTCP), которое идентифицирует все потоки аудиовизуальной информации, доступные для второй части контента аудиовизуальной информации. Серверное устройство затем ожидает (ответа) получателя, чтобы выбрать, какой из потоков аудиовизуальной информации получатель желает принять. Получатель будет делать выбор (например, автоматически или на основании ввода пользователя в получателе), и посылать серверному устройству индикацию, какой(ие) поток(и) аудиовизуальной информации был(и) выбран(ы) и к каким портам выбранный(е) поток(и) аудиовизуальной информации должен(ы) быть переданы в виде потока.
Фиг. 8 показывает последовательность операций, иллюстрирующую пример процесса 380 для приема сообщений описания сеанса в сообщении RTCP при использовании списка воспроизведения на стороне сервера. Фиг. 8 показывает действия, выполненные получателем аудиовизуальной информации, таким как клиентское устройство 102 (например, на фиг. 1, 2, 3 или 4).
Первоначально, сообщение RTCP принимают от источника контента аудиовизуальной информации (действие 382). Источником контента аудиовизуальной информации является, например, серверное устройство 104 на фиг. 1, 2, 3 или 4.
Сообщение описания сеанса для следующей части контента аудиовизуальной информации в списке воспроизведения извлекают из сообщения RTCP (действие 384). Когда передача в виде потока частей контента аудиовизуальной информации в списке воспроизведения только начинается, этой следующей частью контента аудиовизуальной информации является первая часть контента аудиовизуальной информации в списке воспроизведения. После начала передачи в виде потока по меньшей мере одной из частей контента аудиовизуальной информации следующей частью контента аудиовизуальной информации является следующая часть, идентифицированная в списке воспроизведения. Следует отметить, что эта следующая часть может следовать в порядке, определенном списком воспроизведения, или пользователь может быть способен осуществлять навигацию к отличной части в пределах списка воспроизведения (например, пользователь может быть способен запросить, чтобы конкретная часть в списке воспроизведения быть пропущена или "перепрыгнута"). Следует также отметить, что сообщение описания сеанса для следующей части контента аудиовизуальной информации обычно принимается до воспроизведения текущей части заканчиваемого контента аудиовизуальной информации (чтобы позволить клиентскому устройству 102 немедленно начать воспроизведение следующей части контента аудиовизуальной информации, когда воспроизведение текущей части контента аудиовизуальной информации закончено).
Извлеченное сообщение описания сеанса затем используется в обработке следующей части контента аудиовизуальной информации (действие 386). Эта обработка обычно включает в себя воспроизведение следующей части контента аудиовизуальной информации в клиентском устройстве 102.
Фиг. 9 иллюстрирует систему 500 для мультивещания мультимедийных представлений согласно одному варианту осуществления. В этом варианте осуществления система 500 включает в себя источник 502 содержимого, сервер 504 и клиентов 506i-506x, которые связаны с сервером 504 через сеть 508. Сетью 508 может быть любая подходящая проводная (включая оптическое волокно) или беспроводная сеть (например, РЧ или оптическая в свободном пространстве). В одном варианте осуществления сетью 508 является Интернет, но в других вариантах осуществления сетью 508 может быть локальная сеть (LAN), сеть области университетского городка и т.д.
В этом варианте осуществления сервер 504 включает в себя генератор 510 объявления. Как будет описано более подробно ниже, варианты осуществления генератора 510 объявления генерируют потоки, содержащие информацию относительно мультимедийных представлений, подлежащих мультивещанию по сети 508. Работа этого варианта осуществления системы 500 во время осуществления мультивещания мультимедийных представлений описана ниже со ссылкой на фиг. 10 - фиг. 12.
Фиг. 10 иллюстрирует последовательность работы сервера системы 500 из фиг. 9 при мультивещании мультимедийного представления согласно одному варианту осуществления. Со ссылками на фиг. 9 502 сервер 504 работает следующим образом для осуществления мультивещания мультимедийного представления.
На этапе 524 сервер 504 принимает мультимедийное представление через соединение 512. В этом варианте осуществления сервер 504 принимает мультимедийное представление из источника 502 содержимого через линию 512 связи. В частности, источник 502 содержимого обеспечивает мультимедийный контент, подлежащий мультивещанию, по сети 508. Мультимедийный контент может быть сгенерирован любым подходящим образом. Например, мультимедийный контент может быть предварительно записанным/сгенерированным контентом, который затем сохранен в хранилище данных (не показано), или передаваемым непосредственно с места действия, который фиксируется (например, используя видеокамеру, микрофон и т.д.) и кодируется (кодирующим устройством, не показано).
В обычном применении мультимедийное представление будет включать в себя множество потоков. Например, мультимедийное представление может включать в себя поток видео, поток аудио, другой поток видео, закодированный с более низкой скоростью передачи в битах и другие потоки аудио, закодированные с более низкой скоростью передачи в битах. В других приложениях мультимедийное представление может иметь больше или меньше потоков, чем те, что описаны в примере применения. Таким образом, в этом варианте осуществления сервер 504 принимает мультимедийное представление в форме одного или более потоков на этапе 524.
На этапе 526 сервер 504 формирует поток объявления и осуществляет мультивещание потока объявления по сети 508 через линию 514 связи. В этом варианте осуществления генератор 510 объявления из сервера 504 формирует поток объявления. В некоторых вариантах осуществления генератор 510 объявления может быть сконфигурирован администратором, в то время как в других вариантах осуществления генератор 510 объявления может быть сконфигурирован для обработки потока(ов), принимаемого(ых) на этапе 524, и извлечения информации из этого(их) потока(ов) для формирования потока объявления.
В некоторых вариантах осуществления сервер 504 осуществляет мультивещание потока объявления по выделенному каналу объявления (то есть каналу без информации объявления, относящейся к другим мультимедийным представлениям). Как используется в данном контексте, каналом может быть логический адрес, такой как адрес Интернет протокола (IP) и порт мультивещания. Таким образом, клиент может соединяться с каналом, прослушивая логический адрес и порт, связанный с каналом. Клиенты могут узнать о логическом адресе любым подходящим образом, например, но не ограничиваясь ими, по электронной почте, приглашениями, отправлениями по почте между Web-сайтами, и мультивещанием обычного Протокола Объявления Сеанса (SAP) (например, как определено в Спецификации IETF RFC-2974, "Session Announcement Protocol"). В вариантах осуществления, использующих мультивещания SAP для объявления мультимедийного представления, мультивещанию SAP нет необходимости включать в себя подробную информацию описания представления, которая может быть предоставлена в "совмещенном" (“in-line”) потоке объявления (описано более подробно ниже).
В некоторых вариантах осуществления поток объявления является мультивещанием, "совмещенным" (in-line) с потоком, содержащим мультимедийные данные. Например, может быть осуществлено мультивещание потока мультимедийных данных, используя пакеты согласно Протоколу транспортировки в реальном масштабе времени (RTP), и может быть осуществлено мультивещание потока объявления, используя пакеты согласно Протоколу управления транспортировкой в реальном масштабе времени (RTCP). В одном варианте осуществления RTP определен в описании «запрос на комментарии» (RFC) 3550, документах проблемной группы проектирования Интернет (IETF), июль, 2003 (который включает в себя также спецификацию RTCP). В этом варианте осуществления RTP расширен для поддержки данных объявления в пакетах RTCP. В дальнейшем усовершенствовании данные объявления могут быть посланы "совмещенными" в тех же самых пакетах RTP (или другие пакетах/дейтаграммах протокола), что и мультимедийные данные. В других вариантах осуществления канал объявления может быть внеполосным (например, когда осуществляется мультивещание канала объявления, используя SAP).
Поток объявления содержит информацию, которая описывает мультимедийное представление, такую как, например, идентификация различных каналов, используемых для мультивещания мультимедийного представления, описаний потока (например, указывая тип потока (например, видео или аудио); скорость передачи в битах потока; язык, используемый в потоке, и т.д.), транспортируемых каждым из каналов, информация коррекции ошибок; информация защиты/аутентификации; информация кодирования; информация цифрового управления правами (DRM) и т.д. В одном варианте осуществления поток объявления является повторяющимся мультивещанием во время мультимедийного представления, так чтобы клиенты, присоединяющиеся в разное время, могли принимать информацию описания мультимедийного представления. Клиент, принимающий эту информацию описания представления посредством потока объявления, может затем определять, какие каналы являются подходящими для подсоединения, на основании учета своих ресурсов.
На этапе 528 сервер 504 осуществляет мультивещание потока(ов), выбранного(ых) из потока(ов) мультимедийного представления, принятого(ых) на этапе 524. В некоторых сценариях сервер 504 осуществляет мультивещание всех потоков, принятых на этапе 524. В некоторых вариантах осуществления администратор может конфигурировать сервер 504 для мультивещания конкретных потоков в заранее выбранные каналах. В одном варианте осуществления сервер 504 поддерживает по меньшей мере канал объявления, канал видео и канал аудио. Более часто сервер 504 также поддерживает дополнительные каналы видео- и аудиопотоков с различными скоростями передачи в битах, чтобы обеспечить клиентов, имеющих различные ресурсы, доступные для обработки мультимедийного представления.
Например, как показано на фиг. 11, сервер 504 может быть сконфигурирован так, чтобы поддержать канал 532 объявления, канал 534 ускорения (описанный ниже со ссылками на фиг. 15 и 16), канал 536 видео высокого качества, канал 538 аудио высокого качества, канал 540 приложений, каналы 5421-542N на альтернативных языках и каналы 5441-544M с альтернативными скоростями передачи в битах (для аудио- и/или видеопотоков). В одном варианте осуществления канал 540 приложений может использоваться для мультивещания данных, используемых прикладными программами, которые, как ожидается, будет выполняться локально на клиентах (например, проигрывателе аудиовизуальной информации или других приложениях, которые могут требовать дополнительный (plug-in) модуль для использования мультивещаемых данных приложения, таких как данные Microsoft PowerPoint®). В зависимости от потоков, обеспеченных источником 502 содержимого, и конфигурации сервера 504, и заранее выбранных определений каналов сервер 504 может отображать поток только в один канал, множество каналов или никакие каналы. Например, если мультимедийное представление из источника 502 содержимого включает в себя поток на английском языке и поток на испанском языке, сервер 504 может быть сконфигурирован так, чтобы отобразить поток на испанском языке во все каналы 5421-542N, или только канал 5421, или вообще ни на какой канал.
В некоторых вариантах осуществления "распределение" каналов является заранее выбранным. Например, в вариантах осуществления, в которых каждый канал имеет свой собственный IP-адрес, каналы могут быть набором последовательных IP-адресов в диапазоне IP-адресов, назначенных для мультивещания (то есть диапазон от IP-адреса 224.0.0.0 до IP-адреса 239.255.255.255). Таким образом, канал 532 объявления может быть назначен на IP-адрес 231.0.0.1, канал 534 ускорения может быть назначен на IP-адрес 231.0.0.2, и канал 536 видео высокого качества может быть назначен на IP-адрес 231.0.0.3, и так далее. Точно так же каналы могут быть набором последовательных портов группового IP-адреса. Таким образом, в варианте осуществления на основе RTF канал 532 объявления может быть назначен на порт 231.0.0.1:5000, канал 534 ускорения может быть назначен на порт 231.0.0.1:5002, канал 536 видео высокого качества может быть назначен на порт 231.0.0.1:5004, и так далее (так, чтобы порты 5001, 5003 и 5005 могли использоваться для пакетов RTCP).
Подходы, используемые вышеупомянутыми вариантами осуществления системы 500, имеют несколько преимуществ. Например, так как осуществляется мультивещание потока объявления по выделенному каналу, клиент может более быстро принимать информацию описания представления, таким образом выгодно сокращая задержку запуска. Напротив, обычный подход мультивещания SAP обычно имеет большую задержку запуска, потому что мультивещания SAP обычно объявляют большое количество мультивещаний, что имеет тенденцию уменьшать частоту, с которой осуществляют мультивещание объявления для конкретного мультимедийного представления (что в свою очередь имеет тенденцию увеличивать задержку запуска).
Далее, эти варианты осуществления системы 500 не требуют, чтобы клиенты имели обратный канал к серверу 504, таким образом обеспечивая большую гибкость в доставке мультимедийных представлений требуемой аудитории.
Кроме того, эти варианты осуществления системы 500 устраняют необходимость для сервера обеспечивать файл "информация мультивещания", требуемый в описанной выше обычной системе, и, таким образом, нести затраты, требуемые на поддержание и публикацию этого файла.
Кроме того, так как потоки, мультивещание которых осуществляют в наборе каналов, являются "предсказуемыми" в некоторых вариантах осуществления, клиенты могут выбирать подсоединение к конкретным каналам без ожидания приема и обработки информации описания мультимедийного представления по каналу 532 объявления. Например, агрессивный клиент (обычно клиент с относительно большими ресурсами) может выбрать подсоединение к каналам 536 и 538 видео высокого качества и аудио высокого качества одновременно или вместо подсоединения к каналу 532 объявления, таким образом сокращая задержку запуска, если клиент действительно имеет достаточные ресурсы для обработки потоков без потери данных. Например, клиент с большими ресурсами может быть клиентом, имеющим вычислительную платформу с высокоскоростным центральным процессором и большими ресурсами буферизации и связанным с высокоскоростной компьютерной сетью с относительно большой доступной пропускной способностью. Высокоскоростной центральный процессор и большие ресурсы буферизации значительно уменьшают риск потери данных.
Фиг. 12 иллюстрирует работу клиента 5061 (фиг. 9) при приеме мультимедийного представления, мультивещание которого осуществляют сервером 504 (фиг. 9), согласно одному варианту осуществления. Клиенты 5062-506X (фиг. 9) могут работать по существу идентично. Со ссылками на фиг. 9, 11 и 12 клиент 5061 работает следующим образом при приеме мультимедийного представления.
На этапе 562 клиент 5061, уже приняв логический адрес канала объявления мультимедийного представления, подсоединяется к каналу 532 объявления. Как описано выше для одного варианта осуществления, сервер 504 повторяющимся образом осуществляет мультивещание информации описания представления по выделенному каналу объявления. Таким образом, клиент 5061 может относительно быстро принимать информацию описания представления по сравнению с обычными системами, которые обычно осуществляют мультивещание информации описания относительно большого количества мультимедийных и/или других типов представлений.
На этапе 564 клиент 5061 затем соединяется с одним или более каналов, которые обеспечивают потоки мультимедийных данных, которые описаны в принятом потоке объявления. В одном варианте осуществления клиент 5061 может определять, с каким каналом(ами) соединиться, чтобы иметь оптимальный опыт, используя ресурсы, доступные клиенту 5061. Клиент 5061 затем может принимать выбранный(е) поток(и) мультимедийного представления.
Фиг. 12A иллюстрирует этапы работы клиента 5061 (фиг. 9) при приеме мультимедийного представления, мультивещание которого осуществляют сервером 504 (фиг. 9), согласно другому варианту осуществления. Клиенты 5062-506Х (фиг. 9) могут работать по существу идентично. Со ссылками на фиг. 9, 11 и 12A, клиент 5061 работает следующим образом при приеме мультимедийного представления. В этом варианте осуществления клиент 5061 по существу одновременно исполняет этап 562 (чтобы соединиться с каналом объявления 532, как описано выше) и этап 570.
На этапе 570 клиент 5061 также соединяется с одним или более заранее выбранными каналами мультимедийного представления в дополнение к каналу 532 объявления. Как выше описано для одного варианта осуществления, сервер 504 может быть сконфигурирован для мультивещания потоков по заранее выбранным каналам заранее определенным образом. В этом варианте осуществления клиент 5061 может воспользоваться преимуществом заранее выбранных назначений канала, чтобы соединиться с требуемыми каналами без необходимости принимать информацию описания представления по каналу 532 объявления. Например, в одном сценарии клиент 5061 имеет относительно большие ресурсы для приема и обработки мультимедийного представления, способные к обработке обычных потоков видео высокого качества и аудио высокого качества. Имея эти ресурсы, клиент 5061 может быть сконфигурирован так, чтобы немедленно соединиться с каналами 536 и 538, чтобы принимать поток видео высокого качества и аудио высокого качества с целью уменьшить задержку запуска с относительно высоким ожиданием того, что клиент 5061 может должным образом обрабатывать потоки.
На этапе 572 принятия решения клиент 5061 определяет, может ли он оптимально обрабатывать поток(и), принятый(ые) от канала(ов), к которому(ым) он присоединился на этапе 570 ввиду ресурсов, доступных клиенту 5061. В одном варианте осуществления клиент 5061 использует информацию описания представления, принятую по каналу 532 объявления, чтобы определить, могут ли его ресурсы обрабатывать потоки, принятые по этим каналам. Например, потоки каналов, присоединенные на этапе 570, могут иметь скорости передачи в битах (которые будут описаны в потоке объявления), которые являются слишком большими для клиента 5061 для обработки без потери данных (что может привести к прерывистому аудиовоспроизведению для потоков аудио или появлению блочности при воспроизведении видео для потоков видео). Если клиент 5061 решает на этапе 572, что он может оптимально обрабатывать поток(и) заранее выбранного(ых) канала(ов), клиент 5061 продолжает принимать поток(и) от канала(ов), к которому(ым) клиент 5061 присоединился на этапе 570, пока мультивещание мультимедийного представления не заканчивается.
Однако в этом варианте осуществления, если клиент 5061 на этапе 572 решает, что он не может оптимально обрабатывать поток(и) заранее выбранного(ых) канала(ов), последовательность операций продолжается на этапе 564 (описано выше со ссылками на фиг. 12). На этапе 564, используя информацию описания представления, принятую на этапе 562, клиент 5061 присоединяется к одному или более другим каналам, которые передают потоки мультимедийных данных, которые клиент 5061 может оптимально обрабатывать. На этапе 574 в этом варианте осуществления клиент 5061 может отсоединяться от заранее выбранных каналов, присоединенных на этапе 570. Клиент 5061 продолжает принимать поток(и) от каналов, присоединенных на этапе 564, пока мультивещаемое мультимедийное представление не заканчивается или не сделан выбор "покинуть" канал.
Фиг. 13 иллюстрирует некоторые из компонентов сервера 504 (фиг. 9) согласно одному варианту осуществления. В этом варианте осуществления в дополнение к генератору 510 объявления (описанному выше со ссылкой на фиг. 9) сервер 504 включает в себя контроллер 582 конфигурации, конфигурируемый модуль 584 назначения потоков, интерфейс 586 источника и сетевой интерфейс 588. В некоторых вариантах осуществления эти элементы являются программными модулями или компонентами, которые могут быть выполнены вычислительной средой сервера 504.
Интерфейс 586 источника сконфигурирован так, чтобы принимать один или более мультимедийных потоков из источника 502 содержимого (фиг. 9) по линии 512 связи. Конфигурируемый модуль 584 назначения потоков сконфигурирован так, чтобы принимать потоки от интерфейса 586 источника, поток объявления от генератора 510 объявления и информацию управления от контроллера 582 конфигурации. В этом варианте осуществления конфигурируемый модуль 584 назначения потоков функционирует подобно переключателю при преобразовании или направлении одного или более потоков, принятых от интерфейса 586 источника на канал(ы) мультивещания. Сетевой интерфейс 588 осуществляет мультивещание выбранных потоков по сети 508 (фиг. 9). В некоторых вариантах осуществления контроллер 582 конфигурации конфигурирует конфигурируемый модуль 584 назначения потоков, чтобы преобразовать (отобразить) принимаемый(е) поток(и) мультимедийного представления в канал(ы). Кроме того, в некоторых вариантах осуществления контроллер 582 конфигурации дает команду генератору 510 объявления генерировать объявления. Последовательность операций одного варианта осуществления контроллера 582 конфигурации описана ниже со ссылкой на фиг. 13 и 14.
Фиг. 14 иллюстрирует последовательность операций контроллера 582 конфигурации (фиг. 13) при мультивещании мультимедийного представления согласно одному варианту осуществления. Со ссылками на фиг. 13 и 14 один вариант осуществления контроллера 582 конфигурации выполняет мультивещание мультимедийного представления, как описано ниже.
На этапе 602 контроллер 582 конфигурации согласно этому варианту осуществления принимает информацию конфигурации от администратора. Администратор может вручную обеспечивать информацию конфигурации на контроллер 582 конфигурации из сервера 504. Эта информация конфигурации может определять каждый из каналов в терминах логического адреса и включать в себя информацию описания представления (описанную выше). Например, информация представления может включать в себя тип(ы) аудиовизуальной информации потока(ов) мультимедийного представления, который(е) должен(ы) подвергаться мультивещанию, скорости передачи в битах; язык(и), информацию коррекции ошибок; информацию защиты/аутентификации; информацию кодирования; информацию цифрового управления правами (DRM) и т.д.
В альтернативных вариантах осуществления контроллер 582 конфигурации может быть сконфигурирован так, чтобы извлечь информацию описания представления непосредственно из самих потоков (например, из заголовка или информации метаданных, включенной в потоки) после приема от источника 502 содержимого (фиг. 9) через интерфейс 586 источника.
На этапе 604 контроллер 582 конфигурации конфигурирует модуль 584 назначения потоков так, чтобы отобразить поток объявления от генератора 510 объявления и поток(и) мультимедийных данных от интерфейса 586 источника на каналы, как описано в информации описания представления. Этот поток объявления повторно мультивещается по каналу объявления сервером 504 в течение мультивещания мультимедийного представления.
На этапе 606 контроллер 582 конфигурации выдает информацию описания представления для потока(ов) на генератор 510 объявления. Как описано выше, генератор 510 объявления формирует поток объявления, который включает в себя информацию описания представления.
Как описано выше, "распределение" каналов может быть заранее выбранным. Например, клиенту может быть дан логический адрес (например, URL) для подсоединения к мультивещаемому мультимедийному представлению. В одном варианте осуществления этот первый логический адрес является заранее выбранным так, чтобы передавать поток объявления в одном варианте осуществления. В этом примере следующий последовательный логический адрес является заранее выбранным так, чтобы передавать канал ускорения, в то время как следующий последовательный логический адрес является заранее выбранным так, чтобы передавать поток видео высокого качества, и так далее, как показано в варианте осуществления на фиг. 11. Контроллер 582 конфигурации конфигурирует модуль 584 назначения потоков так, чтобы отобразить поток объявления и потоки мультимедийных данных согласно заранее выбранному размещению каналов.
Фиг. 15 иллюстрирует некоторые из компонентов сервера 504 (фиг. 9) согласно другому варианту осуществления. Этот альтернативный вариант осуществления сервера 504 по существу подобен варианту осуществления на фиг. 13, за исключением того, что этот вариант осуществления включает в себя генератор 702 ускоренного потока. В одном варианте осуществления генератор 702 ускоренного потока сконфигурирован так, чтобы формировать поток, в котором каждый блок мультимедийных данных, мультивещание которого осуществляется, содержит текущий подблок мультимедийных данных и заранее выбранное количество предыдущих подблоков данных. Например, может осуществляться мультивещание ускоренного потока так, что дейтаграмма содержит текущий кадр(ы) мультимедийного представления и кадр(ы) предыдущих пяти секунд. В этом варианте осуществления генератор 702 ускоренного потока выдает ускоренный поток на конфигурируемый модуль 584 назначения потоков для отображения (назначения) в выделенный канал ускорения, такой как канал 534 ускорения (фиг. 11). Однако в других вариантах осуществления дейтаграмма канала ускорения не должна включать в себя текущий(е) кадр(ы).
Фиг. 16 иллюстрирует последовательность операций сервера 504 с генератором 702 ускоренного потока (фиг. 15) согласно одному варианту осуществления. Со ссылками на фиг. 15 и 16 этот вариант осуществления сервера 504 работает так, как описано ниже.
На этапе 802 генератор 702 ускоренного потока формирует блок мультимедийных данных для мультивещания по сети 508 (фиг. 9). В этом варианте осуществления генератор 702 ускоренного потока формирует блок, используя текущий подблок данных мультимедийного представления и предыдущие Z подблоков данных мультимедийного представления. Как упомянуто выше, блоком может быть дейтаграмма или пакет и подблоками могут быть кадры мультимедийных данных. В одном варианте осуществления Z выбирают так, чтобы гарантировать, что блок (то есть пакет или дейтаграмма) содержит ключевой кадр, необходимый для того, чтобы воспроизводить или декодировать мультимедийные данные. В других вариантах осуществления Z выбирают безотносительно к тому, будет ли обеспечен блок, имеющий ключевой кадр.
На этапе 804 осуществляют мультивещание блока мультимедийных данных, сформированного на этапе 802, по сети 508 (фиг. 9). В этом варианте осуществления генератор 702 ускоренного потока подает блок мультимедийных данных на конфигурируемый модуль 584 назначения потоков, который затем отображает блок на канал ускорения. Сервер 504 затем осуществляет мультивещание блока мультимедийных данных по сети 508 (фиг. 9) через сетевой интерфейс 588. В одном варианте осуществления сервер 504 осуществляет мультивещание модуля со скоростью передачи в битах, которая "быстрее, чем реальное время" (то есть со скоростью передачи в битах, которая является быстрее чем скорость передачи в битах "нижележащих" (основных) мультимедийных данных). Этот подход выгодно позволяет клиенту, имеющему относительно большие ресурсы, соединяться с каналом ускорения и быстро заполнять буфер его мультимедийного проигрывателя при приеме блока так, чтобы визуализация или воспроизведение могли начинаться более быстро. Эта особенность расширена в вариантах осуществления, в которых мультивещаемый блок мультимедийных данных включает в себя ключевой кадр. Альтернативно, скорость передачи в битах, с которой сервер 504 осуществляет мультивещание блока, не должна быть "быстрее чем реальное время". Этот подход может использоваться в приложениях, в которых клиент одновременно подсоединяется и с каналом ускорения, и с другим каналом, который осуществляет мультивещание мультимедийных данных так, что в действительности клиент принимает мультимедийные данные со скоростью передачи в битах, которая "быстрее чем в реальном масштабе времени".
Если большее количество мультимедийных данных должно быть подвергнуто мультивещанию, последовательность операций возвращается на этап 802, как представлено на этапе 806 принятия решения. Таким образом, например, используя вышеупомянутый пример с мультимедийными кадрами, транспортируемыми в дейтаграммах, следующая дейтаграмма может включать в себя следующий кадр мультимедийных данных плюс кадр, добавленный к предыдущей дейтаграмме, плюс предыдущие (Z-1) кадров. Таким образом, в этом варианте осуществления каждый блок (например, дейтаграмма) представляет скользящее окно текущего подблока (например, кадр) и предыдущие Z кадров, при этом Z выбрано так, чтобы быть достаточно большим, чтобы гарантировать, что каждый блок имеет достаточно информации, чтобы минимизировать время, необходимое для того, чтобы позволить клиентскому мультимедийному проигрывателю запускать визуализацию/воспроизведение мультимедийного представления. Как упомянуто выше, в некоторых вариантах осуществления Z может быть выбрано так, чтобы гарантировать, что каждый блок имеет ключевой кадр.
В одном варианте осуществления блоки видео- и аудиоданных подвергают мультивещанию попеременно по одному и тому же каналу, если мультимедийное представление включает в себя и аудио- и видеопотоки. В других вариантах осуществления отдельные каналы ускорения могут использоваться для аудио- и видеопотоков.
В начале мультимедийного представления в одном варианте осуществления генератор ускоренного потока ждет, пока по меньшей мере Z подблоков мультимедийных данных будут подвергнуты мультивещанию по неускоренному(ым) каналу(ам) перед формированием блока данных на этапе 802.
Фиг. 17 иллюстрирует последовательность операций клиента при приеме ускоренного потока согласно одному варианту осуществления. На этапе 902 клиент (например, один из клиентов 5061-506Х на фиг. 9) соединяется с каналом ускорения. В некоторых сценариях канал ускорения является частью заранее выбранного распределения каналов, и клиент может соединяться с этим или одновременно, или не одновременно с подсоединением к каналу объявления. Как описано выше, канал ускорения может выгодно использоваться клиентом, имеющим относительно большие ресурсы для приема и обработки мультимедийных представлений так, чтобы клиент мог уменьшать задержку запуска.
На этапе 904 клиент принимает один или более блоков мультимедийных данных по каналу ускорения. В одном варианте осуществления каждый блок мультимедийных данных сгенерирован так, как описано выше со ссылкой на фиг. 16. Клиент может затем обрабатывать каждый блок мультимедийных данных, чтобы относительно быстро начать процесс воспроизведения или визуализацию. В одном сценарии клиент принимает блок видеоданных и блок аудиоданных, причем данные видео содержат ключевой кадр так, чтобы клиент мог начинать процесс визуализации/воспроизведения как можно скорее. Как описано выше, блок не должен иметь ключевой кадр в других вариантах осуществления.
На этапе 906 клиент может затем соединиться с неускоренным каналом, таким как канал 536 видео высокого качества и канал 538 аудио высокого качества. В одном варианте осуществления неускоренные каналы, к которым подсоединяется клиент, являются заранее выбранными, используя выше описанное заранее выбранное распределение каналов. В других вариантах осуществления клиент подсоединяется к каналу(ам) на основании информации описания представления, содержащейся в потоке объявления. На этапе 908 клиент отключается от канала ускорения. В одном варианте осуществления клиент отключается от канала ускорения немедленно после приема блока или блоков мультимедийных данных, необходимых, чтобы начать процесс или процессы визуализации/воспроизведения.
Хотя этапы 902 до 908 описаны как выполняемые последовательно, в последовательности операций на фиг. 17 (также как в других последовательностях операций, описанных здесь) этапы могут быть выполнены в порядке, отличном от показанного, или с некоторыми этапами, выполняемыми более одного раза, или с некоторыми этапами, выполняемыми одновременно, или их комбинации. Например, в некоторых вариантах осуществления этапы 902 и 906 выполняют параллельно так, чтобы последовательность операций была такой, когда клиент подсоединяется к ускоренным и неускоренным каналам одновременно. Этап 904 выполняется последовательно после этапа 902, и после этапов 904 и 906 переходят на этап 908.
Фиг. 17A иллюстрирует пример сценария, в котором клиент может соединяться с каналом ускорения и некоторыми заранее выбранные каналами и затем соединяться с другими каналами (например, на основании информации объявления, принятой по каналу объявления). В этом примере клиент соединяется с каналом ускорения (то есть, этап 902) одновременно с соединением с одним или более заранее выбранным(и) неускоренным(и) каналом(ами) (то есть этап 906). Затем клиент принимает один или более блоков мультимедийных данных по каналу ускорения (то есть этап 904), а также мультимедийные и данные объявления от неускоренных каналов. В результате подсоединения к каналу объявления клиент может решать покинуть (отключиться от) заранее выбранный(е) канал(ы) и соединяться с другими неускоренными каналами (то есть этапы 572, 564 и 574).
Различные варианты осуществления мультивещания, описанные выше, возможно осуществить в компьютерных средах с серверами и клиентами. Примерная компьютерная среда, подходящая для использования в сервере и клиенте, описана ниже со ссылкой на фиг. 18.
Фиг. 18 иллюстрирует общую компьютерную среду 1000, которая может использоваться для осуществления описанных способов. Компьютерная среда 1000 является только одним примером вычислительной среды и не предназначена для предложения какого-либо ограничения на возможности использования или функциональные возможности компьютерных и сетевых архитектур. Компьютерная среда 1000 не должна интерпретироваться как имеющая какую-либо зависимость или требования, касающегося любого или комбинации компонентов, проиллюстрированных в примерной компьютерной среде 1000.
Компьютерная среда 1000 включает в себя вычислительное устройство общего назначения в форме компьютера 1002. Компоненты компьютера 1002 могут включать в себя, но не ограничиваются ими, один или более процессоров или блоков 1004 обработки, системную память 1006 и системную шину 1008, которая подсоединяет различные системные компоненты, включая процессор 1004, к системной памяти 1006.
Системная шина 1008 представляет собой одну или более любую из нескольких типов шинных структур, включая шину памяти или контроллер памяти, шину периферийных устройств, ускоренный графический порт и процессор или локальную шину, используя любую из множества шинных архитектур. В качестве примера такая архитектура может включать в себя шину Архитектуры Промышленного стандарта (ISA), шину Микроканальной Архитектуры (MCA), Усовершенствованную шину ISA (EISA), локальную шину Ассоциации Стандартов Видео Электроники (VESA), шину соединения периферийных компонентов (PCI), также известную как шина Mezzanine, шина PCI Express, Универсальную Последовательную Шину (USB), Безопасную Цифровую шину (SD), или IEEE 1394, то есть, шину FireWire.
Компьютер 1002 может включать в себя ряд считываемых компьютером носителей. Такими носителями могут быть любые доступные носители, которые доступны компьютеру 1002, и включают в себя и энергозависимые и энергонезависимые, носители, сменные и несменные носители.
Системная память 1006 включает в себя считываемые компьютером носители в форме энергозависимой памяти, такой как оперативная память (ОЗУ, RAM) 1010; и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ, ROM) 1012 или флэш-память (флэш-ОЗУ). Базовая система ввода/вывода (БСВВ, BIOS) 1014 содержит основные подпрограммы, которые помогают передавать информацию между элементами в компьютере 1002, например во время запуска, сохраненные в ROM 1012 или флэш-памяти. ОЗУ 1010 обычно содержит данные и/или программные модули, которые являются немедленно доступными и/или используемыми в настоящее время блоком 1004 обработки.
Компьютер 1002 может также включать в себя другие сменные/несменные, энергозависимые/энергонезависимые компьютерные носители данных. В качестве примера фиг. 10 иллюстрирует накопитель 1016 на жестком диске для считывания с и записи на несменный энергонезависимый магнитный носитель (не показан), накопитель 1018 на магнитном диске для считывания с и записи на сменный энергонезависимый магнитный диск 1020 (например, "гибкий диск") и накопитель 1022 на оптическом диске для считывания с и/или записи на сменный энергонезависимый оптический диск 1024 типа CD-ROM, DVD-ROM, или другой оптический носитель. Накопитель 1016 на жестком диске, накопитель 1018 на магнитном диске и накопитель 1022 на оптическом диске каждый связаны с системной шиной 1008 одним или более интерфейсом 1025. Альтернативно, накопитель 1016 на жестком диске, накопитель 1018 на магнитном диске и накопитель 1022 на оптическом диске могут быть связаны с системной шиной 1008 одним или более интерфейсами (не показаны).
Накопители и связанные с ними считываемые компьютером носители обеспечивают энергонезависимое хранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 1002. Хотя пример иллюстрирует жесткий диск 1016, сменный магнитный диск 1020 и сменный оптический диск 1024, следует заметить, что другие типы считываемых компьютером носителей, которые могут сохранять данные и которые являются доступными для компьютера, например магнитные кассеты или другие магнитные устройства хранения, карты с флэш-памятью, CD-ROM, цифровые универсальные диски (DVD) или другая оптическая память, память с произвольным доступом (ОЗУ), память только для считывания (ROM), электрически стираемая программируемая память только для считывания (EEPROM) и т.п., могут также использоваться, чтобы осуществить примерную вычислительную систему и среду.
Любое число программных модулей может быть сохранено на жестком диске 1016, магнитном диске 1020, оптическом диске 1024, ROM 1012 и/или RAM 1010, включая в качестве примера, операционную систему 1026, одну или более прикладных программ 1028, другие программные модули 1030 и данные 1032 программ. Каждое из операционной системы 1026, одной или более прикладных программ 1028, других программных модулей 1030 и данных 1032 программы (или некоторой их комбинации) может реализовывать все или часть резидентных компонентов, которые поддерживают распределенную файловую систему.
Пользователь может вводить команды и информацию в компьютер 1002 через устройства ввода данных, такие как клавиатура 1034 и устройство управления позицией 1036 (например, "мышь"). Другие устройства ввода данных 1038 (не показаны конкретно) могут включать в себя микрофон, джойстик, игровую клавиатуру, спутниковую антенну, последовательный порт, сканер и/или подобные устройства. Эти и другие устройства ввода данных связаны с блоком 1004 обработки через интерфейс 1040 ввода/вывода, который соединен с системной шиной 1008, но может быть связан другим интерфейсом и шинными структурами, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB).
Монитор 1042 или другой тип устройства отображения может также быть связан с системной шиной 1008 через интерфейс, например видеоадаптер 1044. В дополнение к монитору 1042 другие периферийные устройства вывода могут включать в себя компоненты, такие как динамики (не показаны) и принтер 1046, который может быть связан с компьютером 1002 через интерфейс 1040 ввода/вывода.
Компьютер 1002 может работать в связанной в сеть среде, используя логические соединения с одним или более удаленными компьютерами, например удаленное вычислительное устройство 1048. В качестве примера удаленным вычислительным устройством 1048 может быть ПК, портативный компьютер, сервер, маршрутизатор, сетевой компьютер, равноправное устройство или другой обычный сетевой узел и т.п. Удаленное вычислительное устройство 1048 иллюстрируется как портативный компьютер, который может включать в себя многие или все элементы и признаки, описанные здесь относительно компьютера 1002. Альтернативно, компьютер 1002 может работать также в несвязанной в сеть среде.
Логические соединения между компьютером 1002 и удаленным компьютером 1048 изображены как локальная сеть (LAN) 1050 и глобальная сеть (WAN) 1052. Такие сетевые среды являются обычными в офисах, компьютерных сетях предприятия, интранет и Интернет.
При реализации в сетевой среде LAN компьютер 1002 связан с локальной сетью 1050 через сетевой интерфейс или адаптер 1054. При реализации в сетевой среде WAN компьютер 1002 обычно включает в себя модем 1056 или другие средства для установления соединения по глобальной сети 1052. Модем 1056, который может быть внутренним или внешним относительно компьютера 1002, может быть связан с системной шиной 1008 через интерфейс 1040 ввода-вывода или другие соответствующие механизмы. Должно быть понятно, что проиллюстрированные сетевые соединения являются примерами и что могут использоваться другие средства установления по меньшей мере одной линии связи между компьютерами 1002 и 1048.
В связанной в сеть среде, такой как проиллюстрирована с вычислительной средой 1000, программные модули, изображенные как относящиеся к компьютеру 1002, или части их могут быть сохранены в удаленном устройстве памяти. В качестве примера, удаленные прикладные программы 1058 хранятся на устройстве памяти удаленного компьютера 1048. С целью иллюстрации прикладные программы или программы и другие выполняемые программные компоненты типа операционной системы проиллюстрированы здесь как дискретные модули, хотя очевидно, что такие программы и компоненты хранятся в различные моменты времени в различных компонентах памяти вычислительного устройства 1002 и выполняются по меньшей мере одним процессором данных компьютера.
Различные модули и способы могут быть описаны здесь в общем контексте выполняемых компьютером команд, таких как программные модули, выполняемых одним или более компьютером или другими устройствами. Обычно программные модули включают в себя подпрограммы, программы, объекты, компоненты, структуры данных и т.д. для выполнения конкретных задач или реализуют конкретные абстрактные типы данных. Эти программные модули и т.п. могут быть выполнены как естественный код или могут быть загружены и выполнены, например в виртуальной машине или другой среде выполнения оперативной компиляции. Как правило, функциональные возможности программных модулей могут быть объединены или распределены как необходимо в различных вариантах осуществления.
Реализации этих модулей и способов могут быть сохранены или переданы посредством некоторой формы считываемых компьютером носителей. Считываемыми компьютером носителями могут быть любые доступные носители, к которым можно обращаться посредством компьютера. В качестве примера, но не ограничения, считываемые компьютером носители может включать в себя "компьютерные носители данных" и "средства связи".
"Компьютерные носители данных" включают в себя энергозависимые и энергонезависимые, сменные и несменные носители, осуществленные любым способом или технологией для хранения информации, например, считываемых компьютером команд, структур данных, программных модулей или других данных. Компьютерные носители данных включают в себя, но не ограничиваются ими, ОЗУ, ПЗУ, EEPROM, флэш-память или память другой технологии, CD-ROM, цифровые универсальные диски (DVD) или другую оптическую память, магнитные кассеты, магнитную ленту, магнитную память на дисках или другие магнитные устройства хранения, или любую другую среду, которая может использоваться для сохранения нужной информации и к которой можно обращаться компьютером.
"Средства связи" обычно реализуют считываемые компьютером команды, структуры данных, программные модули или другие данные в модулируемом сигнале данных, таком как сигнал несущей или другом транспортном механизме. Средства связи также включают в себя любые средства доставки информации. Термин "модулированный сигнал данных" означает сигнал, который имеет один или более из его набора параметров установленным или измененным таким образом, чтобы кодировать информацию в сигнале. Только в качестве неограничивающего примера, средства связи включают в себя проводные носители, типа проводной сети или непосредственного проводного соединения, и беспроводные носители, типа акустического, РЧ, инфракрасного и других беспроводных носителей. Комбинации любых вышеупомянутых также включены в понятие считываемых компьютером носителей.
Повсюду в настоящем описании была сделана ссылка на "один вариант осуществления", "вариант осуществления" или "примерный вариант осуществления", означающий, что конкретно описанный признак, структура или характеристика включена по меньшей мере в один вариант осуществления настоящего изобретения. Таким образом, использование таких фраз может относиться к более чем только одному варианту осуществления. Кроме того, описанные признаки, структуры или характеристики могут быть объединены любым подходящим образом в одном или более вариантов осуществления.
Специалисты могут признать, однако, что изобретение может быть внедрено на практике без одной или более специфических деталей или с другими способами, ресурсами, материалами и т.д. В других случаях известные структуры, ресурсы или операции не показаны или не описаны подробно просто для того, чтобы избежать усложнения аспектов изобретения.
В то время как варианты осуществления примера и применения были проиллюстрированы и описаны, должно быть понято, что изобретение не ограничено точной конфигурацией и ресурсами, описанными выше. Различные модификации, изменения и разновидности, очевидные специалистам, могут быть сделаны в конструкции, операции и деталях способов и систем настоящего изобретения, раскрытого здесь, без отрыва от контекста заявленного изобретения.
Хотя описание выше использует язык, который является специфическим для структурных особенностей и/или методологических действий, должно быть понято, что изобретение, заявленное в прилагаемой формуле изобретения, не ограничено конкретными признаками или описанными действиями. Скорее конкретные признаки и действия раскрыты как примерные формы осуществления изобретения.
Изобретение относится к системам и способам передачи аудиовизуальной информации и данных. Техническим результатом является обеспечение внедрения сообщения описания сеанса в сообщение протокола управления передачей в реальном масштабе времени. Сообщение описания сеанса, которое описывает аудиовизуальное представление, передаваемое в виде потока получателю, внедряется по меньшей мере в некоторые сообщения Протокола Управления передачей в реальном масштабе времени (RTCP), посылаемые от источника контента аудиовизуальной информации получателю. Это сообщение может быть связано, например, с одной из множества частей контента аудиовизуальной информации в списке воспроизведения контента аудиовизуальной информации, который передают в виде потока от устройства получателю. В соответствии с некоторыми аспектами сообщение RTCP, которое внедряет сообщение описания сеанса, содержит по меньшей мере три поля: первое поле, содержащее данные, идентифицирующие сообщение RTCP как относящееся к типу, который внедряет сообщение описания сеанса; второе поле, содержащее данные, которые являются сообщением описания сеанса для мультимедийного представления; и третье поле, содержащее данные, идентифицирующие длину сообщения RTCP, сгенерированного посредством суммирования длины первого, второго и третьего полей. 4 н. и 7 з.п. ф-лы, 20 ил., 3 табл.
1. Считываемый компьютером носитель, содержащий множество считываемых компьютером команд, которые при выполнении вычислительным устройством вынуждают это вычислительное устройство выполнять способ формирования и передачи сообщения описания мультимедийного сеанса, содержащий этапы:
идентифицируют часть контента аудиовизуальной информации, который должен быть передан в виде потока от упомянутого вычислительного устройства на принимающее вычислительное устройство, запрашивающее эту часть контента аудиовизуальной информации;
получают информацию, описывающую идентифицированную часть контента аудиовизуальной информации;
генерируют сообщение Протокола Управления передачей в реальном масштабе времени (RTCP), имеющее полученную информацию об идентифицированной части контента аудиовизуальной информации, при этом сообщение RTCP содержит:
первое поле, содержащее данные, идентифицирующие сообщение RTCP как относящееся к типу сообщения, которое имеет внедренное сообщение описания сеанса;
второе поле, содержащее данные, которые являются сообщением описания сеанса для представления аудиовизуальной информации; причем упомянутое сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), так что информация SDP упомянутого представления аудиовизуальной информации делается доступной клиентскому устройству посредством упомянутого сообщения RTCP без приема клиентом отдельного сообщения описания сеанса SDP;
третье поле, содержащее данные, идентифицирующие длину сообщения RTCP;
четвертое поле, содержащее данные, которые идентифицируют версию RTP (Протокол транспортировки в реальном масштабе времени), используемого для передачи в виде потока представления аудиовизуальной информации;
пятое поле, содержащее данные, идентифицирующие включено ли дополнительное заполнение октетами в сообщение RTCP;
шестое поле, содержащее данные, идентифицирующие были ли данные во втором поле сжаты;
седьмое поле, содержащее данные, идентифицирующие сообщение описания сеанса и адрес отправителя сообщения описания сеанса;
восьмое поле, содержащее данные, идентифицирующие количество блоков RTP-состояния, содержащихся в сообщении RTCP;
девятое поле, содержащее данные, идентифицирующие применяют ли данные в блоке RTP-состояния сообщения RTCP ко всем RTP-пакетам, имеющим конкретный идентификатор потока SDP, или только к RTP-пакетам, имеющим конкретный номер типа полезных данных RTP;
десятое поле, содержащее данные, идентифицирующие номер типа полезных данных RTP для блока RTP-состояния сообщения RTCP;
одиннадцатое поле, содержащее данные, идентифицирующие поток аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
двенадцатое поле, содержащее данные, идентифицирующие источник потока аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
тринадцатое поле, содержащее данные, идентифицирующие значение поля RTP Timestamp, которое имеет RTP-пакет для потока аудиовизуальной информации аудиовизуального представления, если RTP-пакет послан в начале аудиовизуального представления;
четырнадцатое поле, содержащее данные, идентифицирующие значение поля номера RTP последовательности первого RTP-пакета, который послан для потока аудиовизуальной информации аудиовизуального представления;
пятнадцатое поле, содержащее данные, которые указывают, что RTCP сообщение содержит фрагмент сообщения описания сеанса;
шестнадцатое поле, содержащее данные, которые идентифицируют фрагмент;
причем длина сообщения RTCP в третьем поле генерируется посредством суммирования длины первого поля, длины второго поля, длины третьего поля, длины четвертого поля, длины пятого поля, длины шестого поля, длины седьмого поля, длины восьмого поля, длины девятого поля, длины десятого поля, длины одиннадцатого поля, длины двенадцатого поля, длины тринадцатого поля, длины четырнадцатого поля, длины пятнадцатого поля и длины шестнадцатого поля; и
передают RTCP сообщение на принимающее вычислительное устройство.
2. Считываемый компьютером носитель по п.1, в котором представление аудиовизуальной информации содержит мультимедийное представление.
3. Считываемый компьютером носитель по п.1, в котором данные в седьмом поле содержат контрольную сумму, вычисленную по сообщению описания сеанса и адресу отправителя сообщения описания сеанса.
4. Считываемый компьютером носитель, хранящий выполняемые компьютером команды, которые при выполнении одним или более процессорами вычислительного устройства, вынуждают упомянутые один или более процессоров вычислительного устройства выполнять способ приема аудиовизуальной информации с использованием сообщения описания мультимедийного сеанса, содержащий этапы:
принимают от источника контента аудиовизуальной информации сообщение Протокола Управления передачей в реальном масштабе времени (RTCP);
извлекают из этого сообщения RTCP сообщение описания сеанса, связанное с одной из множества частей контента аудиовизуальной информации в списке воспроизведения контента аудиовизуальной информации, передаваемого в виде потока от источника контента аудиовизуальной информации на это устройство, причем упомянутое сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), так что информация SDP об одной из множества частей контента аудиовизуальной информации делается доступной клиенту без приема клиентом отдельного сообщения описания сеанса SDP; и
обрабатывают одну из множества частей контента аудиовизуальной информации, на основании, по меньшей мере частично, упомянутого сообщения описания сеанса, при этом сообщение RTCP содержит:
первое поле, содержащее данные, идентифицирующие сообщение RTCP как относящееся к типу сообщения, которое внедряет сообщение описания сеанса;
второе поле, содержащее данные, которые являются сообщением описания сеанса для представления аудиовизуальной информации; причем упомянутое сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), так что информация SDP этого представления аудиовизуальной информации делается доступной клиентскому устройству посредством упомянутого сообщения RTCP без приема клиентом отдельного сообщения описания сеанса SDP;
третье поле, содержащее данные, идентифицирующие длину сообщения RTCP;
четвертое поле, содержащее данные, которые идентифицируют версию RTP (Протокол транспортировки в реальном масштабе времени), используемого для передачи в виде потока представления аудиовизуальной информации;
пятое поле, содержащее данные, идентифицирующие включено ли в сообщение RTCP дополнительное заполнение октетами;
шестое поле, содержащее данные, идентифицирующие были ли данные во втором поле сжаты;
седьмое поле, содержащее данные, идентифицирующие сообщение описания сеанса и адрес отправителя сообщения описания сеанса;
восьмое поле, содержащее данные, идентифицирующие количество блоков RTP-состояния, содержащихся в сообщении RTCP;
девятое поле, содержащее данные, идентифицирующие применяют ли данные в блоке RTP-состояния сообщения RTCP ко всем RTP-пакетам, имеющим конкретный идентификатор потока SDP, или только к RTP-пакетам, имеющим конкретный номер типа полезных данных RTP;
десятое поле, содержащее данные, идентифицирующие номер типа полезных данных RTP для блока RTP-состояния сообщения RTCP;
одиннадцатое поле, содержащее данные, идентифицирующие поток аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
двенадцатое поле, содержащее данные, идентифицирующие источник потока аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
тринадцатое поле, содержащее данные, идентифицирующие значение поля RTP Timestamp, которое имеет RTP-пакет для потока аудиовизуальной информации аудиовизуального представления, если RTP-пакет послан в начале аудиовизуального представления;
четырнадцатое поле, содержащее данные, идентифицирующие значение поля номера RTP последовательности первого RTP-пакета, который послан для потока аудиовизуальной информации аудиовизуального представления;
пятнадцатое поле, содержащее данные, которые указывают, что RTCP сообщение содержит фрагмент сообщения описания сеанса;
шестнадцатое поле, содержащее данные, которые идентифицируют фрагмент; и
причем длина сообщения RTCP в третьем поле генерируется посредством суммирования длины первого поля, длины второго поля, длины третьего поля, длины четвертого поля, длины пятого поля, длины шестого поля, длины седьмого поля, длины восьмого поля, длины девятого поля, длины десятого поля, длины одиннадцатого поля, длины двенадцатого поля, длины тринадцатого поля, длины четырнадцатого поля, длины пятнадцатого поля и длины шестнадцатого поля.
5. Считываемый компьютером носитель по п.4, в котором сообщение RTCP является частью пакета RTCP.
6. Считываемый компьютером носитель по п.4, в котором способ дополнительно содержит воспроизведение одной из множества частей контента аудиовизуальной информации в устройстве.
7. Считываемый компьютером носитель по п.4, в котором способ дополнительно содержит повторение приема, извлечения и обработки для каждой из других частей контента аудиовизуальной информации во множестве частей контента аудиовизуальной информации.
8. Способ передачи сообщения описания мультимедийного сеанса, при этом способ реализуется в устройстве и содержит этапы:
создают сообщение протокола управления передачей в реальном масштабе времени (RTCP), которое включает в себя сообщение описания сеанса, причем сообщение описания сеанса связано с одной из множества частей контента аудиовизуальной информации в списке воспроизведения контента аудиовизуальной информации, передаваемого в виде потока с устройства на клиентское устройство, и сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), которое содержит информацию SDP об одной из множества частей контента аудиовизуальной информации; и
посылают сообщение RTCP на клиентское устройство, причем информация SDP об одной из множества частей контента аудиовизуальной информации делается доступной на клиентском устройстве без посылки отдельного сообщения описания сеанса SDP от этого устройства; и
при этом сообщение RTCP содержит:
первое поле, содержащее данные, идентифицирующие сообщение RTCP как относящееся к типу сообщения, которое внедряет сообщение описания сеанса;
второе поле, содержащее данные, которые являются сообщением описания сеанса для представления аудиовизуальной информации; причем упомянутое сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), так что информация SDP этого представления аудиовизуальной информации делается доступной клиентскому устройству посредством упомянутого сообщения RTCP без приема клиентом отдельного сообщения описания сеанса SDP;
третье поле, содержащее данные, идентифицирующие длину сообщения RTCP;
четвертое поле, содержащее данные, которые идентифицируют версию RTP (Протокол транспортировки в реальном масштабе времени), используемого для передачи в виде потока представления аудиовизуальной информации;
пятое поле, содержащее данные, идентифицирующие включено ли в сообщение RTCP дополнительное заполнение октетами;
шестое поле, содержащее данные, идентифицирующие были ли данные во втором поле сжаты;
седьмое поле, содержащее данные, идентифицирующие сообщение описания сеанса и адрес отправителя сообщения описания сеанса;
восьмое поле, содержащее данные, идентифицирующие количество блоков RTP-состояния, содержащихся в сообщении RTCP;
девятое поле, содержащее данные, идентифицирующие применяют ли данные в блоке RTP-состояния сообщения RTCP ко всем RTP-пакетам, имеющим конкретный идентификатор потока SDP, или только к RTP-пакетам, имеющим конкретный номер типа полезных данных RTP;
десятое поле, содержащее данные, идентифицирующие номер типа полезных данных RTP для блока RTP-состояния сообщения RTCP;
одиннадцатое поле, содержащее данные, идентифицирующие поток аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
двенадцатое поле, содержащее данные, идентифицирующие источник потока аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
тринадцатое поле, содержащее данные, идентифицирующие значение поля RTP Timestamp, которое будет иметь RTP-пакет для потока аудиовизуальной информации аудиовизуального представления, если RTP-пакет послан в начале аудиовизуального представления;
четырнадцатое поле, содержащее данные, идентифицирующие значение поля номера RTP последовательности первого RTP-пакета, который послан для потока аудиовизуальной информации аудиовизуального представления;
пятнадцатое поле, содержащее данные, которые указывают, что RTCP сообщение содержит фрагмент сообщения описания сеанса;
шестнадцатое поле, содержащее данные, которые идентифицируют фрагмент; и
причем длина сообщения RTCP в третьем поле генерируется посредством суммирования длины первого поля, длины второго поля, длины третьего поля, длины четвертого поля, длины пятого поля, длины шестого поля, длины седьмого поля, длины восьмого поля, длины девятого поля, длины десятого поля, длины одиннадцатого поля, длины двенадцатого поля, длины тринадцатого поля, длины четырнадцатого поля, длины пятнадцатого поля и длины шестнадцатого поля.
9. Способ по п.8, дополнительно содержащий этапы:
создают второе сообщение RTCP, которое включает в себя второе сообщение описания сеанса, при этом второе сообщение описания сеанса связано со второй из множества частей контента аудиовизуальной информации в списке воспроизведения; и
посылают второе сообщение RTCP на клиентское устройство.
10. Способ по п.8, в котором устройство является серверным устройством.
11. Система передачи и приема аудиовизуальной информации с использованием сообщения описания мультимедийного сеанса, содержащая:
серверное устройство;
клиентское устройство;
причем серверное устройство выполнено с возможностью:
создания сообщения Протокола Управления передачей в реальном масштабе времени (RTCP), которое включает в себя сообщение описания сеанса, при этом сообщение описания сеанса связано с одной из множества частей контента аудиовизуальной информации в списке воспроизведения контента аудиовизуальной информации, передаваемого в виде потока с серверного устройства на клиентское устройство; и
сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), которое содержит информацию SDP об одной из множества частей контента аудиовизуальной информации; и
посылают сообщение RTCP на клиентское устройство, причем клиентское устройство выполнено с возможностью:
приема от серверного устройства сообщения RTCP;
извлечения из сообщения RTCP сообщения описания сеанса, при этом информация SDP об одной из множества частей контента аудиовизуальной информации делается доступной на клиентском устройстве без приема клиентом отдельного сообщения описания сеанса SDP от серверного устройства; и
обработки одной из множества частей контента аудиовизуальной информации, на основании, по меньшей мере частично, сообщения описания сеанса,
при этом сообщение RTCP содержит:
первое поле, содержащее данные, идентифицирующие сообщение RTCP как относящееся к типу сообщения, которое внедряет сообщение описания сеанса;
второе поле, содержащее данные, которые являются сообщением описания сеанса для представления аудиовизуальной информации; причем упомянутое сообщение описания сеанса является сообщением описания сеанса согласно Протоколу Описания Сеанса (SDP), так что информация SDP этого представления аудиовизуальной информации делается доступной клиентскому устройству посредством упомянутого сообщения RTCP без приема клиентом отдельного сообщения описания сеанса SDP;
третье поле, содержащее данные, идентифицирующие длину сообщения RTCP;
четвертое поле, содержащее данные, которые идентифицируют версию RTP (Протокол транспортировки в реальном масштабе времени), используемого для передачи в виде потока представления аудиовизуальной информации;
пятое поле, содержащее данные, идентифицирующие включено ли в сообщение RTCP дополнительное заполнение октетами;
шестое поле, содержащее данные, идентифицирующие были ли данные во втором поле сжаты;
седьмое поле, содержащее данные, идентифицирующие сообщение описания сеанса и адрес отправителя сообщения описания сеанса;
восьмое поле, содержащее данные, идентифицирующие количество блоков RTP-состояния, содержащихся в сообщении RTCP;
девятое поле, содержащее данные, идентифицирующие применяют ли данные в блоке RTP-состояния сообщения RTCP ко всем RTP-пакетам, имеющим конкретный идентификатор потока SDP, или только к RTP-пакетам, имеющим конкретный номер типа полезных данных RTP;
десятое поле, содержащее данные, идентифицирующие номер типа полезных данных RTP для блока RTP-состояния сообщения RTCP;
одиннадцатое поле, содержащее данные, идентифицирующие поток аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
двенадцатое поле, содержащее данные, идентифицирующие источник потока аудиовизуальной информации аудиовизуального представления, к которому относится блок RTP-состояния сообщения RTCP;
тринадцатое поле, содержащее данные, идентифицирующие значение поля RTP Timestamp, которое будет иметь RTP-пакет для потока аудиовизуальной информации аудиовизуального представления, если RTP-пакет послан в начале аудиовизуального представления;
четырнадцатое поле, содержащее данные, идентифицирующие значение поля номера RTP последовательности первого RTP-пакета, который послан для потока аудиовизуальной информации аудиовизуального представления;
пятнадцатое поле, содержащее данные, которые указывают, что RTCP сообщение содержит фрагмент сообщения описания сеанса;
шестнадцатое поле, содержащее данные, которые идентифицируют фрагмент; и
причем длина сообщения RTCP в третьем поле генерируется посредством суммирования длины первого поля, длины второго поля, длины третьего поля, длины четвертого поля, длины пятого поля, длины шестого поля, длины седьмого поля, длины восьмого поля, длины девятого поля, длины десятого поля, длины одиннадцатого поля, длины двенадцатого поля, длины тринадцатого поля, длины четырнадцатого поля, длины пятнадцатого поля и длины шестнадцатого поля.
| US 6275471 B1, 14.08.2001 | |||
| Способ и приспособление для нагревания хлебопекарных камер | 1923 |
|
SU2003A1 |
| Топчак-трактор для канатной вспашки | 1923 |
|
SU2002A1 |
| СИСТЕМА И СПОСОБ ДЛЯ ИНТЕГРАЦИИ СООБЩЕНИЯ В ГРАФИЧЕСКУЮ СРЕДУ | 1998 |
|
RU2192040C2 |
