ПЛАВНАЯ ПОТОКОВАЯ ПЕРЕДАЧА КЛИЕНТСКОГО МУЛЬТИМЕДИА БЕЗ ФИКСАЦИИ СОСТОЯНИЯ

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

Потоковое мультимедиа - это мультимедиа, которое постоянно принимается и обычно представляется конечному пользователю (с использованием клиента), в то время как оно доставляется посредством поставщика потоковой передачи (с использованием сервера). Существует несколько протоколов для потокового мультимедиа, включающих в себя протокол потоковой передачи в реальном времени (RTSP), транспортный протокол реального времени (RTP) и протокол управления транспортным уровнем в реальном времени (RTCP), которые приложения потоковой передачи данных зачастую используют совместно. Протокол потоковой передачи в реальном времени (RTSP), разработанный инженерной группой по развитию Интернета (IETF) и созданный в 1998 году в качестве запроса на обсуждение (RFC) 2326, является протоколом для использования в системах потокового мультимедиа, который дает возможность клиенту удаленно управлять сервером потокового мультимедиа, выдавая команды в стиле VCR, к примеру, "воспроизведение" и "пауза", и предоставляя временной доступ к файлам на сервере.

Отправка самих потоковых данных не является частью RTSP-протокола. Большинство RTSP-серверов используют стандартизированный RTP в качестве транспортного протокола для фактических аудиовидеоданных, выступая в определенной степени в качестве канала метаданных. RTP задает стандартизированный формат пакетов для доставки аудио и видео по Интернету. RTP разработан рабочей группой по вопросам транспортировки аудио-видео IETF и сначала опубликован в 1996 году как RFC 1889 и заменен на RFC 3550 в 2003 году. Протокол является аналогичным по синтаксису и работе протоколу передачи гипертекста (HTTP), но RTSP добавляет новые запросы. Хотя HTTP - это протокол без фиксации состояния, RTSP является протоколом с фиксацией состояния. RTSP использует идентификатор сеанса, чтобы отслеживать сеансы при необходимости. RTSP-сообщения отправляются из клиента на сервер, хотя существуют некоторые исключения на то, когда сервер должен отправлять сообщения в клиент.

Приложения потоковой передачи данных обычно используют RTP в сочетании с RTCP. Хотя RTP переносит мультимедийные потоки (например, аудио и видео) или внеполосные служебные сигналы (двухтональный многочастотный набор номера (DTMF)), приложения потоковой передачи данных используют RTCP, чтобы отслеживать статистику передачи и информацию качества обслуживания (QoS). RTP допускает только один тип сообщения, которое переносит данные из источника в точку назначения. Во многих случаях, существует потребность в других сообщениях в сеансе. Эти сообщения управляют потоком и качеством данных и дают возможность получателю отправлять обратную связь в источник или источники. RTCP является протоколом, спроектированным с этой целью. RTCP имеет пять типов сообщений: сообщение отправляющего устройства, сообщение приемного устройства, сообщение описания источника, сообщение завершения и специализированное сообщение. RTCP предоставляет внеполосную управляющую информацию для RTP-потока и взаимодействует с RTP при доставке и пакетировании мультимедийных данных, но не транспортирует сами данные. Приложения потоковой передачи данных используют RTCP, чтобы периодически передавать управляющие пакеты участникам потокового мультимедийного сеанса. Одна функция RTCP состоит в том, чтобы предоставлять обратную связь по качеству обслуживания, которое предоставляет RTP. RTCP собирает статистику по мультимедийному подключению и такую информацию, как "отправлено байтов", "отправлено пакетов", "потеряно пакетов", "дрожание", "обратная связь" и "задержка на передачу и подтверждение приема". Приложение может использовать эту информацию, чтобы повышать качество обслуживания, возможно посредством ограничения потока либо использования другого кодека или скорости передачи битов.

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

Помимо этого, Интернет содержит множество типов загружаемых элементов мультимедийного содержимого, включающих в себя аудио, видео, документы и т.д. Эти элементы содержимого являются зачастую очень большими, к примеру, видео в сотни мегабайтов. Пользователи зачастую извлекают документы по Интернету с использованием HTTP через веб-обозреватель. Интернет создал обширную инфраструктуру из маршрутизаторов и прокси-серверов, которые являются эффективными при кэшировании данных для HTTP. Серверы могут предоставлять кэшированные данные клиентам с меньшей задержкой и посредством использования меньших ресурсов, чем при повторном запрашивании содержимого из первоначального источника. Например, пользователь в Нью-Йорке может загружать элемент содержимого, обслуживаемый из хоста в Японии, и принимать элемент содержимого через маршрутизатор в Калифорнии. Если пользователь в Нью-Джерси запрашивает идентичный файл, маршрутизатор в Калифорнии может иметь возможность предоставлять элемент содержимого без повторного запрашивания данных из хоста в Японии. Это уменьшает сетевой трафик по возможно загруженным маршрутам и дает возможность пользователю в Нью-Джерси принимать элемент содержимого с меньшим временем задержки.

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

