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

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

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНЫЕ ССЫЛКИ К СВЯЗАННЫМ ЗАЯВКАМ

[0001] Настоящая заявка является не предварительной заявкой на патент, испрашивающая приоритет следующих предварительных заявок, каждая на имя Michael G. Luby, и др. и каждая названная "Enhanced Block-Request Streaming System":

[0002] Предварительная заявка на патент США №61/244767, поданный 22 сентября 2009,

[0003] Предварительная заявка на патент США №61/257719, поданный 3 ноября 2009,

[0004] Предварительная заявка на патент США №61/258088, поданный 4 ноября 2009,

[0005] Предварительная заявка на патент США №61/285779, поданный 11 декабря 2009, и

[0006] Предварительная заявка на патент США №61/296725, поданный 20 января 2010.

[0009] Патент США Номер 6 307 487, Luby (в дальнейшем "Luby I");

[0010] Патент США Номер 7 068 729 к Shokrollahi, и др. (в дальнейшем "Shokrollahi I ");

[0011] Заявка на патент США № 11/423391 поданная 9 июня 2006 и названная "Forward Error-Correcting (FEC) Coding and Streaming" на имя Luby, и др. (в дальнейшем "Luby, II);

[0012] Заявка на патент США № 12/103605 поданная 15 апреля 2008, названная "Dynamic Stream Interleaving and Sub-Stream Based Delivery" на имя Luby, и др. (в дальнейшем "Luby III");

[0013] Заявка на патент США №12/705202 поданная 12 февраля 2010, названная "Block Partitioning for a Data Stream", на имя Pakzad, и др. (в дальнейшем "Pakzad"); и

[0014] Заявка на патент США №12/859161, поданная 18 августа 2010, названная "Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" на имя Luby, и др. (в дальнейшем "Luby IV").

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

[0015] Настоящее изобретение относится к усовершенствованным системам потоковой передачи мультимедиа и способам, более конкретно - к системам и способам, которые адаптированы к условиям сети и буферов, чтобы оптимизировать представление переданного в виде потока мультимедиа, и обеспечивают эффективную одновременную, или распределенную во времени, доставку переданных в виде потока данных мультимедиа.

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

[0016] Доставка потокового мультимедиа может стать все более и более важной, поскольку она становится более распространенной для высококачественного аудио и видео, которое должно быть доставлено на основании сети пакетной передачи, такой как Интернет, сотовые и беспроводные сети, сети электропитания, и другие типы сетей. Качество, с которым может быть представлено доставленное потоковое мультимедиа, может зависеть от ряда факторов, включая разрешение (или другие атрибуты) первоначального контента, качество кодирования первоначального контента, способностей устройств приема декодировать и представить мультимедиа, своевременность и качество сигнала, принятого в приемниках, и т.д. Чтобы создать опыт воспринятого хорошего потокового мультимедиа, транспортировка и своевременность сигнала, принятого в приемниках, могут быть особенно важными. Хорошая транспортировка может обеспечить точность потока, принятого в приемнике, относительно того, что посылает отправитель, в то время как своевременность может представить, как быстро приемник может начать воспроизведение контента после начального запроса этого контента.

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

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

[0019] Традиционно системы доставки мультимедиа могут быть охарактеризованы или как модель "загрузки" или как модель "потоковой передачи". Модель "загрузки" может быть охарактеризована посредством независимости тактирования между доставкой данных мультимедиа и проигрыванием мультимедиа на устройстве пользователя или получателя.

[0020] Как пример, мультимедиа загружается достаточно заранее перед тем, когда оно необходимо или будет использоваться, и когда оно используется, столько сколько необходимо уже доступно в получателе. Доставка в контексте загрузки часто выполняется, используя протокол транспортировки файлов, такой как HTTP, FTP или Доставка Файла по Однонаправленному Транспортному каналу (FLUTE), и скорость доставки может быть определена лежащим в основе потоком и/или протоколом управления перегрузкой, таким как TCP/IP. Работа потока или протокола управления перегрузкой может быть независимой от проигрывания мультимедиа пользователю или устройству назначения, которое может иметь место одновременно с загрузкой или в некоторое другое время.

[0021] Режим "потоковой передачи" может быть охарактеризован тесным соединением между синхронизацией доставки данных мультимедиа и проигрыванием мультимедиа на устройстве пользователя или получателя. Доставка в этом контексте часто выполняется, используя протокол потоковой передачи, такой как Протокол потоковой передачи, в реальном времени (RTSP) для управления и Транспортный Протокол в реальном времени (RTP) для данных мультимедиа. Скорость доставки может быть определена сервером потоковой передачи, часто соответствуя скорости проигрывания данных.

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

[0023] Преимущество модели "загрузки" может состоять в том, что эта технология, которая должна выполнить такие загрузки, например HTTP, хорошо разработана, широко развернута и применима в широком диапазоне применений. Серверы загрузки и решений, предназначенных для массивной масштабируемости таких загрузок файлов (например, HTTP Web Серверы и Сети доставки контента) могут быть легко доступными, делая развертывание услуг, основанных на этой технологии, простым и низким по стоимости.

[0024] Некоторые неудобства модели "потоковой передачи" могут быть теми, что обычно скорость передачи доставки данных мультимедиа не приспособлена к доступной полосе частот в соединении от сервера к клиенту, и что требуются специализированные серверы потоковой передачи или более сложная архитектура сети, обеспечивающая полосу пропускания и гарантии задержки. Хотя существуют системы потоковой передачи, которые поддерживают изменение скорости передачи данных доставки согласно доступной полосе частот (например, Adobe Flash Adaptive Streaming), они обычно не столь эффективны как протоколы управления транспортными потоками загрузки, такие как TCP, при использовании всей доступной полосы частот.

[0025] Недавно, были развиты и развернуты новые системы доставки мультимедиа на основании комбинации моделей "потоковой передачи" и "загрузки". Пример такой модели, упомянут здесь как модель "потоковой передачи с запросом блоков", в которой клиент мультимедиа запрашивает блоки данных мультимедиа от обслуживающей инфраструктуры, используя протокол загрузки, такой как HTTP. Проблемой в таких системах может быть способность начать воспроизведение потока, например, декодирование и воспроизведение принятых аудио и видео потоков, используя персональный компьютер и отображение видео на экране компьютера и проигрывание аудио через встроенные громкоговорители, или, в качестве другого примера, декодирование и воспроизведение принятых аудио и видео потоков, используя телевизионную приставку и отображение видео на телевизионном устройстве отображения и проигрывание аудио через систему стерео.

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

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

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

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

[0029] Нижеследующее подробное описание вместе с сопровождающими чертежами обеспечит лучшее понимание существа и преимуществ настоящего изобретения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0030] Фиг. 1 изображает элементы системы потоковой передачи с запросом блоков согласно вариантам осуществления настоящего изобретения.

