ОБНОВЛЕНИЕ ФАЙЛА МАНИФЕСТА ДЛЯ СЕТЕВОЙ ПОТОКОВОЙ ПЕРЕДАЧИ КОДИРОВАННЫХ ВИДЕОДАННЫХ Российский патент 2015 года по МПК H04L29/06 

Область техники, к которой относится изобретение

Это раскрытие относится к хранению и транспортировке закодированных мультимедийных данных.

Уровень техники

Возможности цифрового видео могут быть встроены в широкий спектр устройств, включая цифровые телевизоры, системы прямого цифрового вещания, системы беспроводного вещания, карманные персональные компьютеры (PDA), ноутбуки или настольные компьютеры, цифровые фотоаппараты, устройства цифровой записи, цифровые медиапроигрыватели, видеоигровые устройства, игровые приставки, сотовые или спутниковые радиотелефоны, устройства видеоконференц-связи и т.п. Цифровые видеоустройства реализуют методы сжатия видео, например, описанные в стандартах, определенных в MPEG-2, MPEG-4, ITU-T H.263 или ITU-T H.264/MPEG-4, Часть 10, Усовершенствованное кодирование видео (AVC), и расширениях таких стандартов, для более эффективной передачи и приема цифровой видеоинформации.

Методы сжатия видео выполняют пространственное предсказание и/или временное предсказание для уменьшения или устранения избыточности, присущей последовательностям видеокадров. При блочном видеокодировании видеокадр или секция могут быть разделены на макроблоки. Каждый макроблок может быть дополнительно разделен. Макроблоки в кадре или секции с внутренним кодированием (I) кодируются с использованием пространственного предсказания по отношению к соседним макроблокам. Макроблоки в кадре или секции с межкадровым кодированием (P или B) могут использовать пространственное предсказание по отношению к соседним макроблокам в том же самом кадре или секции или временное предсказание по отношению к другим опорным кадрам.

После того как видеоданные были закодированы, видеоданные могут быть пакетированы для передачи или хранения. Видеоданные могут быть собраны в видеофайл, соответствующий любому из множества стандартов, таких как основной формат медиафайла Международной организации по стандартизации (ISO) и его расширения, такие как ITU-T H.264/AVC. Такие пакетированные видеоданные могут транспортироваться множеством путей, например, посредством передачи по компьютерной сети с помощью сетевой потоковой передачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

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

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

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

В некоторых случаях пользователь может пожелать воспроизвести видеоданные иным образом, не от начала до конца. Например, пользователь может пожелать воспроизвести видеоданные в режиме ускоренной перемотки вперед или перемотки назад, или начиная с конкретной точки воспроизведения. Такие режимы воспроизведения видео, которые являются режимами, отличающимися от воспроизведения от начала до конца, могут упоминаться как "нестандартные режимы". В нестандартных режимах, так как не все видеоданные будут, в конечном счете, воспроизведены, нет необходимости получать все видеоданные. Это раскрытие также обеспечивает методы для поддержки нестандартных режимов. Например, устройство подготовки контента может обеспечить указания относительно местоположения диапазонов байтов кадров в видеоданных, используемых для нестандартных режимов, например, изображений мгновенного обновления декодера (IDR). В общем, изображения IDR могут декодироваться независимо от данных любых кадров, являющихся внешними по отношению к самим изображениям IDR. Кадры или секции изображений IDR, как правило, кодируются в режиме внутреннего предсказания, чтобы избежать зависимостей от других кадров или секций. Таким образом, клиентское устройство может получить информацию, указывающую местоположения изображений IDR для загрузки только данных для изображений IDR для использования в отображении видеоданных в нестандартном режиме, например ускоренной перемотке вперед. Во временной подпоследовательности также могут быть включены другие данные. Данные могут быть расположены в порядке кодирования, так что данные, используемые для ссылки, имеют место раньше, чем (и в непрерывной последовательности байтов) ссылающиеся данные. Например, I-кадр может предшествовать P-кадру, за которым может следовать один или более B-кадров, любой или все из которых могут предшествовать другим B-кадрам, которые могут ссылаться на более ранние B-кадры в иерархическом порядке.

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

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

Видеофайлы, например сегменты представлений медиаконтента, могут соответствовать видеоданным, инкапсулированным согласно любому базовому формату ISO мультимедийных файлов, формату файлов масштабируемого видеокодирования (SVC), формату файлов усовершенствованного видеокодирования (AVC), формату файлов Проекта партнерства третьего поколения (3GPP) и/или формату файлов многовидового видеокодирования (MVC) или другим подобным форматам видеофайлов.

Базовый формат ISO мультимедийных файлов предназначен для хранения синхронизированной медиаинформации для презентации в гибком, расширяемом формате, который делает возможными обмен, управление, редактирование и презентацию медиа-информации. Базовый формат ISO мультимедийных файлов (ISO/IEC 14496-12:2004) указан в MPEG-4 Часть-12, которая определяет общую структуру для синхронизированных медиафайлов. Базовый формат ISO мультимедийных файлов используется как базис для других форматов файлов в семействе, например формата файлов AVC (ISO/IEC 14496-15), определяющего поддержку для H.264/MPEG-4 AVC сжатия видео, формата файлов 3GPP, формата файлов SVC и формата файлов MVC. Формат файлов 3GPP и формат файлов MVC являются расширениями формата файлов AVC. Базовый формат ISO мультимедийных файлов содержит синхронизацию, структуру и медиаинформацию для синхронизированных последовательностей медиаданных, таких как аудио-визуальные презентации. Файловая структура может быть объектно-ориентированной. Файл может быть очень просто разделен на базовые объекты, и структура объектов вытекает из их типа.

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

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

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

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

Методы этого раскрытия могут быть применимы к сетевым протоколам потоковой передачи, такими как потоковая передача по HTTP, например, в соответствии с динамической адаптивной потоковой передачей по HTTP (DASH). В потоковой передаче по HTTP часто используемые операции включают в себя операции GET и partial (частичный) GET. Операция GET возвращает целый файл, соответствующий данному унифицированному указателю ресурсов (URL) или другому идентификатору, например, URI. Операция partial GET принимает диапазон байтов как входной параметр и возвращает непрерывное число байтов файла, соответствующее принятому диапазону байтов. Таким образом, фрагменты фильма могут быть обеспечены для потоковой передачи по HTTP, потому что операция partial GET может получить один или более отдельных фрагментов фильма. Следует отметить, что во фрагменте фильма может быть несколько фрагментов различных дорожек. При потоковой передаче по HTTP представление медиаданных может быть структурированным набором данных, которые доступны для клиента. Клиент может запросить и загрузить информацию о медиаданных, чтобы предоставить службу потоковой передачи пользователю.

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

Мультимедийный контент может содержать последовательность из одного или более периодов. Периоды могут быть определены элементом Period (Период) в MPD. Каждый период может иметь атрибут start (начало) в MPD. MPD может включать в себя атрибут start и атрибут availableStartTime (возможноеВремяНачала)} для каждого периода. Для услуг прямой трансляции сумма атрибута start периода и атрибута MPD availableStartTime может указывать время доступности периода в формате UTC, в частности первый Сегмент медиаданных каждого представления в соответствующий период. Для услуг по требованию атрибут start первого периода может быть 0. Для любого другого периода атрибут start может указывать смещение времени между временем начала соответствующего Периода относительно времени начала первого Периода. Каждый период может простираться до начала следующего Периода или до конца медиапрезентации в случае последнего периода. Время начала Периодов может быть точными. Оно может отражать фактический момент, следующий из воспроизведения медиаданных всех предшествующих периодов.

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

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

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

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

Фиг. 1 является блок-схемой, изображающей примерную систему 10, которая реализует методы для потоковой передачи медиаданных по сети. В этом примере система 10 включает в себя устройство 20 подготовки контента, серверное устройство 60 и клиентское устройство 40. Клиентское устройство 40 и серверное устройство 60 коммуникативно связаны сетью 74, которая может включать в себя Интернет. В некоторых примерах устройство 20 подготовки контента и серверное устройство 60 могут также быть связаны сетью 74 или другой сетью, или могут быть коммуникативно соединены напрямую. В некоторых примерах устройство 20 подготовки контента и серверное устройство 60 могут включать в себя одно и то же устройство.

Устройство 20 подготовки контента в примере на фиг. 1 содержит аудиоисточник 22 и видеоисточник 24. Аудиоисточник 22 может содержать, например, микрофон, который создает электрические сигналы, представляющие собой захваченные аудиоданные для кодирования аудиокодером 26. Альтернативно, аудиоисточник 22 может содержать носитель данных, хранящий ранее записанные аудиоданные, генератор аудиоданных, такой как компьютеризированный синтезатор, или любой другой источник аудиоданных. Видеоисточник 24 может содержать видеокамеру, которая создает видеоданные для кодирования видеокодером 28, носитель данных, закодированный с ранее записанными видеоданными, блок генерирования видеоданных, такой как источник компьютерной графики, или любой другой источник видеоданных. Устройство 20 подготовки контента не обязательно коммуникативно связано с серверным устройством 60 во всех примерах, а может сохранять мультимедийный контент на отдельный носитель, который считывается серверным устройством 60.

