СИСТЕМА УЛУЧШЕННОЙ ПОТОКОВОЙ ПЕРЕДАЧИ БЛОКОВ ПО ЗАПРОСУ ДЛЯ ОБРАБОТКИ ПОТОКОВОЙ ПЕРЕДАЧИ С МАЛОЙ ЗАДЕРЖКОЙ Российский патент 2017 года по МПК H04N21/2381 H04N21/845 H04N21/438 

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

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

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

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

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

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

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

В качестве примера, мультимедиа загружается в достаточном количестве заранее до того, когда оно нужно или будет использоваться, а когда оно используется, оно уже имеется как раз в нужном количестве у получателя. Передача в контексте загрузки часто выполняется с использованием протокола транспортировки файлов, например 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 Erasure Codes for Reliable Computer Communication Protocols», Computer Communication Review, 27(2):24-36 (апрель 1997) (в дальнейшем «Rizzo»), и Bloemer и др., «An XOR-Based Erasure-Resilient Coding Scheme», Технический отчет TR-95-48, Международный институт вычислительной техники, Беркли, Калифорния (1995) (в дальнейшем «XOR-Reed-Solomon») или где-либо еще.

Другие примеры кодов FEC включают в себя коды LDPC, коды цепной реакции, например описанные в Luby I, и коды многоэтапной цепной реакции, например в Shokrollahi I.

Примеры процесса декодирования FEC для разновидностей кодов Рида-Соломона описываются в Rizzo и XOR-Reed-Solomon. В тех примерах декодирование может применяться после того, как принято достаточное количество пакетов исходных данных и данных восстановления. Процесс декодирования может иметь большой объем вычислений, и, в зависимости от имеющихся в наличии ресурсов CPU, может требовать значительного времени для завершения относительно длительности времени, занятого мультимедиа в блоке. Приемник может учитывать эту длительность времени, необходимую для декодирования, при вычислении задержки, необходимой между началом приема мультимедийного потока и воспроизведением мультимедиа. Эта задержка из-за декодирования воспринимается пользователем как задержка между запросом конкретного мультимедийного потока и началом воспроизведения. Соответственно, желательно минимизировать эту задержку.

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

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

Для некоторых кодов FEC, в особенности кодов Рида-Соломона, время кодирования и декодирования может непрактично расти с ростом количества кодированных символов на исходный блок. Таким образом, на практике часто существует практическая верхняя граница (255 является приблизительным практическим пределом для некоторых применений) для общего количества кодированных символов, которые могут формироваться в расчете на исходный блок, особенно в типичном случае, когда процесс кодирования или декодирования Рида-Соломона выполняется специальными аппаратными средствами, например, процессы MPE-FEC, которые используют коды Рида-Соломона, включенные как часть стандарта DVB-H для защиты потоков от потери пакетов, реализуются в специализированных аппаратных средствах в сотовом телефоне, которые ограничиваются всего 255 кодированными символами Рида-Соломона на исходный блок. Поскольку символы часто необходимо помещать в отдельные полезные нагрузки пакетов, это устанавливает практическую верхнюю границу на максимальную длину кодируемого исходного блока. Например, если полезная нагрузка пакета ограничивается 1024 байтами или меньше, и каждый пакет несет один кодированный символ, то кодированный исходный блок может составлять не более 255 килобайт, и это, конечно, также является верхней границей размера самого исходного блока.

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

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

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

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

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

ОБЗОР СИСТЕМЫ

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

На Фиг. 1 иллюстрируется система 100 потоковой передачи блоков, содержащая обслуживающую инфраструктуру 101 блоков («BSI»), в свою очередь содержащую систему 103 захвата для захвата контента 102, подготовки этого контента и его упаковки для услуги от сервера 104 потоковой передачи HTTP путем сохранения его в хранилище 110 контента, которое доступно системе 103 захвата и серверу 104 потоковой передачи HTTP. Как показано, система 100 также может включать в себя кэш 106 HTTP. При работе, клиент 108, например клиент потоковой передачи HTTP, отправляет запросы 112 на сервер 104 потоковой передачи HTTP и принимает ответы 114 от сервера 104 потоковой передачи HTTP или из кэша 106 HTTP. В каждом случае элементы, показанные на Фиг. 1, могут быть реализованы по меньшей мере частично в программном обеспечении, содержащем программный код, который выполняется на процессоре или другой электронике.

Контент может содержать фильмы, аудио, плоское 2D видео, 3D видео, другие типы видео, изображения, согласованный по времени текст, согласованные по времени метаданные или подобное. Некоторый контент может включать в себя данные, которые нужно представлять или потреблять согласованно по времени, например данные для представления вспомогательной информации (идентификатор станции, реклама, котировки акций, последовательности Flash™ и т.д.) вместе с другим воспроизводимым мультимедиа. Также могут использоваться другие гибридные представления, которые объединяют другое мультимедиа и/или выходят за пределы просто аудио и видео.

Как проиллюстрировано на Фиг. 2, мультимедийные блоки могут храниться в обслуживающей инфраструктуре 101(1) блоков, которая может быть, например, сервером HTTP, устройством сети передачи контента, посредником HTTP, посредником либо сервером FTP, или некоторым другим сервером или системой мультимедиа. Обслуживающая инфраструктура 101(1) блоков соединена с сетью 122, которая может быть, например, сетью с интернет-протоколом («IP»), такой как Интернет. Клиент системы потоковой передачи по запросу блоков показан с шестью функциональными компонентами, а именно селектором 123 блоков, который снабжается описанными выше метаданными и выполняющий функцию выбора блоков или частичных блоков, которые нужно запросить, из множества имеющихся в наличии блоков, указанных метаданными, запросчик 124 блоков, который принимает инструкции запросов от селектора 123 блоков и выполняет операции, необходимые для отправки запроса заданного блока, частей блока или нескольких блоков к обслуживающей инфраструктуре 101(1) блоков по сети 122 и для приема данных, содержащих блок в ответ, а также буфер 125 блоков, блок 126 отслеживания буфера, декодер 127 мультимедиа и один или более преобразователи 128 мультимедиа, которые облегчают потребление мультимедиа.

Данные блоков, принятые запросчиком 124 блоков, передаются для временного хранения в буфер 125 блоков, который хранит мультимедийные данные. В качестве альтернативы, принятые данные блоков могут сохраняться непосредственно в буфер 125 блоков, как проиллюстрировано на Фиг. 1. Декодер 127 мультимедиа снабжается мультимедийными данными с помощью буфера 125 блоков и выполняет такие преобразования над этими данными, которые необходимы для обеспечения подходящих входных данных в преобразователи 128 мультимедиа, которые визуализируют мультимедиа в виде, подходящем для пользователя или другого потребления. Примеры преобразователей мультимедиа включают в себя визуальные устройства отображения, которые можно встретить в мобильных телефонах, компьютерных системах или телевизорах, а также могут включать в себя звуковоспроизводящие устройства, например громкоговорители или наушники.

Примером декодера мультимедиа является функция, которая преобразует данные в формате, описанном в стандарте кодирования видео H.264, в аналоговые или цифровые отображения видеокадров, например карту пикселей YUV-формата с ассоциированными временными отметками представления для каждого кадра или выборки.

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

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

Приемник может иметь элементы управления, например «пауза», «быстрая перемотка вперед», «перемотка назад» и т.д., что может привести к потреблению блока при воспроизведении с разной скоростью, но если приемник может получить и декодировать каждую последующую последовательность блоков в агрегированное время, меньшее либо равное их агрегированному времени воспроизведения за исключением последнего блока в последовательности, то приемник может представить пользователю мультимедиа без остановки. В некоторых описаниях в этом документе, конкретная позиция в мультимедийном потоке называется конкретным «временем» в мультимедиа, соответствующим времени, которое прошло бы между началом воспроизведения мультимедиа и временем, когда достигается конкретная позиция в видео потоке. Время или позиция в мультимедийном потоке является традиционным понятием. Например, там, где видео поток содержит 24 кадра в секунду, про первый кадр можно сказать, что он имеет позицию или время t=0,0 секунд, а про 241-ый кадр можно сказать, что он имеет позицию или время t=10,0 секунд. Естественно, в видео потоке на основе кадров позиция или время не должны быть непрерывными, так как каждый из битов в потоке от первого бита 241-го кадра до точно перед первым битом 242-го кадра могут все иметь одинаковое значение времени.

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

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

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

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

Система захвата может включать в себя процессор 302 захвата (например, центральный процессор (CPU)), память 304, которое может хранить программный код во время исполнения, и дисковое запоминающее устройство 306, все из которых осуществляет связь друг с другом по шине 300. Система может дополнительно включать в себя устройство 308 отображения (например, жидкокристаллический дисплей (LCD) или электроннолучевую трубку (CRT)). Система также может включать в себя устройство 310 буквенно-цифрового ввода (например, клавиатуру) и устройство 312 сетевого интерфейса для приема источника контента и передачи в хранилище контента.

Дисковое запоминающее устройство 306 может включать в себя машиночитаемый носитель информации, на котором может храниться один или более наборы инструкций (например, программное обеспечение), воплощающих любую одну или более методологии или функции, описанные в этом документе. Инструкции также могут находиться, полностью или по меньшей мере частично, в памяти 304 и/или в процессоре 302 захвата во время их исполнения системой, причем память 304 и процессор 302 захвата также составляют машиночитаемые носители информации.

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

Клиентская система может включать в себя процессор 402 клиента (например, центральный процессор (CPU)), память 404, которая может хранить программный код во время исполнения, и дисковое запоминающее устройство 406, все из которых осуществляют связь друг с другом по шине 400. Система может дополнительно включать в себя устройство 408 отображения (например, жидкокристаллический дисплей (LCD) или электроннолучевую трубку (CRT)). Система также может включать в себя устройство 410 буквенно-цифрового ввода (например, клавиатуру) и устройство 412 сетевого интерфейса для отправки запросов и приема ответов.

Дисковое запоминающее устройство 406 может включать в себя машиночитаемый носитель информации, на котором может храниться один или более наборы инструкций (например, программное обеспечение), воплощающие любую одну или более методологии или функции, описанные в этом документе. Инструкции также могут находиться, полностью или по меньшей мере частично, в памяти 404 и/или в процессоре 402 клиента во время их исполнения системой, причем память 404 и процессор 402 клиента также составляют машиночитаемые носители информации.

ИСПОЛЬЗОВАНИЕ ФОРМАТА ФАЙЛА 3GPP

Формат файла 3GPP или любой другой файл на основе базового формата мультимедийного файла ISO, например формата файла MP4 или формата файла 3GPP2, может использоваться в качестве контейнерного формата для потоковой передачи HTTP со следующими особенностями. Индекс сегмента может включаться в каждый сегмент, чтобы сигнализировать временные смещения и байтовые диапазоны, так что клиент может загружать подходящие порции файлов или мультимедийные сегменты при необходимости. Распределение во времени глобального представления всего представления мультимедиа и локальное распределение во времени в каждом файле 3GP или мультимедийном сегменте можно точно выровнять. Дорожки в одном файле 3GP или мультимедийном сегменте можно точно выровнять. Дорожки между отображениями также можно выровнять путем присвоения каждой из них глобальной временной шкалы, так что переключение по отображению может быть плавным, и совместное представление мультимедийных компонентов в разных отображениях может быть синхронным.

Формат файла может содержать профиль для Адаптивной Потоковой Передачи со следующими свойствами. Все данные фильма могут содержаться во фрагментах фильма - блок «moov» может не содержать никакой информации о выборке. Данные выборки Аудио и Видео могут чередоваться, с аналогичными требованиями в отношении профиля прогрессивной загрузки, который задан в TS26.244. Блок «moov» можно поместить в начало файла, с последующими данными смещения фрагмента, также называемыми индексом сегмента, содержащим информацию о смещении во временных и байтовых диапазонах для каждого фрагмента или по меньшей мере подмножества фрагментов в содержащем сегменте.

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

ОБЗОР УСОВЕРШЕНСТВОВАННЫХ СПОСОБОВ

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

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

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

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

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

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

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

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

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

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

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

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

Действительные точки переключения могут быть точками поиска, в частности RAP, в целевом потоке. Возможны разные реализации, например фиксированные структуры GoP или выравнивание RAP по потокам (на основе начала мультимедиа или на основе GoP).

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

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

Форматом фрагмента может быть сохраненный поток пакетов транспортного протокола в режиме реального времени (RTP) с синхронизацией аудио/видео, достигаемой по протоколу управления передачей в реальном масштабе времени (RTCP).

Форматом сегмента также может быть сохраненный поток пакетов MPEG-2 с синхронизацией аудио/видео, достигаемой по внутреннему распределению во времени TS MPEG-2.

Использование сигнализации и/или формирования блоков для повышения эффективности потоковой передачи

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

ИНДЕКСИРОВАНИЕ В СЕГМЕНТАХ

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

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

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

Разные варианты возможны для добавления данных о временном и байтовом смещении фрагмента в файл 3GPP:

Во-первых, для этой цели может использоваться блок произвольного доступа к фрагменту фильма («MFRA»). MFRA обеспечивает таблицу, которая может помогать программам считывания в отыскании точек произвольного доступа в файле, используя фрагменты фильма. В поддержку этой функции, MFRA, между прочим, содержит байтовые смещения блоков MFRA, содержащих точки произвольного доступа. MFRA можно поместить в конец файла или рядом с ним, но это не обязательно так. Путем сканирования с конца файла в поисках блока смещения произвольного доступа к фрагменту фильма и использования информации о размере в нем, можно определить местоположение начала блока произвольного доступа к фрагменту фильма. Однако помещение MFRA в конец для потоковой передачи HTTP обычно требует по меньшей мере 3-4 запросов HTTP для доступа к нужным данным: по меньшей мере один для запроса MFRA из конца файла, один для получения MFRA и, наконец, один для получения нужного фрагмента в файле. Поэтому помещение в начало может быть желательным, поскольку тогда MFRA может быть загружен вместе с первыми мультимедийными данными в одиночном запросе. Также, использование MFRA для потоковой передачи HTTP может быть неэффективным, поскольку не нужна никакая информация в «MFRA», кроме времени и moof_offset, и указание смещений вместо длин может потребовать больше битов.

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

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

ИНДЕКСИРОВАНИЕ СЕГМЕНТА

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

Если клиент знает только нужное время начала меньшей части сегмента, то он может запросить весь файл, затем считать файл от начала до конца для определения подходящего места начала воспроизведения. Чтобы улучшить использование полосы пропускания, сегменты могут включать в себя индексный файл в качестве метаданных, причем индексный файл соотносит байтовых диапазонов отдельных блоков с временными диапазонами, которым соответствуют блоки, называемое индексированием сегмента или картой сегмента. Эти метаданные могут быть отформатированы в виде XML данных или могут быть двоичными, например, соответствуя структуре атома и блока в формате файла 3GPP. Индексирование может быть простым, в котором временные и байтовые диапазоны каждого блока являются абсолютными относительно начала файла, либо они могут быть иерархическими, когда некоторые блоки группируются в родительские блоки (а те в блоки предков и т.д.), и временной и байтовый диапазон для заданного блока выражается относительно временного и/или байтового диапазона родительского блока этого блока.