[0031] Фиг. 2 иллюстрирует систему потоковой передачи с запросом блоков согласно Фиг. 1, показывая большие подробности в элементах клиентской системы, которая подсоединена к инфраструктуре обслуживания блоков ("BSI"), чтобы принять данные, которые обработаны системой потребления контента.

[0032] Фиг. 3 иллюстрирует реализацию аппаратного обеспечения / программного обеспечения системы потребления.

[0033] Фиг. 4 иллюстрирует реализацию аппаратного обеспечения/программного обеспечения клиентской системы.

[0034] Фиг. 5 иллюстрирует возможные структуры хранилища контента, показанного на Фиг. 1, включая сегменты и файлы дескриптора представления мультимедиа ("MPD"), и разбиение сегментов, тактирование и другую структуру в файле MPD.

[0035] Фиг. 6 иллюстрирует подробности типичного исходного сегмента, который может быть сохранен в хранилище контента, проиллюстрированном на Фиг. 1 и 5.

[0036] Фиг. 7a и 7b иллюстрируют простую и иерархическую индексацию в пределах файлов.

[0037] Фиг. 8(a) иллюстрирует переменный размер блока с выровненными точками поиска по множеству версий потока мультимедиа.

[0038] Фиг. 8 (b) иллюстрирует переменный размер блока с не выровненными точками поиска по множеству версий потока мультимедиа.