Необработанные аудио- и видеоданные могут содержать аналоговые или цифровые данные. Аналоговые данные могут быть оцифрованы перед кодированием аудиокодером 26 и/или видеокодером 28. Аудиоисточник 22 может получать аудиоданные от говорящего участника, пока участник говорит, а источник видеосигнала 24 может одновременно получать видеоданные говорящего участника. В других примерах аудиоисточник 22 может содержать компьютерно-читаемый носитель данных, содержащий сохраненные аудиоданные, а видеоисточник 24 может содержать компьютерно-читаемый носитель данных, содержащий сохраненные видеоданные. Таким образом, методы, описанные в этом раскрытии, могут быть применены к аудио- и видеоданным в режиме прямой трансляции, потоковой передачи или в режиме реального времени или к заархивированным, предварительно записанным аудио- и видеоданным.

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

В некоторых примерах аудиокодер 26 может закодировать метку времени в каждом закодированном аудиокадре, которая представляет время, в которое были записаны аудиоданные для закодированного аудиокадра, и, аналогично, видеокодер 28 может закодировать метку времени в каждом закодированном видеокадре, которая представляет собой время, в которое были записаны видеоданные для закодированного видеокадра. В таких примерах аудиокадр, соответствующий видеокадру, может содержать аудиокадр, содержащий метку времени, и видеокадр, содержащий ту же самую метку времени. Устройство 20 подготовки контента может включать в себя внутренние часы, из которых аудиокодер 26 и/или видеокодер 28 могут генерировать метки времени, или которые аудиоисточник 22 и видеоисточник 24 могут использовать для связи аудиоданных и видеоданных, соответственно, с меткой времени.

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

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

Как и многие стандарты видеокодирования, H.264/AVC определяет синтаксис, семантику и процесс декодирования для битовых потоков без ошибок, любой из которых соответствует некоторому профилю или уровню. H.264/AVC не конкретизирует кодер, но кодер должен гарантировать, что генерируемые битовые потоки совместимы со стандартами для декодера. В контексте стандарта видеокодирования "профиль" соответствует подмножеству алгоритмов, возможностей или инструментов и ограничений, которые применяются к ним. Например, как определено стандартом H.264, "профиль" - это подмножество всего синтаксиса битового потока, который определен стандартом H.264. "Уровень" соответствует ограничениям потребления ресурсов декодером, таких как, например, память декодера и вычисления, которые связаны с разрешением изображений, битовая скорость и скорость обработки макроблоков (MB). О профиле можно сообщить с помощью значения profile_idc (индикатор профиля), а об уровне можно сообщить с помощью значения level_idc (индикатор уровня).

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

Декодер, соответствующий профилю, обычно поддерживает все возможности, определенные в профиле. Например, как возможность кодирования, кодирование с B-изображениями не поддерживается в базовом профиле H.264/AVC, но поддерживается в других профилях H.264/AVC. Декодер, соответствующий уровню, должен быть способен декодировать любой битовый поток, который не требует ресурсов вне ограничений, определенных в уровне. Определения профилей и уровней могут быть полезными для интерпретируемости. Например, во время передачи видео пара определений профиля и уровня может согласовываться и быть согласованной для всего сеанса передачи. В частности, в H.264/AVC уровень может определять, например, ограничения на число макроблоков, которые должны быть обработаны, размер буфера декодированных изображений (DPB), размер буфер кодированных изображений (СРВ), диапазон вектора вертикального движения, максимальное число векторов движения на два последовательных MB и может ли B-блок иметь области подмакроблоков меньше, чем 8×8 пикселей. Таким образом, декодер может определить, способен ли декодер должным образом декодировать битовый поток.

Стандарты сжатия видео, такие как ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 часть 10 и будущий стандарт Высокоэффективного видеокодирования (HEVC), используют временное предсказание с компенсацией движения для уменьшения временной избыточности. Кодер, такой как видеокодер 28, может использовать предсказание с компенсацией движения от некоторых ранее закодированных изображений (также называемых здесь кадрами) для предсказания текущих кодированных изображений согласно векторам движения. Есть три основных типа изображений в типичном видеокодировании. Это изображение с внутренним кодированием ("I-изображения" или "I-кадры"), изображения с предсказанием ("P-изображения" или "P-кадры") и изображения с предсказанием вперед/назад ("B-изображения" или "B-кадры"). P-изображения могут использовать опорное изображение перед текущим изображением во временной последовательности. В B-изображении каждый блок B-изображения может быть предсказан по одному или двум опорным изображениям. Эти опорные изображения могут быть расположены до или после текущего изображения во временной последовательности.

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

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

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

Блок 30 инкапсуляции принимает пакеты PES для элементарных потоков представления от аудиокодера 26 и видеокодер 28 и формирует соответствующие блоки сетевого уровеня абстракции (NAL) из пакетов PES. В примере H.264/AVC (усовершенствованное кодирование видео) кодированные видеосегменты организуются в блоки NAL, которые обеспечивают "ориентированное на сети" представление видеоданных, предназначенное для таких применений, как видеотелефония, хранение, вещание или потоковая передача. Блоки NAL могут подразделяться на блоки NAL слоя видеокодирования (VCL) и блоки NAL не-VCL. Блоки VCL могут содержать основной механизм сжатия и могут включать в себя блок, макроблок и/или данные уровня секции. Другие блоки NAL могут быть блоками NAL не-VCL. В некоторых примерах кодированное изображение в один момент времени, обычно представляемое как основное кодированное изображение, может содержаться в устройстве доступа, которое может включать в себя один или более блоков NAL.

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

Дополнительная расширяющая информация (SEI) может содержать информацию, которая не является необходимой для декодирования кодированных фрагментов данных изображений из блоков NAL VCL, но может помочь в процессах, связанных с декодированием, отображением, устойчивостью к ошибкам и другими целями. Сообщения SEI могут содержаться в блоках NAL не-VCL. Сообщения SEI являются нормативной частью спецификаций некоторых стандартов, и таким образом не всегда являются обязательными для совместимой со стандартом реализации декодера. Сообщения SEI могут быть сообщениями SEI на уровне последовательности или сообщениями SEI на уровне изображения. Некоторая информация на уровне последовательности может содержаться в сообщениях SEI, таких как сообщения SEI с информацией о масштабируемости в примере SVC и сообщения SEI с информацией о масштабируемости ракурса в MVC. Эти примеры сообщений SEI могут передавать информацию, например, об извлечении рабочих точек и характеристиках рабочих точек. Кроме того, блок 30 инкапсуляции может сформировать файл манифеста, такой как дескриптор медиапрезентации (MPD), который описывает характеристики представлений. Блок 30 инкапсуляции может форматировать MPD в соответствии с расширяемым языком разметки (XML).

Блок 30 инкапсуляции может предоставить данные для одного или более представлений мультимедийного контента наряду с файлом манифеста (например, MPD) на выходной интерфейс 32. Выходной интерфейс 32 может содержать сетевой интерфейс или интерфейс для записи на носитель данных, такой как интерфейс универсальной последовательной шины (USB), устройства записи CD или DVD, интерфейс к магнитному или флэш-носителю данных или другие интерфейсы для хранения или передачи медиаданных. Блок 30 инкапсуляции может предоставить данные каждого из представлений мультимедийного контента на выходной интерфейс 32, который может отправить данные серверному устройству 60 посредством сетевой передачи или носителю данных. В примере на фиг. 1 серверное устройство 60 включает в себя носитель 62 данных, который хранит различные мультимедийные контенты 64, каждый из которых включает в себя соответствующий файл 66 манифеста и одно или более представлений 68A-68N (представления 68). В соответствии с методами этого раскрытия части файла 66 манифеста могут быть сохранены в отдельных местах, например, местах носителя 62 данных или другого носителя данных, потенциально другого устройства сети 74, такого как прокси-устройство.

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

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

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

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

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

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

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

Блок 70 обработки запросов сконфигурирован принимать сетевые запросы от клиентских устройств, таких как клиентское устройство 40, на данные носителя 72 данных. Например, блок 70 обработки запросов может реализовывать протокол передачи гипертекста (HTTP) версия 1.1, как описано в RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” by R. Fielding et al, Network Working Group, IETF, June 1999. То есть блок 70 обработки запросов может быть сконфигурирован принимать запросы HTTP GET или partial GET и предоставлять данные мультимедийного контента 64 в ответ на запросы. Запросы могут указывать сегмент одного из представлений 68, например, с помощью URL сегмента. В некоторых примерах запросы могут также указывать один или более диапазонов байтов сегмента, таким образом, включая в себя запросы partial GET. Блок 70 обработки запросов дополнительно может быть сконфигурирован обслуживать запросы HTTP HEAD для предоставления данных заголовка сегмента одного из представлений 68. В любом случае, блок 70 обработки запросов может быть сконфигурирован обрабатывать запросы для предоставления запрашиваемых данных запрашивающему устройству, такому как клиентское устройство 40.

