РАСШИРЕННАЯ СИСТЕМА ПОТОКОВОЙ ПЕРЕДАЧИ С ЗАПРОСОМ БЛОКОВ, ИСПОЛЬЗУЮЩАЯ СИГНАЛИЗАЦИЮ ИЛИ СОЗДАНИЕ БЛОКОВ Российский патент 2015 года по МПК H04L29/06 H04N7/24 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0088] Недавно стало обычной практикой рассматривать использование кодов с прямой коррекцией ошибок (FEC) для защиты потокового мультимедиа во время передачи. Когда послан по сети пакетной передачи, примеры которой включают в себя Интернет и беспроводные сети, такие как стандартизированные группами, такими как 3GPP, 3GPP2 и DVB, исходный поток помещается в пакеты, когда он генерируется, или сделан доступным, и таким образом пакеты могут быть использованы, чтобы переносить исходный поток или поток контента в порядке, в котором он генерируется, или сделан доступным, на приемники.

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

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

[0091] Есть много примеров кодов FEC, которые могут быть использованы, чтобы обеспечить защиту исходного потока. Коды Рида-Соломона являются хорошо известными кодами для коррекции ошибок и стираний в системах связи. Для коррекции стираний, например, в сетях пакетных данных, известная эффективная реализация кодов Рида-Соломона использует матрицы Каучи (Cauchy) или Вандермонда (Vandermonde), как описано в L. Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", ", Computer Communication Review, 27(2):24-36 (апрель 1997) (в дальнейшем "Rizzo") и Bloemer, et al, "An XOR-Based Erasure-Resilient Coding Scheme", Technical Report TR-95-48, International Computer Science Institute, Berkeley, California (1995) (в дальнейшем "XOR-Reed-Solomon") или в другом месте.

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

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

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

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

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

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

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

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

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

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

КРАТКИЙ ОБЗОР СИСТЕМЫ

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

[0103] На Фиг. 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, могут быть реализованы, по меньшей мере, частично, в программном обеспечении, содержащем программный код, который выполняется на процессоре или другой электронике.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0134] Некоторые CDNs предпочитают большие файлы и могут вызвать фоновые выборки всего файла из исходного сервера, сначала просматривая запрос диапазона. Большинство CDNs, однако, будет обслуживать запросы диапазона из кэша, если данные будут доступны. Может поэтому быть, выгодно иметь некоторую часть клиентских запросов целого файла сегмента. Эти запросы могут позже быть отменены в случае необходимости.

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

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

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

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

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

ИСПОЛЬЗОВАНИЕ СОЗДАНИЯ БЛОКОВ И/ИЛИ СИГНАЛИЗАЦИИ, ЧТОБЫ СДЕЛАТЬ БОЛЕЕ ЭФФЕКТИВНУЮ ПОТОКОВУЮ ПЕРЕДАЧУ

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

ИНДЕКСАЦИЯ В ПРЕДЕЛАХ СЕГМЕНТОВ

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

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

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

[0144] Различные варианты возможны, чтобы добавить данные времени и смещения в байтах фрагмента к файлам 3GPP:

[0145] Во-первых, Поле Произвольного доступа Фрагмента Кино ("MFRA") может использоваться с этой целью. MFRA обеспечивает таблицу, которая может помочь считывателям в обнаружении точек произвольного доступа в файле, использующем фрагменты кино. Для поддержки этой функции MFRA в связи с этим содержит смещения в байтах полей MFRA, содержащих точки произвольного доступа. MFRA может быть помещено в конец или около конца файла, но это не является обязательным случаем. Просматривая от конца файла в поиске Поля Смещения Произвольного доступа Фрагмента Кино и используя информацию размера в нем, можно быть в состоянии определить местонахождение начала Поля Произвольного доступа Фрагмента Кино. Однако размещение MFRA в конце для потоковой передачи HTTP обычно требует по меньшей мере 3-4 HTTP запроса, чтобы получить доступ к желательным данным: по меньшей мере один, чтобы запросить MFRA от конца файла, один, чтобы получить MFRA, и наконец один, чтобы получить желательный фрагмент в файле. Поэтому, размещение в начале может быть желательным, так как затем MFRA может быть загружено вместе с первыми данными мультимедиа в единственном запросе. Кроме того, использование MFRA для потоковой передачи HTTP может быть неэффективным, так как ни одна из информации в "MFRA" не является необходимой, кроме времени и moof_offset, и задание смещений вместо длин могут потребовать большего количества битов.

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