ПРИМЕРНАЯ СТРУКТУРА КАРТЫ ИНДЕКСИРОВАНИЯ

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

Фиг. 6 показывает примерную общую структуру мультимедийного сегмента. В каждом сегменте, либо в начале, либо по всему исходному сегменту, также может присутствовать информация индексирования, которая содержит карту сегмента с временным/байтовым смещением. Карта сегмента с временным/байтовым смещением в одном варианте осуществления может быть списком пар временного/байтового смещения (T(0), B(0)), (T(1), B(1)), …, (T(i), B(i)), …, (T(n), B(n)), где T(i-1) представляет время начала в сегменте для воспроизведения i-ого фрагмента мультимедиа относительно исходного времени начала мультимедиа среди всех мультимедийных сегментов, T(i) представляет время окончания для i-ого фрагмента (и соответственно время начала для следующего фрагмента), а байтовое смещение B(i-1) является соответствующим индексом байта начала данных в этом исходном сегменте, где i-ый фрагмент мультимедиа начинается относительно начала исходного сегмента, и B(i) является соответствующим индексом конечного байта i-го фрагмента (и соответственно индексом первого байта следующего фрагмента). Если сегмент содержит несколько мультимедийных компонентов, то T(i) и B(i) могут обеспечиваться для каждого компонента в сегменте абсолютным способом, либо они могут выражаться относительно другого мультимедийного компонента, который служит опорным мультимедийным компонентом.

В этом варианте осуществления количество фрагментов в исходном сегменте равно n, где n может меняться от сегмента к сегменту.

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

Для каждого фрагмента также может присутствовать значение, которое указывает, начинается ли фрагмент в точке поиска или содержит ли ее, т.е. в точке, в которой никакое мультимедиа после той точки не зависит ни от какого мультимедиа перед той точкой, и соответственно мультимедиа дальше с того фрагмента можно воспроизвести независимо от предыдущих фрагментов. Точки поиска обычно являются точками в мультимедиа, где воспроизведение может начинаться независимо от всех предыдущих мультимедиа. Фиг. 6 также показывает простой пример возможного индексирования сегмента для исходного сегмента. В том примере, значение временного смещения выражается в единицах миллисекунд, и соответственно первый фрагмент этого исходного сегмента начинается через 20 секунд от начала мультимедиа, и первый фрагмент имеет время воспроизведения в 485 миллисекунд. Байтовое смещение начала первого фрагмента равно 0, а байтовое смещение конца первого фрагмента/начала второго фрагмента равно 50,245, и соответственно первый фрагмент имеет размер 50,245 байт. Если фрагмент или субсегмент не начинается с точки произвольного доступа, но точка произвольного доступа содержится во фрагменте или субсегменте, то может задаваться разница времени декодирования или времени представления между временем начала и фактическим временем RAP. Это обеспечивает возможность клиенту в случае переключения на этот мультимедийный сегмент точно узнать время до того, как нужно будет представить переключение с отображения.

В дополнение или вместо простого или иерархического индексирования может использоваться гирляндное индексирование и/или гибридное индексирование.

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

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

Фиг. 7 иллюстрирует некоторые примеры, например, простой индекс 700 и иерархический индекс 702.

Ниже приведены два конкретных примера блока, который содержит карту сегмента, один называется блоком индекса времени (‘TIDX’), а другой называется (‘SIDX’). Определение соответствует структуре блока в соответствии с базовым форматом мультимедийного файла ISO. Другие исполнения для таких блоков, чтобы определить аналогичный синтаксис и такую же семантику и функциональные возможности, должны быть очевидны читателю.

Блок индекса времени

Определение

Тип блока: ‘tidx’

Контейнер: Файл

Обязательный: Нет

Количество: Любое число из нуля или единицы

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

Индекс сегмента может содержать, например, следующий синтаксис:

aligned(8) class TimeIndexBox

extends FullBox(‘frai’) {

unsigned int(32) targettype;

unsigned int(32) time_reference_track_ID;

unsigned int(32) number_of_elements;

unsigned int(64) first_element_offset;

unsigned int(64) first_element_time;

for(i=1; i<=number_of_elements; i++)

{

bit (1) random_access_flag;

unsigned int(31) length;

unsigned int(32) deltaT;

}

}

Семантика

targettype: является типом данных блока, на которые ссылается этот блок индекса времени. Это может быть либо заголовок фрагмента фильма («moof»), либо блок индекса времени («tidx»).

time-reference_track_id: указывает дорожку, по отношению к которой задаются временные смещения в этом индексе.

number_of_elements: количество элементов, индексированных этим блоком индекса времени.

first_element_offset: Байтовое смещение от начала файла первого индексированного элемента.

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

random_access_flag: Единица, если время начала элемента является точкой произвольного доступа. Ноль в противном случае.

length: Длина индексированного элемента в байтах

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

БЛОК ИНДЕКСА СЕГМЕНТА

Блок индекса сегмента (‘sidx’) обеспечивает компактный индекс фрагментов фильма и других блоков индекса сегмента в сегменте. Существует две циклические конструкции в блоке индекса сегмента. Первый цикл документирует первую выборку субсегмента, т.е. выборку в первом фрагменте фильма, на который ссылается второй цикл. Второй цикл обеспечивает индекс субсегмента. Контейнером для блока ‘sidx’ является файл или непосредственно сегмент.

Синтаксис

aligned(8) class SegmentIndexBox extends FullBox(‘sidx’, version, 0) {

unsigned int(32) reference_track_ID;

unsigned int(16) track_count;

unsigned int(16) reference_count;

for (i=1; i<= track_count; i++)

{

unsigned int(32) track_ID;

if (version==0)

{

unsigned int(32) decoding_time;

} else

{

unsigned int(64) decoding_time;

}

}

for(i=1; i<= reference_count; i++)

{

bit (1) reference_type;

unsigned int(31) reference_offset;

unsigned int(32) subsegment_duration;

bit(1) contains_RAP;

unsigned int(31) RAP_delta_time;

}

}

Семантика:

reference_track_ID обеспечивает track_ID для опорной дорожки.

track_count: количество дорожек, индексированных в следующем цикле (1 или больше);

reference_count: количество элементов, индексированных вторым циклом (1 или больше);

track_ID: ID дорожки, для которой фрагмент дорожки включается в первый фрагмент фильма, идентифицированный этим индексом; точно один track_ID в этом цикле равен reference_track_ID;

decoding_time: время декодирования для первой выборки на дорожке, идентифицированной по track_ID во фрагменте фильма, на который ссылается первый элемент во втором цикле, выраженное в шкале времени дорожки (как документировано в поле шкалы времени в блоке заголовка мультимедиа дорожки);

reference_type: когда установлен в 0, указывает, что ссылка идет на блок фрагмента фильма (‘moof’); когда установлен в 1, указывает, что ссылка идет на блок индекса сегмента (‘sidx’);

reference_offset: расстояние в байтах от первого байта, следующего за содержащим блок индекса сегмента, до первого байта блока, на который ссылаются;

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

contains_RAP: когда ссылка идет на фрагмент фильма, этот бит может быть 1, если фрагмент дорожки в том фрагменте фильма для дорожки с track_ID, равном reference_track_ID, содержит по меньшей мере одну точку произвольного доступа, в противном случае этот бит устанавливается в 0; когда ссылка идет на индекс сегмента, тогда этот бит устанавливается в 1, только если любая из ссылок в том индексе сегмента имеет этот бит, установленный в 1, и 0 в противном случае;

RAP_delta_time: если contains_RAP равно 1, обеспечивает время представления (композиции) точки произвольного доступа (RAP); зарезервировано со значением 0, если contains_RAP равно 0. Время выражается в виде разницы между временем декодирования первой выборки субсегмента, документированного этой записью, и временем представления (композиции) точки произвольного доступа, на дорожке с track_ID, равным reference_track_ID.

ОТЛИЧИЯ МЕЖДУ TIDX И SIDX

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

Второй цикл SIDX реализует функциональные возможности TIDX. В частности, SIDX позволяет иметь смесь целевых объектов для ссылки для каждого индекса, называемую reference_type, тогда как TIDX ссылается либо только на TIDX, либо только на MOOF. Number_of_elements в TIDX соответствует reference_count в SIDX, time-reference_track_id в TIDX соответствует reference_track_ID в SIDX, first_element_offset в TIDX соответствует reference_offset в первом входе второго цикла, first_element_time в TIDX соответствует decoding_time у reference_track в первом цикле, random_access_flag в TIDX соответствует contains_RAP в SIDX с дополнительной свободой в том, что в SIDX RAP не обязательно может помещаться в начало фрагмента, требуя поэтому RAP_delta_time, length в TIDX соответствует reference_offset в SIDX, и в конечном счете deltaT в TIDX соответствует subsegment_duration в SIDX. Поэтому функциональные возможности двух блоков эквивалентны.

ЗАДАНИЕ ПЕРЕМЕННЫХ РАЗМЕРОВ БЛОКА И БЛОКИ СУБ-GOP

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

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

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

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

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

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

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

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

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

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

Фиг. 6 показывает пример индексирования сегмента, где блоки имеют переменный размер, и где границами блоков является частичная GoP, т.е. частичный объем мультимедийных данных между одной RAP и следующей RAP. В этом примере, точки поиска указываются индикатором RAP, причем значение индикатора RAP, равное 1, указывает на то, что блок начинается с или содержит RAP, или точку поиска, и где индикатор RAP, равный 0, указывает на то, что блок не содержит RAP или точки поиска. В этом примере первые три блока, т.е. байты с 0 по 157,033, содержат первую GoP, которая имеет длительность представления в 1,623 секунды, со временем представления от 20 секунд до 21,623 секунды в контенте. В этом примере первый из трех первых блоков содержит 0,485 секунды времени представления и содержит первые 50,245 байт мультимедийных данных в сегменте. В этом примере блоки 4, 5, и 6 содержат вторую GoP, блоки 7 и 8 содержат третью GoP, а блоки 9, 10, и 11 содержат четвертую GoP. Отметим, что могут быть другие RAP в мультимедийных данных, которые не предназначены в качестве точек поиска, и они соответственно не сигнализируются как RAP в карте сегмента.

Вновь обращаясь к Фиг. 6, если клиент или приемник хочет получить доступ к контенту, начиная с временного смещения приблизительно в 22 секунды в представлении мультимедиа, то клиент может сначала использовать другую информацию, например MPD, более подробно описанное ниже, чтобы сначала определить, что соответствующие мультимедийные данные находятся в этом сегменте. Клиент может загрузить первую часть сегмента, чтобы получить индексирование сегмента, которое в этом случае составляет всего несколько байт, например, используя запрос байтового диапазона HTTP. Используя индексирование сегмента, клиент может определить, что первый блок, который ему следует загрузить, является первым блоком с временным смещением, которое составляет не более 22 секунд и начинается с RAP, т.е. с точки поиска. В этом примере, хотя блок 5 имеет временное смещение, которое меньше 22 секунд, т.е. его временное смещение составляет 21,965 секунды, индексирование сегмента указывает, что блок 5 не начинается с RAP, и соответственно вместо него на основе индексирования сегмента клиент выбирает для загрузки блок 4, поскольку его время начала составляет не более 22 секунд, т.е. его временное смещение равно 21,623 секунды, и он начинается с RAP. Таким образом, на основе индексирования сегмента клиент сделает запрос диапазона HTTP, начиная с байтового смещения 157,034.

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

Как правило, каждый блок включает в себя часть мультимедийных данных, которые вместе с предыдущими блоками могут воспроизводиться проигрывателем мультимедиа. Таким образом, блочная структура и сигнализация клиенту блочной структуры индексирования сегмента, содержащейся в сегменте или обеспечиваемой клиенту другим способом, может значительно улучшить возможность клиента в обеспечении быстрого переключения канала и плавном воспроизведении, несмотря на колебания и сбои в сети. Поддержка блоков переменной длительности и блоков, которые включают в себя только части GoP, что разрешено индексированием сегмента, может значительно улучшить восприятие потоковой передачи. Например, снова обращаясь к Фиг. 6 и примеру, описанному выше, когда клиент хочет начать воспроизведение приблизительно с 22 секунд в представлении, клиент может запросить с помощью одного или более запросов данные в блоке 4, а затем подать их в проигрыватель мультимедиа, как только он имеется в наличие для начала воспроизведения. Таким образом, в этом примере воспроизведение начинается, как только 42,011 байт блока 4 принимаются на клиенте, соответственно обеспечивая быстрое время переключения каналов. Если вместо этого клиенту нужно запросить всю GoP перед тем, как должно было начаться воспроизведение, то время переключения каналов было бы больше, так как это составляет 144,211 байт данных.

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

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

Время показано сверху в секундах, а блоки и точки поиска двух сегментов для двух отображений показаны слева направо в показателях их распределения во времени относительно этой временной шкалы, и соответственно длина каждого показанного блока пропорциональна времени воспроизведения и не пропорциональна количеству байтов в блоке. В этом примере индексирование сегмента для обоих сегментов двух отображений имело бы одинаковые временные смещения для точек поиска, но потенциально отличающиеся количества блоков или фрагментов между точками поиска, и разные байтовые смещения для блоков из-за разных объемов мультимедийных данных в каждом блоке. В этом примере, если клиент хочет переключиться с отображения 1 на отображение 2 во время представления приблизительно в 23 секунды, то клиент может запросить вплоть до блока 1.2 в сегменте для отображения 1, и начать запрашивание сегмента для отображения 2, начинающегося с блока 2.2, и соответственно переключение может произойти в представлении, совпадающем с точкой поиска 1.2 в отображении 1, которая находится в том же времени, что и точка поиска 2.2 в отображении 2.

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

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

В этом варианте осуществления позиции точек поиска по отображениям могут быть не выровнены. Блоки формируются так, что новый блок начинается в каждой точке поиска, и соответственно может отсутствовать выравнивание между блоками разных версий представления. Пример такой структуры с не выровненными точками поиска между разными отображениями показан на Фиг. 8(b). Время показано сверху в секундах, а блоки и точки поиска двух сегментов для двух отображений показаны слева направо в показателях их распределения во времени относительно этой временной шкалы, и соответственно длина каждого показанного блока пропорциональна его времени воспроизведения и не пропорциональна количеству байтов в блоке. В этом примере, индексирование сегмента для обоих сегментов двух отображений имело бы потенциально разные временные смещения для точек поиска, а также потенциально отличающиеся количества блоков или фрагментов между точками поиска, и разные байтовые смещения для блоков из-за разных объемов мультимедийных данных в каждом блоке. В этом примере, если клиент хочет переключиться с отображения 1 на отображение 2 во время представления приблизительно в 25 секунд, то клиент может запросить вплоть до блока 1.3 в сегменте для отображения 1, и начать запрашивание сегмента для отображения 2, начинающегося с блока 2.3, и соответственно переключение может произойти в представлении, совпадающем с точкой поиска 2.3 в отображении 2, которая находится в середине воспроизведения блока 1.3 в отображении 1, и соответственно часть мультимедиа для блока 1.2 не будет воспроизведена (хотя может потребоваться загрузить мультимедийные данные для кадров блока 1.3, которые не воспроизводятся, в буфер приемника для декодирования других кадров блока 1.3, которые воспроизводятся).

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

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