Как изображено в примере на фиг. 1, мультимедийный контент 64 включает в себя файл 66 манифеста, который может соответствовать описанию медиапрезентации (MPD). Файл 66 манифеста может содержать описания различных альтернативных представлений 68 (например, видеоуслуг с различным качеством), и описание может включать в себя, например, информацию о кодеке, значение профиля, значение уровня, битовую скорость и другие описательные характеристики представлений 68. Клиентское устройство 40 может получить MPD медиапрезентации, чтобы определить, как получить доступ к сегментам представлений 68.

В частности веб-приложение 52 может получить данные (не показаны) конфигурации клиентского устройства 40, чтобы определить возможности по декодированию видеодекодера 48 и возможности по воспроизведению видеовывода 44. Данные конфигурации могут также включать в себя любое или все из предпочтений языка, выбранного пользователем клиентского устройства 40, одну или более перспектив камеры, соответствующих настройкам глубины, установленным пользователем клиентского устройства 40, и/или рейтинговые оценки, выбранные пользователем клиентского устройства 40. Веб-приложение 52 может содержать, например, веб-браузер или медиаклиент, сконфигурированный, чтобы подавать запросы HTTP GET и partial GET. Веб-приложение 52 может соответствовать инструкциям программного обеспечения, выполняемым одним или более процессорами или блоками обработки (не показаны) клиентского устройства 40. В некоторых примерах вся или часть функциональности, описанной в отношении веб-приложения 52, может быть реализована в аппаратных средствах или комбинации аппаратных средств, программного обеспечения и/или встроенного микропрограммного обеспечения, где необходимые аппаратные средства могут быть обеспечены для выполнения инструкций программного обеспечения или встроенного микропрограммного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

В некоторых примерах клиентское устройство 40 может сохранять структуру данных, указывающую на конкретные представления 68, из которых клиентское устройство 40 запросило данные для мультимедийного контента 64. Клиентское устройство 40 может также сохранять указания относительно того, что именно было воспроизведено и в какое время. То есть структура данных может обеспечивать информацию, указывающую время начала и конца и в реальном (или "физическом") времени и времени презентации. Структура данных может дополнительно обеспечивать информацию, указывающую время начального запуска и начала воспроизведения. После завершения воспроизведения мультимедийного контента 64 клиентское устройство 40 может отправить структуру данных серверному устройству 60 и/или устройству 20 подготовки контента. Серверное устройство 60 и/или устройство 20 подготовки контента может использовать информацию, принятую от клиентского устройства 40, для определения более оптимальных путей улучшения качества восприятия, например, уменьшения пауз при воспроизведении.

Сетевой интерфейс 54 может принять и предоставить данные сегментов выбранного представления веб-приложению 52, которое может в свою очередь обеспечить сегменты для блока 50 декапсуляции. Блок 50 декапсуляции может декапсулировать элементы видеофайла в составляющие потоки PES, депакетизировать потоки PES для получения кодированных данных и отправить кодированные данные или аудиодекодеру 46 или видеодекодеру 48, в зависимости от того, являются ли кодированные данные частью аудиопотока или видеопотока, например, как указано в заголовках пакетов PES потока. Аудиодекодер 46 декодирует закодированные аудиоданные и отправляет декодированные аудиоданные на аудиовыход 42, в то время как видеодекодер 48 декодирует закодированные видеоданные и отправляет декодированные видеоданные, которые могут включать в себя множество ракурсов потока, на видеовыход 44.

Видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, блок 30 инкапсуляции, веб-приложение 52 и блок 50 декапсуляции, каждый из них может быть реализован как любое множество подходящих электронных схем обработки, в зависимости от обстоятельств, таких как один или более микропроцессоров, цифровых сигнальных процессоров (DSP), специализированных интегральных схем (ASIC), программируемых пользователем вентильных матриц (FPGA), дискретных логических схем, программного обеспечения, аппаратных средств, встроенного микропрограммного обеспечения или любых их комбинаций. И видеокодер 28, и видеодекодер 48 могут быть включены в один или несколько кодеров или декодеры, любой из которых может быть интегрирован как часть комбинированного видео- кодера/декодера (CODEC). Аналогично, и аудиокодер 26, и аудиодекодер 46 могут быть включены в один или более кодеров или декодеры, любой из которых может быть интегрирован как часть комбинированного CODEC. Устройство, включающее в себя видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, блок 30 инкапсуляции, веб-приложение 52 и/или блок 50 декапсуляции, может содержать интегральную схему, микропроцессор и/или устройство беспроводной связи, такое как сотовый телефон.

Фиг. 2 является концептуальной схемой, изображающей элементы примерного мультимедийного контента 100. Мультимедийный контент 100 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному в памяти 62. В примере на фиг. 2 мультимедийный контент 100 включает в себя описание медиапрезентации (MPD) 102 и множество представлений 110-120. Представление 110 включает в себя дополнительные данные 112 заголовка и сегменты 114A-114N (сегменты 114), в то время как представление 120 включает в себя дополнительные данные 122 заголовка и сегменты 124A-124N (сегменты 124). Для удобства буква N используется для обозначения последнего фрагмента фильма в каждом из представлений 110, 120. В некоторых примерах у представлений 110, 120 может быть различное число фрагментов фильма.

MPD 102 может содержать структуру данных, отдельную от представлений 110-120. MPD 102 может соответствовать файлу 66 манифеста на фиг 1. Аналогично, представления 110-120 могут соответствовать представлениям 68 на фиг. 1. В общем, MPD 102 может включать в себя данные, которые, как правило, описывают характеристики представлений 110-120, такие как характеристики кодирования и воспроизведения, группы представлений, профиль, которому соответствует MPD 102, информацию о типе текста, информацию о ракурсе, рейтинговую информацию, информацию о нестандартном режиме (например, информацию, указывающую представления, которые включают временные подпоследовательности) и/или информацию для получения вынесенных периодов (например, для вставки адресной рекламы в медиаконтент во время воспроизведения). Вынесенные периоды могут также называться внешними периодами. Фиг. 4-7, обсуждаемые более подробно ниже, изображают различные примеры мультимедийного контента с различными элементами, входящими в одно из или в оба: MPD и/или представления (например, в сегменты представлений или данные заголовков представлений). Любые или все из MPD на фиг. 4-7 могут соответствовать в значительной степени MPD 102 на фиг. 2.

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

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

Каждый из сегментов 114, 124 может быть связан с уникальным унифицированным идентификатором ресурсов (URI), например, унифицированным указателем ресурсов (URL). Таким образом, каждый из сегментов 114, 124 может быть получен независимо с использованием сетевого протокола потоковой передачи, такого как DASH. Таким образом, приемное устройство, например, клиентское устройство 40, может использовать запрос HTTP Get для получения сегментов 114 или 124. В некоторых примерах клиентское устройство 40 может использовать запросы HTTP partial Get для получения конкретных диапазонов байтов сегментов 114 или 124.

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

Может иметься относительно небольшое количество профилей, которым могут соответствовать MPD. Профили могут дополняться уровнями для решения вопросов, связанных с возможностями, аналогично тому, каким образом H.264/AVC включает в себя профили и уровни для видеокодирования. Профили MPD могут иметь луковичную структуру, то есть профиль более высокого уровня может включать в себя все элементы всех профилей более низкого уровня. Может иметься процесс регистрации с регистрирующим органом для регистрации различных профилей. В некоторых примерах клиентское устройство, такое как клиентское устройство 40, может быть сконфигурировано получать информацию, указывающую профиль для MPD, такого как MPD 102, до получения других данных MPD, таких как характеристики представлений 110-120, сообщаемых MPD 102. Таким образом, до предоставления доступа к MPD 102 может быть сообщен профиль для MPD 102.

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

Профили могут описывать характеристики такие как, например, особенности MPD 102, использование сети, формат(ы) медиаданных, используемый кодек(и), форматы защиты и/или количественные показатели, такие как битовые скорости, размеры экрана и т.п. Таким образом, профиль MPD 102 может обеспечивать информацию, указывающую, какие кодеки должны поддерживаться для того, чтобы получить данные MPD 102 и/или мультимедийный контент 100. Профили могут также быть описаны как "точки соответствия". Профили, которым соответствует MPD, могут быть указаны в атрибуте "Профили" описания MPD. Таким образом, клиентское устройство может быть сконфигурировано получать часть MPD 102, включающую информацию, касающуюся атрибута "Профили" перед получением дополнительных данных MPD 102. Альтернативно, профили могут быть указаны в качестве параметра в типе MIME описания MPD. Например, о профилях "X, Y и Z" может быть сообщено следующим образом:

video/vnd.mpeg.mpd;profiles="X,Y,Z".

В некоторых примерах MPD 102 может ссылаться на данные внешних периодов (также называемых вынесенными периодами). Период, как правило, соответствует конкретной временной секции мультимедийного контента. Каждый период может включать в себя одно или более представлений, таких как представления 110-120. Внешний период, однако, может быть вставлен в или между периодами мультимедийного контента 100. Внешний период может включать в себя мультимедийные данные в дополнение к мультимедийным данным мультимедийного контента. Например, внешние периоды могут включать в себя данные рекламы.

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

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