Сущность изобретения

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

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

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

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

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

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

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

Подробное описание изобретения

В данном документе описана система адаптивной потоковой передачи, которая предоставляет соединение без фиксации состояния между клиентом и сервером для воспроизведения потокового мультимедиа, в котором данные форматируются таким способом, который дает возможность клиенту принимать решения, возлагаемые на сервер в предыдущих протоколах, и, следовательно, реагировать более быстро на изменяющиеся характеристики сети. Помимо этого, система адаптивной потоковой передачи работает таким способом, который дает возможность существующей инфраструктуре Интернет-кэширования кэшировать потоковые мультимедийные данные, тем самым давая возможность большему числу клиентов просматривать идентичное содержимое приблизительно одновременно. Система адаптивной потоковой передачи запрашивает части мультимедийного файла или передаваемого вживую потокового события в порциях небольшого размера, имеющих отличающийся URL-адрес. Каждая порция может быть отдельным мультимедийным файлом или может быть частью целого мультимедийного файла. По мере того, как событие проходит, клиент продолжает запрашивать порции до конца события. Каждая порция содержит информацию метаданных, которая описывает кодирование порции и мультимедийного содержимого для воспроизведения посредством клиента. Сервер может предоставлять порции в нескольких кодировках, так что клиент, например, может быстро переключаться на порции с другой скоростью передачи битов или скоростью воспроизведения. Поскольку порции соответствуют HTTP-стандартам Консорциума по разработке и распространению стандартов и протоколов для WWW-систем (W3C), порции являются достаточно небольшими, чтобы кэшироваться, и система предоставляет порции аналогичным образом в каждого клиента, порции естественно кэшируются посредством существующей Интернет-инфраструктуры без модификации. Таким образом, система адаптивной потоковой передачи предоставляет улучшенное взаимодействие с пользователем с меньшим числом перерывов при воспроизведении потокового мультимедиа и повышенной вероятностью того, что клиент принимает мультимедиа с меньшем временем задержки из более локального сервера кэширования. Поскольку соединение между клиентом и сервером является соединением без фиксации состояния, идентичный клиент и сервер не должны быть соединены в течение длительности длинного события. Система без фиксации состояния, описанная в данном документе, вообще не имеет сходства с сервером, давая возможность клиентам объединять манифесты из серверов, которые, возможно, были начаты в разное время, а также давая возможность администраторам сервера активировать или завершать работу исходных серверов согласно тому, что диктует нагрузка.

В некоторых вариантах осуществления, система адаптивной потоковой передачи использует новый формат передачи данных между сервером и клиентом. Клиент запрашивает порции мультимедиа из сервера, которые включают в себя часть мультимедиа. Например, для 10-минутного файла, клиент может запрашивать 2-секундные порции. Следует отметить, что в отличие от типичной потоковой передачи, при которой сервер проталкивает данные в клиента, в этом случае клиент извлекает порции мультимедиа из сервера. В случае передаваемого вживую потока сервер может создавать мультимедиа "на лету" и формировать порции, чтобы отвечать на клиентские запросы. Таким образом, клиент может отставать от сервера только на несколько порций с точки зрения того, насколько быстро сервер создает порции и насколько быстро клиент запрашивает порции.

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

Фиг.1 является блок-схемой, которая иллюстрирует компоненты системы адаптивной потоковой передачи в одном варианте осуществления. Система 100 адаптивной потоковой передачи включает в себя компонент 110 запросов порций, компонент 120 синтаксического анализа порций, компонент 130 ассемблирования манифестов, компонент 140 воспроизведения мультимедиа, компонент 150 мониторинга QoS и компонент 160 тактовой синхронизации. Каждый из этих компонентов описывается подробнее в данном документе. Система 100 адаптивной потоковой передачи, как описано в данном документе, работает главным образом в клиентской компьютерной системе. Тем не менее, специалисты в данной области техники должны понимать, что различные компоненты системы могут быть размещены в различных местоположениях в сетевом окружении содержимого, чтобы предоставлять конкретные положительные результаты.

