Система улучшенной потоковой передачи блоков по запросу для обработки потоковой передачи с малой задержкой

Система улучшенной потоковой передачи блоков по запросу для обработки потоковой передачи с малой задержкой

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

Обычно системы передачи мультимедиа могут быть описаны либо моделью «загрузки», либо моделью «потоковой передачи». Модель «загрузки» может отличаться независимостью распределения во времени между передачей мультимедийных данных и воспроизведением мультимедиа пользователю или устройству-получателю.

В качестве примера, мультимедиа загружается в достаточном количестве заранее до того, когда оно нужно или будет использоваться, а когда оно используется, оно уже имеется как раз в нужном количестве у получателя. Передача в контексте загрузки часто выполняется с использованием протокола транспортировки файлов, например HTTP, FTP или доставки файлов однонаправленным транспортом (FLUTE), и скорость передачи можно определить по лежащему в основе потоку и/или протоколу отслеживания перегрузок, например TCP/IP. Работа потока или протокола отслеживания перегрузок может не зависеть от воспроизведения мультимедиа пользователю или устройству назначения, которое может происходить одновременно с загрузкой или в какое-нибудь другое время.

Режим «потоковой передачи» может отличаться сильной связью между распределением во времени передачи мультимедийных данных и воспроизведением мультимедиа пользователю или устройству-получателю. Передача в этом контексте часто выполняется с использованием протокола потоковой передачи, например потокового протокола реального времени (RTSP) для управления и транспортного протокола в режиме реального времени (RTP) для мультимедийных данных. Скорость передачи можно определить с помощью сервера потоковой передачи, часто она совпадает со скоростью воспроизведения данных.

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

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 30 иллюстрирует отношения между мультимедийными фрагментами для потоковой передачи с малой задержкой и мультимедийными фрагментами.

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

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

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

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

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

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

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

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

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

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

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

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

В самом простом случае каждое альтернативное отображение может храниться в одиночном файле 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 для получения фрагментов фильма при необходимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В последнее время стало установившейся практикой рассматривать использование кодов упреждающего исправления ошибок (FEC) для защиты потокового мультимедиа во время передачи. При отправке по пакетной сети, примеры которой включают в себя Интернет и беспроводные сети, например стандартизованные группами, такими как 3GPP, 3GPP2 и DVB, исходный поток помещается в пакеты, когда он формируется, или обеспечивается, и соответственно пакеты могут использоваться для переноса исходного потока или потока контента в порядке, в которым он формируется или передается в приемники.

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

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

Есть много примеров кодов FEC, которые могут использоваться для обеспечения защиты исходного потока. Коды Рида-Соломона являются общеизвестными кодами для коррекции ошибок и коррекции со стиранием в системах связи. Для коррекции со стиранием, например, в сетях пакетной передачи данных общеизвестная эффективная реализация кодов Рида-Соломона использует матрицы Коши или Вандермонда, которые описаны в L. Rizzo, «Effective Era