ТАБЛИЦА 1 Информация о периодах в MPD Period E 1...N М Обеспечивает информацию Периода PeriodAitributes Список   М Уже существующие атрибуты Периода PeriodDuration A   О Обеспечивает продолжительность Периода, может использоваться в качестве альтернативы атрибуту start (начало) следующего Периода. RepresentationGroupListURI A   O URI, который указывает на документ, который содержит список Представлений. RepresentationGroups E 0..N   Этот элемент содержит описание Группы представлений PeriodListURI A   M URI, который указывает на документ, который содержит один или несколько элементов Периода.

Таким образом, элемент Period описания MPD 102 может ссылаться на внешние (или вынесенные) периоды, например, с помощью periodListURl. Для контента по запросу указания относительно продолжительности периодов могут быть более полезны для клиентских устройств, такими как клиентское устройство 40, чем время начала, для поддержки внешних периодов. MPD может включать в себя последовательность Периодов, где Периоды могут быть внутренними или внешними. Использование таких вынесенных Периодов, наряду с пользовательской информацией, может дать возможность адресной рекламы для пользователя. Серверное устройство 60 и/или устройство 20 подготовки контента может быть сконфигурировано динамически генерировать отдельные MPD для каждого пользователя или для каждого клиентского устройства. Клиентское устройство 40 или другое устройство, может объединить воспроизведение адресной рекламы и услуги прямой трансляции, например, используя динамически создаваемое MPD.

Таким образом, методы этого раскрытия могут поддерживать ситуации, в которых поставщик услуг предлагает содержание по требованию через 3GPP AHS. Содержание может включать в себя несколько сцен, и между каждой сценой может быть добавлена реклама. Реклама может быть разной для каждого пользователя. То есть может быть добавлена адресная реклама. Кроме того, каждая реклама может иметь различную продолжительность. Аналогично, поставщик услуг может предложить конкретную услугу прямой трансляции (например, бесплатную услугу). При доступе к услуге прямой трансляции поставщик услуг может добавить рекламу, которая может быть, а может и не быть адресована пользователю. Продолжительность рекламы может отличаться в зависимости от времени доступа, места доступа, пользователя и т.п. Серверное устройство 60 может быть сконфигурировано обеспечивать URL услуги прямой трансляции только после завершения рекламы, чтобы гарантировать, что реклама просмотрена.

Фиг. 3 является блок-схемой, изображающей элементы примерного видеофайла 150, который может соответствовать сегменту представления, такому как один из сегментов 114, 124 на фиг. 2. Каждый из сегментов 114, 124 может включать в себя данные, которые в значительной степени соответствуют расположению данных, изображенному в примере на фиг. 3. Аналогично, сегменты на фиг. 4-7, обсуждаемые ниже, могут также в значительной степени соответствовать структуре видеофайла 150. Как описано выше, видеофайлы в соответствии с базовым форматом ISO мультимедийных файлов и его расширениями хранят данные в последовательностях объектов, называемых "полями". В примере на фиг. 3 видеофайл 150 включает в себя поле 152 типа файла (FTYP), поле 154 фильма (МООВ), поля 162 фрагментов фильма (MOOF) и поле 164 произвольного доступа к фрагментам фильма (MFRA).

Поле 152 типа файла (FTYP), как правило, описывает тип файла для видеофайла 150. Поле 152 типа файла может включать в себя данные, которые указывают спецификацию, которая описывает наилучшее использование для видеофайла 150. Поле 152 типа файла может размещаться перед полем 154 MOOV, полями 162 фрагментов фильма и полем 164 MFRA.

В некоторых примерах сегмент, такой как видеофайл 150, может включать в себя поле обновления MPD (не показано) перед полем 152 FTYP. Поле обновления MPD может включать в себя информацию, указывающую, что MPD, соответствующий представлению, включающему в себя видеофайл 150, должно быть обновлено, наряду с информацией для обновления MPD. Например, поле обновления MPD может обеспечить URI или URL для ресурса, который должен использоваться для обновления MPD. В качестве другого примера, поле обновления MPD может включать в себя данные для обновления MPD. В некоторых примерах поле обновления MPD может следовать сразу за полем типом сегмента (STYP) (не показано) видеофайла 150, где поле STYP может определять тип сегмента для видеофайла 150. Фиг. 7, обсуждаемая более подробно ниже, обеспечивает дополнительную информацию относительно поля обновления MPD.

Поле 154 MOOV в примере на фиг. 3 включает в себя поле 156 заголовка фильма (MVHD), поле 158 дорожки (TRAK) и одно или более полей 160 расширений фильма (MVEX). В целом, поле 156 MVHD может описывать общие характеристики видеофайла 150. Например, поле 156 MVHD может включать в себя данные, которые описывают, когда видеофайл 150 был первоначально создан, когда видеофайл 150 был последний раз изменен, временные рамки для видеофайла 150, продолжительность воспроизведения для видеофайла 150 или другие данные, которые, как правило, описывают видеофайл 150.

Поле 158 TRAK может включать в себя данные для дорожки видеофайла 150. Поле 158 TRAK может включать в себя поле заголовка дорожки (TKHD), которое описывает характеристики дорожки, соответствующей полю 158 TRAK. В некоторых примерах поле 158 TRAK может включать в себя кодированные видеоизображения, в то время как в других примерах кодированные видеоизображения дорожки могут содержаться во фрагментах 162 фильма, на который могут ссылаться данные поля 158 TRAK.

В некоторых примерах видеофайл 150 может включать в себя более одной дорожки. Соответственно, поле 154 MOOV может включать в себя число полей TRAK, равное числу дорожек в видеофайле 150. Поле 158 TRAK может описывать характеристики соответствующей дорожки видеофайла 150. Например, поле 158 TRAK может описывать временную и/или пространственную информацию для соответствующей дорожки. Поле TRAK, аналогично полю 158 TRAK поля 154 MOOV, может описывать характеристики дорожки набора параметров, когда блок 30 инкапсуляции (фиг. 1) добавляет дорожку набора параметров в видеофайл, такой как видеофайл 150. Блок 30 инкапсуляции может сообщать о наличии сообщений SEI уровня последовательности в дорожке набора параметров в поле TRAK, описывающем дорожку набора параметра.

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

Поле 154 MOOV может включать в себя число полей 160 MVEX, равное числу фрагментов 162 фильма в видеофайле 150. Каждое из полей 160 MVEX может описывать характеристики соответствующего одного из фрагментов 162 фильма. Например, каждое поле MVEX может включать в себя поле заголовка расширений фильма (MEHD), которое описывает продолжительность по времени для соответствующего одного из фрагментов фильма 162.

Как отмечалось выше, блок 30 инкапсуляции может хранить набор данных последовательности во фрагменте видеоданных, который не включает в себя фактические кодированные видеоданные. Фрагмент видеоданных может, как правило, соответствовать блоку доступа, который является представлением кодированного изображения в конкретный момент времени. В контексте AVC кодированное изображение включает в себя один или более блоков NAL VCL, которые содержат информацию для создания всех пикселей блока доступа, и другие соответствующие блоки NAL не-VCL, такие как сообщения SEI. Соответственно, блок 30 инкапсуляции может включать в себя набор данных последовательности, который может включать в себя сообщения SEI уровня последовательности, в одном из фрагментов 162 фильма. Блок 30 инкапсуляции может дополнительно сообщать о наличии набора данных последовательности и/или наличии сообщений SEI уровня последовательности в одном из фрагментов 162 фильма в одном из полей 160 MVEX, соответствующих одному из фрагментов 162 фильма.

Фрагменты 162 фильма могут включать в себя одно или более кодированных видеоизображений. В некоторых примерах фрагменты 162 фильма могут включать в себя одну или более групп изображений (GOP), каждая из которых может включать в себя много кодированных видеоизображений, например, кадров или изображений. Кроме того, как описано выше, в некоторых примерах фрагменты 162 фильма могут включать в себя наборы данных последовательности. Каждый из фрагментов 162 фильма может включать в себя поле заголовка фрагмента фильма (MFHD, не показано на фиг. 3). Поле MFHD может описывать характеристики соответствующего фрагмента фильма, такие как порядковый номер для фрагмента фильма. Фрагменты 162 фильма могут содержаться в видеофайле 150 в порядке порядковых номеров.

Поле 164 MFRA может описывать точки произвольного доступа во фрагментах 162 фильма видеофайла 150. Это может помочь с выполнением нестандартных режимов, таких как выполнение поиска конкретного места по времени в видеофайле 150. Поле 164 MFRA является, как правило, необязательным, и не должен содержаться в видеофайлах в некоторых примерах. Аналогично, клиентское устройство, такое как клиентское устройство 40, не обязательно должно ссылаться на поле 164 MFRA для правильного декодирования и отображения видеоданных видеофайла 150. Поле 164 MFRA может включать в себя число полей (не показаны) произвольного доступа к фрагментам дорожки (TFRA), равное числу дорожек видеофайла 150 или, в некоторых примерах, равное числу мультимедийных дорожек (например, дорожек без подсказок) видеофайла 150.