[0039] Фиг. 9 (a) иллюстрирует таблицу метаданных.

[0040] Фиг. 9 (b) иллюстрирует передачу блоков и таблицы метаданных от сервера к клиенту.

[0041] Фиг.10 иллюстрирует блоки, которые являются независимыми от границ RAP.

[0042] Фиг. 11 иллюстрирует непрерывное и прерывающееся тактирование по сегментам.

[0043] Фиг. 12 является чертежом, показывающим аспекты масштабируемых блоков.

[0044] Фиг. 13 является графическим представлением развития (эволюции) некоторых переменных в системе потоковой передачи с запросом блоков в течение времени.

[0045] Фиг. 14 изображает другое графическое представление развития некоторых переменных в системе потоковой передачи с запросом блоков в течение времени.

[0046] Фиг. 15 изображает сетку состояний ячеек как функцию пороговых значений.

[0047] Фиг. 16 является последовательностью операций процесса, который может быть выполнен в приемнике, который может запрашивать одиночные блоки и множественные блоки в каждом запросе.

[0048] Фиг. 17 является последовательностью операций гибкого конвейерного процесса.

[0049] Фиг. 18 иллюстрирует пример набора запросов-кандидатов, их приоритетов, и на какие соединения они могут быть выданы, в некоторое время.

[0050] Фиг. 19 иллюстрирует пример набора запросов-кандидатов, их приоритетов, и на какие соединения они могут быть выданы, который изменяется от одного момента времени к другому.

[0051] Фиг. 20 является последовательностью операций последовательного кэширования выбора прокси-сервера на основании идентификатора файла.

[0052] Фиг. 21 иллюстрирует определение синтаксиса для подходящего языка выражения.

[0053] Фиг. 22 иллюстрирует пример подходящей хэш-функции.

[0054] Фиг. 23 иллюстрирует примеры правил построения идентификатора файла.

[0055] Фиг. 24 (a)-(e) иллюстрируют флуктуации полосы пропускания TCP-соединений.

[0056] Фиг. 25 иллюстрирует множественные HTTP-запросы в отношении исходных и исправленных данных.

[0057] Фиг. 26 иллюстрирует время переключения канала с и без FEC.

[0058] Фиг. 27 иллюстрирует подробности генератора исправленного сегмента, который в качестве части системы потребления, показанной на Фиг. 1, генерирует исправленные сегменты из исходных сегментов и параметров управления.

[0059] Фиг. 28 иллюстрирует соотношения между исходными блоками и исправленными блоками.

[0060] Фиг. 29 иллюстрирует процедуру для услуг в реальном времени в разное время в клиенте.

[0061] На чертежах аналогичные элементы обозначены аналогичными номерами, и подиндексы предоставлены в круглых скобках, чтобы указать множественные случаи аналогичных или идентичных пунктов. Если иначе не указано, оконечный подиндекс (например, "N" или "М") не предназначен, чтобы ограничиваться каким-либо конкретным значением, и количество экземпляров одного элемента может отличаться от количества экземпляров другого элемента, даже когда одно и то же количество проиллюстрировано, и подиндекс использован снова.

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

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

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

ПОТОКОВАЯ ПЕРЕДАЧА HTTP

[0064] Потоковая передача HTTP является специфическим типом передачи в виде потока. С потоковой передачей HTTP источники могут быть стандартными web-серверами и сетями доставки контента (CDN) и могут использовать стандартный HTTP. Этот метод может вовлекать сегментацию потока и использование множественных потоков, все - в пределах контекста стандартизированных запросов HTTP. Мультимедиа, такое как видео, может быть закодированным при множестве скоростей передачи в битах, чтобы сформировать различные версии, или представления. Термины "версия" и "представление" использованы синонимично в этом документе. Каждая версия или представление могут быть разбиты на меньшие части, возможно, порядка нескольких секунд каждая, чтобы сформировать сегменты. Каждый сегмент может быть, затем сохранен на web-сервере или CDN как отдельный файл.

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