[0147] Последняя, и возможно самая подходящая, спецификация нового поля, названного Поле Индекса Времени ("TIDX"), специально назначенная с целью обеспечить точные времена или длительности фрагмента и смещение в байтах эффективным образом. Это описано более подробно в следующем разделе. Альтернативное поле с теми же самыми функциональными возможностями может быть Полем Индекса Сегмента ("SIDX"). Здесь, если иначе не обозначено, эти два могут быть взаимозаменяемыми, поскольку оба поля обеспечивают способность обеспечить точные времена или длительности фрагмента и смещение в байтах эффективным образом. Разность между TIDX и SIDX представлена ниже. Должно быть, очевидно, как взаимозаменять поля TIDX и поля SIDX, поскольку оба поля реализовывают индекс сегментов.

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

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

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

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

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

[0151] Фиг. 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) могут быть предоставлены для каждого компонента в сегменте абсолютным образом или они могут быть выражены относительно другого компонента мультимедиа, который служит опорным компонентом мультимедиа.

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

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

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

[0155] В дополнение к, или вместо, могут использоваться простая или иерархическая индексация, гирляндная индексация и/или гибридная индексация.

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

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

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

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

ПОЛЕ ИНДЕКСА ВРЕМЕНИ

[0160] Определение

[0161] Тип поля: 'tidx'

[0162] Контейнер: Файл

[0163] Обязательность: Нет

[0164] Количество: Любое число ноль или один

[0165] Поле Индекса Времени может обеспечить набор индексов времени и смещений в байтах, которые ассоциируют некоторые области файла с некоторыми временными интервалами представления. Поле Индекса Времени может включать в себя поле targettype (тип цели), которое указывает тип данных, на которые ссылаются. Например, Поле Индекса Времени с targettype равным "moof” обеспечивает индекс на Фрагменты Мультимедиа, содержащиеся в файле в терминах, как времени, так и в терминах смещений в байтах. Поле Индекса Времени с targettype Поля Индекса Времени может использоваться, чтобы построить иерархический индекс времени, позволяя пользователям файла быстро перейти к требуемой части индекса.

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

[0167] aligned(8) class TimelndexBox

extends FullBox('frai') {

unsigned int(32) targettype;

[0168] 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=l; i<= number_of_elements; i++)

{

bit (1) random_access_flag;

unsigned int(31) length;

unsigned int(32) deltaT;

}

}

[0169] Семантика

[0170] targettype: является типом данных поля, на которые ссылаются с помощью этого Поля Индекса Времени. Оно может быть или Заголовком Фрагмента Кино ("moof”) или Полем Индекса Времени ("tidx").

[0171] time_reference_track_id: указывает дорожку, относительно которой заданы смещения во времени в этом индексном файле.

[0172] number_of_elements: набор элементов, индексированных этим Полем Индекса Времени.

[0173] first_element_offset: смещение в байтах от начала файла первого индексированного элемента.

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

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

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

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

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

[0178] Поле Индекса сегментов ('sidx') обеспечивает компактный индекс (индексный файл) фрагментов кино, и другие поля Индекса Сегментов в сегменте. В Поле Индекса сегментов есть две структуры цикла. Первый цикл документирует первую выборку подсегментов, то есть, выборку в первом фрагменте кино, на которую ссылается второй цикл. Второй цикл обеспечивает индекс подсегмента. Контейнером для поля 'sidx' является файл или непосредственно сегмент.

[0179]

aligned(8) class SegmentlndexBox extends FullBox('sidx', version, 0) {

unsigned int(32) reference_track_ID;

unsigned int(16) track_count;

unsigned int(16) reference_count;

for (i=l ; 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;

}

}

[0180] Семантика:

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

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

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

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

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

[0186] reference_type: когда установлено в 0, указывает, что это ссылка на поле ('moof') фрагмента кино; когда установлено в 1, указывает, что это ссылка на поле ('sidx') индекса сегментов;

[0187] reference_offset: расстояние в байтах от первого байта после содержащего Поле Индекса Сегмента до первого байта поля, на которое ссылаются;

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

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

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

РАЗЛИЧИЯ МЕЖДУ TIDX И SIDX

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

[0192] Второй цикл SIDX реализовывает функциональные возможности TIDX. В частности, SIDX разрешает иметь смесь целей для ссылки для каждого индекса, указанного посредством reference_type, тогда как TIDX только указывает, или только TIDX, или только MOOF. Значение number_of_elements в TIDX соответствует reference_count в SIDX, time-reference_track_ID в TIDX соответствует reference_track_ID в SIDX, tfirst_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. Поэтому функциональные возможности этих двух полей эквивалентны.

РАЗДЕЛЕНИЕ НА БЛОКИ ПЕРЕМЕННОГО РАЗМЕРА И БЛОКИ SUB-GOP (ПОД-GOP)

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

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

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

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

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

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

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

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

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

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

[0203] Фиг. 6 показывает пример индексации сегментов, где блоки имеют переменный размер, и где размером блоков является частичная GoP, то есть, частичное количество данных мультимедиа между одной RAP и следующей RAP. В этом примере точки поиска обозначены индикатором RAP, в котором значение 1 индикатора RAP указывает, что блок начинается с или содержит RAP, или точку поиска, и в котором индикатор 0 RAP указывает, что блок не содержит RAP или точку поиска. В этом примере первые три блока, то есть байты 0 до 157033, содержат первую GoP, которая имеет длительность представления 1623 секунд, со временем представления, проходящим с 20 секунд в контенте до 21623 секунд. В этом примере первый из трех первых блоков содержит 0,485 секунды времени представления, и содержит первые 50245 байтов данных мультимедиа в сегменте. В этом примере блоки 4, 5 и 6 содержат вторую GoP, блоки 7 и 8 содержат третью GoP, и блоки 9, 10 и 11 содержат четвертую GoP. Следует отметить, что могут быть другие RAP в данных мультимедиа, которые не определяются как точки поиска, и таким образом не сообщаются в качестве RAP в карте сегментов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0218] Как описано в Pakzad, определение структуры блоков сегмента, включая блоки, которые охватывают частичные группы GoP или части более чем на GoP, может воздействовать на способность клиента разрешить быстрое время переключения канала. Согласно Pakzad, обеспечены способы, которые при заданном времени запуска обеспечивают структуру блоков и целевую скорость загрузки, которая может гарантировать, что, если клиент начал загружать представление с любой точки поиска и начал проигрывание после того, как целевое время запуска истекло, то проигрывание может продолжаться гладко, пока в каждой точке во времени количество данных, которые загрузил клиент, равно, по меньшей мере, целевой скорости загрузки, умноженной на истекшее время с начала загрузки. Выгодно для клиента иметь доступ к целевому времени запуска и целевой скорости загрузки, поскольку это предоставляет клиенту средство определить, когда начать проигрывать представление в самой ранней точке во времени, и позволяет клиенту продолжать проигрывать представление, пока загрузка удовлетворяет условию, описанному выше. Таким образом, способ, описанный ниже, обеспечивает средство для включения целевого времени запуска и целевой скорости загрузки в Описание Представления Мультимедиа, так чтобы оно могло использоваться в целях, описанных выше.

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

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

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

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

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

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

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