В некоторых примерах фрагменты 162 фильма могут включать в себя одно или более изображений IDR и/или ODR. Аналогично, поле 164 MFRA может обеспечивать указания относительно местоположения в видеофайле 150 изображений IDR и ODR. Соответственно, временная подпоследовательность видеофайла 150 может быть сформирована из изображений IDR и ODR видеофайла 150. Временная подпоследовательность может также включать в себя другие изображения, такие как P-кадры и/или B-кадры, которые зависят от изображений IDR и/или ODR. Кадры и/или секции временной подпоследовательности могут быть расположены в сегментах так, что кадры/секции временной подпоследовательности, которые зависят от других кадров/секций подпоследовательности, могут быть должным образом декодированы. Например, в иерархической структуре данных данные, используемые для предсказания других данных, могут также быть включены во временную подпоследовательность. Кроме того, данные могут быть расположены в непрерывной подпоследовательности, так что в запросе partial GET может быть указан один диапазон байтов для получения всех данных конкретного сегмента, используемого для временной подпоследовательности. Клиентское устройство, такое как клиентское устройство 40, может извлечь временную подпоследовательность видеофайла 150 путем определения диапазонов байтов фрагментов 162 фильма (или частей фрагментов 162 фильма), соответствующих изображениям IDR и/или ODR. Как обсуждается более подробно ниже, видеофайлы, такие как видеофайл 150, могут включать в себя поле перечня подфрагментов и/или поле фрагментов поддорожки, любой или оба из которых могут включать в себя данные для извлечения временной подпоследовательности видеофайла 150.

Фиг. 4 является концептуальной схемой, изображающей примерный мультимедийный контент 200, включающий в себя MPD 202 и группы представлений 210-220. Мультимедийный контент 200 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному в памяти 62. В этом примере представления мультимедийного контента 200 упорядочены по группам представлений. То есть представления с общим набором характеристик могут быть собраны в группу представлений, которая обеспечивает упрощенную адаптацию к пропускной способности сети.

В этом примере MPD 202 включает в себя общие характеристики 204A представлений, которые включают в себя информацию, описывающую общие характеристики группы 210 представлений, и общие характеристики 204B представлений, описывающие общие характеристики группы 220 представлений. Общие характеристики могут включать в себя характеристики кодирования и/или воспроизведения представлений, такие как кодек, профиль и уровень кодека, которым соответствуют представления в группе представлений, разрешение в пикселях, частота кадров или другие характеристики представлений.

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

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

Рейтинг может описывать пригодность контента для конкретных аудиторий. Например, в Соединенных Штатах Америки Американская киноассоциация определяет следующие рейтинги G, PG, PG-13, R и NC-17. В качестве другого примера, в Великобритании Британское бюро классификации кинофильмов определяет следующие рейтинги U, PG, 12A, 12, 15, 18 и R18. В качестве еще одного примера, в Китайской Республике (Тайвань) категории кинофильмов включают в себя категорию для широкой аудитории, защищенную категорию, категорию, требующую контроля со стороны взрослых, и ограниченную категорию.

Путем обеспечения общих характеристик 204 соответствующих групп представлений, например, групп 210-220 представлений, клиентское устройство (например, клиентское устройство 40) может выбрать соответствующую группу из групп 210-220 представлений по меньшей мере частично на основании соответствующих общих характеристик 204 представлений. В примере на фиг. 4 MPD 202 также включает в себя индивидуальные характеристики 206A, 206B, 208A и 208B представлений, соответствующие, соответственно, представлениям 212A, 212B, 222A, 222B. Индивидуальные характеристики 206A, 206В, 208A и 208B представлений могут включать в себя информацию, указывающую характеристики представлений 212A, 212В, 222A, 222B, не указанные в общих характеристиках 204 представлений. Например, индивидуальные характеристики 206A, 206B, 208A и 208B представлений могут включать в себя информацию, указывающую битовые скорости для соответствующих представлений 212A, 212B, 222A, 222B.

Представления группы представлений можно считать взаимоисключающими в том смысле, что они могут представлять один и то же контент (одно и то же видео, один и тот же язык аудио и т.д.) с различным кодированием или другими параметрами. MPD 202 может обеспечивать информацию для выбора одной из групп 210-220 представлений, например, общие характеристики 204 представления. Эта информация может включать в себя информацию, указывающую, может ли клиент декодировать и воспроизвести данное представление. Таким образом, клиентское устройство может убрать из рассмотрения представления, которые клиентское устройство не может декодировать и/или воспроизвести. Соответственно, клиентское устройство 40 может выбрать подходящую группу представлений, которая может быть декодирована и воспроизведена, затем выбрать представление из группы на основании, например, доступности пропускной способности сети.

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

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

В некоторых примерах общие характеристики 204 представлений могут соответствовать XML элементам RepresentationGroup описания MPD 202. Индивидуальные характеристики представлений могут соответствовать, в некоторых примерах, подэлементам соответствующих элементов RepresentationGroup описания MPD 202.

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

Фиг. 5 является концептуальной схемой, изображающей другой примерный мультимедийный контент 250, в котором данные MPD разделены на различные части для различных групп представлений. Мультимедийный контент 250 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному в памяти 62. В частности файл манифеста для мультимедийного контента 250 включает в себя часть 252 MPD, которая, как правило, включает данные, связанные с группами представлений. В этом примере часть 252 MPD включает в себя данные 254A и 254B групп представлений (данные 254 групп представлений), которые соответствует соответствующим группам 270-280 представлений, как изображено стрелками, указывающими от данных 254 групп представлений к соответствующим группам 270-280 представлений.

В этом примере данные 254A группы представлений включают в себя общие характеристики 256A группы представлений и местоположение части MPD для группы 258A представлений. То есть местоположение части MPD для группы 258A представлений указывает местоположение части MPD для группы 260A представлений. Местоположение части MPD для группы 258A представлений может соответствовать, например, URI или URL части MPD для группы 260A представлений. Аналогично, данные 254B группы представлений включают в себя общие характеристики 256B группы представлений и местоположение части MPD для группы 258B представлений, соответствующей части MPD для группы 260B представлений.

Часть MPD для группы 260A представлений включает в себя информацию, указывающую характеристики конкретных представлений 272A, 272B (представления 272) группы 270 представлений. Аналогично, часть MPD для группы 260B представлений включает в себя информацию, указывающую характеристики конкретных представлений 282A, 282B (представления 282) группы 280 представлений.

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

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

Таблица 2 ниже обеспечивает примерный элемент, который может быть добавлен к MPD, такому как MPD 202 на фиг. 4 и/или части 252 MPD на фиг. 5, которые описывают характеристики групп представлений. Общие характеристики 204 представлений (фиг. 4) и/или общие характеристики 256 групп представлений могут быть форматированы в соответствии со структурой Таблицы 2.

ТАБЛИЦА 2 RepresentationGroup E 1..N M Этот элемент содержит описание Группы представлений RepresentationGroupAtiri Список Элементов и Атрибутов     Описывает значения по умолчанию для этой группы, может включать в себя информацию о профиле. Representation E 0..N O Этот элемент содержит описание Представления. RepresentationAttribut Список Элементов и Атрибутов 0,1 O Описывает атрибуты Представления, которые относятся к этому Представлению. RepresentationListURI A 0..N O URI, который указывает на документ, который содержит список Представлений.

XML ниже приводит примеры элементов Группы представлений структуры данных MPD:

<RepresentationGroup annotation="ex0" annotation2="ex1">

<representationListURI="http://www.example.com/representations1.xml/>

</RepresentationGroup>

<RepresentationGroup annotation="ex2" annotation2="ex3">

<representationListURI="http://www.example.com/representations2.xml/>

</RepresentationGroup>

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

ТАБЛИЦА 3 Representation E 1..N M Этот элемент содержит описание Представления. bandwidth A   M Минимальная пропускная способность гипотетического канала с постоянной скоростью передачи в битах в секунду (бит/с), по которому представление может быть доставлено так, что клиент, после буферизации в течение точно minBufferTime (минБуферноеВремя), может быть уверен в наличии достаточного количества данных для непрерывного воспроизведения. …             texttype A   O Указывает тип текста. Возможные опции: подзаголовок
субтитры
<другие, требующие определения>     cameraangle A   O Обеспечивает ракурс. Простое пояснение, например, основной, в середине, вид игроков     Rating E 0…N   Обеспечивает рейтинговую информацию SchemeInformation E 0,1 O Этот элемент дает информацию об используемой рейтинговой схеме. Элемент может быть расширен, чтобы обеспечивать больше информации для конкретной схемы.     schemeIdUri       Обеспечивает абсолютный URL для идентификации схемы. Определение этого элемента зависит от схемы, используемой для определения рейтинга.

В некоторых примерах данные для групп представлений и данные для отдельных представлений в таких группах могут быть представлены в MPD, таком как MPD 202, с иерархической зависимостью. То есть информация об отдельных представлениях может сообщаться в виде дочерних элементов соответствующего элемента группы представлений, например, описания MPD 202. Аналогично, для части 252 MPD и частей MPD для групп 260 представлений индивидуальные характеристики 262, 264 представлений могут соответствовать дочерним элементам общих характеристик 256 групп представлений.

