Плавная потоковая передача клиентского мультимедиа без фиксации состояния

Плавная потоковая передача клиентского мультимедиа без фиксации состояния

Иллюстрации

Показать все

Реферат

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

Потоковое мультимедиа - это мультимедиа, которое постоянно принимается и обычно представляется конечному пользователю (с использованием клиента), в то время как оно доставляется посредством поставщика потоковой передачи (с использованием сервера). Существует несколько протоколов для потокового мультимедиа, включающих в себя протокол потоковой передачи в реальном времени (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. Система адаптивной потоковой передачи включает в себя клиентские элементы управления, чтобы отвечать на действия пользователя и управлять воспроизведени