[0225] В дополнительном варианте осуществления изобретения сегменты мультимедиа могут быть совместимыми с Форматом Файла Мультимедиа на основе ISO, описанного в ISO/IEC 14496-12 или выведенных из него спецификациях (таким как формат 3GP-файла, описанный в 3GPP Technical Specification 26.244). Секция Использование Формата Файла 3GPP (выше) описывает новые расширения к Формату Файла Мультимедиа на основе ISO, разрешая эффективное использование структур данных этого формата файла в системе потоковой передачи с запросом блоков. Как описано в этой ссылке, информация может быть предоставлена в пределах файла, разрешающего быстрое и эффективное отображение между временными сегментами представления мультимедиа и диапазонами в байтах в пределах файла. Данные самого мультимедиа могут быть структурированы согласно конструкции Movie Fragment (Фрагмента Кино), определенному в ISO/IEC14496-12. Эта информация, обеспечивающая время и смещения в байтах, может быть структурирована иерархически или как единственный блок информации. Эта информация может быть предоставлена в начале файла. Предоставление этой информации, используя эффективное кодирование, как описано в секции Использование Формата Файла 3GPP приводит к тому, что клиент будет способен извлечь эту информацию быстро, например, используя частичный HTTP запрос GET, в случае, когда протоколом загрузки файла, используемым системой потоковой передачи с запросом блоков, является HTTP, что приводит к короткому запуску, поиску или времени переключения потока и поэтому к улучшенному пользовательскому опыту.

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

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

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

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

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

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

[0231] Элемент MediaPresentationDescription

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

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

[0234] Presentationldentifier: Информация такая, что представление может быть уникально идентифицировано среди других представлений. Может также содержать частные поля или названия.

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

[0236] MediaPresentationDescriptionURI: URI для того, чтобы датировать описание представления мультимедиа.

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

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

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

[0240] SafetyGuardlntervalLiveService: Информация относительно максимального времени цикла «живой» услуги в сервере. Предоставляет индикацию клиенту, какая информация уже доступна в текущее время. Эта информация может быть необходимой, если ожидается, что клиент и сервер будут работать во время UTC, и никакая жесткая синхронизация времени не предоставлена.

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

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