Как правило, там, где картинки кодируются в виде групп картинок (GoP), первая картинка в последовательности может быть точкой поиска, но это не всегда должно быть так.

ОПТИМАЛЬНОЕ РАЗДЕЛЕНИЕ БЛОКОВ

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

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

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

МОДЕЛЬ ДАННЫХ ПРЕДСТАВЛЕНИЯ МУЛЬТИМЕДИА

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

Как проиллюстрировано, хранилище 110 контента хранит множество исходных сегментов 510, MPD 500 и сегменты 512 восстановления. MPD может содержать записи 501 периода, которые в свою очередь могут содержать записи 502 отображения, которые содержат информацию 503 о сегменте, например ссылки на сегменты 504 инициализации и мультимедийные сегменты 505.

Фиг. 9(а) иллюстрирует примерную таблицу 900 метаданных, тогда как Фиг. 9(b) иллюстрирует пример того, как клиент 902 потоковой передачи HTTP получает таблицу 900 метаданных и мультимедийные блоки 904 по соединению с сервером 906 потоковой передачи HTTP.

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

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

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

В дополнительном варианте осуществления изобретения мультимедийные сегменты могут быть совместимы с базовым форматом мультимедийного файла ISO, описанным в ISO/IEC 14496-12 или производных спецификациях (например, форматом файла 3GP, описанным в Техническом описании 3GPP 26.244). Раздел «Использование формата файла 3GPP» (выше) описывает новые улучшения в базовом Формате мультимедийного файла ISO, допускающие эффективное использование структур данных этого формата файла в системе потоковой передачи по запросу блоков. Как описано в этой отсылке, информация может обеспечиваться в файле, допуская быстрое и эффективное соотнесение между временными сегментами представления мультимедиа и байтовыми диапазонами в файле. Сами мультимедийные данные могут быть структурированы в соответствии с конструкцией фрагмента фильма, заданной в ISO/IEC 14496-12. Эта информация, обеспечивающая временные и байтовые смещения, может быть структурирована иерархически или в виде одиночного блока информации. Эта информация может быть предусмотрена в начале файла. Обеспечение этой информации с использованием эффективного кодирования, как описано в разделе «Использование формата файла 3GPP», приводит к способности клиента быстро извлекать эту информацию, например с использованием частичных запросов GET HTTP, если протоколом загрузки файла, используемым системой потоковой передачи по запросу блоков, является HTTP, что приводит к короткому времени запуска, поиска или переключения потока, а поэтому к улучшенному восприятию пользователя.

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

Блок кодированного мультимедиа, содержащий мультимедиа нескольких типов, например аудио и видео, может иметь разные моменты окончания представления для разных типов мультимедиа. В системе потоковой передачи по запросу блоков, такие блоки мультимедиа могут воспроизводиться последовательно таким образом, что каждый тип мультимедиа воспроизводится непрерывно, и соответственно выборки мультимедиа одного типа из одного блока могут воспроизводиться перед выборками мультимедиа другого типа в предыдущем блоке, что называется в этом документе «непрерывной стыковкой блоков». В качестве альтернативы такие мультимедийные блоки могут воспроизводиться таким образом, что самая ранняя выборка любого типа одного блока воспроизводится после последней выборки любого типа предыдущего блока, что в этом документе называется «прерывающейся стыковкой блоков». Непрерывная стыковка блоков может быть подходящей, когда оба блока содержат мультимедиа из одинакового элемента контента и одинакового отображения, кодированные в последовательности, либо в иных случаях. Как правило, в одном отображении непрерывная стыковка блоков может применяться при стыковке двух блоков. Это выгодно, так как может применяться существующее кодирование, и сегментация может выполняться без необходимости выравнивать дорожки мультимедиа на границах блоков. Это иллюстрируется на Фиг. 10, где видео поток 1000 содержит блок 1202 и другие блоки с RAP, например RAP 1204.

ОПИСАНИЕ ПРЕДСТАВЛЕНИЯ МУЛЬТИМЕДИА

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

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

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

Элемент MediaPresentationDescription

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

Version: Номер версии для протокола, чтобы гарантировать расширяемость.

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

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

MediaPresentationDescriptionURI: URI для датирования описания представления мультимедиа.

Stream: Описывает тип потока или представления мультимедиа: видео, аудио или текст. Тип видео потока может содержать аудио и может содержать текст.

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

MaximumClientPreBufferTime: Максимальное количество времени, которое клиент может предварительно буферизовать мультимедийный поток. Это распределение во времени может отличать потоковую передачу от прогрессивной загрузки, если клиент ограничивается загрузкой после этого максимального времени предварительной буферизации. Значение может отсутствовать, указывая, что могут не применяться никакие ограничения в плане предварительной буферизации.

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

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

LocalCachingPermitted: Этот флаг указывает на то, может ли клиент HTTP кэшировать загруженные данные локально после их воспроизведения.

LivePresentationInterval: Содержит интервалы времени, в течение которых представление может иметься в наличие, путем задания StartTime и EndTime. StartTime указывает время начала услуг, а EndTime указывает время окончания услуги. Если EndTime не задано, то время окончания неизвестно в данное время, и UpdateFrequency может гарантировать, что клиенты получают доступ к времени окончания до фактического времени окончания услуги.

OnDemandAvailabilityInterval: Интервал представления указывает наличие услуги в сети. Может быть предусмотрено несколько интервалов представления. Клиент HTTP может не иметь возможности доступа к услуге вне любого заданного окна времени. Путем обеспечения OnDemand Interval может задаваться дополнительный отложенный просмотр. Этот атрибут также может присутствовать для услуги прямой трансляции. Если он присутствует для услуги прямой трансляции, то сервер может гарантировать, что клиент может получать доступ к услуге как к услуге OnDemand (по требованию) в течение всех предусмотренных интервалов доступности. Поэтому LivePresentationInterval не может пересекаться ни с каким OnDemandAvailabilityInterval.

MPDFileInfoDynamic: Описывает динамическое формирование файлов по умолчанию в представлении мультимедиа. Другие подробности приведены ниже. Указание по умолчанию уровня MPD может сэкономить ненужное повторение, если используются одни и те же правила для нескольких или всех альтернативных отображений.

MPDCodecDescription: Описывает основные кодеки по умолчанию в представлении мультимедиа. Другие подробности приведены ниже. Указание по умолчанию уровня MPD может сэкономить ненужное повторение, если используются одни и те же кодеки для нескольких или всех отображений.

MPDMoveBoxHeaderSizeDoesNotChange: Флаг для указания, меняется ли заголовок MoveBox по размеру среди отдельных файлов во всем представлении мультимедиа. Этот флаг может использоваться для оптимизации загрузки и может присутствовать только в случае определенных форматов сегмента, в особенности тех, для которых сегменты содержат заголовок moov.

FileURIPattern: Шаблон, используемый Клиентом для формирования сообщений Запросов в отношении файлов в представлении мультимедиа. Разные атрибуты позволяют формирование уникальных URI для каждого из файлов в представлении мультимедиа. Базовым URI может быть URI HTTP.

Alternative Representation: Описывает список отображений.

Элемент AlternativeRepresentation:

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

RepresentationID: Уникальный ID для этого конкретного альтернативного отображения в представлении мультимедиа.

FilesInfoStatic: Обеспечивает явный список начальных времен и URI всех файлов одного альтернативного представления. Статическое обеспечение списка файлов может обеспечить преимущество точного описания распределения во времени представления мультимедиа, но оно может быть не таким компактным, особенно если альтернативное отображение содержит много файлов. Также имена файлов могут иметь произвольные имена.

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

APMoveBoxHeaderSizeDoesNotChange: Флаг, который указывает на то, меняется ли заголовок MoveBox по размеру среди отдельных файлов в альтернативном представлении. Этот флаг может использоваться для оптимизации загрузки и может присутствовать только в случае определенных форматов сегмента, в особенности тех, для которых сегменты содержат заголовок moov.

APCodecDescription: Описывает основные кодеки файлов в альтернативном представлении.

Элемент Media Description

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

TrackDescription: Атрибут XML, который инкапсулирует все метаданные для мультимедиа, которое содержится в этом отображении. Атрибут TrackDescription содержит следующие атрибуты:

TrackID: Уникальный ID для дорожки в альтернативном отображении. Может использоваться, если дорожка является частью описания группировки.

Bitrate: Скорость передачи данных дорожки.

TrackCodecDescription: Атрибут XML, который содержит все атрибуты кодека, используемого на этой дорожке. Атрибут TrackCodecDescription содержит следующие атрибуты:

MediaName: Атрибут, определяющий тип мультимедиа. Типы мультимедиа включают в себя «аудио», «видео», «текст», «приложение» и «сообщение».

Codec: CodecType, включающий в себя профиль и уровень.

LanguageTag: LanguageTag, если применимо.

MaxWidth, MaxHeight: Для видео Высота и Ширина содержащегося видео в пикселях.

SamplingRate: Для аудио, частота дискретизации

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

GroupType: Тип, на основе которого клиент может решить, как группировать дорожки.

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

СИГНАЛИЗАЦИЯ ВРЕМЕН НАЧАЛА СЕГМЕНТА

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

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

В частности, если длительность файла задается в MPD в виде d секунд, то n-ый файл может начинаться с точки произвольного доступа в момент (n-1)d или непосредственно следующий.

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

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

(2) Во-вторых, добавить точное время начала в MPD для каждого сегмента. Для случая типа по требованию компактность MPD может быть уменьшена. Для случаев типа прямой трансляции это может потребовать регулярного обновления MPD, что может уменьшить масштабируемость.

(3) В-третьих, добавить глобальное время или точное время начала относительно объявленного времени начала отображения или объявленного времени начала сегмента в MPD к сегменту в том смысле, что сегмент содержит эту информацию. Это можно добавить к новому блоку, выделенному для адаптивной потоковой передачи. Этот блок также может включать в себя информацию, которая обеспечена блоком «TIDX» или «SIDX». Результат этого третьего подхода состоит в том, что при поиске до конкретной позиции около начала одного из сегментов клиент, на основе MPD, может выбрать следующий сегмент после содержащего необходимую точку поиска. Простым ответом в этом случае может быть перемещение точки поиска вперед к началу извлеченного сегмента (т.е. в следующую точку произвольного доступа после точки поиска). Обычно точки произвольного доступа обеспечены по меньшей мере каждые несколько секунд (и часто существует небольшой выигрыш кодирования, если делать их менее частыми), и поэтому в наихудшем случае точку поиска можно переместить на несколько секунд позже заданного. В качестве альтернативы клиент может определять при извлечении информации заголовка для сегмента, что запрошенная точка поиска фактически находится в предыдущем сегменте, и вместо этого запросить тот сегмент. Это может привести к случайному увеличению времени, необходимого для выполнения операции поиска.

СПИСОК ДОСТУПНЫХ СЕГМЕНТОВ

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

Сегменты можно дифференцировать на вневременные сегменты, содержащие только метаданные, и мультимедийные сегменты, которые в основном содержат мультимедийные данные. Описание представления мультимедиа («MPD») преимущественно идентифицирует и присваивает разные атрибуты каждому из сегментов, либо в неявном виде, либо в явном виде. Атрибуты, преимущественно присвоенные каждому сегменту, содержат период, в течение которого доступен сегмент, ресурсы и протоколы, по которым доступны сегменты. К тому же мультимедийным сегментам преимущественно присваиваются такие атрибуты, как время начала сегмента в представлении мультимедиа и длительность сегмента в представлении мультимедиа.

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

Там, где представление мультимедиа имеет тип «прямой трансляции», что преимущественно указывается атрибутом в описании представления мультимедиа, например атрибутом Service, сегменты, содержащие представление мультимедиа после фактического времени дня, обычно не формируются или по меньшей мере не доступны, несмотря на то, что сегменты полностью описаны в MPD. Однако с помощью указания, что услуга представления мультимедиа имеет тип «прямой трансляции», клиент может формировать список доступных сегментов вместе с атрибутами распределения во времени для внутреннего времени клиента NOW по времени настенных часов на основе информации, содержащейся в MPD, и времени загрузки MPD. Сервер преимущественно работает в том смысле, что он делает ресурс доступным так, что опорный клиент, работающий с экземпляром MPD по времени настенных часов NOW, может получать доступ к ресурсам.

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

Предположим, что список сегментов, каждый с временем начала tS, описан либо в явном виде списком воспроизведения в элементах, например FileInfoStatic, либо в неявном виде с использованием такого элемента, как FileInfoDynamic. Выгодный способ формирования списка сегментов с использованием FileInfoDynamic описан ниже. На основе этого правила составления клиент имеет доступ к списку URI для каждого отображения r, в этом документе называемого FileURI(r,i), и времени начала tS(r,i) для каждого сегмента с индексом i.

Использование информации в MPD для формирования доступного окна времени сегментов может выполняться с использованием следующих правил.

Для услуги типа «по требованию», что преимущественно указывается атрибутом, например Service, если текущее время настенных часов на клиенте NOW находится в любом диапазоне наличия, преимущественно выраженном элементом MPD, например OnDemandAvailabilityInterval, то доступны все описанные сегменты этого представления По Требованию. Если текущее время настенных часов на клиенте NOW находится вне любого диапазона наличия, то никакие из описанных сегментов в этом представлении по требованию не доступны.

Для услуги типа «прямой трансляции», что преимущественно указывается атрибутом, например Service, время начала tS(r,i) преимущественно выражает время наличия по времени настенных часов. Время начала наличия может выводиться как сочетание времени услуги прямой трансляции у события и некоторого оборотного времени на сервере для захвата, кодирования и публикации. Время для этого процесса может задаваться, например, в MPD, используя защитный интервал tG, заданный, например, как SafetyGuardIntervalLiveService в MPD. Это обеспечило бы минимальную разность между временем UTC и наличием данных на сервере потоковой передачи HTTP. В другом варианте осуществления MPD в явном виде задает время наличия сегмента в MPD без обеспечения оборотного времени в виде разности между временем прямой трансляции события и оборотным временем. В нижеследующем описании предполагается, что любые глобальные времена задаются как времена наличия. Специалист в области прямой трансляции мультимедиа может вывести эту информацию из подходящей информации в описании представления мультимедиа после прочтения этого описания.

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

Ограничение доступных сегментов регулируется следующими значениями:

Время NOW настенных часов (как имеющееся в наличие для клиента).

Разрешенная глубина буфера отложенного просмотра tTSB, например, заданная как TimeShiftBufferDepth в описании представления мультимедиа.

Клиенту в относительном времени события tl можно разрешить только запрашивать сегменты с временами начала tS(r, i) в интервале (NOW-tTSB) и NOW или в таком интервале, что время окончания сегмента с длительностью d также включается, приводя к интервалу (NOW-tTSB -d) и NOW.

ОБНОВЛЕНИЕ MPD

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

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

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

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

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

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

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

Две возможности могут существовать для распределения во времени мультимедиа по обновлению MPD для набора отображений или всех отображений. Либо (а) существующая глобальная временная шкала продолжается по всему обновлению MPD (называемому в этом документе «непрерывным обновлением MPD»), либо (b),текущая временная шкала заканчивается, и начинается новая временная шкала с сегмента, следующего за изменением (в этом документе называется «прерывающееся обновление MPD»).

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

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

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

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