Компонент 110 запросов порций выполняет запросы из клиента на предмет отдельных порций мультимедиа из сервера. Как показано на фиг.2, клиентский запрос может передаваться сначала на граничный сервер (например, Интернет-кэш), затем на исходный сервер и затем на принимающий сервер. На каждой стадии, если запрашиваемые данные обнаружены, то запрос не поступает на следующий уровень. Например, если граничный сервер имеет запрашиваемые данные, то клиент принимает данные из граничного сервера, и исходный сервер не принимает запрос. Каждая порция может иметь универсальный указатель ресурса (URL), который индивидуально идентифицирует порцию. Серверы Интернет-кэширования способны кэшировать ответы сервера на конкретные URL-запросы (например, HTTP GET). Таким образом, когда первый клиент осуществляет вызов сервера, чтобы получать порцию, граничные серверы кэшируют эту порцию, и последующие клиенты, которые запрашивают идентичную порцию, могут принимать порцию из граничного сервера (на основе настроек продолжительности существования кэша и серверного времени существования (TTL)). Компонент 110 запросов порций принимает порцию и передает ее в компонент 120 синтаксического анализа порций для интерпретации.

Компонент 120 синтаксического анализа порций интерпретирует формат порции мультимедиа, принимаемой посредством компонента 110 запросов порций, и разделяет порцию на составные части. Типично, порция включает в себя часть заголовка, содержащую метаданные, и часть данных, содержащую мультимедийное содержимое. Компонент синтаксического анализа порций предоставляет метаданные в компонент 130 ассемблирования манифестов и мультимедийное содержимое в компонент 140 воспроизведения мультимедиа.

Компонент 130 ассемблирования манифестов ассемблирует манифест, который описывает мультимедийный элемент, которому принадлежит принимаемое мультимедийное содержимое. Большие мультимедийные файлы, которые клиенты загружают как единое целое (т.е. не передаваемые потоком), зачастую включают в себя манифест, описывающий весь файл, кодеки и скорости передачи битов, используемые для того, чтобы кодировать различные части файла, маркеры значимых положений в файле и т.д. Во время потоковой передачи, в частности, передаваемого вживую содержимого, сервер не может предоставлять готовый манифест, поскольку событие по-прежнему продолжается. Таким образом, сервер предоставляет максимально возможно большую часть манифеста через метаданные в порциях мультимедиа. Сервер также может предоставлять интерфейс прикладного программирования (API), к примеру, предварительно заданный URL-адрес, для клиента, чтобы запрашивать манифест до текущей точки в мультимедийном потоке. Это может быть полезным, когда клиент присоединяется к передаваемому вживую и потоком событию после того, как событие уже происходит. Манифест дает возможность клиенту запрашивать ранее переданные потоком части мультимедийного элемента (например, посредством перемотки обратно), и клиент продолжает принимать новые части манифеста через метаданные порций передаваемого в потоке мультимедиа.

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

Компонент 140 воспроизведения мультимедиа воспроизводит принимаемое мультимедийное содержимое с использованием клиентских аппаратных средств. Компонент 140 воспроизведения мультимедиа может активировать один или более кодеков, чтобы интерпретировать контейнер, в котором транспортируется мультимедийное содержимое, и распаковывать или иным образом декодировать мультимедийное содержимое из сжатого формата в исходный формат (например, YV12, RGBA или PCM-аудиовыборки), готовый к воспроизведению. Компонент 140 воспроизведения мультимедиа затем может предоставлять мультимедийное содержимое в исходном формате в API операционной системы (например, Microsoft DirectX) для воспроизведения на аппаратных средствах воспроизведения звука и видео локальной компьютерной системы, к примеру, на дисплее и динамиках.