[0243] LivePresentationlnterval: Содержит временные интервалы, во время которых представление может быть доступным, задавая StartTimes и EndTimes. StartTime указывает начальное время услуги, и EndTime указывает время окончания услуги. Если EndTime не определено, то время окончания неизвестно в текущее время, и UpdateFrequency может гарантировать, что клиенты получают доступ ко времени окончания перед фактическим временем окончания услуги.

[0244] OnDemandAvailabilityInterval: Интервал представления указывает доступность услуги в сети. Могут быть обеспечены множественные интервалы представления. Клиент HTTP может быть не в состоянии получить доступ к услуге вне какого-либо заданного временного окна. Обеспечивая OnDemandAvailabilityInterval, дополнительный просмотр смещения во времени может быть определен. Этот атрибут может также присутствовать для «живой» услуги. В случае, если он присутствует для «живой» услуги, сервер может гарантировать, что клиент может получить доступ к услуге как к услуге OnDemand (по требованию) во время всех предоставленных интервалов доступности. Поэтому, LivePresentationlnterval может не перекрываться ни с каким OnDemandAvailabilitylnterval.

[0245] MPDFilelnfoDynamic: Описывает динамическую конструкцию файлов по умолчанию в представлении мультимедиа. Более подробно описано ниже. Спецификация по умолчанию на уровне MPD может сэкономить не необходимое повторение, если используются одинаковые правила для нескольких или всех альтернативных представлений.

[0246] MPDCodecDescription: Описывает главные кодеки по умолчанию в представлении мультимедиа. Более подробно описано ниже. Спецификация по умолчанию на уровне MPD может сэкономить не необходимое повторение, если используются одинаковые кодеки для нескольких или всех представлений.

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

[0248] FileURIPattern: шаблон, используемый клиентом, чтобы генерировать сообщения запроса для файлов в пределах представления мультимедиа. Различные атрибуты допускают генерирование уникальных указателей URI для каждого из файлов в пределах представления мультимедиа. Основные URI могут быть URI HTTP.

[0249] Альтернативное Представление: Описывает список представлений.

[0250] Элемент AlternativeRepresentation:

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

[0252] RepresentationID: уникальный ID для этого конкретного Альтернативного Представления в пределах представления мультимедиа.

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

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

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

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

[0257] Элемент Описания Мультимедиа

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

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

[0260] TrackID: уникальный ID для дорожки в пределах альтернативного представления. Он может использоваться в случае, если дорожка является частью описания группирования.

[0261] Bitrate: скорость передачи в битах дорожки.

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

[0263] MediaName: атрибут, определяющий тип мультимедиа. Виды мультимедиа включают в себя "аудио", "видео", "текст", "приложение", и "сообщение".

[0264] Codec: Тип кодека, включающий профиль и уровень.

[0265] LanguageTag: Тэг языка, если применимо.

[0266] Макс Width, MaxHeight: Для видео - высота и ширина содержащегося видео в пикселях.

[0267] SamplingRate: Для аудио - частота выборок

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

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

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

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

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

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

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

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

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

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

[0277] (3) Третье, добавить глобальное время или точное начальное время относительно объявленного начального времени представления или объявленного начального времени сегмента в MPD для сегмента в том смысле, что сегмент содержит эту информацию. Она может быть добавлена к новому полю, выделенному адаптивной передаче в виде потока. Это поле может также включать в себя информацию в соответствии с полем "SIDX" или "TIDX". Следствием этого третьего подхода является то, что при поиске конкретной позиции около начала одного из сегментов клиент, на основании MPD, может выбрать последующий сегмент для того сегмента, который содержит необходимую точку поиска. Простым ответом в этом случае может быть переместить начальную точку вперед к началу извлеченного сегмента (то есть, к следующей Точке Произвольного доступа после этой точки поиска). Обычно, Точки Произвольного доступа предоставляются, по меньшей мере, каждые несколько секунд (и часто есть небольшой выигрыш кодирования от создания их менее частыми), и таким образом, в худшем случае точка поиска может быть перемещена, чтобы быть на несколько секунд позже, чем заданная. Альтернативно, клиент может определить при восстановлении информации заголовка для сегмента, что запрошенная точка поиска находится фактически в предыдущем сегменте и запросить вместо данной такой сегмент. Это может привести к случайному увеличению во времени, требуемом для выполнения операции поиска.

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

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

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

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

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

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

[0283] Предположим, что список сегментов, каждый с начальным временем, tS, описан или явно посредством проигрывания в элементах, таких как FilelnfoStatic, или неявно посредством использования элемента, такого как FilelnfoDynamic. Предпочтительный способ, чтобы сгенерировать список сегментов, используя FilelnfoDynamic, описан ниже. На основании этом правила конструирования клиент имеет доступ к списку URI для каждого представления, r, упомянутого здесь как FileURI (r, z), и начальному времени tS (r, i) для каждого сегмента с индексом i.

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