[0066] Преимущества потоковой передачи HTTP могут включать в себя адаптацию скорости передачи в битах, быстрый запуск и поиск, и минимальная не являющаяся необходимой доставка. Эти преимущества исходят из управления доставкой, чтобы быть только коротким временем перед проигрыванием, создавая максимальное использование доступной полосы частот (посредством мультимедиа с переменной скоростью передачи битов), и оптимизацию сегментации потока и интеллектуальных клиентских процедур.

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

[0068] В некоторых вариантах осуществления описание представления мультимедиа может быть статическим, хотя сегменты могут быть созданы динамически. Описание представления мультимедиа может быть настолько компактным, насколько это возможно, чтобы минимизировать доступ и время загрузки для обслуживания. Другая возможность соединения выделенного сервера может быть минимизирована, например, регулярная или частая синхронизация тактирования между клиентом и сервером.

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

[0070] Описание представления мультимедиа может также разрешить гибкость развертывания и компактность согласно требованиям.

[0071] В самом простом случае каждое Альтернативное Представление может быть сохранено в единственном 3GP файле, то есть, файле, соответствующем тому, что определено в 3GPP TS26.244, или любом другом файле, который соответствует базовому формату файла мультимедиа ISO, как определено в ISO/IEC 14496-12 или последующих спецификациях (такой как формат файла 3GP, описанный в 3GPP Technical Specification 26.244). В оставшейся части этого документа при упоминании 3GP файла должно быть понятно, что ISO/IEC 14496-12 и полученные на его основе спецификации могут отобразить все описанные особенности на более общий формат файла мультимедиа на основе ISO, как определено в ISO/IEC 14496-12 или любых полученных на его основе спецификациях. Клиент может затем запросить начальную часть файла, чтобы изучить метаданные мультимедиа (которые обычно хранятся в поле заголовка Movie (Кинофильм), также называемое полем "moov"), вместе с моментами времени фрагмента кино и смещениями в байтах. Клиент может затем выдать запросы получить частичный HTTP, чтобы получить фрагменты кино, как требуется.

[0072] В некоторых вариантах осуществления может быть желательно, разделить каждое представление на несколько сегментов, где сегменты. В случае если формат сегмента основан на формате 3GP файла, то сегменты содержат не накладывающиеся интервалы времени фрагментов кино, названных "временным разделением". Каждый из этих сегментов может содержать множественные фрагменты кино, и каждый может быть действительным 3GP файлом в его собственной правильности. В другом варианте осуществления представление разделяется на начальный сегмент, содержащий метаданные (обычно поле Заголовок Кино "moov") и ряд сегментов мультимедиа, каждый содержащий данные мультимедиа, и конкатенация начального сегмента и любого сегмента мультимедиа формирует действительный 3GP файл, так же как и конкатенация начального сегмента и всех сегментов мультимедиа одного представления формирует действительный 3GP файл. Полное представление может быть сформировано посредством проигрывания каждого сегмента в его очередь, отображение локальных отметок времени в пределах файла на глобальное время представления согласно начальному времени каждого представления.

[0073] Нужно отметить, что повсюду в этом описании ссылки на "сегмент" должна пониматься как включающая в себя любой объект данных, который полностью или частично построен или считан с носителя данных или иначе получен в результате запроса протокола загрузки файла, включая, например, запрос HTTP. Например, в случае HTTP объекты данных могут храниться в фактических файлах, постоянно находящихся на диске или другом носителе данных, соединенном с или являющемся частью сервера HTTP, или объекты данных могут быть построены с помощью CGI сценария или другой динамически выполняемой программой, которая выполняется в ответ на запрос HTTP. Термины "файл" и "сегмент" использованы синонимично в этом документе, если иначе не определено. В случае HTTP сегмент можно рассмотреть как тело объекта ответа на запрос HTTP.

