Улучшенная потоковая передача по запросу блоков с использованием шаблонов и правил составления url

Улучшенная потоковая передача по запросу блоков с использованием шаблонов и правил составления url

Иллюстрации

Показать все

Реферат

2420-185243RU/015

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

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

[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 г.

[0007] Данная заявка также притязает на преимущество Предварительной патентной заявки США № 61/372399, поданной 10 августа 2010 под авторством Ying Chen (Ин Чэнь) и др. и озаглавленной "HTTP Streaming Extensions".

[0008] Каждая предварительная заявка, упомянутая выше, настоящим включается в этот документ путем отсылки во всех смыслах. Настоящее раскрытие изобретения также включает в себя путем отсылки, как если бы они были полностью изложены в этом документе во всех смыслах, следующие принадлежащие тому же правообладателю заявки/патенты:

[0009] Патент США № 6307487, выданный Luby (в дальнейшем "Luby I");

[0010] Патент США № 7068729, выданный 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 и Сети доставки контента) могут быть легко доступны, делая развертывание услуг на основе этой технологии простым и недорогим.

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

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

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

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

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

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

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

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

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

[0031] Фиг. 3 иллюстрирует аппаратную/программную реализацию системы захвата.

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

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

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

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

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

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

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

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

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

[0041] Фиг. 11 иллюстрирует непрерывный и прерывистый тайминг по сегментам.

[0042] Фиг. 12 - фигура, показывающая особенность масштабируемых блоков.

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

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

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

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

[0047] Фиг. 17 - блок-схема алгоритма гибкого конвейерного процесса.

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

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

[0050] Фиг. 20 - блок-схема алгоритма совместимого выбора кэширующего прокси-сервера на основе идентификатора файла.

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

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

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

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

[0055] Фиг. 25 иллюстрирует несколько запросов HTTP исходных данных и данных восстановления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРИМЕРЫ ПРЕИМУЩЕСТВ

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

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

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

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

[0084] Обычно каждый блок может быть декодируемым независимо. Например, в случае видеоизображения каждый блок может начинаться с "точки поиска". В некоторых схемах кодирования точка поиска называется "Точками произвольного доступа" или "RAP", хотя не все RAP могут назначаться точкой поиска. Аналогичным образом в других схемах кодирования точка поиска начинается в кадре "Независимого обновления данных", или "IDR", в случае кодирования видеоизображения H.264, хотя не все IDR могут назначаться точкой поиска. Точка поиска является положением в видеоизображении (или другом), где декодер может начать декодирование без необходимости каких-либо данных о предшествующих кадрах или данных или выборок, что могло бы быть случаем, когда кадр или выборка, которая декодируется, кодировалась не автономно, а, например, как разность между текущим кадром и предшествующим кадром.

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

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

[0087] В последнее время стало установившейся практикой рассматривать использование кодов Прямого исправления ошибок (FEC) для защиты потокового мультимедиа во время передачи. При отправке по пакетной сети, примеры которой в