[0285] Для услуги типа "по требованию", что предпочтительно указано атрибутом, таким как Service, если текущее время настенных часов в клиенте NOW находится в пределах какого-нибудь диапазона доступности, предпочтительно выраженного элементом MPD, таким как OnDemandAvailabilitylnterval, то все описанные сегменты этого представления «по требованию» являются доступными. Если текущее время настенных часов в клиенте NOW находится вне какого-нибудь диапазона доступности, то ни один из описанных сегментов этого представления «по требованию» не доступен.

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

[0287] Если текущее время настенных часов в клиенте NOW находится вне какого-либо диапазона интервала «живого» представления, предпочтительно выраженного элементом MPD, таким как LivePresentationlnterval, то ни один из описанных сегментов этого живого представления не является доступным. Если текущее время настенных часов в клиенте NOW находится в пределах интервала «живого» представления, то, по меньшей мере, некоторые сегменты описанных сегментов этого «живого» представления могут быть доступными.

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

[0289] Время NOW настенных часов (в качестве доступного для клиента).

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

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

ОБНОВЛЕНИЕ MPD

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

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

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

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

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

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

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

[0299] Две возможности могут существовать для тактирования мультимедиа при обновлении MPD для набора представлений или всех представлений. Или (a) существующая шкала глобального времени продолжается через обновление MPD (упомянутое здесь как "непрерывное обновление MPD"), или (b), шкала текущего времени заканчивается, и новая шкала времени начинается с сегмента, следующего после изменения (упомянутое здесь как "прерывистое обновление MPD").

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

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

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

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

[0304] Эти два случая иллюстрируются на Фиг. 11.

[0305] Предпочтительно и выгодно ограничить обновления MPD, чтобы сегментировать границы. Объяснения для ограничения таких изменений или обновлений границ сегментов следующие. Во-первых, изменения к двоичным метаданным для каждого представления, обычно Заголовка Кино, могут иметь место, по меньшей мере, по границам сегмента. Во-вторых, Описание Представления Мультимедиа может содержать указатели (URL) на сегменты. В некотором смысле MPD является структурой данных "зонтик", группирующей все файлы сегмента, ассоциированные с представлением мультимедиа. Чтобы поддерживать эти отношения ограничения, на каждый сегмент можно ссылаться посредством единственного MPD и когда MPD обновлен, оно предпочтительно обновляется только по границе сегмента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0322] Указание изменений набора кодированных двоичных метаданных представления, таких как изменения заголовка кино "moov" могут быть достигнуты по-разному: (a) может быть одно поле moov для всего представления в отдельном файле, на который ссылаются в MPD, (b) может быть одно поле moov для каждого альтернативного представления в отдельном файле, на который ссылаются в каждом Альтернативном Представлении, (c), каждый сегмент может содержать поле moov и является, поэтому отдельным, (d) может быть поле moov для всего представления в одном 3GP файле вместе с MPD.

[0323] Следует отметить, что в случае (a) и (b) единственное 'moov' может быть предпочтительно объединено с понятием достоверности выше в том смысле, что на большее количество 'moov' полей можно сослаться в MPD, пока их достоверность является несвязной. Например, с определением границы периода достоверность 'moov' в старом периоде может истечь с началом нового периода.

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

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

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

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

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

[0328] Примеры изменений включают в себя дополнение или удаление представлений, изменения к одному или более представлениям, такие как изменение в скорости передачи в битах, разрешения, формата изображения, включенных дорожек или параметров кодека, и изменения правил построения URL, например, другой исходный сервер для рекламы. Некоторые изменения могут затронуть только сегмент инициализации, такой как элемент, Заголовок Кино ("moov"), ассоциированный с представлением, тогда как другие изменения могут затронуть Описание Представления Мультимедиа (MPD).

[0329] В случае контента «по требованию» эти изменения и их тактирование могут быть известны заранее и могут быть сообщены в Описании Представления Мультимедиа.

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

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

[0332] Решения описаны и предложены, чтобы обеспечить обновление метаданных, включая описание представления мультимедиа и двоичные метаданные представления, такие как элементы "moov" в представлении адаптивного потокового мультимедиа HTTP.

[0333] Для случая «живого» контента точки, в которых могут измениться MPD или "moov", могут не быть известны, когда MPD строится. Поскольку частого "опроса" MPD, чтобы проверить на обновления, необходимо обычно избегать по причинам полосы частот и масштабируемости, обновления к MPD могут быть обозначены "в диапазоне" в самих файлах сегментов, то есть, каждый сегмент мультимедиа может иметь опцию, чтобы указать обновления. В зависимости от форматов (a)-(c) сегментов выше, различное обновление может быть сигнализировано.

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

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

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

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