Два случая иллюстрируются на Фиг. 11.

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

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

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

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

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

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

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

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

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

СИГНАЛИЗАЦИЯ ДЛИТЕЛЬНОСТИ СЕГМЕНТА

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

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

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

Длительности каждого сегмента в одном отображении или наборе отображений преимущественно могут передаваться одиночной строкой, которая задает все длительности сегментов для одиночного интервала от начала прерывающегося обновления, т.е. начала периода, до последнего мультимедийного сегмента, описанного в MPD. В одном варианте осуществления формат этого элемента является текстовой строкой, соответствующей произведению, которая содержит список с записями длительностей сегментов, причем каждая запись содержит атрибут длительности dur и факультативный множитель mult атрибута, указываящий, что это отображение содержит <mult> сегментов первой записи с длительностью <dur> первой записи, затем <mult> сегментов второй записи с длительностью <dur> второй записи, и т.д.

Каждая запись длительности задает длительность одного или более сегментов. Если значение <dur> сопровождается символом «*» и числом, то это число задает количество последовательных сегментов с этой длительностью, в секундах. Если знак множителя «*» отсутствует, то количество сегментов равно одному. Если «*» присутствует без последующего числа, то все последующие сегменты имеют заданную длительность, и в списке не может быть никаких дополнительных записей. Например, строка «30*» означает, что все сегменты имеют длительность 30 секунд. Строка «30*12 10,5» указывает 12 сегментов с длительностью 30 секунд с последующим сегментом длительности 10,5 секунд.

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

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

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

ИЗМЕНЕНИЯ И ОБНОВЛЕНИЯ МЕТАДАННЫХ ОТОБРАЖЕНИЯ

Указание изменений двоично-кодированных метаданных отображения, например изменений заголовка фильма «moov», может выполняться разными способами: (а) может быть один блок moov для всего отображения в отдельном файле, упоминаемом в MPD, (b) может быть один блок moov для каждого альтернативного отображения в отдельном файле, упоминаемом в каждом альтернативном отображении, (с) каждый сегмент может содержать блок moov и поэтому является независимым, (d) Блок moov может присутствовать для всего отображения в одном файле 3GP вместе с MPD.

Отметим, что в случае (a) и (b) одиночный ‘moov’ преимущественно может объединяться с понятием действительности из вышеизложенного в том смысле, что больше блоков ‘moov’ может упоминаться в MPD при условии, что их действительность является непересекающейся. Например, с помощью определения границы периода действительности ‘moov’ в старом периоде может истекать с началом нового периода.

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

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

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

СИГНАЛИЗАЦИЯ ОБНОВЛЕНИЙ В МЕТАДАННЫХ СЕГМЕНТА

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

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

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

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

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

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

Для случая контента прямой трансляции, моменты, в которые MPD или «moov» могут меняться, могут быть неизвестны, когда формируется MPD. Так как обычно следует избегать частого «опроса» MPD для проверки обновлений по причинам полосы пропускания и масштабируемости, обновления MPD могут указываться «в полосе» в самих файлах сегментов, т.е. каждый мультимедийный сегмент может иметь возможность указывать обновления. В зависимости от форматов сегментов с (а) по (с) выше может сигнализироваться разное обновление.

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

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

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

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

Блок информации потоковой передачи

Определение

Тип блока: ‘sinf’

Контейнер: Нет

Обязательный: Нет

Количество: Ноль или один.

Блок информации потоковой передачи содержит информацию о потоковом представлении, частью которого является файл.

Синтаксис

aligned(8) class StreamingInformationBox

extends FullBox(‘sinf’) {

unsigned int(32) streaming_information_flags;

/// Следующее является факультативными полями

string mpd_location

}

Семантика

streaming_information_flags содержит логическое ИЛИ нуля или более из следующего:

0x00000001 последует обновление заголовка фильма

0x00000002 обновление описания представления

0x00000004 окончание представления

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

Примерный вариант использования для Обновлений MPD для Услуг Прямой Трансляции

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

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

Предположим, что пользователь Анна получает доступ к услуге в автобусе с помощью своего мобильного устройства, и услуга предоставляется немедленно. Рядом с ней сидит другой пользователь, Пол, который смотрит событие на компьютере класса лэптоп. Забивают гол, и оба празднуют это событие одновременно. Пол говорит Анне, что первый гол в игре был еще более захватывающим, и Анна использует услугу, так, что она может посмотреть событие на 30 минут раньше во времени. Увидев гол, она возвращается к событию прямой трансляции.

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

Обновление MPD осуществимо асинхронно к передаче сегментов, как объясняется где-то в другом месте в этом документе. Сервер может обеспечить гарантии приемнику, что MPD не обновляется в течение некоторого времени. Сервер может опираться на текущее MPD. Однако, никакой явной сигнализации не нужно, когда MPD обновляется раньше некоторого минимального периода обновления.

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

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

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

Блок обновления MPD можно обнаружить в MPD после блока «styp», с заданным типом блока = «mupe», не требующим контейнера, не обязательным и имеющим количество, равное нулю или единице. Блок обновления MPD содержит информацию о представлении мультимедиа, частью которого является сегмент.

Примерный синтаксис выглядит следующим образом:

aligned(8) class MPDUpdateBox

extends FullBox(‘mupe’) {

unsigned int(3) mpd information flags;

unsigned int(l) new-location flag;

unsigned int(28) latest_mpd_update time;

/// Следующее является факультативными полями

string mpd_location

}

Семантика различных объектов класса MPDUpdateBox может выглядеть следующим образом:

mpd_information_flags: логическое ИЛИ нуля или более из следующего:

0x00 обновление описания представления мультимедиа сейчас

0x01 обновление описания представления мультимедиа впереди

0x02 окончание представления

0x03-0x07 зарезервировано

new_location_flag: если установлен в 1, то новое описание представления мультимедиа имеется в наличие в новом местоположении, заданном mpd_location.

latest_mpd_update time: задает время (в мс), к которому необходимо обновление MPD, относительно времени выпуска MPD у последнего MPD. Клиент может выбирать обновление MPD в любое время между настоящим моментом.

mpd_location: присутствует тогда и только тогда, когда устанавливается new_location_flag, и если это так, то mpd_location обеспечивает унифицированный указатель ресурса для нового описания представления мультимедиа.

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

Отложенный просмотр и сетевой PVR

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

СПЕЦИАЛЬНЫЕ МУЛЬТИМЕДИЙНЫЕ СЕГМЕНТЫ

Когда формат файла ISO/IEC 14496-12 используется в системе потоковой передачи по запросу блоков, проблема состоит в том, как описано выше, что может быть выгодно, хранить мультимедийные данные для одиночной версии представления в нескольких файлах, конфигурированных в последовательных временных сегментах. Кроме того, может быть полезно выполнить конфигурирование таким образом, что каждый файл начинается с точки произвольного доступа. Дополнительно может быть выгодно, выбирать позиции точек поиска во время процесса кодирования видео и сегментировать представление на несколько файлов, каждый начинающийся с точки поиска, на основе выбора точек поиска, который был сделан во время процесса кодирования, при этом каждая точка произвольного доступа может помещаться или не помещаться в начало файла, но при этом каждый файл начинается с точки произвольного доступа. В одном варианте осуществления с описанными выше свойствами метаданные представления, или описание представления мультимедиа, могут содержать точную длительность каждого файла, причем длительность воспринимается означающей, например, разницу между временем начала видео мультимедиа файла и временем начала видео мультимедиа следующего файла. На основе этой информации в метаданных представления клиент способен построить соотнесение между глобальной временной шкалой для представления мультимедиа и локальной временной шкалой для мультимедиа в каждом файле.

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

Теперь будет описан дополнительный вариант осуществления изобретения для обеспечения правильной работы системы потоковой передачи по запросу блоков, несмотря на упомянутое выше расхождение. В этом способе может быть предусмотрен элемент в каждом файле, который задает соотнесение локальной временной шкалы мультимедиа в файле (под которой понимается временная шкала, начинающаяся от временной отметки нуля, по отношению к которой временные отметки декодирования и композиции выборок мультимедиа в файле задаются в соответствии с ISO/IEC 14496-12) с глобальной временной шкалой представления. Эта информация соотнесения может содержать одиночную временную отметку в глобальном времени представления, которая соответствует нулевой временной отметке на локальной временной шкале файла. Информация соотнесения в качестве альтернативы может содержать значение смещения, которое задает разницу между глобальным временем представления, соответствующим нулевой временной отметке на локальной временной шкале файла, и глобальным временем представления, соответствующим началу файла в соответствии с информацией, обеспечиваемой в метаданных представления.

Примером таких блоков может быть, например, блок времени декодирования фрагмента дорожки (‘tfdt’) или блок регулировки фрагмента дорожки (‘tfad’) вместе с блоком регулировки мультимедийного фрагмента дорожки (‘tfma’).

Примерный клиент, включающий в себя формирование списка сегментов

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

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

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

Для каждого отображения, клиент получает двоичные метаданные, например заголовок «moov» для отображения, если присутствует, и мультимедийные сегменты выбранных отображений. Клиент получает доступ к мультимедийному контенту, запрашивая сегменты или байтовые диапазоны сегментов, по возможности с использованием списка сегментов. Клиент может сначала буферизовать мультимедиа перед началом представления, и как только представление началось, клиент продолжает потребление мультимедийного контента, постоянно запрашивая сегменты или части сегментов, принимая во внимание процедуры обновления MPD.

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

Если окончание представления мультимедиа еще не достигнуто, и если текущее время воспроизведения попадает в пороговую величину, для которой клиент ожидает окончания мультимедиа в мультимедиа, описанном в MPD для любого потребляемого отображения или отображения, которое будет потребляться, то клиент может запросить обновление MPD с новым временем считывания времени приема T. Как только оно принято, клиент по возможности принимает во внимание, обновленное MPD и новое время T при формировании списков доступных сегментов. Фиг. 29 иллюстрирует процедуру для услуг прямой трансляции в разные моменты на клиенте.

ФОРМИРОВАНИЕ СПИСКА ДОСТУПНЫХ СЕГМЕНТОВ

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

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

Клиент использует правила составления URL и распределение во времени, которые, например, дополнительно определяются в этом документе. Как только получается список описанных сегментов, этот список дополнительно ограничивается доступными сегментами, которые могут быть подмножеством сегментов полного представления мультимедиа. Создание управляется текущим значением времени настенных часов NOW на клиенте. Как правило, сегменты имеются в наличии только в течение любого времени NOW в наборе моментов наличия. Для моментов NOW вне этого окна не имеются в наличие никакие сегменты. К тому же для услуг прямой трансляции предположим, что некоторое время checktime обеспечивает информацию о том, насколько далеко в будущем описано мультимедиа. Checktime задается на документированной в MPD оси времени мультимедиа; когда время воспроизведения клиента достигает checktime, он преимущественно запрашивает новое MPD.

Затем, список сегментов дополнительно ограничивается checktime вместе с атрибутом MPD TimeShiftBufferDepth, так что имеющимися в наличии мультимедийными сегментами являются только те, для которых сумма времени начала мультимедийного сегмента и времени начала отображения попадает в интервал между NOW минус timeShiftBufferDepth минус длительность последнего описанного сегмента, и меньшим значением из либо checktime, либо NOW.

МАСШТАБИРУЕМЫЕ БЛОКИ

Иногда имеющаяся в наличии полоса пропускания снижается так низко, что блок или блоки, принимаемые в настоящее время на приемнике, вряд ли будут полностью приняты вовремя для воспроизведения без временной остановки представления. Приемник может заранее обнаруживать такие ситуации. Например, приемник может определять, что он принимает блоки, кодируя 5 единиц мультимедиа в каждые 6 единиц времени, и содержит буфер на 4 единицы мультимедиа, так что приемник может предположить необходимость остановки представления, или паузы, примерно через 24 единицы времени. При достаточном уведомлении, приемник может среагировать на такую ситуацию, например, путем отказа от текущего потока блоков и начала запроса блока или блоков из другого отображения контента, например того, которое использует меньше полосы пропускания на единицу времени воспроизведения. Например, если приемник переключается на отображение, где блоки кодированы для по меньшей мере на 20% большего времени видео для такого же размера блоков, то приемник может устранить необходимость останавливаться до тех пор, пока не улучшится ситуация с полосой пропускания.

Однако, может быть неэкономно заставлять приемник полностью отбрасывать данные, уже принятые из оставленного отображения. В варианте осуществления системы потоковой передачи блоков, описанном в этом документе, данные в каждом блоке могут кодироваться и конфигурироваться таким образом, что некоторые префиксы данных в блоке могут использоваться для продолжения представления без принятой оставшейся части блока. Например, могут использоваться общеизвестные методики масштабируемого кодирования видео. Примеры таких способов кодирования видео включают в себя Масштабируемое Кодирование Видео (SVC) H.264 или временную масштабируемость в Улучшенном Кодировании Видеосигнала (AVC) H.264. Преимущественно, этот способ позволяет продолжать представление на основе части блока, которая принята, даже когда прием блока или блоков мог быть оставлен, например, из-за изменений в имеющейся в наличии полосе пропускания. Другое преимущество состоит в том, что одиночный файл данных может использоваться в качестве источника для нескольких разных отображений контента. Это возможно, например, путем использования частичных запросов GET HTTP, которые выбирают подмножество блока, соответствующее необходимому отображению.

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

Фиг. 12 является чертежом, показывающим аспект масштабируемых блоков. На этом чертеже передатчик 1200 выводит метаданные 1202, масштабируемый уровень 1 (1204), масштабируемый уровень 2 (1206) и масштабируемый уровень 3 (1208), причем последний задерживается. Тогда приемник 1210 может использовать метаданные 1202, масштабируемый уровень 1 (1204) и масштабируемый уровень 2 (1206) для показа представления 1212 мультимедиа.

НЕЗАВИСИМЫЕ УРОВНИ МАСШТАБИРУЕМОСТИ

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

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

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

Примером методики, которая может использоваться для формирования уровней с вышеупомянутым свойством, является методика масштабируемого кодирования видео, например, которая описана в стандартах H.264/SVC ITU-T. Другим примером методики, которая может использоваться для формирования уровней с вышеупомянутым свойством, является методика уровней с временной масштабируемостью, которая обеспечена в стандарте H.264/AVC ITU-T.

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

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

СОЧЕТАНИЯ

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

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

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

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

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

УСОВЕРШЕНСТВОВАННЫЙ ДИСПЕТЧЕР БУФЕРА

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

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

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

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

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

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

Фиг. 13 иллюстрирует изменение значения B_current со временем, когда воспроизводится мультимедиа и принимаются блоки. Как показано на Фиг. 13, значение B_current равно нулю для моментов раньше t₀, указывая, что не принято никаких данных. В момент t₀ принимается первый блок, и значение B_current увеличивается до равного длительности воспроизведения принятого блока. В то же время воспроизведение еще не началось, и поэтому значение B_current остается постоянным до момента t₁, в который поступает второй блок, и B_current увеличивается на размер этого второго блока. В то же время начинается воспроизведение, и значение B_current начинает уменьшаться линейно до момента t₂, когда поступает третий блок.