Компонент 150 мониторинга QoS анализирует успешность приема пакетов из сервера и адаптирует клиентские запросы на основе набора текущей сети и других состояний. Например, если клиент обычно принимает порции приема мультимедиа с запозданием, то компонент 150 может определять то, что полоса пропускания между клиентом и сервером является недостаточной для текущей скорости передачи битов, и клиент может начинать запрашивать порции мультимедиа на меньшей скорости передачи битов. Мониторинг QoS может включать в себя измерение другой эвристики, к примеру, частоты кадров при рендеринге, размера окна, размера буфера, частоты повторной буферизации и т.д. Порции мультимедиа для каждой скорости передачи битов могут иметь отличающийся URL-адрес так, что порции для различных скоростей передачи битов кэшируются посредством инфраструктуры Интернет-кэширования. Следует отметить, что сервер не отслеживает состояние клиента и не знает, на какой скорости передачи битов любой конкретный клиент в настоящее время воспроизводит. Сервер может просто предоставлять идентичный мультимедийный элемент на множестве скоростей передачи битов, чтобы удовлетворять потенциальным клиентским запросам в диапазоне состояний. Помимо этого, начальный манифест и/или метаданные, которые принимает клиент, могут включать в себя информацию о скоростях передачи битов и других свойствах кодирования, доступную из сервера, так что клиент может выбирать кодирование, которое предоставляет хорошее взаимодействие с клиентом.

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

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

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

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

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

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

Фиг.2 является блок-схемой, которая иллюстрирует операционное окружение системы плавной потоковой передачи с использованием Microsoft Windows и IIS в одном варианте осуществления. Окружение типично включает в себя исходный клиент 210, сеть 240 доставки содержимого и внешнюю сеть 270. Исходный клиент является источником мультимедийного или передаваемого вживую события. Исходный клиент включает в себя источник 220 мультимедиа и один или более кодеров 230. Источник 220 мультимедиа может включать в себя камеры, каждая из которых предоставляет несколько ракурсов камеры, микрофоны захватывают аудио, слайдовые презентации, текст (к примеру, из службы скрытых субтитров), изображения и другие типы мультимедиа. Кодеры 230 кодируют данные из источника 220 мультимедиа в одном или более форматов кодирования параллельно. Например, кодеры 230 могут формировать кодированное мультимедиа на множестве скоростей передачи битов.

Сеть 240 доставки содержимого включает в себя один или более принимающих серверов 250 и один или более исходных серверов 260. Принимающие серверы 250 принимают кодированное мультимедиа в каждом из форматов кодирования из кодеров 230 и создают манифест, описывающий кодированное мультимедиа. Принимающие серверы 250 могут создавать и сохранять порции мультимедиа, описанные в данном документе, или могут создавать порции "на лету" по мере того, как они запрашиваются. Принимающие серверы 250 могут принимать проталкиваемые данные, к примеру, через HTTPPOST, из кодеров 230 или через извлечение посредством запрашивания данных из кодеров 230. Кодеры 230 и принимающие серверы 250 могут соединяться во множестве конфигураций с резервированием. Например, каждый кодер может отправлять кодированные мультимедийные данные в каждый из принимающих серверов 250 или только в один принимающий сервер до тех пор, пока не возникает сбой. Исходные серверы 260 являются серверами, которые отвечают на клиентские запросы на предмет порций мультимедиа. Исходные серверы 260 также могут конфигурироваться во множестве конфигураций с резервированием.

Внешняя сеть 270 включает в себя граничные серверы 280 и другую Интернет- (или другую сетевую) инфраструктуру и клиенты 290. Когда клиент выполняет запрос на предмет порции мультимедиа, клиент адресует запрос на исходные серверы 260. Вследствие схемы сетевого кэширования, если один из граничных серверов 280 содержит данные, то этот граничный сервер может отвечать клиенту без передачи запроса. Тем не менее, если данные не доступны в граничном сервере, то граничный сервер передает запрос в один из исходных серверов 260. Аналогично, если один из исходных серверов 260 принимает запрос на данные, которые не доступны, исходный сервер может запрашивать данные из одного из принимающих серверов 250.

Фиг.3 является блок-схемой последовательности операций способа, которая иллюстрирует обработку системы адаптивной потоковой передачи на клиенте, чтобы воспроизводить мультимедиа, в одном варианте осуществления. Сначала на этапе 310, система выбирает начальное кодирование, при котором можно запрашивать кодированное мультимедиа из сервера. Например, система может первоначально выбирать наименьшую доступную скорость передачи. Система, возможно, ранее отправила запрос на сервер, чтобы обнаруживать доступные скорости передачи и другие доступные кодировки. Далее на этапе 320, система запрашивает и воспроизводит конкретную порцию мультимедиа, как описано дополнительно со ссылкой на фиг.4. Далее на этапе 330, система определяет показатель качества обслуживания на основе запрашиваемой порции. Например, порция может включать в себя метаданные для стольких порций, сколько сервер в настоящее время сохраняет, которые клиент может использовать для того, чтобы определять то, насколько быстро клиент запрашивает порции относительно того, насколько быстро сервер формирует порции. Этот процесс описывается подробнее в данном документе.