[0338] Поле информации потоковой передачи

[0339] Определение

[0340] Тип Поля: 'sinf'

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

Обязательность: Нет

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

[0341] Поле Информации Потоковой Передачи содержит информацию о текущем представлении, частью которого является файл.

[0342] Синтаксис

[0343] aligned(8) class StreaminglnformationBox

extends FullBox('sinf') {

unsigned int(32) streaming_information_flags;

[0344] / Следующие поля являются опциональными

string mpd_location

}

[0345] Семантика

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

[0347] 0x00000001 Обновление Заголовка Кино следует

[0348] 0x00000002 Обновление Описания Представления

[0349] 0x00000004 Конец представления

[0350] mpd_location присутствует, если и только если флаги Обновления Описания Представления установлены и обеспечивает Унифицированный Указатель Ресурса для нового Описания Представления Мультимедиа.

ПРИМЕРНЫЙ СЛУЧАЙ ИСПОЛЬЗОВАНИЯ ОБНОВЛЕНИЙ MPD ДЛЯ «ЖИВЫХ» УСЛУГ

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

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

[0353] Предположим, что пользователь, Анна, получает доступ к услуге в автобусе с помощью ее мобильного устройства, и услуга доступна немедленно. Рядом с нею сидит другой пользователь, Пол, который просматривает событие на своем ноутбуке. Забит гол, и оба празднуют это событие в одно и то же время. Пол говорит Анне, что первый гол в игре был еще более захватывающим, и Анна использует услугу так, чтобы она могла просмотреть событие 30 минут назад во времени. После просмотра гола, она возвращается к «живому» (в реальном времени) событию.

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

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

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

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

[0358] "Время публикации" MPD обеспечивает уникальный идентификатор для MPD, и когда MPD было выпущено. Это также обеспечивает привязку для процедур обновления.

[0359] Поле обновления MPD может быть найдено в MPD после поля "styp", и определено Типом Поля = "mupe", не нуждаясь ни в каком контейнере, не будучи обязательным и имеющим количество ноль или один. Поле обновления MPD содержит информацию о представлении мультимедиа, частью которого является сегмент.

[0360] Примерный синтаксис следующий:

[0361] aligned(8) class MPDUpdateBox

[0362] extends FullBox('mupe') {

[0363] unsigned int(3) mpd_information_flags;

[0364] unsigned int(l) new_location_flag;

[0365] unsigned int(28) latest_mpd_update_time;

[0366] /// Следующее является опциональными полями

[0367] string mpd_location

[0368] }

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

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

[0371] 0×00 Описание Представления Мультимедиа обновить теперь

[0372] 0×01 Описание Представления Мультимедиа обновить в будущем

[0373] 0×02 Конец представления

[0374] 0×03-0×07 зарезервировано

[0375] new_location_flag: если установлен в 1, то новое Описание Представления Мультимедиа доступно в новом местоположении, определенном посредством mpd_location.

[0376] latest_mpd_update_time: определяет время (в миллисекундах), когда обновление MPD необходимо относительно времени выпуска MPD самого последнего MPD. Клиент может выбрать обновить MPD любое время между теперь.

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

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

ПРОСМОТР СМЕЩЕНИЯ ВО ВРЕМЕНИ И PVR СЕТИ

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

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

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

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

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

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

ПРИМЕРНЫЙ КЛИЕНТ, ВКЛЮЧАЮЩИЙ В СЕБЯ ГЕНЕРИРОВАНИЕ СПИСКА СЕГМЕНТОВ

[0384] Примерный клиент описан ниже. Он может использоваться как эталонный клиент для сервера, чтобы гарантировать надлежащее генерирование и обновления MPD.

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

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

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

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

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

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

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

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

[0392] Клиент использует правила построения URL и тактирование как, например, определено дополнительно здесь. Как только список описанных сегментов получен, этот список далее ограничивается доступными сегментами, которые могут быть поднабором сегментов полного представления мультимедиа. Конструкция управляется текущим значением часов во времени NOW клиента. Обычно сегменты только доступны в течение любого времени NOW в пределах набора времен доступности. В течение времен NOW вне этого окна, никакие сегменты не доступны. Кроме того, для услуг в реальном времени («живых»), предположим, что некоторое временное контрольное время предоставляет информацию о том, как далеко в будущее мультимедиа описано. Контрольное время определено на оси времени MPD-задокументированного мультимедиа; когда клиентское время воспроизведения достигает контрольного времени, оно предпочтительно запрашивает новое MPD.

[0393] Когда клиентское время воспроизведения достигает контрольного времени, оно предпочтительно запрашивает новое MPD.

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

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

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

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

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

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

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

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

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

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

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

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

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

КОМБИНАЦИИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0420] 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 имеет место, когда больше данных было принято, чем необходимо, чтобы проигрываться в течение времени (Tnow-t); B_current будет увеличиваться с момента времени t до времени T_now.

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

[0422] Функция 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 или от других факторов.

[0423] В конкретном варианте осуществления разделение, описанное выше, может быть основано на таблице конфигурации, содержащей многие пороговые значения для 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. Эти пороговые значения определяют разделение, содержащее (n1+1)×(n2+1) сетку ячеек, где i-я ячейка j-й строка соответствует области, в которой B_r-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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПЕРЕМЕННОЕ ИЗМЕНЕНИЕ РАЗМЕРОВ ЗАПРОСА

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

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

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

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

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

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

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

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

[0447] Другой вариант осуществления показан на Фиг. 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0459] Тест на этапе 1430 может быть применен к совокупности всех активных соединений на интерфейсе, как объяснено более подробно ниже.

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

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

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

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

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

[0465] Предположим, что для всех соединений ответом на тест, описанный на этапе 1430 со времени t до некоторого более позднего времени t', является "Нет", и между временем t и t' запрос А изменяет свой приоритет от 0 на 5, запрос B удаляется из списка кандидатов, и новый запрос G с приоритетом 0 добавляется к списку кандидатов. Затем во время t' новый список кандидатов может быть, как показано на Фиг. 19.

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

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

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

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

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

[0471] Эти способы могут быть предпочтительно объединены со скоординированными HTTP и FEC.

ВЫБОР СООТВЕТСТВУЮЩЕГО СЕРВЕРА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КОНСТРУКЦИЯ URL И ГЕНЕРИРОВАНИЕ СПИСКА СЕГМЕНТОВ И ПОИСК

[0488] Генерирование списка сегментов имеет дело с проблемой того, как клиент может сгенерировать список сегментов из MPD в конкретное локальное клиентское время NOW для конкретного представления, которое начинается в некоторое начальное время (starttime) или относительно начала представления мультимедиа для случаев по требованию или выраженных во времени «настенных часов». Список сегментов может содержать указатель, например URL, на необязательные начальные метаданные представления, а также список сегментов мультимедиа. Каждому сегменту мультимедиа может быть назначено начальное время, длительность и указатель. Начальное время обычно выражает приближение времени мультимедиа содержащегося в сегменте мультимедиа, но не обязательно точное время выборки. Начальное время используется клиентом потоковой передачи HTTP, чтобы выдать запрос загрузки в подходящее время. Генерирование списка сегментов, включая начальное время каждого, может быть сделано разными способами. URL могут быть обеспечены как список проигрывания, или правило построения URL может предпочтительно использоваться для компактного представления списка сегментов.

[0489] Список сегментов, основанный на построении URL, может, например, быть выполнен, если MPD сигнализирует это конкретным атрибутом или элементом, таким как FileDynamicInfo или эквивалентным сигналом. Общий способ создать список сегментов из конструкции URL предложен ниже в секции "Обзор конструкции URL”. Основанная на списке воспроизведения конструкция может, например, быть сигнализирована различным сигналом. Поиск в списке сегментов и получение точного времени мультимедиа также предпочтительно реализуется в этом контексте.

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

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

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

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

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

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

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

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

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

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

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

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

[0500] <expression>, совместимое с продукцией <lateral> не изменяется.

[0501] <expression>, совместимое с продукцией <variable> (<переменная>), заменяется значением переменной, идентифицированной строкой <token> (<маркер>) продукции <variable>.

[0502] <expression>, совместимое с продукцией <function> (<функция>), оценивается посредством оценки каждого из его аргументов согласно этим правилам и применяя преобразование к этим аргументам, в зависимости от элемента <token> продукции <функция>, как описано ниже.

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

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

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

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

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

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

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

[0510] Другим примером оператора является оператор последовательности, идентифицированный продукцией <operator> ';'. Результат оценки этого оператора является правый аргумент. Следует отметить, что как и со всеми операторами, оба аргумента оцениваются, и левый аргумент оценивается первым.

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

[0512] Фиг. 23 иллюстрирует некоторые примеры правил построения идентификатора файла, когда входными переменными являются "id", задающая идентификатор для представления желательного представления, и "seq", задающая последовательный номер для файла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0526] FileURIFormat=sprintf ("%s%s%s%s%s. %s", BaseURI, BaseFileName,

[0527] RepresentationlDFormat, SeparatorFormat,

[0528] FileSequencelDFormat, FileExtension);

[0529] и FileURI (r, i) построен как

[0530] FileURI (r, i)=sprintf (FileURIFormat, r, i);

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

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

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

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

ПОИСК

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

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

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

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

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