Прогрессия B_current продолжается в этой «пилообразной» манере, увеличиваясь ступенчато каждый раз, когда принимается блок (в моменты t₂, t₃, t₄, t₅ и t₆), и плавно уменьшаясь, когда данные воспроизводятся между ними. Отметим, что в этом примере воспроизведение проходит на нормальной скорости воспроизведения для контента, и поэтому наклон кривой между приемом блоков равен точно -1, означая, что одна секунда мультимедийных данных воспроизводится за каждую одну секунду реального времени. При кадровом мультимедиа, воспроизводимым с заданным количеством кадров в секунду, например, 24 кадра в секунду, наклон в -1 будет приближенно выражен малыми ступенчатыми функциями, которые указывают воспроизведение каждого отдельного кадра данных, например, ступенями в -1/24 секунды, когда воспроизводится каждый кадр.

Фиг. 14 показывает другой пример развития B_current со временем. В том примере первый блок поступает в t₀, и воспроизведение начинается немедленно. Поступление блоков и воспроизведение продолжаются до момента t₃, в который значение B_current достигает нуля. Когда это происходит, никакие дополнительные мультимедийные данные не имеются в наличии для воспроизведения, вызывая паузу в представлении мультимедиа. В момент t₄ принимается четвертый блок, и воспроизведение можно возобновить. Этот пример, поэтому показывает случай, когда прием четвертого блока произошел позже, чем нужно, приведя к паузе в воспроизведении и соответственно плохому восприятию пользователя. Таким образом, цель усовершенствованного диспетчера буфера и других особенностей состоит в снижении вероятности этого события, одновременно обеспечивая высокое качество мультимедиа.

Монитор 126 буфера также может вычислять другой показатель, B_ratio(t), который является отношением мультимедиа, принятого в заданный период времени, к длине этого периода времени. Точнее говоря, B_ratio(t) равно T_received/(T_now-t), где T_received является объемом мультимедиа (измеренным по его времени воспроизведения), принятым в период времени от t, некоторого момента раньше текущего времени, до текущего момента T_now.

B_ratio(t) может использоваться для измерения скорости изменения B_current. B_ratio(t)=0 является случаем, когда никакие данные не приняты с момента t; B_current будет уменьшен на (T_now-t) с того момента, допуская, что мультимедиа воспроизводится. B_ratio(t)=1 является случаем, когда мультимедиа принимается в таком же объеме, как воспроизводится, за время (T_now-t); B_current будет иметь такое же значение в момент T_now, как в момент t. B_ratio(t)>1 является случаем, когда принято больше данных, чем необходимо для воспроизведения за время (T_now-t); B_current будет увеличен с момента t до момента T_now.

Монитор 126 буфера дополнительно вычисляет значение State, которое может принимать дискретное количество значений. Монитор 126 буфера дополнительно оснащается функцией NewState(B_current, B_ratio), которая, принимая во внимание текущее значение B_current и значения B_ratio для t<T_now, обеспечивает новое значение State в качестве выходных данных. Всякий раз, когда B_current и B_ratio заставляют эту функция возвращать значение, отличное от текущего значения State, новое значение присваивается State, и это новое значение State указывается селектору 123 блоков.

Функция NewState может оцениваться относительно пространства всех возможных значений пары (B_current, B_ratio(T_now-T_x)), где T_x может быть фиксированным (конфигурированным) значением или может выводиться из B_current, например, с помощью таблицы конфигурации, которая соотносит значения B_current со значениями T_x, или может зависеть от предыдущего значения State. Монитор 126 буфера обеспечивается одним или несколькими разбиениями этого пространства, причем каждое разбиение содержит наборы непересекающихся областей, причем каждая область аннотируется значением State. Оценка функции NewState тогда содержит операцию идентификации разбиения и определения области, в которую попадает пара (B_current, B_ratio(T_now-T_x)). Возвращаемое значение тогда является аннотацией, ассоциированной с той областью. В простом случае обеспечивается только одно разбиение. В более сложных случаях разбиение может зависеть от пары (B_current, B_ratio(T_now-T_x)) в предыдущее время оценки функции NewState, или от других факторов.

В конкретном варианте осуществления, описанное выше разбиение может быть основано на таблице конфигурации, содержащей некоторое количество пороговых значений для B_current и некоторое количество пороговых значений для B_ratio. В частности, пусть пороговыми значениями для B_current будут B_thresh(0)=0, B_thresh(1), ..., B_thresh(n₁), B_thresh(n₁+1)=∞, где n₁ является количеством ненулевых пороговых значений для B_current. Пусть пороговыми значениями для B_ratio будут B_r-thresh(0)=0, B_r-thresh(1), ..., B_r-thresh(n₂), B_r-thresh(n₂+1)=∞, где n₂ является количеством пороговых значений для B_ratio. Эти пороговые значения задают разбиение, содержащее сетку (n₁+1) на (n₂+1) ячеек, где i-ая ячейка j-ой строки соответствует области, в которой B_thresh(i-1)<=B_current<B_thresh(i) и B_r-thresh(j-1)<=B_ratio<B_r-thresh(j). Каждая ячейка описанной выше сетки аннотируется значением State, например, ассоциируемым с конкретными значениями, сохраненными в памяти, и тогда функция NewState возвращает значение State, ассоциированное с ячейкой, указанной значениями B_current и B_ratio(T_now-T_x).

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

Другие способы задания разбиений пространства будут очевидны специалистам в данной области техники при прочтении этого раскрытия изобретения. Например, разбиение может задаваться с использованием неравенств на основе линейных комбинаций B_ratio и B_current, например, пороговые величины линейного неравенства вида α1•B_ratio+α2•B_current≤α0 для действительнозначных α0, α1 и α2, чтобы задать полупространства в общем пространстве, и задания каждого непересекающегося множества как пересечения некоторого количества таких полупространств.

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

Подходящими значениями State могут быть «Низкое», «Устойчивое» и «Полное». Пример подходящего набора пороговых значений и результирующая сетка ячеек показаны на Фиг. 15.

На Фиг. 15 пороговые величины B_current показаны на горизонтальной оси в миллисекундах с показанными ниже значениями гистерезиса в виде «+/-значение». Пороговые величины B_ratio показаны на вертикальной оси в промилле (т.е. умноженными на 1000) с показанными ниже значениями гистерезиса в виде «+/-значение». Значения State аннотируются в ячейках сетки в виде «L», «S» и «F» для «Низкого», «Устойчивого» и «Полного» соответственно.

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

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

Селектор 123 блоков выбирает блоки на основе значения State, указанного последний раз блоком 126 отслеживания буфера. Когда этим значением State является «Устойчивое», селектор 123 блоков выбирает блок из того же отображения, что и предыдущий выбранный блок. Выбранный блок является первым блоком (в порядке воспроизведения), содержащим мультимедийные данные за период времени в представлении, для которого никакие мультимедийные данные не запрошены ранее.

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

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

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

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

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

Вышеописанный вариант осуществления обеспечивает существенное преимущество в том, что использование значения B_ratio при оценке функции NewState в блоке 126 отслеживания буфера позволяет быстрее увеличить качество в начале представления по сравнению со способом, который рассматривает только B_current. Без учета B_ratio может накапливаться большой объем буферизованных данных перед тем, как система сможет выбрать блоки с большей скоростью мультимедийных данных, и, следовательно, более высоким качеством. Однако, когда значение B_ratio большое, это указывает на то, что имеющаяся в наличии полоса пропускания гораздо выше скорости мультимедийных данных у ранее принятых блоков, и что даже при относительно небольших буферизованных данных (т.е. низком значении для B_current) остается безопасно запрашивать блоки с большей скоростью мультимедийных данных, и, следовательно, более высоким качеством. В равной степени, если значение B_ratio низкое (например, <1), то это указывает на то, что имеющаяся в наличии полоса пропускания опустилась ниже скорости мультимедийных данных у ранее запрошенных блоков, и соответственно даже если B_current большой, то система переключится на меньшую скорость мультимедийных данных и, следовательно, более низкое качество, например, чтобы избежать достижения точки, где B_current=0, и воспроизведение мультимедиа останавливается. Этот улучшенное поведение может быть особенно важным в окружениях, где сетевые условия, а соответственно и скорости передачи, могут быстро и динамически меняться, например, когда пользователи осуществляют потоковую передачу на мобильные устройства.

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

ЗАДАНИЕ ПЕРЕМЕННОГО РАЗМЕРА ЗАПРОСА

Высокая частота запросов может быть необходима, если каждый запрос относится к одиночному блоку, и если каждый блок кодирует короткий мультимедийный сегмент. Если мультимедийные блоки короткие, то воспроизведение видео быстро переходит от блока к блоку, что более часто позволяет приемнику регулировать или изменять выбранную скорости передачи данных путем изменения отображения, повышая вероятность того, что воспроизведение может продолжаться без остановки. Однако недостатком высокой частоты запросов является то, что они могут быть неустойчивыми в некоторых сетях, в которых доступная полоса пропускания ограничивается в сети от клиента к серверу, например, в беспроводных сетях WAN, например беспроводных WAN 3G и 4G, где емкость линии связи данных от клиента к сети ограничивается или может стать ограниченной на короткие или длительные периоды времени из-за изменений в условиях радиосвязи.

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

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

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

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

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

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

Другим примером условия, которое при выполнении может заставить запросы обращаться к нескольким блокам, является переменное значение State, описанное выше. Например, когда State является «Устойчивым» или «Полным», то запросы могут выдаваться в отношении нескольких блоков, но когда State является «Низким», то все запросы могут быть в отношении одного блока.

Другой вариант осуществления показан на Фиг. 16. В этом варианте осуществления, когда нужно выдать следующий запрос (определенный на этапе 1300), текущее значение State и B_current используется для определения размера следующего запроса. Если текущим значением State является «Низкое» или текущим значением State является «Полное», и текущее отображение не является наивысшим имеющимся в наличии (определено на этапе 1310, ответ «Да»), то следующий запрос выбирается коротким, например, точно для следующего блока (блок определен и запрос выполнен на этапе 1320). Логическое обоснование этого состоит в том, что это условия, при которых вероятно, что довольно скоро будет переключение отображений. Если текущим значением State является «Устойчивое» или текущим значением State является «Полное», и текущее отображение является наивысшим имеющимся в наличии (определено на этапе 1310, ответ «Нет»), то длительность последовательных блоков, запрошенных в следующем запросе, выбирается пропорциональной α-доли B_current для некоторого фиксированного α<1 (блоки определены на этапе 1330, запрос выполнен на этапе 1340), например, для α=0,4, если B_current=5 секундам, то следующий запрос может относиться приблизительно к 2 секундам блоков, тогда как если B_current=10 секундам, то следующий запрос может относиться приблизительно к 4 секундам блоков. Одно логическое обоснование этого состоит в том, что в этих условиях могло быть маловероятно, что переключение на новое отображение будет выполнено за количество времени, которое пропорционально B_current.

ГИБКАЯ КОНВЕЙЕРНАЯ ОБРАБОТКА

Системы потоковой передачи блоков могут использовать протокол запроса файлов, который имеет в основе конкретный транспортный протокол, например TCP/IP. В начале соединения по TCP/IP или другому транспортному протоколу может потребоваться некоторое значительное время для достижения использования полной имеющейся в наличии полосы пропускания. Это может приводить к «потере при запуске соединения» каждый раз, когда запускается новое соединение. Например, в случае TCP/IP потеря при запуске соединения возникает из-за как времени, затраченного на начальное квитирование связи TCP для установления соединения, так и времени, затраченного на протокол отслеживания перегрузок для достижения полного использования имеющейся в наличии полосы пропускания.

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

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

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

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

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

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

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

Если проверка проходит, то по соединению можно выдать дополнительный запрос. Один пример подходящей проверки состоит в том, больше ли количество принятый байтов фиксированной доли размера запрошенных данных. Например, эта доля может составлять 80%. Другой пример подходящей проверки основан на нижеследующем вычислении, как проиллюстрировано на Фиг. 17. При вычислении, пусть R будет оценкой скорости передачи данных соединения, T будет оценкой периода кругового обращения («RTT»), а X будет числовым коэффициентом, который, например, мог быть постоянной, установленной в значение между 0,5 и 2, где оценки R и T обновляются на регулярной основе (обновлены на этапе 1410). Пусть S будет размером данных, запрошенных в последнем запросе, B будет принятым количеством байтов в запрошенных данных (вычислено на этапе 1420).

Подходящей проверкой было бы инструктировать приемник (или передатчик, если это применимо) выполнить процедуру оценки неравенства (S-B)<X•R•T (проверено на этапе 1430), и если «Да», то выполнить действие. Например, проверка может проводиться, чтобы увидеть, есть ли другой запрос, готовый к выдаче по соединению (проверено на этапе 1440), и если «Да», то выдать тот запрос по соединению (этап 1450), а если «Нет», тогда процесс возвращается к этапу 1410, чтобы продолжить обновление и проверку. Если результатом проверки на этапе 1430 является «Нет», то процесс возвращается к этапу 1410, чтобы продолжить обновление и проверку.

Проверка неравенства на этапе 1430 (выполненная, например, подходящим образом запрограммированными элементами) заставляет каждый последующий запрос выдаваться, когда объем оставшихся данных, которые нужно принять, равен X-кратному объему данных, который можно принять на текущей оцененной скорости приема в одном RTT. В данной области техники известно некоторое количество способов для оценки скорости передачи данных, R, на этапе 1410. Например, скорость передачи данных может оцениваться как Dt/t, где Dt является количеством битов, принятых в предыдущие t секунд, и где t может быть, например, 1 с или 0,5 с либо некоторым другим интервалом. Другим способом является экспоненциальное среднее взвешенное, или фильтр с Бесконечной Импульсной Характеристикой (IIR) первого порядка на входящую скорость передачи данных. В данной области техники известно некоторое количество способов для оценки RTT, T, на этапе 1410.

Проверка на этапе 1430 может применяться к агрегации всех активных соединений на интерфейсе, как подробнее объясняется ниже.

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

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

Например, возможно, что если ответом на проверку, описанную на этапе 1430, является «Да» в некоторый момент t, то следующим выданным запросом был бы запрос A, тогда как если ответом на проверку, описанную на этапе 1430, не является «Да» до некоторого момента t'>t, то следующим выданным запросом вместо этого был бы запрос B, потому что либо запрос A был удален из списка потенциальных запросов между моментом t и t', либо потому что запрос B был добавлен в список потенциальных запросов с более высоким приоритетом, чем запрос A, между моментом t и t', или потому что запрос B был в списке кандидатов в момент t, но с меньшим приоритетом, чем запрос A, и между моментом t и t' приоритет запроса B сделали выше, чем у запроса A.

Фиг. 18 иллюстрирует пример списка запросов в списке кандидатов запросов. В этом примере имеются три соединения, и имеются шесть запросов в списке кандидатов, обозначенные A, B, C, D, E и F. Каждый из запросов в списке кандидатов может выдаваться по подмножеству соединений как указано, например, запрос A может выдаваться по соединению 1, тогда как запрос F может выдаваться по соединению 2 или соединению 3. Приоритет каждого запроса также обозначается на Фиг. 18, и меньшее значение приоритета указывает на то, что запрос имеет больший приоритет. Таким образом, запросы A и B с приоритетом 0 являются запросами наивысшего приоритета, тогда как запрос F со значением приоритета 3 является наименьшим приоритетом среди запросов в списке кандидатов.