[0074] Термины "представление" и "элемент контента" использованы синонимично в этом документе. Во многих примерах представлением является аудио, видео или другое мультимедийное представление, которое имеет определенное время "проигрывания", но возможны другие изменения.

[0075] Термины "блок" и "фрагмент" используются синонимично в этом документе, если иначе не определено, и обычно относятся к наименьшей агрегации данных, которые индексированы. На основании доступной индексации клиент может запрашивать различные части фрагмента в различных запросах HTTP или может запрашивать один или более последовательных фрагментов или частей фрагментов в одном запросе HTTP. В случае, когда используются сегменты, основанные на формате файла мультимедиа на основе ISO, или сегменты, основанные на формате 3GP файла, фрагмент обычно относится к фрагменту кино, определенному как комбинация поля ('moof) заголовка фрагмента кино и поля ('mdat') данных мультимедиа.

[0076] Здесь, сеть, несущая данные, как предполагается, основана на пакетной передаче, чтобы упростить описание здесь, с признанием, что после прочтения этого раскрытия специалист в данной области техники может применить варианты осуществления настоящего изобретения, описанного здесь, к другим типам сетей передачи, таким как сети с непрерывным потоком битов.

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

[0078] В этом описании, чтобы упростить описания, предполагается, что FEC применяется к "блоку" или "фрагменту" данных один раз, то есть, "блок" является "исходным блоком" для целей кодирования и декодирования с FEC. Клиентское устройство может использовать индексацию сегментов, описанную здесь, чтобы помочь определить структуру исходного блока сегмента. Специалист в данной области техники может применить варианты осуществления настоящего изобретения к другим типам структур исходного блока, например, исходный блок может быть частью фрагмента или охватывать один или более фрагментов или частей фрагментов.

[0079] Коды FEC, рассматриваемые для использования с потоковой передачей с запросом блоков, являются обычно систематическими кодами FEC, то есть, исходные символы исходного блока могут быть включены в качестве части кодирования исходного блока, и таким образом исходные символы передаются. Как понятно специалисту в данной области техники, варианты осуществления, описанные здесь, применяются одинаково хорошо к кодам FEC, которые не являются систематическими. Систематический кодер FEC генерирует из исходного блока исходных символов некоторое количество исправленных символов, и комбинация из, по меньшей мере, некоторых исходных и исправленных символов являются закодированными символами, которые посылаются по каналу, представляя исходный блок. Некоторые коды FEC могут быть полезными для эффективного генерирования стольких многих исправленных символов, сколько необходимо, таких как "информационные добавочные коды" или "коды заполнения", и примеры этих кодов включают в себя "коды цепной реакции" и "многоступенчатые коды цепной реакции". Другие FEC коды, такие как коды Рида-Соломона, могут фактически генерировать только ограниченное число исправленных символов для каждого исходного блока.

[0080] Предполагается во многих из этих примеров, что клиент подсоединен к серверу мультимедиа или множеству серверов мультимедиа, и клиент запрашивает потоковое мультимедиа по каналу или множеству каналов от сервера мультимедиа или множества серверов мультимедиа. Однако, также возможны более сложные компоновки.

ПРИМЕРЫ ВЫГОД

[0081] При потоковой передаче с запросом блоков клиент мультимедиа поддерживает взаимосвязь между тактированием этих запросов блока и тактированием проигрывания мультимедиа пользователю. Эта модель может сохранить преимущества модели "загрузки", описанной выше, избегая некоторых из неудобств, которые происходят из обычного разъединения проигрывания мультимедиа от доставки данных. Модель потоковой передачи с запросом блоков использует механизмы управления скоростью передачи и потребления, доступные в транспортных протоколах, таких как TCP, чтобы гарантировать, что максимальная доступная полоса частот используется для данных мультимедиа. Дополнительно, подразделение представления мультимедиа на блоки позволяет выбрать каждый блок закодированных данных мультимедиа из ряда множественных доступных кодирований.

[0082] Этот выбор может быть основан на любом количестве критериев, включая соответствие скорости передачи данных мультимедиа доступной полосе частот, даже когда доступная полоса частот изменяется в течении времени, согласование разрешения мультимедиа или сложности декодирования со возможностями клиента или конфигурации, или согласование с пользовательским предпочтением, таким как языки. Выбор может также включать в себя загрузку и представление вспомогательных компонентов, таких как компоненты доступности, закрытый ввод субтитров, подзаголовки, видео с языком жестов, и т.д. Примеры существующих систем, использующих модель потоковой передачи с запросом блоков, включают в себя Move Networks (ТМ), Microsoft Smooth Streaming и Протокол потоковой передачи Apple iPhone (ТМ).

[0083] Обычно каждый блок данных мультимедиа может быть сохранен на сервере как индивидуальный файл, и затем протокол, такой как HTTP, используется совместно с программным обеспечением сервера HTTP, выполняемым на сервере, чтобы запрашивать файл как единицу. Как правило, клиенту предоставляются файлы метаданных, которые могут, например быть в формате на расширяемом языке разметки (XML) или в текстовом формате списка воспроизведения или в двоичном формате, которые описывают особенности представления мультимедиа, такие как доступные кодирования (например, требуемая полоса частот, разрешения, параметры кодирования, тип мультимедиа, язык), обычно называемые "представлениями" в этом документе, и способ, которым кодирования были разделены на блоки. Например, метаданные могут включать в себя Унифицированный указатель ресурса (URL) для каждого блока. Сами URL могут обеспечить схему, такую как имеющую предшествующую последовательность "http://", чтобы указать, что протоколом, который должен использоваться, чтобы получить доступ к зарегистрированному ресурсу, является HTTP. Другим примером является "ftp://", чтобы указать, что протоколом, который должен использоваться, является FTP.

[0084] В других системах, например, блоки мультимедиа могут быть построены "на-лету" сервером в ответ на запрос от клиента, который указывает часть представления мультимедиа, в то время, которое запрошено. Например, в случае HTTP со схемой "http://" выполнение запроса этого URL обеспечивает ответ на запрос, который содержит некоторые специфические данные в теле объекта этого ответа на запрос. Реализация в сети относительно того, как генерировать этот ответ на запрос, может быть весьма различной, в зависимости от реализации сервера, обслуживающего такие запросы.

[0085] Как правило, каждый блок может быть независимо декодируемым. Например, в случае видео мультимедиа, каждый блок может начаться с «начальной точки». В некоторых схемах кодирования начальные точки упоминаются как "точки произвольного доступа" или "RAPs", хотя не все RAP могут определяться как начальная точка. Аналогично, в других схемах кодирования начальная точка начинается в кадре "обновления независимых данных", или "IDR", в случае кодирования видео H.264, хотя не все IDRs могут определяться как начальная точка. Начальная точка является позицией в видео (или другом) мультимедиа, где декодер может начать декодирование, не требуя никаких данных о предшествующих кадрах или данных или выборок, как может иметь место, когда кадр или выборка, которая декодируется, были закодированы не автономным способом, но как, например, разность между текущим кадром и предшествующим кадром.

[0086] Проблемой в таких системах может быть возможность начать проигрывание потока, например, декодируя и воспроизводя принятые аудио и видео потоки, используя персональный компьютер, и отображая видео на экране компьютера и проигрывая аудио через встроенные громкоговорители, или в качестве другого примера, декодирование и воспроизведение принятых аудио и видео потоков, используя телевизионную приставку и отображая видео на телевизионном устройстве отображения и поигрывая аудио через стерео систему. Первичной проблемой может быть необходимость минимизировать задержку между тем, когда пользователь решает просматривать новый контент, доставленный как поток, и предпринимает действие, которое выражает это решение, например, пользователь, нажимает на ссылку в окне браузера или на кнопку проигрывания устройства дистанционного управления, и когда контент начинает отображаться на экране пользователя, в дальнейшем названном "временем переключения контента". К каждой из этих проблем могут относиться элементы расширенной системы, описанной здесь.

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