Далее на этапе 340 принятия решения, если система определяет то, что текущий показатель QoS является слишком низким, и соединение клиента с сервером не может обрабатывать текущее кодирование, затем система переходит к этапу 350, иначе система возвращается к этапу 320, чтобы обрабатывать следующую порцию. Далее на этапе 350, система выбирает другое кодирование мультимедиа, при этом система выбирает другое кодирование посредством запрашивания данных из другого URL-адреса на предмет последующих порций из сервера. Например, система может выбирать кодирование, которое использует половину полосы пропускания текущего кодирования. Аналогично, система может определять то, что показатель QoS указывает, что клиент может обрабатывать кодирование на более высокой скорости передачи битов, и клиент может запрашивать более высокую скорость передачи битов для последующих порций. Таким образом, клиент регулирует скорость передачи битов на предмет повышения и понижения на основе текущего состояния.

Несмотря на то, что фиг.3 иллюстрирует определение QoS как осуществляемое после каждой порции, специалисты в данной области техники должны распознавать, что другие реализации QoS являются общераспространенными, к примеру, ожидание фиксированного числа пакетов или порций (например, каждого 10-го пакета), чтобы выполнять определение QoS. После этапа 350, система возвращается к этапу 320, чтобы обрабатывать следующую порцию, если она доступна, или завершает выполнение, если дополнительное мультимедиа недоступно (не показано).

Фиг.4 является блок-схемой последовательности операций способа, которая иллюстрирует обработку системы адаптивной потоковой передачи, чтобы обрабатывать одну порцию мультимедиа, в одном варианте осуществления. Далее на этапе 410, система отправляет запрос на порцию из клиента на сервер по сети на основе выбранной начальной скорости передачи битов. Например, система может выбирать конкретный URL-адрес, по которому можно запрашивать данные, на основе выбранного кодирования (например, http://server/a.isml/quality/bitrate). Далее на этапе 420, система принимает запрашиваемую порцию в клиенте. Система может принимать порцию из сервера или из кэша между сервером и клиентом в сети. Далее на этапе 430, система синтаксически разбирает порцию на часть метаданных и часть мультимедийных данных. Например, каждая порция может содержать метаданные, которые описывают кодирование порции, и мультимедийные данные, подходящие для воспроизведения с использованием кодека и надлежащих аппаратных средств.

Далее на этапе 440, система добавляет метаданные порции в действующий мультимедийный манифест, который описывает информацию о большем мультимедийном элементе, которому принадлежит каждая из порций мультимедийных данных. Например, система может сохранять манифест в запоминающем устройстве, который содержит метаданные из каждой порции мультимедийного файла. Далее на этапе 450, система воспроизводит мультимедийные данные с использованием кодека, идентифицированного посредством метаданных порции и аппаратных средств клиента. Мультимедийные данные могут включать в себя видео, аудио и другие типы данных, которые система воспроизводит на аппаратных средствах, включающих в себя дисплей, динамики и т.д. Альтернативно или дополнительно, данные могут включать в себя неаудиовизуальные данные (например, текст), которые используются некоторым отличным от воспроизведения способом, при этом система обрабатывает данные на основе типа данных. После этапа 450, эти этапы завершаются.

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

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

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

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

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

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

В некоторых вариантах осуществления, система адаптивной потоковой передачи предоставляет клиентскую логику для переключения на потоки с различной скоростью воспроизведения (например, быстрое проигрывание мультимедиа), предоставленные посредством сервера. Например, сервер может включать в себя 2X, 5X, 0,5X и другие скорости воспроизведения. Клиент может переключаться на поток с другой скоростью, чтобы предоставлять пользователю видимость того, что мультимедиа ускоренно перематывается вперед (например, 2X) или перематывается назад (например, 0,5X). Чтобы переключаться, клиент просто запрашивает другую порцию мультимедиа, например, по другому URL-адресу. Клиент может плавно переключаться между воспроизведением порций на текущей скорости и воспроизведением порций на другой скорости посредством продолжения воспроизведения конкретных порций, которые принимаются. Это предоставляет прозрачное взаимодействие для конечного пользователя с небольшим временем задержки между запросом пользователя и изменением при воспроизведении мультимедиа. Это также экономит полосу пропускания сети, поскольку клиент не загружает, например, 2 раза данные, чтобы воспроизводить мультимедиа в два раза быстрее, а вместо этого загружает кодирование с уменьшенным размером мультимедиа, которое кодировано на более высокой скорости.

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

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

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

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

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

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