Если в этот момент времени t соединение 1 проходит проверку, описанную на этапе 1430, то либо запрос A, либо запрос B выдается по соединению 1. Если вместо этого соединение 3 проходит проверку, описанную на этапе 1430 в это время t, то запрос D выдается по соединению 3, поскольку запрос D является запросом с наивысшим приоритетом, который может быть выдан по соединению 3.

Предположим, что для всех соединений ответом на проверку, описанную на этапе 1430, с момента t до некоторого более позднего момента t' является «Нет», и между моментом t и t' запрос A меняет свой приоритет с 0 на 5, запрос B удаляется из списка кандидатов, и новый запрос G с приоритетом 0 добавляется в список кандидатов. Тогда, в момент t', новый список кандидатов может быть таким, как показан на Фиг. 19.

Если в момент t' соединение 1 проходит проверку, описанную на этапе 1430, то запрос C с приоритетом 4 выдается по соединению 1, поскольку это запрос наивысшего приоритета в списке кандидатов, который может быть выдан по соединению 1 в данный момент времени.

Предположим в той же самой ситуации, что вместо этого был бы выдан запрос A по соединению 1 в момент t (который был одним из двух вариантов с наивысшим приоритетом для соединения 1 в момент t, как показано на Фиг. 18). Поскольку ответом на проверку, описанную на этапе 1430, с момента t до некоторого более позднего момента t' является «Нет» для всех соединений, соединение 1 по-прежнему передает данные по меньшей мере до момента t' для запросов, выданных перед моментом t, и соответственно запрос A не начался бы по меньшей мере до момента t'. Выдача запроса C в момент t' является лучшим решением, нежели выдача запроса A в момент t, поскольку запрос C начинается в тот же момент после t', когда начинался бы запрос A, и поскольку к тому времени запрос C имеет более высокий приоритет, чем запрос A.

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

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

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

Эти способы преимущественно могут объединяться с совместным HTTP и FEC.

СОГЛАСОВАННЫЙ ВЫБОР СЕРВЕРА

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

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

Первый вариант осуществления способа описан со ссылкой на Фиг. 20. Клиент сначала получает набор адресов интернет-протокола IP₁, IP₂, …, IP_n, как показано на этапе 1710. Если имеется файл, для которого должны быть выданы запросы, как решено на этапе 1720, то клиент определяет адрес интернет-протокола для выдачи запросов в отношении файла, как определено на этапах 1730-1770. Учитывая набор адресов интернет-протокола и идентификатор для файла, который нужно запросить, способ содержит упорядочение адресов интернет-протокола способом, определенным идентификатором файла. Например, для каждого адреса интернет-протокола формируется байтовая строка, содержащая сцепление адреса интернет-протокола и идентификатора файла, как показано на этапе 1730. К этой байтовой строке применяется хэш-функция, как показано на этапе 1740, и результирующие значения хэш-функции конфигурируются в соответствии с фиксированным упорядочением, как показано на этапе 1750, например, увеличивающимся нумерационным порядком, формируя упорядочение в адресах интернет-протокола. Одна и та же хэш-функция может использоваться всеми клиентами, тем самым гарантируя, что одинаковый результат формируется хэш-функцией над заданным вводом от всех клиентов. Хэш-функция может статически конфигурироваться во всех клиентах в наборе клиентов, или все клиенты в наборе клиентов могут получать частичное или полное описание хэш-функции, когда клиенты получают список адресов интернет-протокола, или все клиенты в наборе клиентов могут получать частичное или полное описание хэш-функции, когда клиенты получают идентификатор файла, или хэш-функция может определяться другим способом. Выбирается адрес интернет-протокола, который является первым в этом упорядочении, и этот адрес затем используется для установления соединения и выдачи запросов в отношении всего или частей файла, как показано на этапах 1760 и 1770.

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

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

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

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

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

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

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

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

ВЕРОЯТНОСТНЫЕ ЗАПРОСЫ ВСЕГО ФАЙЛА

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

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

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

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

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

Составление URL, формирование списка сегментов и поиск по нему

Формирование списка сегментов сталкивается с проблемой того, каким образом клиент может сформировать список сегментов из MPD в локальное время NOW конкретного клиента для конкретного отображения, которое начинается в некоторое время начала starttime либо относительно начала представления мультимедиа для случаев по требованию, либо выраженное временем настенных часов. Список сегментов может содержать указатель, например URL, на опциональные исходные метаданные отображения, а также список мультимедийных сегментов. Каждому мультимедийному сегменту могут быть присвоены starttime, длительность и указатель. Starttime обычно выражает приближенное значение времени мультимедиа у содержащегося в сегменте мультимедиа, но не обязательно точное время выборки. Starttime используется клиентом потоковой передачи HTTP для выдачи запроса загрузки в подходящее время. Формирование списка сегментов, включающего время начала каждого, может выполняться разными способами. URL могут обеспечиваться в виде списка воспроизведения или правило составления URL может использоваться преимущественно для компактного отображения списка сегментов.

Список сегментов на основе составления URL может, например, выполняться, если MPD сигнализирует это с помощью определенного атрибута или элемента, например FileDynamicInfo или эквивалентного сигнала. Обобщенный способ формирования списка сегментов из составления URL приведен ниже в разделе «Обзор составления URL». Составление на основе списка воспроизведения может, например, сигнализироваться с помощью другого сигнала. Поиск по списку сегментов и попадание в точное время мультимедиа также преимущественно реализуется в этом контексте.

ОБЗОР КОНСТРУКТОРА URL

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

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

КОНСТРУКТОР URL

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

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

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

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

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

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

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

Сейчас будет описан конкретный пример со ссылкой на Фиг. 21 и последующие чертежи. Примером определения синтаксиса для подходящего языка выражений, заданного в дополненной форме Бэкуса-Наура, является показанный на Фиг. 21. Пример правил для оценивания строки, соответствующей правилу вывода <expression> на Фиг. 21, содержит рекурсивное преобразование строки, подчиняющейся правилу вывода <expression> (<expression>), в строку, подчиняющуюся правилу вывода <literal>, следующим образом:

<expression>, подчиняющееся правилу вывода <literal>, остается без изменений.

<expression>, подчиняющееся правилу вывода <variable>, заменяется значением переменной, идентифицированной строкой <token> в правиле вывода <variable>.

<expression>, подчиняющееся правилу вывода <function>, оценивается путем оценивания каждого из его аргументов в соответствии с этими правилами и применения преобразования к этим аргументам, зависящего от элемента <token> в правиле вывода <function>, как описано ниже.

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

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

Примером функции является функция «printf». Эта функция принимает один или более аргументы. Первый аргумент может подчиняться правилу вывода <string> (в дальнейшем «строка»). Функция printf оценивает преобразованную версию первого аргумента. Примененное преобразование является таким же, как функция «printf» в стандартной библиотеке языка C, с дополнительными аргументами, включенными в правило вывода <function>, поставляющее дополнительные аргументы, ожидаемые функцией printf в стандартной библиотеке языка C.

Другим примером функции является функция «hash». Эта функция принимает два аргумента, первый из которых может быть строкой, а второй может подчиняться правилу вывода <number> (в дальнейшем «число»). Функция «hash» применяет хэш-алгоритм к первому аргументу и возвращает результаты, которые являются неотрицательным целым числом меньше второго аргумента. Пример подходящей хэш-функции задается в функции на языке C, показанной на Фиг. 22, чьими аргументами является входная строка (исключая окружающие кавычки) и числовое входное значение. Другие примеры хэш-функции хорошо известны специалистам в данной области техники.

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

Некоторыми примерами операторов являются операторы сложения, вычитания, деления, умножения и деления по модулю, идентифицированные правилами вывода <operator> ‘+’, ‘-‘, ‘/’, ‘*’, ‘%’ соответственно. Эти операторы требуют, чтобы правила вывода <expression> либо сторона правила вывода <operator> оценивались числами. Оценка оператора содержит применение подходящей арифметической операции (сложение, вычитание, деление, умножение и деление по модулю соответственно) к этим двум числам обычным способом и возвращение результата в виде, соответствующем правилу вывода <number>.

Другим примером оператора является оператор присвоения, идентифицированный правилом вывода <operator> ‘=’. Этот оператор требует, чтобы левый аргумент оценивался строкой, содержимое которой соответствует правилу вывода <token>. Содержимое строки задается строкой символов в окружающих кавычках. Оператор равенства вызывает присвоение переменной, чьим именем является <token>, равной содержимому левого аргумента, значения, равного результату оценивания правого аргумента. Это значение также является результатом оценивания операторного выражения.

Другим примером оператора является оператор последовательности, идентифицированный правилом вывода <operator> ‘;’. Результатом оценивания этого оператора является правый аргумент. Отметим, что как и в случае всех операторов, оцениваются оба аргумента, и левый аргумент оценивается первым.

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

Фиг. 23 иллюстрирует некоторые примеры правил составления идентификатора файла, причем входными переменными являются «id», задающая идентификатор для отображения в нужном представлении, и «seq», задающая порядковый номер для файла.

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

ПРАВИЛА СОСТАВЛЕНИЯ URL И РАСПРЕДЕЛЕНИЕ ВО ВРЕМЕНИ

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

Для этого пункта предполагается наличие описания представления мультимедиа на клиенте.

Допустим, что клиент потоковой передачи HTTP воспроизводит мультимедиа, которое загружается в рамках представления мультимедиа. Фактическое время представления клиента HTTP может задаваться относительного того, где находится время представления относительно начала представления. При инициализации может допускаться время представления t=0.

В любой момент t, клиент HTTP может загрузить любые данные со временем воспроизведения tP (также относительно начала представления) не более MaximumClientPreBufferTime впереди фактического времени представления t и любые данные, которые необходимы из-за взаимодействия с пользователем, например, поиска, быстрой перемотки вперед, и т.д. В некоторых вариантах осуществления MaximumClientPreBufferTime может даже не задаваться в том смысле, что клиент может загружать данные впереди текущего времени воспроизведения tP без ограничений.

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

Основным процессом в предоставлении услуг потоковой передачи может быть загрузка данных путем формирования подходящих запросов для загрузки всех файлов/сегментов или подмножества файлов/сегментов, например, с использованием запросов GET HTTP или частичных запросов GET HTTP. Это описание рассматривает то, каким образом обращаться к данным для определенного времени воспроизведения tP, но обычно клиент может загружать данные для большего временного диапазона времени воспроизведения, чтобы избежать неэффективных запросов. Клиент HTTP может минимизировать количество/частоту запросов HTTP при предоставлении услуги потоковой передачи.

Для получения доступа к мультимедийным данным во время воспроизведения tP или по меньшей мере близко к времени воспроизведения tP в конкретном отображении клиент определяет URL на файл, который содержит это время воспроизведения, и к тому же определяет байтовый диапазон в файле для доступа к этому времени воспроизведения.

Описание представления мультимедиа может присваивать каждому отображению id отображения, r, например, с использованием атрибута RepresentationID. Другими словами, содержимое MPD, когда записывается системой захвата или когда считывается клиентом, будет интерпретироваться так, что существует присвоение. Чтобы загрузить данные для определенного времени воспроизведения tP для определенного отображения с id r, клиент может составить подходящий URI для файла.

Описание представления мультимедиа может присваивать каждому файлу или сегменту каждого отображения r следующие атрибуты:

(a) порядковый номер i файла в отображении r, причем i=1, 2, …, Nr, (b) относительное время начала файла с id отображения r и индексом файла i относительно времени представления, заданное как ts(r, i), (c) URI файла для файла/сегмента с id отображения r и индексом файла i, обозначенный как FileURI(r, i).

В одном варианте осуществления время начала файла и URI файла могут быть обеспечены в явном виде для отображения. В другом варианте осуществления список URI файла может быть предусмотрен в явном виде, причем каждый URI файла получает неотъемлемо присвоенный индекс i в соответствии с позицией в списке, и время начала сегмента выводится как сумма всех длительностей сегментов для сегментов с 1 по i-1. Длительность каждого сегмента может быть обеспечена в соответствии с любым из рассмотренных выше правил. Например, любой специалист в математике может использовать другие способы выведения методологии, чтобы легко вывести время начала из одиночного элемента или атрибута и позиции/индекса URI файла в отображении.

Если динамическое правило составления URI предусмотрено в MPD, то время начала каждого файла, и каждый URI файла могут составляться динамически с использованием правила составления, индекса запрошенного файла и по возможности некоторых дополнительных параметров, предусмотренных в описании представления мультимедиа. Информация может обеспечиваться, например, в атрибутах и элементах MPD, например FileURIPattern и FileInfoDynamic. FileURIPattern обеспечивает информацию о том, как составить URI на основании порядкового номера i индекса файла и id отображения r. FileURIFormat составляется в виде:

FileURIFormat=sprintf(«%s%s%s%s%s.%s», BaseURI, BaseFileName,

RepresentationIDFormat, SeparatorFormat,

FileSequenceIDFormat, FileExtension);

FileURI(r,i) составляется в виде

FileURI(r,i)=sprintf(FileURIFormat, r, i);

Относительное время начала ts(r, i) для каждого файла/сегмента может выводиться с помощью некоторого атрибута, содержащегося в MPD, описывающего длительность сегментов в этом отображении, например атрибута FileInfoDynamic. MPD также может содержать последовательность атрибутов FileInfoDynamic, которая глобальна для всех отображений в представлении мультимедиа или по меньшей мере для всех отображений в периоде точно так же, как задано выше. Если запрашиваются мультимедийные данные для определенного времени воспроизведения tP в отображении r, то соответствующий индекс i(r, tP) может выводиться в виде i(r, tp), так что время воспроизведения этого индекса находится в интервале времени начала ts(r, i(r, tP)) и ts(r, i(r, tP)+1). Доступ к сегменту может дополнительно ограничиваться вышеупомянутыми случаями, например, сегмент является недоступным.

Доступ к точному времени воспроизведения tP, как только получается индекс и URI соответствующего сегмента, зависит от фактического формата сегмента. В этом примере предположим, что мультимедийные сегменты имеют локальную временную шкалу, которая начинается в 0 без потери общности. Чтобы получить доступ к и представить данные во времени воспроизведения tP, клиент может загрузить данные, соответствующие локальному времени, из файла/сегмента, к которому можно получить доступ посредством URI FileURI(r, i), причем i=i(r, t_p).

Как правило, клиенты могут загрузить весь файл и могут затем получить доступ к времени воспроизведения tP. Однако не обязательно загружать всю информацию файла 3GP, так как файл 3GP предусматривает структуры для соотнесения локального распределения во времени с байтовым диапазоном. Поэтому только определенных байтовых диапазонов для доступа к времени воспроизведения tP может быть достаточно для воспроизведения мультимедиа при условии, что имеется в наличии достаточная информация о произвольном доступе. Также достаточная информация о структуре и соотнесении байтового диапазона с локальным распределением во времени мультимедийного сегмента может обеспечиваться в начальной части сегмента, например, с использованием индекса сегмента. Имея доступ к начальным, например, 1200 байтам сегмента, клиент может получить достаточную информацию для прямого доступа к байтовому диапазону, необходимому для времени воспроизведения tP.

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

ПОИСК