Фиг. 6 является концептуальной схемой, изображающей другой примерный мультимедийный контент 300, который может использоваться для поддержки нестандартных режимов. Мультимедийный контент 300 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному в памяти 62. В этом примере MPD 302 включает в себя информацию 304 о представлении, которая может включать в себя информацию о временной подпоследовательности 306. В этом примере информация о представлении 304 включает в себя характеристики представления 310. Представление 310 включает в себя сегменты 312A-312D (сегменты 312). В этом примере каждый из сегментов 312 включает в себя соответствующее поле 314 перечня подфрагментов и данные 316 о точках произвольного доступа (RAP). В других примерах некоторые сегменты могут не включать в себя никаких точек произвольного доступа, в то время как некоторые сегменты могут включать в себя множество точек произвольного доступа. Точки произвольного доступа могут включать в себя изображения IDR или ODR.

Клиентское устройство 40 может извлечь временную подпоследовательность из представления 310. Например, клиентское устройство 40 может извлечь каждую из точек RAP 316 для формирования временной подпоследовательности представления 310. Альтернативно, клиентское устройство 40 может получить подмножество точек RAP 316, таких как точки RAP 316A и 316C или 316A и 316D. Получая и воспроизводя только точки 316 произвольного доступа (или их поднаборы), клиентское устройство 40 может воспроизвести представление 310 в нестандартном режиме, например, ускоренной перемотке вперед или назад. Аналогично, клиентское устройство 40 может перейти или промотать к одной конкретной точке из точек 316 произвольного доступа, чтобы начать воспроизведение с требуемого временного положения.

Мультимедийный контент может включать в себя любую или обе из: временную информацию 306 о подпоследовательности и/или поле 314 SFIX для указания информации для нестандартных режимов. Информация 306 о временной подпоследовательности может включать в себя элемент "Нестандартный режим" описания MPD 302, такой как определено в Таблице 4 ниже:

ТАБЛИЦА 4 TrickMode E 0,1 O Обеспечивает информацию для нестандартного режима. Также указывает, что Представление может использоваться в качестве Представления нестандартного режима. alternatePlayoutRate A   O Указывает максимальную скорость воспроизведения как число, кратное скорости обычного воспроизведения, которую это Представление поддерживает с тем же самым профилем декодера и требованиями уровня, что и для нормальной скорости воспроизведения. TemporalSubSequence E 0…N O Указывает, что это Представление содержит временную подпоследовательность, к которой можно легко получить доступ с помощью диапазонов байтов, используя информацию Поля перечня подфрагментов ('sfix). frameRate A   M Указывает частоту кадров временной подпоследовательности. bandwidth A   O Указывает минимальную пропускную способность гипотетического канала с постоянной скоростью передачи в битах в секунду (бит/с), по которому временная подпоследовательность может быть доставлена так, что клиент, после буферизации в течение точно minBufferTime (минБуферноеВремя), может быть уверен в наличии достаточного количества данных для непрерывного воспроизведения. altematePlayoutRate A   O Указывает максимальную скорость воспроизведения как число, кратное обычной скорости воспроизведения, которую эта временная подпоследовательность поддерживает с тем же самым профилем декодера и требованиями уровня, что и для нормальной скорости воспроизведения.

В примере Таблицы 4 элемент Нестандартного режима включает в себя элемент Временной подпоследовательности, который указывает, что соответствующее представление содержит временную подпоследовательность, к которой можно получить доступ с помощью диапазонов байтов, используя информацию полей 314 перечней подфрагментов. Точки RAP 316 могут соответствовать частям фрагментов фильма, таким как фрагменты 162 фильма, изображенные на фиг. 3.

Поля 314 перечней подфрагментов могут, как правило, описывать местоположения диапазонов байтов точек 316 произвольного доступа соответствующих сегментов 312. В целом, поля 314 перечней подфрагментов могут находиться после поля перечня сегментов (SIDX) (не показано на фиг. 6) сегментов 312 и обеспечивать размеры префиксов фрагментов фильма для фрагментов фильма, на которые ссылается непосредственно предшествующее поле перечня сегментов. В таблице 5 ниже приводятся свойства примерного поля SFIX.

ТАБЛИЦА 5 Свойства поля перечня подфрагментов Тип поля SFIX Контейнер Нет Обязательное Нет Количество Одно на поле перечня сегментов

Псевдокод ниже обеспечивает примерный синтаксис для полей 314 перечня подфрагментов:

aligned(8) class SubFragmentlndexBox

extends FullBox('strf',0,0) {

unsigned int(32) fragment_count;

unsigned int(8) sub_fragment_count;

for( i=0; i< fragment_count; i++)

for( j=0; j< sub_fragment_count-1; j++)

unsigned int(32) prefix_size;

}

Описание ниже обеспечивает примерный набор семантики для синтаксиса, описанного выше:

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

sub_fragment_count указывает число подфрагментов на фрагмент

prefix_size указывает размер префикса фрагмента i, занятого подфрагментом j.

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

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

Таблица 6 описывает свойства поля фрагментов поддорожки:

ТАБЛИЦА 6 Свойства поля фрагментов поддорожки Тип поля STRF Контейнер Поле фрагмента дорожки ("TRAF") Обязательное Нет Количество Ноль или одно

Псевдокод ниже показывает примерный синтаксис для поля фрагментов поддорожки:

aligned(8) class SubTrackFragBox

extends FullBox('strf', 0, 0) {

unsigned int(8) sub_track_count;

unsigned int(16) sample_count[sub_track_count-1];

for( i=0; i< sub_track_count; i++)

{

for (j=0; j< sample_count[i]; j++)

bit(1) cur_sub_trak_flag;

}

reserved_trailing_bits;

}

Описание ниже обеспечивает примерную семантику для примерного синтаксиса поля фрагментов поддорожки, описанного выше:

sub_track_count указывает число фрагментов поддорожки; когда это поле присутствует, sub_track_count может быть равным или больше 2.

sample_count[i] указывает число фрагментов данных во фрагменте поддорожки с индексом i+1. Фрагменты данных фрагмента поддорожки считаются элементами всех фрагментов поддорожки с меньшими значениями индекса. Число фрагментов данных во фрагменте 0 поддорожки равно числу нулей первой битовой строки в последующем цикле. Число фрагментов данных во фрагменте поддорожки с индексом sub_track_count-1, то есть число sample_count[sub_track_count-1], равно числу фрагментов данных во Фрагменте Дорожки.

cur_sub_track_flag, равный 1 в итерации i внешнего цикла, указывает, что фрагмент данных принадлежит фрагменту поддорожки с индексом i+1. Эта величина, равная 0 в итерации внешнего цикла, указывает, что фрагмент данных принадлежит фрагменту поддорожки с индексом меньше i+1. Замечание: То есть первая итерация цикла содержит флаги sample_count[0], указывающие положения фрагментов данных во фрагменте 1 поддорожки, которые не находятся также во фрагменте 0 поддорожки. Вторая итерация цикла содержит флаги sample_count[1], указывающие положения фрагментов данных во фрагменте 2 поддорожкии и также не во фрагменте 1 поддорожки и т.д. sample_count[sub_track_count-1] считается равными числу фрагментов данных во Фрагменте Дорожки.

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

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

Фиг. 7 является концептуальной схемой, изображающей другой примерный мультимедийный контент 350, в котором сегменты 362A-362D могут включать в себя поля 364 обновления MPD для указания, что MPD 352 должен быть обновлен. Мультимедийный контент 350 может соответствовать мультимедийному контенту 64 (фиг. 1) или другому мультимедийному контенту, сохраненному в памяти 62. В целом, MPD 352 включает в себя информацию 354 о представлении для представления 360, такую как характеристики представления 360 и URI или URL сегментов 362 представления 360. В некоторых случаях представление 360 может быть сформировано из контента прямой трансляции, например, спортивного мероприятия, и поэтому URI сегментов 362 не могут быть определены заранее. Поэтому, когда сегменты представления 360 сформированы, один или более сегментов может включать в себя поля обновления MPD для указания, что MPD 352 должен быть обновлен.

Например, на фиг. 7 сегмент 362A включает в себя поле 364 обновления MPD и данные 366A сегмента. Данные 366A сегмента, как правило, могут быть сформированы согласно видеофайлу 150 (фиг. 3). Однако сегмент 362A также включает в себя поле 364A обновления MPD. Таким образом, клиентское устройство 40 может обновить MPD 352 на основании данных поля 364A обновления MPD. Поле 364A обновления MPD может включать в себя обновления к MPD 352 или может включать в себя URI или URL обновления для MPD 352. Следует понимать, что данные полей 364 обновления MPD не обязательно содержатся в явных полях. Например, данные, которые в значительной степени соответствуют данным полей 364 обновления MPD, могут содержаться в других полях сегментов 362 или в части заголовка сегментов 362. Таким образом, "часть" сегментов 362, которая включает в себя информацию об обновлении MPD, может соответствовать части заголовка, полю обновления MPD, подобному полям 364 обновления MPD, или данным, содержащимся в одном или более других полях сегментов 362.

Таким образом, после получения данных сегмента 362A клиентское устройство 40 может проанализировать поле 364A обновления MPD для обновления MPD 352. Клиентское устройство 40 может затем использовать обновленную версию MPD 352 для получения сегментов 362B и 362C. Сегменты 362B и 362C включают в себя данные сегментов 366B, 366C, которые опять же могут быть форматированы согласно видеофайлу 150 на фиг. 3. Клиентское устройство 40 может также получить данные сегмента 362D. В этом примере сегмент 362D включает в себя поле 364B обновления MPD, которое клиентское устройство 40 может использовать для выполнения другого обновления MPD 352 способом, который в значительной степени соответствует первому обновлению. Соответственно, чтобы принять сегменты за сегментом 362D представления 360, клиентское устройство 40 может использовать обновленную версию MPD 352, основанную на обновлениях, выполненных по данным поля 364B обновления MPD.

Поле обновления MPD, такое как поля 364A, 364B обновления MPD, могут включать в себя свойства согласно Таблице 7 ниже:

ТАБЛИЦА 7 Свойства поля обновления MPD Тип поля MUPE Контейнер Нет Обязательное Нет Количество Ноль или одно

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

aligned(8) class MPDUpdateBox

extends FullBox('mupe') {

unsigned int(3) mpd_information_flags;

unsigned int(1) new_location_flag;

unsigned int(28) latest_mpd_update_time;

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

string mpd_location

}

Примерный набор семантики для примерного синтаксиса поля обновления MPD представлен ниже:

mpd_information_flags содержит логическое ИЛИ никаких либо нескольких элементов из нижеследующего:

0x00 Обновить Описание медиапрезентации сейчас

0x01 Обновить Описание медиапрезентации заранее

0x02 Конец презентации

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

new_location_flag, если установлен равным 1, то новое Описание медиапрезентации доступно в новом местоположении, указанном в mpd_location.

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

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

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

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

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

Фиг. 8 является блок-схемой последовательности операций, изображающей примерный способ для обеспечения указаний относительно групп представлений серверным устройством и для выбора групп представлений клиентским устройством, а также отдельных представлений в выбранной группе представлений. Хотя способ на фиг. 8 описан в отношении серверного устройства 60 и клиентского устройства 40, следует понимать, что другие устройства могут реализовывать методы, аналогичные таковым из способа на фиг. 8. Например, устройство 20 подготовки контента или одно или более сетевых устройств сети доставки контента могут выполнять некоторые или все функции, отнесенные к серверному устройству 60.

Серверное устройство 60 может сначала получить (например, создать или принять от устройства 20 подготовки контента), данные для набора представлений мультимедийного контента, где представления в наборе имеют одну или более общих характеристик, а также файл манифеста для мультимедийного контента. Набор представлений может соответствовать группе представлений. Серверное устройство 60 может обеспечить указания относительно групп представлений клиентскому устройству 40 (400). Например, серверное устройство 60 может предоставить MPD 202 (фиг. 4) или часть MPD 252 (фиг. 5) клиентскому устройству 40. Другие примерные MPD на фиг. 2, 6 и 7 могут также включать в себя указания относительно групп представлений, такие как XML элементы групп представлений. В любом случае, клиентское устройство 40 может принять информацию, описывающую характеристики групп представлений (402), например, из файла MPD или части файла MPD, принятого от серверного устройства 60.

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

После выбора группы представлений клиентское устройство 40 может запросить данные для части MPD, которая описывает конкретно представления группы представлений. В ответ серверное устройство 60 может предоставить клиентскому устройству 40 указания относительно битовых скоростей представления, помимо прочих индивидуальных характеристик представлений, в выбранной группе представлений (406). Например, серверное устройство 60 может отправить клиентскому устройству 40 данные для конкретной одной из частей MPD для групп 260 представлений (фиг. 5). В других примерах клиентское устройство 40, возможно, уже приняло полное MPD для мультимедийного контента (например, MPD 202 на фиг. 4), но оно может детально анализировать части MPD, соответствующие конкретно выбранной группе представлений. Таким образом, в некоторых примерах этап 406 на фиг. 8 может иметь место до этапа 402 и/или этапа 404.

В любом случае, после приема характеристик, соответствующих представлениям выбранной группы представлений, в том числе битовые скорости для представлений (408), клиентское устройство 40 может определить доступную в настоящий момент величину пропускной способности сети (410). Клиентское устройство 40 может затем выбрать представление из выбранной группы представлений (412), так что выбранное представление имеет битовую скорость, которая находится в пределах определенной доступной в настоящий момент величины пропускной способности сети. Битовые скорости представлений описывают примеры характеристик кодирования отдельных представлений в группе представлений. Клиентское устройство 40 может затем запросить данные выбранного представления (414). Например, клиентское устройство 40 может создать (например, генерировать и отправить) запрос HTTP GET, чтобы запросить сегмент выбранного представления. Альтернативно, клиентское устройство 40 может создать HTTP partial GET, который указывает диапазон байтов сегмента выбранного представления, в любом случае, клиентское устройство 40 может подать запрос серверному устройству 60.

Серверное устройство 60 может принять запрос и в ответ отправить запрошенные данные клиентскому устройству 40 (416). Например, блок 70 обработки запросов может определить сетевой адрес клиентского устройства 40 из данных принятого запроса, например, адрес Протокола Интернета (IP) отправителя и порт отправителя принятого запроса. Блок 70 обработки запросов может сформировать сетевые пакеты, включающие в себя требуемые данные, и отправить запрошенные данные клиентскому устройству 40, например, предназначенные для определенного IP-адреса клиентского устройства 40.

После приема запрошенных данных клиентское устройство 40 может начать декодировать и отображать принятые данные (418). Во время приема запрашиваемых данных клиентское устройство 40 может продолжить анализировать в настоящий момент доступную пропускную способность сети и подавать запросы на данные из представлений, имеющих битовые скорости, которые находятся в пределах в настоящий момент доступной величины пропускной способности сети (410-414). Если величина пропускной способности сети изменяется, клиентское устройство 40 может адаптивно переключиться на другое представление в выбранной группе представлений. Например, клиентское устройство 40 может определить сегмент в новом представлении, соответствующий положению во времени последнего сегмента, запрошенного из предыдущего представления в группе представлений, затем запросить определенный сегмент (или его часть) в новом представлении.

В некоторых примерах серверное устройство 60 может обеспечить MPD, соответствующий вставке адресной рекламы, клиентскому устройству 40 во время способа на фиг. 8. MPD может побудить клиентское устройство 40 получить рекламные мультимедийные данные, адресованные пользователю клиентского устройства 40. В некоторых примерах клиентское устройство 40 может дополнительно предоставить серверному устройству 60 пользовательскую информацию для обеспечения адресных рекламных медиаданных для пользователя клиентского устройства 40. Пользовательская информация может включать в себя пользовательские настройки, идентифицирующую пользователя информацию (такую как идентификатор пользователя), демографические данные о пользователе или другую подобную информацию. Вставка адресной рекламы может происходить, например, перед этапом 400 на фиг. 8 или после этапа 418 и до выбора последующего представления, например, для последующего периода мультимедийного контента.

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

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

Фиг. 9 является блок-схемой последовательности операций, изображающей примерный способ обеспечения серверным устройством данных для нестандартного режима и использования данных клиентским устройством для получения и воспроизведения данных нестандартного режима мультимедийного контента. Хотя способ на фиг. 9 описан в отношении серверного устройства 60 и клиентского устройства 40, следует понимать, что другие устройства могут реализовывать методы, аналогичные таковым из способа на фиг. 9. Например, устройство 20 подготовки контента или одно или более сетевых устройств сети доставки контента могут выполнять некоторые или все функции, отнесенные к серверному устройству 60. Кроме того, выбор нестандартного режима может быть выполнен в сочетании с выбором группы представлений и представления из группы представлений, как описано выше в отношении фиг. 8.

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

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

В ответ на этот запрос на использование нестандартного режима клиентское устройство 40 может определить, доступна ли временная подпоследовательность для представления, и если это так, запросить данные для получения по меньшей мере части временной подпоследовательности (438). Серверное устройство 60 может ответить на запрос путем предоставления указаний относительно местоположений данных для временной подпоследовательности клиентскому устройству 40 (440). В некоторых примерах часть MPD для мультимедийного контента может указывать местоположения данных для временной подпоследовательности. В других примерах клиентское устройство 40 может запросить поля перечня подфрагментов и/или поля фрагментов поддорожки из сегментов соответствующего представления.

В любом случае, клиентское устройство 40 может использовать принятые данные, включающие в себя информацию, указывающую местоположения данных для временной подпоследовательности, для запроса данных временной подпоследовательности из указанных местоположений (442). Например, клиентское устройство 40 может определить местоположения (например, URL сегментов и, возможно, диапазоны байтов сегментов), включающие в себя точки произвольного доступа IDR и/или точки произвольного доступа ODR. Клиентское устройство 40 может затем создать запросы HTTP GET или partial GET на данные временной подпоследовательности, чтобы воспроизвести видеоданные в соответствии с нестандартным режимом.

После приема запросов HTTP GET и/или partial GET от клиентского устройства 40 серверное устройство 60 может предоставить запрошенные данные клиентскому устройству 40 (444). Например, серверное устройство 60 может отправить сегменты в ответ на запросы HTTP GET или фрагменты медиаданных сегментов (или части фрагментов медиаданных) в ответ на запросы HTTP partial GET. После приема запрошенных данных клиентское устройство 40 может декодировать и отобразить принятые данные (446). Аналогично, клиентское устройство 40 может продолжить запрашивать данные из представления (или другого представления, если величина доступной пропускной способности сети изменяется).

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

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

Фиг. 10 является блок-схемой последовательности операций, изображающей примерный способ для обеспечения серверным устройством указаний, что файл манифеста, например MPD, должен быть обновлен, и для обновления MPD клиентским устройством. Хотя способ на фиг. 10 описан в отношении серверного устройства 60 и клиентского устройства 40, следует понимать, что другие устройства могут реализовывать методы, аналогичные таковым из способа на фиг. 10. Например, устройство 20 подготовки контента или одно или более сетевых устройств сети доставки контента могут выполнять некоторые или все функции, отнесенные к серверному устройству 60. Кроме того, обновление MPD может быть выполнено в сочетании с выбором нестандартного режима и/или выбором группы представлений и представления из группы представлений, как описано в отношении фиг. 8 и 9 выше.

В некоторых примерах устройство 20 подготовки контента может закодировать и инкапсулировать закодированные видеоданные, захваченные во время события прямого эфира, такого как спортивное мероприятие. Таким образом, клиентское устройство 40 может получать закодированные данные события почти в режиме реального времени, по мере того как происходит событие. Сначала серверное устройство 60 может принять одно или более представлений мультимедийного контента, соответствующего событию прямого эфира, и обеспечить указания относительно характеристик для представлений мультимедийного контента в MPD (460). MPD может описывать только характеристики и местоположения сегментов до конкретного положения во времени мультимедийного контента, поскольку мультимедийный контент формируется по мере того, как событие снимается в прямом эфире.

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

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

Используя поле обновления, клиентское устройство 40 может запросить обновления к MPD (472). Например, клиентское устройство 40 может определить сетевое местоположение обновлений для MPD и запросить обновления из определенного местоположения. Серверное устройство 60 или другое устройство, хранящее обновления к MPD (например, устройство 20 подготовки контента), может отправить информацию, указывающую обновления к MPD (474), которую клиентское устройство 40 может использовать для обновления MPD (476). Альтернативно, в некоторых примерах поле обновления MPD может включать в себя информацию, указывающую сами обновления MPD, в этом случае клиентское устройство 40 может обновить MPD, используя информацию поля обновления MPD. В любом случае, клиентское устройство 40 может затем запросить сегменты, следующие после положения во времени, в котором предыдущее MPD больше не применимо, используя обновленную версию MPD (478). Клиентское устройство 40 и серверное устройство 60 могут продолжить выполнять подобные этапы, пока клиентское устройство 40 не завершит воспроизведение мультимедийного контента.

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

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

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

Фиг. 11 является блок-схемой последовательности операций, изображающей примерный способ для создания и использования данных отчетного документа о качестве восприятия (QoE). Хотя способ на фиг. 11 описан по отношению к серверному устройству 60 и клиентскому устройству 40, следует понимать, что другие устройства могут реализовывать методы, аналогичные таковым из способа фиг. 11. Например, устройство 20 подготовки контента или одно или более сетевых устройств сети доставки контента могут выполнять некоторые или все функции, отнесенные к серверному устройству 60. Кроме того, предоставление отчета QoE серверному устройству 60 и/или устройству 20 подготовки контента может быть выполнено в сочетании с любым или всем из: обновлением MPD, выбором нестандартного режима и/или выбором группы представлений и представления от группы представлений, как описано в отношении фиг. 8, 9 и 10 выше.

Сначала серверное устройство 60 может предоставить клиентскому устройству 40 указания относительно характеристик представлений мультимедийного контента в MPD (500). Как обсуждалось выше, клиентское устройство 40 может выбрать представление (502), например, на основании возможностей для декодирования и/или воспроизведения клиентского устройства 40, пользовательских настроек, доступной пропускной способности сети и/или других характеристик представлений мультимедийного контента. Клиентское устройство 40 может затем запросить один или более сегментов выбранного представления (504).

Серверное устройство 60 может отправить запрошенные сегменты клиентскому устройству 40 (506). После приема запрошенных сегментов клиентское устройство 40 может декодировать и отобразить принятые данные (508). Клиентское устройство 40 может затем определить, были ли приняты все видеоданные (510). Если последний сегмент представления (или мультимедийного контента в целом) не был принят (ветвь "НЕТ" для 510), клиентское устройство 40 может снова оценить доступную в настоящий момент величину пропускной способности сети, выбрать представление на основании этого анализа (502) и запросить сегменты представления (504).

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

Например, клиентское устройство 40 может создать отчет, чтобы включить в него указания относительно выбранных сегментов и представлений (512). Клиентское устройство 40 может также записать случаи переполнения/незаполнения буфера, которые могут приводить к паузам при воспроизведении медиаданных. Клиентское устройство 40 может сформировать отчет, включающий в себя последовательность элементов PeriodReport (ОтчетОПериоде), представлящих собой Периоды, которые были воспроизведены до конца. Элемент Периода может включать в себя последовательность элементов RepresentationReport (ОтчетОПредставлении), каждый из которых представляет собой непрерывное воспроизведение части Представления и обеспечивает время начала и конца и в реальном времени и во времени презентации. Отчет может также включать в себя время начального запуска, которое является временем от запроса пользователя на просмотр содержания до начала воспроизведения. Таким образом, отчетный документ может содержать электронный документ, форматированный с помощью расширяемого языка разметки (XML), указывающий представления мультимедийного контента, из которых клиентское устройство получало медиаданные мультимедийного контента.

Клиентское устройство 40 может обеспечить отчет серверному устройству 60 или другому устройству сети доставки контента, такому как устройство 20 подготовки контента или специальное устройство сбора отчетов. Таким образом, серверное устройство 60 может принять указания относительно сегментов и представлений, принятых клиентским устройством 40 (514). Серверное устройство 60 может затем предоставить указания, например, устройству 20 подготовки контента или другому устройству, связанному с поставщиком услуги или сборщиком медиаданных, для улучшения подготовки контента (516). Из информации, предоставленной клиентским устройством 40, поставщик услуг может точно определить, что было воспроизведено до конца, когда были паузы в воспроизведении, и когда были переключения между представлениями. Альтернативно или дополнительно, клиентское устройство 40 может предоставить сводную информацию в виде полной продолжительности воспроизведения и ряда различных, непрерывных периодов воспроизведения для каждого представления, вместе с числом пауз и средним значением и дисперсией продолжительности паузы.

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

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

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

В качестве примера, а не ограничения, такие компьютерно-читаемые носители данных могут содержать RAM, ROM, EEPROM, CD-ROM или другое запоминающее устройство на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, флэш-память или любую другую среду, которая может использоваться для хранения требуемого кода программы в виде инструкций или структур данных, и к которым может получить доступ компьютер. Кроме того, любое соединение следует называеть компьютерно-читаемым носителем. Например, если инструкции передаются с веб-сайта, сервера или другого удаленного источника с помощью коаксиального кабеля, волоконно-оптического кабеля, витой пары, цифровой абонентской линии (DSL) или беспроводных технологий, таких как инфракрасное излучение, радио и микроволны, то коаксиальный кабель, волоконно-оптический кабель, витая пара, DSL или беспроводные технологии, такие как инфракрасное излучение, радио и микроволны включаются в определение среды. Однако следует понимать, что компьютерно-читаемые носители данных и носители данных не включают в себя соединения, несущие волны, сигналы или другие передающие среды, скорее направлены на некратковременные, материальные носители данных. Термин «диск», используемый здесь, включает в себя компакт-диски (CD), лазерные диски, оптические диски, цифровые универсальные диски (DVD), гибкие магнитные диски и диски Blu-ray, причем магнитные диски обычно воспроизводят данные магнитным образом, в то время как оптические диски воспроизводят данные оптически с помощью лазеров. Комбинации приведенного выше также должны быть включены в объем компьютерно-читаемых носителей.

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

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

Изобретение относится к хранению и транспортировке закодированных мультимедийных данных. Техническим результатом является улучшение потоковой передачи медиаданных по сети. Предложен способ получения мультимедийных данных. Способ включает в себя этап, на котором получают данные первого сегмента представления мультимедийного контента в соответствии с данными копии файла манифеста, сохраненного клиентским устройством, при этом данные первого сегмента соответствуют периоду мультимедийного контента. Далее согласно способу получают часть второго сегмента представления в соответствии с файлом манифеста, при этом данные второго сегмента соответствуют периоду, которому соответствуют данные первого сегмента, при этом второй сегмент имеет место после первого сегмента в упомянутом представлении и при этом упомянутая часть второго сегмента указывает, что файл манифеста должен быть обновлен. А также обновляют копию файла манифеста, сохраненного клиентским устройством, на основании указания, что файл манифеста должен быть обновлен, и получают медиаданные второго сегмента в соответствии с обновленным файлом манифеста. 6 н. и 29 з.п. ф-лы, 11 ил., 7 табл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. Устройство по п. 14, в котором средство для обновления файла манифеста содержит:
средство для определения одного или более элементов файла манифеста, которые должны быть обновлены; и
средство для обновления только определенных одного или более элементов файла манифеста.

18. Устройство по п. 14, дополнительно содержащее:
средство для получения медиаданных из второго, другого представления мультимедийного контента; и
средство для отправки информации, указывающей данные полученные из первого представления и второго представления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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