[0539] Как описано здесь, должно быть, очевидно, как реализовать клиент прямой потоковой передачи 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

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

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

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

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

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

[0545] В качестве примера, предположим 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 Кб/сек может быть поддержан с одним соединением.

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

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

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

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

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

[0550] Краткий обзор способа без - FEC описан ниже, который является способом совместного запроса HTTP/TCP, в котором только данные мультимедиа исходных блоков запрашиваются, используя множественные одновременные соединения HTTP/TCP, то есть, никаких FEC-исправленных данных не запрашивают. В способе без - FEC части одного и того же фрагмента запрашивают по различным соединениям, например, используя запросы диапазонов в байтах HTTP для частей фрагмента, и таким образом, например, каждый запрос диапазона в байтах HTTP предназначен для части диапазона в байтах, обозначенного в карте сегментов для этого фрагмента. Может иметь место случай, что отдельный запрос HTTP/TCP повышает свою скорость доставки, чтобы полностью использовать доступную полосу частот посредством нескольких RTT (времен передачи туда и обратно), и таким образом имеется относительно длительный период времени, когда скорость доставки меньше, чем доступная полоса частот, и таким образом, если единственное соединение HTTP/TCP используется, чтобы загрузить, например, первый фрагмент контента, который должен быть проигран, время переключения канала может быть большим. Используя способ без - FEC, загрузка различных частей одного и того же фрагмента по различным соединениям HTTP/TCP может значительно уменьшить время переключения канала.

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

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

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

[0554] Фиг. 26 является увеличенным изображением первых двух секунд 5 TCP-соединений, показанных на Фиг. Фиг. 24 (a)-(e), где на Фиг. 26 ось X показывает время с промежутками в 100 миллисекунд, и ось Y показывает скорость, с которой биты, принимаются в клиенте по каждому из 5 TCP-соединений, измеренных по интервалам 100 миллисекунд. Одна линия показывает совокупное количество битов, которое было принято в клиенте для этого фрагмента из первых 4 соединений HTTP (исключая соединение HTTP, по которому запрошены данные FEC), то есть, которые прибывают, не используя способ без - FEC. Другая линия показывает совокупное количество битов, которое было принято в клиенте для фрагмента от всех 5 из соединений HTTP (включая соединение HTTP, по которому запрошены FEC-данные), то есть, которые прибывают, используя способ FEC. Для способа FEC предполагается, что фрагмент может быть FEC декодированным из приема любых 200000 битов из 250000 запрошенных битов, которые могут быть реализованы, если используется, например, код 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 в худшей случае.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0568] Количество исходных символов в исходном блоке, соответствующих фрагменту 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.

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

[0570] Информация индексации исправления и информация 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 и информации индексации для соответствующего фрагмента соответствующего исходного сегмента.

[0571] В качестве примера, рассмотрим пример, показанный на Фиг. 28, показывающий фрагмент 2, который начинается при смещении в байтах B(l)=6410, и заканчивается при смещении в байтах B(2)=6770. В этом примере размер символа равен S=64 байта, и пунктирные вертикальные линии показывают смещения в байтах в исходном сегменте, которые соответствуют множеству S. Полный размер исправленного сегмента как доли размера исходного сегмента установлен в R=0,5 в этом примере. Количество исходных символов в исходном блоке для фрагмента 2 вычисляют как NSS(2)=ceiling((6770-6410)/64)=ceiling(5,625)=6, и эти 6 исходных символов имеют ESI 0, 5, соответственно, при этом первый исходный символ составляет первые 64 байта фрагмента 2, который начинается в индексе 6410 байтов в исходном сегменте, второй исходный символ составляет следующие 64 байта фрагмента 2, который начинается в индексе 6474 байтов в исходном сегменте, и т.д. Конечное смещение в байтах исправленного блока, соответствующего фрагменту 2, вычисляется как RB(2)=64*ceiling (0,5*6770/64)=64*ceiling (52,89)=64*53=3392, и начальное смещение в байтах исправленного блока, соответствующего фрагменту 2, вычисляется как RB(1)=64*ceiling (0,5*6410/64)=64*ceiling (50,07)=64*51=3264, и таким образом в этом примере имеются два исправленных символа в исправленном блоке, соответствующем фрагменту 2 с ESI 6 и 7, соответственно, начинающиеся при смещении в байтах 3264 в исправленном сегменте, и заканчивающиеся при смещении в байтах 3392.

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

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

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

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

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

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

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

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

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

5. Способ по п.4,в котором запросами файлов являются НТТР-запросы.

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

7. Способ по п.1, в котором сегмент из множества сегментов включает в себя группу картинок (GoP), и при этом группу картинок разделяют на больше чем один блок.

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