Клиент может попытаться перейти к определенному времени представления t_p в отображении. На основе MPD клиент имеет доступ к времени начала мультимедийного сегмента и URL мультимедийного сегмента у каждого сегмента в отображении. Клиент может получить индекс сегмента segment_index у сегмента, вероятнее всего содержащего выборки мультимедиа для времени представления t_p, в виде максимального индекса сегмента i, для которого время начала tS(r, i) меньше либо равно времени представления t_p, т.е. segment_index=max { i | tS(r, i)<=t_p }. URL сегмента получается в виде FileURI(r, i).

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

Для точного поиска в отношении времени представления t_p клиенту потоковой передачи HTTP нужно получить доступ к точке произвольного доступа (RAP). Чтобы определить точку произвольного доступа в мультимедийном сегменте в случае Адаптивной Потоковой Передачи HTTP 3GPP, клиент может использовать, например, информацию в блоке ‘tidx’ или ‘sidx’, если имеется, для определения местоположения точек произвольного доступа и соответствующего времени представления в представлении мультимедиа. В случаях, когда сегмент является фрагментом фильма 3GPP, клиенту также можно использовать информацию в блоках ‘moof’ и ‘mdat’, например, чтобы найти RAP и получить необходимое время представления из информации во фрагменте фильма и время начала сегмента, выведенное из MPD. Если отсутствует RAP с временем представления перед запрошенным временем представления t_p, то клиент может либо получить доступ к предыдущему сегменту, либо может использовать лишь первую точку произвольного доступа в качестве результата поиска. Когда мультимедийные сегменты начинаются с RAP, эти процедуры простые.

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

ФОРМИРОВАНИЕ СПИСКА СЕГМЕНТОВ

Как описано в этом документе, должно быть, очевидно, как реализовать клиента прямой потоковой передачи HTTP, который использует информацию, обеспеченную MPD, для формирования списка сегментов для отображения, которое имеет сигнализированную приблизительную длительность сегмента dur. В некоторых вариантах осуществления, клиент может присваивать мультимедийным сегментам в отображении последовательные индексы i=1, 2, 3, …, т.е. первому мультимедийному сегменту присваивается индекс i=1, второму мультимедийному сегменту присваивается индекс i=2, и так далее. Затем, списку мультимедийных сегментов с индексами i сегментов присваивается startTime[i], и URL[i] формируется, например, следующим образом. Сначала индекс i устанавливается в 1. Время начала первого мультимедийного сегмента получается как 0, startTime[1]=0. URL мультимедийного сегмента i, URL[i], получается как FileURI(r, i). Процесс продолжается для всех описанных мультимедийных сегментов с индексом i, и startTime[i] мультимедийного сегмента i получается как (i-1)*dur, а URL[i] получается как FileURI(r, i).

ОДНОВРЕМЕННЫЕ ЗАПРОСЫ HTTP/TCP

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

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

Предположим, что каждый блок или фрагмент сегмента загружается по отдельному соединению HTTP/TCP, и что количество параллельных соединений равно n, а длительность воспроизведения каждого блока равна t секунд, и что скорость потоковой передачи контента, ассоциированного с сегментом, равна S. Когда клиент сначала начинает потоковую передачу контента, могут выдаваться запросы первых n блоков, представляющие n*t секунд мультимедийных данных.

Как известно специалистам в данной области техники, имеется большое отклонение в скорости передачи данных у соединений TCP. Однако для упрощения этого обсуждения предположим, что в идеале все соединения происходят параллельно, так что первый блок будет принят полностью примерно в то же время, что и остальные n-1 запрошенные блоки. Для дополнительного упрощения обсуждения, предположим, что агрегированная полоса пропускания, используемая n соединениями загрузки, зафиксирована в значении B для всей продолжительности загрузки, и что скорость потоковой передачи S постоянна во всем отображении. Дополнительно предположим, что структура мультимедийных данных такова, что воспроизведение блока может быть выполнено, когда весь блок имеется в наличии на клиенте, т.е. воспроизведение блока может начаться только после того, как принимается весь блок, например, из-за структуры лежащего в основе кодирования видео, или потому что применяется шифрование для шифрования каждого фрагмента или блока отдельно, и соответственно весь фрагмент или блок нужно принять перед тем, как его можно расшифровать. Таким образом, чтобы упростить обсуждение ниже, мы допускаем, что весь блок нужно принять перед тем, как можно воспроизвести любой из блоков. Тогда время, необходимое перед тем, как поступил и может быть воспроизведен первый блок, приблизительно равно n*t*S/B.

Поскольку желательно минимизировать время переключения контента, с этой целью желательно минимизировать n*t*S/B. Значение t может определяться такими факторами, как лежащая в основе структура кодирования видео и какие способы захвата используются, и соответственно t может быть довольно малым, но очень маленькие значения t приводят к чрезмерно усложненной карте сегмента и, возможно, могут быть несовместимы с эффективным кодированием видео и дешифрованием, если используется. Значение n также может влиять на значение B, т.е. B может быть больше для большего числа n соединений, и соответственно сокращение количества соединений, n, имеет отрицательное побочное действие по возможному уменьшению величины имеющейся в наличии полосы пропускания, которая используется, B, и поэтому может быть неэффективно в достижении цели уменьшения времени переключения контента. Значение S зависит от того, какое отображение выбирается для загрузки и воспроизведения, и в идеале S должно быть как можно ближе к B, чтобы максимизировать качество воспроизведения мультимедиа для заданных сетевых условий. Таким образом, чтобы упростить это обсуждение, предположим, что S приблизительно равно B. Тогда время переключения каналов пропорционально n*t. Таким образом, использование большего количества соединений для загрузки разных фрагментов может ухудшить время переключения каналов, если агрегированная полоса пропускания, используемая соединениями, сублинейно пропорциональна количеству соединений, что обычно имеет место.

В качестве примера предположим t=1 секунде, и при n=1 значение B=500 Кбит/с, при n=2 значение B=700 Кбит/с, а при n=3 значение B=800 Кбит/с. Предположим, что выбирается отображение с S=700 Кбит/с. Тогда при n=1 время загрузки для первого блока равно 1*700/500=1,4 секунды, при n=2 время загрузки для первого блока равно 2*700/700=2 секунды, а n=3 время загрузки для первого блока равно 3*700/800=2,625 секунды. Кроме того, так как количество соединений увеличивается, то, скорее всего, увеличивается непостоянство отдельных скоростях загрузки у соединений (хотя даже при одном соединении вероятна некоторое значительное непостоянство). Таким образом, в этом примере время переключения каналов и непостоянство времени переключения каналов увеличиваются, когда увеличивается количество соединений. Интуитивно блоки, которые передаются, имеют разные приоритеты, т.е. первый блок имеет самый ранний крайний срок передачи, второй блок имеет второй самый ранний крайний срок и т.д., тогда как соединения загрузки, по которым передаются блоки, конкурируют за сетевые ресурсы в течение передачи, и соответственно блоки с самыми ранними крайними сроками больше задерживаются, когда запрашивается больше конкурирующих блоков. С другой стороны, даже в этом случае использование, в конечном счете, более одного соединения загрузки позволяет поддерживать стабильно более высокую скорость потоковой передачи, например, при трех соединениях может поддерживаться скорость потоковой передачи вплоть до 800 Кбит/с в этом примере, тогда как при одном соединении может поддерживаться только поток в 500 Кбит/с.

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

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

СОВМЕСТНОЕ ЗАПРАШИВАНИЕ HTTP/TCP

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

Преимущества совместных запросов HTTP/TCP вместе с использованием данных восстановления FEC могут быть особенно важны для обеспечения согласованно быстрых времен переключения каналов. Например, во время переключения каналов, возможно, что соединения TCP либо только что начались, либо простаивают в течении некоторого периода времени, и в этом случае окно перегрузки, cwnd, находится в минимальном значении для соединений, и соответственно скорости передачи у этих соединений TCP потребуется несколько периодов кругового обращения (RTT) для увеличения, и будет иметь место высокое непостоянство в скоростях передачи по разным соединениям TCP в течение этого времени увеличения.

Теперь будет приведен обзор способа без FEC, который является способом совместного запроса HTTP/TCP, в котором только мультимедийные данные исходных блоков запрашиваются с использованием нескольких одновременных соединений HTTP/TCP, т.е. не запрашиваются никакие данные восстановления FEC. С помощью способа без FEC, части одного и того же фрагмента запрашиваются по разным соединениям, например, с использованием запросов байтовых диапазонов HTTP для частей фрагмента, и соответственно каждый запрос байтового диапазона HTTP относится, например, к части байтового диапазона, указанной в карте сегмента для фрагмента. Может быть так, что отдельный запрос HTTP/TCP увеличивает свою скорость передачи, чтобы полностью использовать имеющуюся в наличии полосу пропускания, за несколько RTT (периоды кругового обращения), и соответственно имеется относительно длительный период времени, когда скорость передачи меньше имеющейся в наличии полосы пропускания, и соответственно, если одиночное соединение HTTP/TCP используется для загрузки, например, первого фрагмента контента, который нужно воспроизвести, то время переключения каналов может быть большим. Используя способ без FEC, загрузка разных частей одного и того же фрагмента по разным соединениям HTTP/TCP может значительно уменьшить время переключения каналов.

Теперь будет приведен обзор способа с FEC, который является способом совместного запроса HTTP/TCP, в котором мультимедийные данные исходного сегмента и данные восстановления FEC, сформированные из мультимедийных данных, запрашиваются с использованием нескольких одновременных соединений HTTP/TCP. С помощью способа с FEC, части одного и того же фрагмента и данные восстановления FEC, сформированные из того фрагмента, запрашиваются по разным соединениям с использованием запросов байтовых диапазонов HTTP для частей фрагмента, и соответственно каждый запрос байтового диапазона HTTP относится, например, к части байтового диапазона, указанной в карте сегмента для фрагмента. Может быть так, что отдельный запрос HTTP/TCP увеличивает свою скорость передачи, чтобы полностью использовать имеющуюся полосу пропускания, за несколько RTT (периоды кругового обращения), и соответственно имеется относительно длительный период времени, когда скорость передачи меньше имеющейся в наличии полосы пропускания, и соответственно, если одиночное соединение HTTP/TCP используется для загрузки, например, первого фрагмента контента, который нужно воспроизвести, то время переключения каналов может быть большим. Использование способа с FEC имеет такие же преимущества, как и способ без FEC, и обладает дополнительным преимуществом в том, что не все запрошенные данные должны поступить до того, как можно восстановить фрагмент, соответственно дополнительно уменьшая время переключения каналов и непостоянство времени переключения каналов. Делая запросы по разным соединениям TCP и избыточно запрашивая путем запрашивания также данных восстановления FEC по меньшей мере по одному из соединений, количество времени, которое требуется для передачи достаточного объема данных, например, чтобы восстановить первый запрошенный фрагмент, который позволяет начать воспроизведение мультимедиа, можно значительно уменьшить и сделать гораздо более согласованным, чем, если бы не использовались совместные соединения TCP и данные восстановления FEC.

Фиг. 24(а)-(е) показывают пример колебаний скорости передачи у 5 соединений TCP, работающих на одной и той же линии связи к одному и тому же клиенту от одного и того же web-сервера HTTP в эмулированной сети Развития с Оптимизацией для Данных (EVDO). На Фиг. 24(а)-(е) ось X показывает время в секундах, а ось Y показывает скорость для каждого соединения, с которой биты принимаются на клиенте по каждому из 5 соединений TCP, измеренную с интервалами в 1 секунду. В этой конкретной эмуляции было всего 12 соединений TCP, работающих на этой линии связи, и соответственно сеть была относительно загружена в течение показанного времени, что могло быть типично, когда более одного клиента осуществляют потоковую передачу в одной и той же соте в мобильной сети. Отметим, что хотя скорости передачи отчасти коррелируют со временем, имеется большая разница в скоростях передачи у 5 соединений во множестве моментов времени.

Фиг. 25 показывает возможную структуру запроса в отношении фрагмента, который имеет размер 250,000 бит (приблизительно 31,25 килобайт), причем имеется 4 запроса байтовых диапазонов HTTP, сделанных параллельно для разных частей фрагмента, т.е. первое соединение HTTP запрашивает первые 50,000 бит, второе соединение HTTP запрашивает следующие 50,000 бит, третье соединение HTTP запрашивает следующие 50,000 бит, и четвертое соединение HTTP запрашивает следующие 50,000 бит. Если FEC не используется, т.е. способ без FEC, то в этом примере имеются только 4 запроса фрагмента. Если FEC используется, т.е. способ с FEC, то в этом примере имеется одно дополнительное соединение HTTP, которое запрашивает дополнительные 50,000 бит данных восстановления FEC в сегменте восстановления, сформированных из фрагмента.

Фиг. 26 является увеличением первой пары секунд у 5 соединений TCP, показанных на Фиг. 24(а)-(е), при этом на Фиг. 26 ось X показывает время в интервалах по 100 миллисекунд, а ось Y показывает скорость, с которой биты принимаются на клиенте по каждому из 5 соединений TCP, измеренную с интервалами по 100 миллисекунд. Одна линия показывает агрегированное количество битов, которое принято на клиенте для фрагмента от первых 4 соединений HTTP (исключая соединение HTTP, по которому запрашиваются данные FEC), т.е. то, что поступает с использованием способа без FEC. Другая линия показывает агрегированное количество битов, которое принято на клиенте для фрагмента от всех 5 соединений HTTP (включая соединение HTTP, по которому запрашиваются данные FEC), т.е. то, что поступает с использованием способа с FEC. Для способа с FEC предполагается, что фрагмент может декодироваться с FEC от приема любых 200,000 бит из 250,000 запрошенных битов, что можно реализовать, если используется, например, код FEC Рида-Соломона, и что можно главным образом реализовать, если используется, например, код RaptorQ, описанный в Luby IV. Для способа с FEC в этом примере принимается достаточно данных для восстановления фрагмента с использованием декодирования FEC после 1 секунды, обеспечивая время переключения каналов в 1 секунду (предполагая, что данные для последующих фрагментов можно запросить и принять до того, как полностью воспроизводится первый фрагмент). Для способа без FEC в этом примере все данные для 4 запросов нужно принять до того, как можно восстановить фрагмент, что происходит после 1,7 секунды, приводя к времени переключения каналов в 1,7 секунды. Таким образом, в показанном на Фиг. 26 примере способ без FEC на 70% хуже в показателях времени переключения каналов, чем способ с FEC. Одной из причин для преимущества, показанного способом с FEC в этом примере, является то, что для способа с FEC прием любых 80% запрошенных данных позволяет восстановить фрагмент, тогда как для способа без FEC необходим прием 100% запрошенных данных. Таким образом, способу без FEC нужно ждать самого медленного соединения TCP для завершения передачи, и вследствие естественных изменений в скорости передачи TCP имеется тенденция к большому расхождению в скорости передачи у самого медленного соединения TCP по сравнению со средним соединением TCP. В способе с FEC в этом примере одно медленное соединение TCP не определяет, когда фрагмент является восстанавливаемым. Вместо этого для способа с FEC передача достаточного количества данных гораздо больше зависит от средней скорости передачи TCP, чем от наихудшего случая скорости передачи TCP.

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

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

Дополнительные общие элементы добавляются к преимуществам, которые можно реализовать с помощью раскрытых выше способов. Например, количество используемых соединений HTTP может меняться в зависимости от текущего объема мультимедиа в буфере мультимедиа, и/или скорости приема в буфер мультимедиа. Совместные запросы HTTP, использующие FEC, т.е. описанный выше способ с FEC и разновидности того способа, могут использоваться активно, когда буфер мультимедиа относительно пустой, например, больше совместных запросов HTTP выполняется параллельно для разных частей первого фрагмента, запрашивающих весь исходный фрагмент и относительно большую долю данных восстановления из соответствующего фрагмента восстановления, и затем переходя к уменьшенному количеству одновременных запросов HTTP, запрашивающих более крупные части мультимедийных данных на запрос, и запрашивающих меньшую долю данных восстановления, например, переходя на 1, 2 или 3 одновременных запроса HTTP, переходя к запросам полных фрагментов или нескольких последовательных фрагментов на запрос, и переходя к отказу от запроса данных восстановления, когда увеличивается буфер мультимедиа.

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

ДОПОЛНИТЕЛЬНЫЕ УЛУЧШЕНИЯ ПРИ ИСПОЛЬЗОВАНИИ ОДНОВРЕМЕННЫХ СОЕДИНЕНИЙ HTTP

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

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

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

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

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

СПОСОБЫ ФОРМИРОВАНИЯ ФАЙЛОВЫХ СТРУКТР, ПОДДЕРЖИВАЮЩИЕ СОВМЕСТНЫЕ СПОСОБЫ HTTP/FEC

Теперь будет описан вариант осуществления для формирования файловой структуры, которая может использоваться преимущественно клиентом, применяющим совместные способы HTTP/FEC. В этом варианте осуществления, для каждого исходного сегмента имеется соответствующий сегмент восстановления, сформированный следующим образом. Параметр R указывает в среднем, сколько данных восстановления FEC формируется для исходных данных в исходных сегментах. Например, R=0,33 указывает, что если исходный сегмент содержит 1,000 килобайт данных, то соответствующий сегмент восстановления содержит приблизительно 330 килобайт данных восстановления. Параметр S указывает размер символа в байтах, используемый для кодирования и декодирования FEC. Например, S=64 указывает, что исходные данные и данные восстановления содержат символы с размером 64 байта каждый для целей кодирования и декодирования FEC.

Сегмент восстановления может формироваться для исходного сегмента следующим образом. Каждый фрагмент исходного сегмента считается исходным блоком для целей кодирования FEC, и соответственно каждый фрагмент рассматривается как последовательность исходных символов исходного блока, из которых формируются символы восстановления. Количество символов восстановления, сформированных в итоге для первых i фрагментов, вычисляется как TNRS(i)=ceiling(R*B(i)/S), где ceiling(x) является функцией, которая выводит наименьшее целое число со значением, которое по меньшей мере равно x. Таким образом, количество символов восстановления, сформированных для фрагмента i, равно NRS(i)=TNRS(i)-TNRS(i-1).

Сегмент восстановления содержит сцепление символов восстановления для фрагментов, когда порядок символов восстановления в сегменте восстановления является порядком фрагментов, из которых они формируются, и во фрагменте символы восстановления находятся в порядке их идентификатора символа кодирования (ESI). Структура сегмента восстановления, соответствующая структуре исходного сегмента, показана на Фиг. 27, включающая генератор 2700 сегментов восстановления.

Отметим, что путем задания количества символов восстановления для фрагмента, как описано выше, общее количество символов восстановления для всех предыдущих фрагментов, а соответственно индекс байта в сегменте восстановления, зависит только от R, S, B(i-1) и B(i), и не зависит ни от какой предыдущей или последующей структуры фрагментов в исходном сегменте. Это полезно, потому что это позволяет клиенту быстро вычислить позицию начала блока восстановления в сегменте восстановления, а также быстро вычислить количество символов восстановления в том блоке восстановления, используя только локальную информацию о структуре соответствующего фрагмента исходного сегмента, из которого формируется блок восстановления. Таким образом, если клиент решает начать загрузку и воспроизведение фрагмента с середины исходного сегмента, то он также может быстро сформировать и получить доступ к соответствующему блоку восстановления из соответствующего сегмента восстановления.

Количество исходных символов в исходном блоке, соответствующее фрагменту i, вычисляется как NSS(i)=ceiling((B(i)-B(i-1))/S). Последний исходный символ дополняется нулевыми байтами для целей кодирования и декодирования FEC, если B(i)-B(i-1) не является кратным S, т.е. последний исходный символ дополняется нулевыми байтами, так что он имеет размер S байт для целей кодирования и декодирования FEC, но эти нулевые байты не сохраняются как часть исходного сегмента. В этом варианте осуществления ESI для исходного символа являются 0, 1, …, NSS(i)-1, а ESI для символов восстановления являются NSS(i), …, NSS(i)+NRS(i)-1.

URL для сегмента восстановления в этом варианте осуществления может формироваться из URL для соответствующего исходного сегмента просто путем добавления, например, суффикса «.repair» к URL исходного сегмента.

Информация индексирования восстановления и информация FEC для сегмента восстановления в неявном виде задается информацией индексирования для соответствующего исходного сегмента и из значений R и S, как описано в этом документе. Временные смещения и структура фрагмента, содержащая сегмент восстановления, определяются временными смещениями и структурой соответствующего исходного сегмента. Байтовое смещение до конца символов восстановления в сегменте восстановления, соответствующем фрагменту i, может вычисляться как RB(i)=S*ceiling(R*B(i)/S). Количество байт в сегменте восстановления, соответствующем фрагменту i, тогда равно RB(i)-RB(i-1), и соответственно количество символов восстановления, соответствующих фрагменту i, вычисляется как NRS(i)=(RB(i)-RB(i-1))/S. Количество исходных символов, соответствующих фрагменту i, может вычисляться как NSS(i)=ceiling((B(i)-B(i-1))/S). Таким образом, в этом варианте осуществления, информация индексирования восстановления для блока восстановления в сегменте восстановления и соответствующая информация FEC могут в неявном виде выводиться из R, S и информации индексирования для соответствующего фрагмента соответствующего исходного сегмента.

В качестве примера рассмотрим пример, показанный на Фиг. 28, показывающий фрагмент 2, который начинается в байтовом смещении B(1)=6,410 и заканчивается в байтовом смещении B(2)=6,770. В этом примере размер символа S=64 байтам, и пунктирные вертикальные линии показывают байтовые смещения в исходном сегменте, которые соответствуют кратным числам S. Общий размер сегмента восстановления в качестве доли размера исходного сегмента устанавливается в R=0,5 в этом примере. Количество исходных символов в исходном блоке для фрагмента 2 вычисляется как NSS(2)=ceiling((6,770-6,410)/64)=ceil(5.625)=6, и эти 6 исходных символов имеют ESI 0, …, 5 соответственно, причем первый исходный символ является первыми 64 байтами фрагмента 2, который начинается в индексе байта 6,410 в исходном сегменте, второй исходный символ является следующими 64 байтами фрагмента 2, который начинается в индексе байта 6,474 в исходном сегменте, и т.д. Конечное байтовое смещение блока восстановления, соответствующего фрагменту 2, вычисляется как RB(2)=64*ceiling(0,5*6,770/64)=64*ceiling(52.8…)=64*53=3,392, а начальное байтовое смещение блока восстановления, соответствующего фрагменту 2, вычисляется как RB(1)=64*ceiling(0,5*6,410/64)=64*ceiling(50,07…)=64*51=3,264, и соответственно в этом примере имеются два символа восстановления в блоке восстановления, соответствующие фрагменту 2 с ESI 6 и 7 соответственно, начинающиеся в байтовом смещении 3,264 в сегменте восстановления и заканчивающиеся в байтовом смещении 3,392.

Отметим, что в показанном на Фиг. 28 примере, даже если R=0,5 и имеются 6 исходных символов, соответствующих фрагменту 2, количество символов восстановления не равно 3, как можно предположить, если просто использовать количество исходных символов для вычисления количества символов восстановления, а вместо этого получилось равным 2 в соответствии со способами, описанными в этом документе. В отличие от простого использования количества исходных символов фрагмента для определения количества символов восстановления, описанные выше варианты осуществления, позволяют вычислить позиционирование блока восстановления в сегменте восстановления исключительно из индексной информации, ассоциированной с соответствующим исходным блоком, соответствующим исходному сегменту. Кроме того, когда растет количество, K, исходных символов в исходном блоке, количество символов восстановления, KR, у соответствующего блока восстановления приблизительно выражается с помощью K*R, так как обычно KR не превышает ceil(K*R) и KR по меньшей мере равно floor((K-1)*R), где floor(x) является наибольшим целым числом не более x.

Существует много разновидностей вышеприведенных вариантов осуществления для формирования файловой структуры, которая может использоваться преимущественно клиентом, применяющим совместные способы HTTP/FEC, что признает специалист в данной области техники. В качестве примера альтернативного варианта осуществления, первоначальный сегмент для отображения может быть разделен на N>1 параллельных сегментов, где для i=1, …, N, заданная доля Fi исходного сегмента содержится в i-ом параллельном сегменте, и где сумма Fi для i=1, …, N равна 1. В этом варианте осуществления может быть одна главная карта сегмента, которая используется для получения карт сегментов для всех параллельных сегментов, аналогичному тому, как карта сегмента восстановления получается из карты исходного сегмента в описанном выше варианте осуществления. Например, главная карта сегмента может указывать структуру фрагмента, если все исходные мультимедийные данные не разделялись на параллельные сегменты, а вместо этого содержались в одном первоначальном сегменте, и тогда карту сегмента для i-ого параллельного сегмента можно получить из главной карты сегмента путем вычисления того, что если объем мультимедийных данных в первом префиксе фрагментов первоначального сегмента равен L байт, то общее количество байт этого префикса в агрегации среди первых i параллельных сегментов равно ceil(L*Gi), где Gi является суммой F_j по j=1, …, i. В качестве другого примера альтернативного варианта осуществления, сегменты могут состоять из сочетания исходных мультимедийных данных для каждого фрагмента с непосредственно следующими данными восстановления для того фрагмента, получая сегмент, который содержит смесь исходных мультимедийных данных и данных восстановления, сформированных с использованием кода FEC из тех исходных мультимедийных данных. В качестве другого примера альтернативного варианта осуществления сегмент, который содержит смесь исходных мультимедийных данных и данных восстановления, можно разделить на несколько параллельных сегментов, содержащих смесь исходных мультимедийных данных и данных восстановления.

СПОСОБЫ ОБРАБОТКИ ПОТОКОВОЙ ПЕРЕДАЧИ С МАЛОЙ ЗАДЕРЖКОЙ

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

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

Однако в условиях, где необходима передача с малой сквозной задержкой, длительность каждого сегмента должна быть короткой для минимизации задержки между действием прямой трансляции и представлением события прямой трансляции на клиенте. Желательно избежать вставки RAP в каждый сегмент, который нужно использовать для потоковой передачи с малой задержкой. Например, RAP в видео обычно реализуются кадрами IDR. Эффективность кодирования может быть улучшена избегая использования кадров IDR в коротких сегментах, желательных для потоковой передачи с малой задержкой.

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

Фиг. 30 иллюстрирует отношения между мультимедийными фрагментами для потоковой передачи с малой задержкой и мультимедийными фрагментами. Мультимедийный сегмент 3002, сформированный для потоковой передачи профиля прямой трансляции, содержит RAP 3004 в начале мультимедийных данных («mdat»). В противоположность, из мультимедийных фрагментов 3004, 3306 и 3008, сформированных для потоковой передачи с малой задержкой, только мультимедийный фрагмент 3004 содержит RAP.

Мультимедийные фрагменты формируются на лету и имеются в наличии для загрузки клиентами через HTTP. Мультимедийные фрагменты можно аккумулировать в мультимедийных сегментах совместимых с профилем прямой трансляции базового формата мультимедийного файла ISO, не требуя каких-либо модификаций в мультимедийных фрагментах. Например, мультимедийные фрагменты могут сцеплены в мультимедийные сегменты.

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

В некоторых вариантах осуществления, индекс сегмента (SIDX) формируется для каждого мультимедийного фрагмента. SIDX может включать в себя временной диапазон отображения в мультимедийном сегменте и соответствующий байтовый диапазон мультимедийного сегмента, занимаемый мультимедийным фрагментом. В некоторых вариантах осуществления, SIDX указывает на то, присутствует ли во фрагменте RAP. На Фиг. 30, поле contains_RAP блока SIDX мультимедийного фрагмента 3004 установлено равным 1, указывая на то, что мультимедийный фрагмент 3004 содержит RAP. Поле contains_RAP блока SIDX мультимедийных фрагментов 3006 и 3008 установлено равным 0, указывая на то, что мультимедийные фрагменты 3006 и 3008 не содержат RAP. SIDX может дополнительно указывать время представления первой RAP во фрагменте.

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

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

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

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

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

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

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

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

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

получают контент, подлежащий обслуживанию;

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

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

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

2. Способ по п. 1, в котором мультимедийный сегмент формируется посредством объединения множества мультимедийных фрагментов.

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

4. Способ по п. 1, дополнительно содержащий этап, на котором формируют один файл описания представления мультимедиа (MPD), который хранит информацию о первом отображении представления мультимедиа, содержащем множество мультимедийных сегментов, и втором отображении представления мультимедиа, содержащем множество мультимедийных фрагментов.

5. Способ по п. 4, в котором файл MPD содержит атрибут для указания частоты возникновения точек произвольного доступа во втором отображении.

6. Способ по п. 5, в котором частота является периодом времени.

7. Способ по п. 5, в котором частота является количеством мультимедийных фрагментов.

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

9. Сервер мультимедиа, содержащий:

процессор, выполненный с возможностью:

получения контента, подлежащего обслуживанию;

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

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

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

10. Сервер мультимедиа по п. 9, в котором мультимедийный сегмент формируется посредством объединения множества мультимедийных фрагментов.

11. Сервер мультимедиа по п. 10, в котором процессор дополнительно выполнен с возможностью формирования мультимедийного сегмента в кэше, и при этом после того, как мультимедийный сегмент сформирован в кэше, множество мультимедийных фрагментов, использованных для формирования мультимедийного сегмента, удаляется из кэша.

12. Сервер мультимедиа по п. 9, в котором процессор дополнительно выполнен с возможностью формирования одного файла описания представления мультимедиа (MPD), который хранит информацию о первом отображении представления мультимедиа, содержащем множество мультимедийных сегментов, и втором отображении представления мультимедиа, содержащем множество мультимедийных фрагментов.

13. Сервер мультимедиа по п. 12, в котором файл MPD содержит атрибут для указания частоты возникновения точек произвольного доступа во втором отображении.

14. Сервер мультимедиа по п. 13, в котором частота является периодом времени.

15. Сервер мультимедиа по п. 13, в котором частота является количеством мультимедийных фрагментов.

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

17. Постоянный машиночитаемый носитель, на котором сохранены машиноисполняемые инструкции, которые при исполнении одним или более вычислительными устройствами побуждают одно или более вычислительных устройств:

получать контент, подлежащий обслуживанию;

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

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

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

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