РАЗМЕЩЕНИЕ ФРАГМЕНТОВ СУБТРЕКА ДЛЯ ПОТОКОВОЙ ПЕРЕДАЧИ ВИДЕОДАННЫХ

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

Данные раскрытие относится к хранению и транспортировке кодированных видеоданных.

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

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

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

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

Были предприняты попытки разработать новые стандарты видеокодирования, основанные на H.264/AVC. Одним таким стандартом является стандарт масштабируемого видеокодирования (SVC), который представляет собой масштабируемое расширение H.264/AVC. Другим стандартом является многовидовое видеокодирование (MVC), которое становится многовидовым расширением H.264/AVC. Совместный проект MVC описан в JVT-AB204, «Joint Draft 8.0 on Multiview Video Coding,» 28^th JVT meeting, Hannover, Germany, July 2008, доступном по адресу http://wftp3.itu.int/av-arch/jvt-site/2008_07_Hannover/JVT-AB204.zip. Версия, встроенная в стандарт AVC, описана в JVT-AD007, «Editors' draft revision to ITU-T Rec. H.264 | ISO/IEC 14496-10 Advanced Video Coding - in preparation for ITU-T SG 16 AAP Consent (in integrated form)», 30^th JVT meeting, Geneva, CH, Feb. 2009, доступном по адресу http://wftp3.itu.int/av-arch/jvt-site/2009_01_Geneva/JVT-AD007.zip.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фрагмент трека может представлять собой фрагмент представления видео базового формата медиафайлов ISO или фрагмент системного потока MPEG-2, который может быть любого вида из следующих: пакетированный элементарный поток (PES), программный поток (PS) или транспортный поток (TS). В транспортном потоке (TS) MPEG-2 пакеты, соответствующие блокам доступа, обычно упорядочиваются по порядку декодирования. Блок доступа может сегментироваться на многочисленные транспортные пакеты в потоке TS. В случае, если фрагмент трека определяется как непрерывная часть системного потока MPEG-2, фрагмент трека может быть представлен как файловый блок, например, файл или сегмент файла. Методы данного раскрытия могут включать в себя переупорядочение блока доступа во фрагменте в несколько фрагментов субтрека, каждый из которых может соответствовать соответствующему иерархическому слою блоков доступа (кодированных изображений), так что и кодированные изображения общего иерархического слоя представляются непрерывно в части потока. Фрагменты субтрека во фрагменте трека могут размещаться в соответствии с порядком декодирования. Таким образом, кодированные видеоизображения общего слоя могут размещаться рядом в видеофайле. Следовательно, устройство назначения может извлекать все кодированные изображения до конкретного иерархического слоя во фрагменте фильма, используя единственный запрос, например, запрос частичного GET HTTP, задающий байтовый диапазон кодированных видеоизображений до требуемого иерархического слоя.

В качестве примера, формат файлов усовершенствованного видеокодирования (AVC) определяет, что кодированные видеоизображения размещаются в порядке декодирования в любом фрагменте трека или фрагменте фильма. Группа изображений (GOP) может иметь некоторое количество изображений, кодированных с использованием различных схем предсказания, например, внутреннее предсказание (I-изображения) и внешнее предсказание (P-изображения и B-изображения). I-изображения могут кодироваться без ссылки на другие изображения, P-изображения могут кодироваться относительно одного или более опорных изображений в одном направлении, и B-изображения могут кодироваться относительно одного или более изображения в обоих направлениях (вперед и назад в видеопоследовательности).

Внешне кодированное изображение может иметь иерархический уровень, равный или больший иерархического уровня опорного изображения для внешне кодированного изображения. Примерная последовательность изображений в порядке отображения может быть I₀B₃B₂B₃B₁B₃B₂B₃P₀, где буква обозначает тип кодирования для каждого изображения, и номер, в данном случае, обозначает иерархический уровень, которому соответствует изображение. Предположим с целью иллюстрации, что каждое изображение ассоциируется с числовым указателем, соответствующим позиции изображения в порядке отображения. Как указано выше, примерная последовательность расставляется в порядке отображения. Чтобы декодировать изображение, кодированное с внешним предсказанием, сначала может декодироваться опорное изображение для кодированного изображения. Таблица 1 ниже приводит примерный порядок декодирования для данной примерной последовательности, где число нижнего индекса ссылается на порядок отображения изображения:

Следовательно, обычное устройство источника может размещать данную примерную последовательность кодированных изображений в соответствии с их порядком декодирования. Обычно, изображения внутри GOP (в примере таблицы 1 размер GOP равен 4) с одинаковым временным иерархическим уровнем могут отделяться от изображений в других GOP этого же иерархического уровня. Например, B₂ и B₆ оба представляют собой изображения временного иерархического уровня 1 в примере таблицы 1, но разделяться изображениями с другими временными уровнями, если будут размещены в порядке декодирования. Даже изображения с одним и тем же временным уровнем в одной GOP могут разделяться изображениями с разными временными уровнями. Предположим в отношении фрагмента, который содержит, например, 10 GOP, что изображения с идентичным временным уровнем могут распределяться в этом фрагменте как многочисленные отдельные экземпляры.

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

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

Например, устройство назначения может быть выполнено с возможностью извлечения изображений до иерархического уровня один, который может соответствовать двум фрагментам субтрека: 0 и 1. Устройство назначения может выдавать запрос, основанный на байтовых диапазонах фрагментов субтрека 0 и 1. В ответ на этот примерный запрос устройство источника может предоставить изображения во фрагменте 0 и 1 субтрека, имеющем порядок отображения 0, 8, 4, 2, 6 и т.д.

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

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

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

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

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

В примерах MPEG-1 и MPEG-2 B-кодированные изображения обеспечивают естественную временную масштабируемость. Трек видеофайла, соответствующего MPEG-1 или MPEG-2, может включать в себя полный набор I-кодированных изображений, P-кодированных изображений и B-кодированных изображений. Отбрасывая B-кодированные изображения, видеофайл может получать соответствующие представления видео с половинным разрешением. MPEG-1 и MPEG-2 также обеспечивают понятие базового слоя и улучшающего слоя для кодирования двух временных слоев, причем изображения улучшающего слоя могут выбирать для каждого направления предсказания изображение или из базового слоя, или из улучшающего слоя в качестве опорного. Следовательно, устройство назначения может запрашивать, и устройство источника может обеспечивать, меньшее количество кодированных изображений, чем полный набор I-, P- и B-кодированных изображений, включенных в видеофайл. Видеоданные, представляемые устройством источника на устройство назначения, тем не менее, могут соответствовать MPEG-1 и MPEG-2 и могут иметь половинное (или меньшее) разрешение кроме исходного, полного набора кодированных изображений.

В качестве другого примера, H.264/AVC использует иерархические B-кодированные изображения для поддержки временной масштабируемости. Первое изображение видеопоследовательности в H.264/AVC может упоминаться как изображение мгновенного обновления декодера (IDR), также известное как ключевое изображение. Ключевые изображения обычно кодируются в регулярных или нерегулярных интервалах, которые являются или внутренне кодированными, или внешне кодированными, с использованием предыдущего ключевого изображения в качестве опорного для предсказания с компенсацией движения. Группа изображений (GOP) обычно включает в себя ключевое изображение и все изображения, которые временно располагаются между ключевым изображением и предыдущим ключевым изображением. GOP может быть разделена на две части, одна представляет собой ключевое изображение, и другая включает в себя неключевые изображения. Неключевые изображения иерархически предсказываются посредством 2 опорных изображений, которыми являются ближайшие изображения более низкого временного уровня из прошлого и будущего времени.

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

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

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

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

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

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

В базовом формате медиафайлов ISO группирование сэмплов представляет собой назначение каждого из сэмплов в треке членом одной группы сэмплов. Не требуется, чтобы сэмплы в группе сэмплов были рядом. Например, при представлении H.264/AVC в формате файлов AVC сэмплы видео на одном временном уровне могут отбираться в одну группу сэмплов. Группы сэмплов могут представляться двумя структурами данных: боксом SampleToGroup (sbdp) и боксом SampleGroupDescription. Бокс SampleToGroup представляет назначение сэмплов группам сэмплов. Может быть один экземпляр бокса SampleGroupDescription для каждого элемента группы сэмплов для описания свойств соответствующей группы.

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

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

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

3GP (формат файлов 3GPP) представляет собой формат мультимедийного контейнера, определенный Проектом партнерства по созданию системы 3-го поколения (3GPP) для мультимедийных услуг универсальной системы мобильной связи (UMTS) третьего поколения (3G). Он обычно используется на мобильных телефонах 3G и других устройствах с возможностями 3G, но также может воспроизводиться на некоторых телефонах и устройствах 2G и 4G. Формат файлов 3GPP основывается на базовом формате медиафайлов ISO. Самый последний 3GP определяется в 3GPP TS26.244 «Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)». Формат файлов 3GPP хранит видеопотоки в виде MPEG-4 Part 2, или H.263, или MPEG-4 Part 10 (AVC/H.264). 3GPP позволяет использовать кодеки AMR и H.263 в базовом формате медиафайлов ISO (MPEG-4 Part 12), так как 3GPP определяет использование полей Элемент сэмпла и полей шаблона в базовом формате медиафайлов ISO, а также определяет новые боксы, на которые ссылаются кодеки. Для хранения характерной для медиа MPEG-4 информации в файлах 3GP, спецификация 3GP ссылается на формат файлов MP4 и AVC, которые также основываются на базовом формате медиафайлов ISO. Спецификации форматов файлов MP4 и AVC описывают использование контента MPEG-4 в базовом формате медиафайлов ISO.

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

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

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

Формат файлов MVC также поддерживает трек экстрактора, который извлекает блоки NAL из разных видов, образуя рабочую точку, которая представляет собой поднабор видов с некоторой частотой кадров. Конструкция трека экстрактора MVC аналогична экстрактору в формате файлов SVC. Однако не поддерживается использование треков экстрактора MVC для формирования альтернативной группы. Для поддержки выбора треков предлагается следующее предложение MPEG для MPEG: P. Frojdh, A. Norkin, and C. Priddle, «File format sub-track selection and switching,» ISO/IEC JTC1/SC29/WG11 MPEG M16665, London UK. Это предложение пытается сделать возможным принцип альтернативной группы / группы переключения на уровне субтрека.

Группа сэмплов отображения представляет собой расширение для группы сэмплов. В группе сэмплов отображения каждый элемент группы (сэмплов) имеет свое описание «groupID» (идентификатор группы), которое фактически представляет собой отображение на view_id (идентификатор вида), после возможного агрегирования блоков NAL в виде в один блок NAL. Другими словами, каждый элемент группы сэмплов имеет свои содержащиеся в нем виды, перечисленные в значении ScalableNALUMapEntry (масштабируемый элемент отображения блока NAL). grouping_type (тип группирования) этого элемента группы сэмплов является «scnm».

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

AVC и 3GPP являются расширениями базового формата медиафайлов ISO, тогда как SVC и MVC являются расширениями формата файлов AVC. Следовательно, методы данного раскрытия могут быть применены в отношении видеофайлов, соответствующих базовому формату медиафайлов ISO, формату файлов AVC и его расширениям, например, SVC и MVC, и/или формату файлов 3GPP. Методы дополнительно могут применяться к этим и другим расширениям этих форматов и дополнительно могут применяться для расширения других форматов файлов для обеспечения фрагментов субтрека сборкой сэмплов видео в различных форматах файлов для потоковой передачи HTTP.

В отношении 3GPP в качестве другого примера, транспорт HTTP/TCP/IP поддерживается для файлов 3GPP для загрузки и прогрессивной загрузки. Кроме того, использование HTTP для потоковой передачи видео может обеспечивать некоторые преимущества, и становятся популярными услуги потоковой передачи видео, основанные на HTTP. Потоковая передача HTTP может обеспечивать некоторые преимущества, включая то, что могут использоваться существующие компоненты и протоколы Интернета, так что не требуются новые усилия для разработки новых методов для транспортировки видеоданных по сети. Другие транспортные протоколы, например, формат полезной нагрузки RTP, требуют, чтобы промежуточные сетевые устройства, например, средние боксы, имели сведения о формате медиа и контексте сигнализации. Также, потоковая передача HTTP может управляться клиентом, что может избежать вопросов управления.

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

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

Фиг.1 представляет собой блок-схему, иллюстрирующую примерную систему 10, в которой устройство 20 источника аудио/видео (A/V) посылает аудио- и видеоданные на устройство 40 назначения A/V. Система 10 на фиг.1 может соответствовать системе видеоконференции, системе сервер/клиент, системе вещатель/приемник или любой другой системе, в которой видеоданные посылаются с устройства источника, такого как устройство 20 источника A/V, на устройство назначения, такое как устройство 40 назначения A/V. В некоторых примерах устройство 20 источника A/V и устройство 40 назначения A/V могут выполнять двунаправленный обмен информацией. Т.е. устройство 20 источника A/V и устройство 40 назначения A/V могут быть способны как кодировать, так и декодировать (и передавать и принимать) аудио- и видеоданные. В некоторых примерах аудиокодер 26 может содержать речевой кодер, также упоминаемый как вокодер.

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

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

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

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

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

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

Устройство 20 источника A/V может предоставлять «услугу» устройству 40 назначения A/V. Услуга, в основном, соответствует поднабору доступных видов данных MVC. Например, данные MVC могут быть доступны для восьми видов, упорядоченных от нуля до семи. Одна услуга может соответствовать стереовидео, имеющему два вида, в то время как другая услуга может соответствовать четырем видам, и еще другая услуга может соответствовать всем восьми видам. В общем, услуга соответствует любой комбинации (т.е. любому поднабору) доступных видов. Услуга также может соответствовать комбинации доступных видов, а также аудиоданных. Рабочая точка может соответствовать услуге, так что устройство 20 источника A/V может дополнительно обеспечивать дескриптор рабочей точки для каждой услуги, предоставляемой устройством 20 источника A/V.

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

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

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

«Программа», используемая в данном раскрытии, может содержать комбинацию аудиоданных и видеоданных, например, элементарный поток аудио и поднабор доступных видов, доставляемых услугой устройства 20 источника A/V. Каждый пакет 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.

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

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

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

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

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

Блок 30 инкапсуляции может дополнительно определять рабочие точки как включающие конкретные фрагменты субтрека. В частности, блок 30 инкапсуляции может определять характеристики рабочих точек, включая временной уровень (temporal_id (временной идентификатор)), quality_id (идентификатор качества), dependency_id (идентификатор зависимости) и/или view_id. В примерах, соответствующих SVC, характеристики могут соответствовать значениям в заголовке блока NAL блоков NAL SVC. В примерах, соответствующих MVC, характеристики могут соответствовать значениям в заголовке блока NAL блоков NAL MVC. В некоторых примерах только временной уровень может присутствовать в качестве характеристики рабочей точки. В контексте SVC могут присутствовать temporal_id (временной уровень), quality_id и dependency_id. В контексте MVC могут присутствовать temporal_id и view_id.

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

Блок 30 инкапсуляции может формировать блоки NAL, содержащие заголовок, который идентифицирует программу, к которой принадлежит NAL, а также полезную нагрузку, например, аудиоданные, видеоданные или данные, которые описывают транспортный или программный поток, которому соответствует блок NAL. Например, в H.264/AVC блок NAL включает в себя 1-байтовый заголовок и полезную нагрузку изменяющегося размера. В одном примере заголовок блока NAL содержит элемент priority_id, элемент temporal_id, элемент anchor_pic_flag (флаг опорного изображения), элемент view_id, элемент non_idr_flag (флаг не-IDR) и элемент inter_view_flag (флаг межвидового предсказания). В обычном MVC сохраняется блок NAL, определенный в H.264, за исключением блоков NAL префикса и блоков NAL кодированного слайса MVC, которые включают в себя 4-байтовый заголовок блока NAL MVC и полезную нагрузку блока NAL.

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

Элемент anchor_pic_flag может обозначать, является ли изображение опорным изображением или неопорным изображением. Опорные изображения и все изображения, следующие за ними в порядке вывода (т.е. в порядке отображения), могут правильно декодироваться без декодирования предыдущих изображений в порядке декодирования (т.е. в порядке битового потока), и, таким образом, могут использоваться в качестве точек случайного доступа. Опорные изображения и неопорные изображения могут иметь разные зависимости, обе из которых сигнализируются в наборе параметров последовательности. Другие флаги будут обсуждаться и использоваться в следующих разделах данной главы. Такое опорное изображение также может упоминаться как точка доступа открытой группы изображений (GOP), в то же время поддерживается точка доступа закрытой GOP, когда элемент non_idr_flag равен нулю. Элемент non_idr_flag обозначает, является ли изображение мгновенным обновлением декодера (IDR) или изображением IDR вида (V-IDR). В общем, изображение IDR и все изображения, следующие за ним в порядке вывода или порядке битового потока, могут правильно декодироваться без декодирования предыдущих изображений или в порядке декодирования, или в порядке отображения.

Элемент view_id может содержать синтаксическую информацию, которая может использоваться для идентификации вида, который может использоваться для интерактивности данных внутри декодера MVC, например, для межвидового предсказания, и вне декодера, например, для визуализации. Элемент inter_view_flag может задавать, используется ли соответствующий блок NAL другими видами для межвидового предсказания. Чтобы передать 4-байтовую информацию заголовка блока NAL для базового вида, который может быть совместимым с AVC, в MVC определяется блок NAL префикса. В контексте MVC блок доступа базового вида включает в себя блоки NAL VCL текущего момента времени вида, а также его блок NAL префикса, который содержит только заголовок блока NAL. Декодер H.264/AVC может игнорировать блок NAL префикса.

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

Блок 30 инкапсуляции также может собирать блоки доступа от множества блоков NAL. В общем, блок доступа может содержать один или более блоков NAL для представления кадра видеоданных, а также аудиоданные, соответствующие кадру, когда такие аудиоданные являются доступными. Блок доступа, в основном, включает в себя все блоки NAL для одного момента времени вывода, например, все аудио- и видеоданные для одного момента времени. Например, если каждый вид имеет частоту кадров 20 кадров в секунду (fps), тогда каждый момент времени может соответствовать интервалу времени 0,05 секунд. Во время этого интервала времени конкретные кадры для всех видов одного и того же блока доступа (одного и того же момента времени) могут визуализироваться одновременно. В примере, соответствующем H.264/AVC, блок доступа может содержать кодированное изображение в одном моменте времени, который может быть представлен как главное кодированное изображение. Следовательно, блок доступа может содержать все аудио- и видеокадры общего временного момента, например, все виды, соответствующие времени X. Данное раскрытие также ссылается на кодированное изображение конкретного вида в качестве «составляющей вида». Т.е. составляющая вида может содержать кодированное изображение (или кадр) для конкретного вида в конкретное время. Следовательно, блок доступа может определяться как содержащий все составляющие вида общего временного момента. Порядку декодирования блоков доступа нет необходимости обязательно быть таким же, что и порядок вывода или отображения.

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), размер буфера кодируемых изображений (CPB), диапазон вектора движения по вертикали, максимальное количество векторов движения на два последовательных MB и, может ли B-блок иметь разделения на субмакроблоки менее 8×8 пикселей. Таким образом, декодер может определять, является ли декодер способным надлежащим образом декодировать битовый поток.

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

В соответствии со стандартом кодирования H.264, в качестве примера, B-изображения используют два списка ранее кодированных опорных изображений, список 0 и список 1. Каждый из этих двух списков может содержать прошлые и/или будущие кодируемые изображения во временном порядке. Блоки в B-изображении могут предсказываться одним способом из нескольких: предсказание с компенсацией движения из опорного изображения списка 0, предсказание с компенсацией движения из опорного изображения списка 1 или предсказание с компенсацией движения из комбинации опорных изображений как списка 0, так и списка 1. Чтобы получить комбинацию опорных изображений как списка 0, так и списка 1, две опорные области с компенсацией движения получаются из опорного изображения списка 0 и списка 1 соответственно. Их комбинация используется для предсказания текущего блока.

Стандарт ITU-T H.264 поддерживает внутреннее предсказание в различных размеров блока, таких как 16 на 16, 8 на 8 или 4 на 4 для составляющей яркости, и 8×8 для составляющих цветности, а также внешнее предсказание в различных размерах блока, таких как 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 и 4×4 для составляющих яркости и соответствующие масштабированные размеры для составляющих цветности. В данном раскрытии «N×N» и «N на N» могут использоваться попеременно для ссылки на пиксельные размеры блока в смысле размеров по вертикали и по горизонтали, например, 16×16 пикселей или 16 на 16 пикселей. Обычно, блок 16×16 имеет 16 пикселей в вертикальном направлении (y=16) и 16 пикселей в горизонтальном направлении (x=16). Аналогично, блок N×N, как правило, имеет N пикселей в вертикальном направлении и N пикселей в горизонтальном направлении, где N представляет неотрицательное целое число. Пиксели в блоке могут размещаться рядами и столбцами. Блоки могут иметь разное количество пикселей в размерах по горизонтали и по вертикали. Т.е. блоки могут включать в себя N×M пикселей, где N необязательно равно M.

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

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

Термин «макроблок» ссылается на структуру данных для кодирования изображения и/или видеоданных в соответствии с двумерным массивом пикселей, который содержит 16×16 пикселей. Каждый пиксель содержит составляющую цветности и составляющую яркости. Следовательно, макроблок может определять четыре блока яркости, причем каждый содержит двумерный массив 8×8 пикселей, два блока цветности, причем каждый содержит двумерный массив 16×16 пикселей, и заголовок, содержащий информацию синтаксиса, такую как структура кодированного блока (CBP), режим кодирования (например, режим внутреннего (I) или внешнего (P или B) кодирования), размер разделения для разделений внутренне кодированного блока (например, 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 или 4×4), или один или более векторов движения для внешне кодированного макроблока.

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

После того как блок 30 инкапсуляции соберет блоки NAL и/или блоки доступа в видеофайл, основанный на принятых данных, блок 30 инкапсуляции передает видеофайл на интерфейс 32 вывода для вывода. В некоторых примерах блок 30 инкапсуляции может хранить видеофайл локально или посылать видеофайл на удаленный сервер при помощи интерфейса 32 вывода, вместо посылки видеофайла непосредственно на устройство 40 назначения. Интерфейс 32 вывода может содержать, например, передатчик, приемопередатчик, устройство для записи данных на считываемый компьютером носитель, такой как, например, накопитель на оптических дисках, накопитель на магнитных носителях (например, накопитель на гибких магнитных дисках), порт универсальной последовательной шины (USB), сетевой интерфейс или другой интерфейс вывода. Интерфейс 32 вывода выводит видеофайл на считываемый компьютером носитель 34, такой как, например, сигнал передачи, магнитный носитель, оптический носитель, память, флеш-накопитель или другой считываемый компьютером носитель.

В конечном счете, интерфейс 36 ввода извлекает данные со считываемого компьютером носителя 34. Интерфейс 36 ввода может содержать, например, накопитель на оптических дисках, накопитель на магнитных носителях, порт USB, приемник, приемопередатчик или другой интерфейс считываемого компьютером носителя. Интерфейс 36 ввода может подавать блок NAL или блок доступа на блок 38 декапсуляции. Блок 38 декапсуляции может декапсулировать элементы видеофайла в составляющие потоков PES, депакетировать потоки PES для извлечения кодированных данных, и посылать кодированные данные или на аудиодекодер 46, или на видеодекодер 48 в зависимости от того, являются ли кодированные данные частью аудио- или видеопотока, например, как обозначено заголовками пакета PES потока. Аудиодекодер 46 декодирует кодированные аудиоданные и посылает декодированные аудиоданные на вывод 42 аудио, тогда как видеодекодер 48 декодирует кодированные видеоданные и посылает декодированные видеоданные, которые могут включать в себя множество видов потока, на вывод 44 видео.

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

Например, блок 38 декапсуляции может выбирать конкретную рабочую точку, которая может соответствовать поднабору доступных иерархических слоев. Затем блок 38 декапсуляции может определить для каждого фрагмента фильма, какие фрагменты субтрека фрагмента фильма соответствуют иерархическим слоям рабочей точки. Кроме того, блок 38 декапсуляции может определить байтовые диапазоны в каждом фрагменте фильма для соответствующих фрагментов субтрека. Основываясь на этих определенных байтовых диапазонах, блок 38 декапсуляции может генерировать запросы частичного GET HTTP, которые задают определенные байтовые диапазоны для фрагментов фильма для извлечения фрагментов субтрека. В некоторых примерах блок 38 декапсуляции может генерировать индивидуальные запросы для каждого требуемого слоя. В некоторых примерах блок 38 декапсуляции может генерировать единственный запрос для фрагментов субтрека, охватывающий многочисленные слои. Блок 38 декапсуляции затем может повторно размещать кодированные сэмплы видео фрагментов субтрека в порядке декодирования, используя объекты повторного сборщика фрагментов субтрека и передать размещенные кодированные сэмплы видео на видеодекодер 48, который может декодировать сэмплы видео. В конечном счете, вывод 44 видео может отображать декодированные сэмплы видео.

Фиг.2 представляет собой блок-схему, иллюстрирующую компоненты примерного блока инкапсуляции. В примере на фиг.2 блок 30 инкапсуляции включает в себя интерфейс 80 ввода видео, интерфейс 82 ввода аудио, блок 60 создания видеофайла и интерфейс 84 вывода видеофайла. Блок 60 создания видеофайла в данном примере включает в себя блок 62 конструирования блока уровня сетевой абстракции (NAL) и блок 64 создания фрагмента субтрека, который дополнительно включает в себя блок 66 управления слоем, блок 68 вставки сэмпла, блок 70 создания заголовка и блок 72 создания объекта повторного сборщика.

Интерфейс 80 ввода видео и интерфейс 82 ввода аудио принимают кодированные видео- и аудиоданные соответственно. Интерфейс 80 ввода видео и интерфейс 82 ввода аудио могут принимать кодированные видео- и аудиоданные, когда данные кодируются, или могут извлекать кодированные видео- и аудиоданные со считываемого компьютером носителя. При приеме кодированных видео- и аудиоданных интерфейс 80 ввода видео и интерфейс 82 ввода аудио передают кодированные видео- и аудиоданные на блок 60 создания видеофайла для сборки в видеофайл.

Блок 60 создания видеофайла может соответствовать блоку управления, включающему в себя аппаратное обеспечение, программное обеспечение и/или программно-аппаратное обеспечение, выполненное с возможностью выполнения функций и процедур, приписываемых им. Каждый из субблоков блока 60 создания видеофайла (блок 62 конструирования блока NAL, блок 64 создания фрагмента субтрека, блок 66 управления слоем, блок 68 вставки сэмпла, блок 70 создания заголовка и блок 72 создания объекта повторного сборщика в данном примере) может быть реализован в виде индивидуальных аппаратных блоков и/или программных модулей, и/или может быть функционально интегрирован или дополнительно разделен на дополнительные субблоки.

Блок 60 создания видеофайла может соответствовать любому подходящему блоку обработки или схеме обработки, такой как, например, один или более микропроцессоров, специализированные интегральные схемы (ASIC), программируемые вентильные матрицы (FPGA), процессоры цифровой обработки сигналов (DSP) или любая их комбинация. Блок 60 создания видеофайла может дополнительно включать в себя считываемый компьютером носитель, содержащий инструкции для любого или для всех из блока 62 конструирования блока NAL, блока 64 создания фрагмента субтрека, блока 66 управления слоем, блока 68 вставки сэмпла, блока 70 создания заголовка и блока 72 создания объекта повторного сборщика, а также процессор для исполнения инструкций.

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

Блок 66 управления слоем может различать различные иерархические слои данных для видеофайла. Блок 66 управления слоем может дополнительно определять соответствие между фрагментами субтрека и иерархическими слоями, например, основываясь на стандарте формата файлов, которому соответствует видеофайл. Например, в отношении H.264/AVC, блок 66 управления слоем может ассоциировать временные слои кодирования с фрагментами субтрека. В качестве другого примера, в отношении SVC, блок 66 управления слоем может ассоциировать пространственные слои (например, базовый слой и один или более улучшающих слоев) с фрагментами субтрека. В качестве другого примера, в отношении MVC, блок 66 управления слоем может ассоциировать разные виды с фрагментами субтрека.

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

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

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

Следовательно, блок 60 создания видеофайла может вырабатывать различные типы видеофайлов, включающих в себя фрагменты субтрека, в соответствии с методами данного раскрытия. После того как блок 60 создания видеофайла вырабатывает видеофайл, включающий в себя фрагменты фильма, имеющие кодированные сэмплы видео, сгруппированные в соответствии с их соответствующими иерархическими уровнями, блок 60 создания видеофайла может передать видеофайл на интерфейс 84 вывода видеофайла. Интерфейс 84 вывода видеофайла может выводить видеофайл, например, на интерфейс 32 вывода устройства 20 источника. В некоторых примерах интерфейс 84 вывода видеофайла может выводить видеофайл на запоминающий носитель устройства 20 источника (не показан). Видеофайл может сохраняться локально в устройстве 20 источника, сохраняться на портативном запоминающем носителе, таком как цифровой многофункциональный диск (DVD), диск Blu-ray, флеш-накопитель, гибкий диск или другой портативный запоминающий носитель, выводиться по сети, например, в соответствии с протоколом потоковой передачи, такой как потоковая передача HTTP, или иным образом выводиться таким образом, что видеофайл может приниматься клиентским устройством, таким как устройство 40 назначения.

Фиг.3 представляет собой блок-схему, иллюстрирующую элементы примерного видеофайла 100, имеющего фрагменты 112 видео, причем каждый включает в себя фрагменты субтрека, имеющие кодированные видеоизображения общего иерархического уровня. Как описано выше, видеофайлы в соответствии с базовым форматом медиафайлов ISO и его расширениями хранят данные в последовательности объектов, упоминаемых как «боксы». В примере на фиг.3, видеофайл 100 включает в себя бокс 102 типа файла (FTYP), бокс 104 фильма (MOOV), боксы 112 фрагмента фильма (MOOF) и бокс 114 случайного доступа фрагмента фильма (MFRA).

Бокс 102 типа файла, в общем, описывает тип файла для видеофайла 100. Бокс 102 типа файла может включать в себя данные, которые идентифицируют спецификацию, которая описывает наилучшее использование для видеофайла 100. Бокс 102 типа файла может размещаться перед боксом 104 MOOV, боксами 112 фрагмента фильма и боксом 114 MFRA.

Бокс 104 MOOV в примере на фиг.3 включает в себя бокс 106 заголовка фильма (MVHD), бокс 108 трека (TRAK) и один или более боксов 110 расширения фильма (MVEX). В общем, бокс 106 MVHD может описывать общие характеристики видеофайла 100. Например, бокс 106 MVHD может включать в себя данные, которые описывают, когда видеофайл 100 был первоначально создан, когда в последний раз был модифицирован видеофайл 100, временную шкалу для видеофайла 100, длительность воспроизведения для видеофайла 100 или другие данные, которые, в общем, описывают видеофайл 100.

В некоторых примерах блок 30 инкапсуляции может определять характеристики фрагментов субтрека, которые соответствуют рабочим точкам в боксе 104 MOOV, или сегмента инициализации для потоковой передачи HTTP. В некоторых примерах блок 30 инкапсуляции может генерировать бокс заголовка фрагмента субтрека, который может включаться в качестве данных заголовка для видеофайла 100, причем один из фрагментов 112 фильма включает в себя фрагмент субтрека, или в других расположениях. Определение фрагмента субтрека может включать в себя структуру данных, которая отображает каждый фрагмент субтрека рабочей точки на описательные характеристики для фрагмента субтрека, такие как, например, значение временного уровня, значение quality_id, значение dependency_id и/или значение view_id. Определение рабочей точки может дополнительно включать в себя описательную информацию, такую как, например, информацию КОДЕК, информацию о профиле и уровне, частота кадров для рабочей точки, средняя скорость передачи битов для рабочей точки, максимальная скорость передачи битов для рабочей точки, пространственное разрешение для рабочей точки, количество видов, подлежащих отображению для рабочей точки, и/или количество видов, подлежащих декодированию для рабочей точки. Определения рабочей точки относящегося стандарта могут модифицироваться так, чтобы включать в себя такие данные.

Бокс 108 TRAK может включать в себя данные для трека видеофайла 100. Бокс 108 TRAK может включать в себя бокс заголовка трека (TKHD), который описывает характеристики трека, соответствующего боксу 108 TRAK. В некоторых примерах бокс 108 TRAK может включать в себя кодированные сэмплы видео, тогда как в других примерах, кодированные сэмплы видео трека могут быть включены во фрагменты 112 фильма, на которые могут ссылаться данные бокса 108 TRAK.

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

Боксы 110 MVEX могут описывать характеристики соответствующих фрагментов 112 фильма, например, чтобы сигнализировать, что видеофайл 100 включает в себя фрагменты 112 фильма в дополнение к видеоданным, включенным в бокс 104 MOOV, если они есть. В контексте потоковых видеоданных кодированные сэмплы видео могут быть включены во фрагменты 112 фильма, а не в бокс 104 MOOV. Следовательно, все кодированные сэмплы видео могут быть включены во фрагменты 112 фильма, а не в бокс 104 MOOV.

Бокс 104 MOOV может включать в себя некоторое количество боксов 110 MVEX, количество которых равно количеству фрагментов 112 фильма в видеофайле 100. Каждый из боксов 110 MVEX может описывать характеристики соответствующего одного из фрагментов 112 фильма. Например, каждый бокс MVEX может включать в себя бокс заголовка расширения фильма (MEHD), который описывает временную длительность для соответствующего одного из фрагментов 112 фильма.

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

Как отмечено выше, блок 30 инкапсуляции может организовывать кодированные сэмплы видео каждого из фрагментов 112 фильма в порядке иерархических уровней кодированных сэмплов видео. Т.е. в каждом из фрагментов 112 фильма блок 30 инкапсуляции может организовывать кодированные сэмплы видео фрагмента фильма так, что кодированные сэмплы видео общего иерархического уровня сохраняются рядом во фрагменте фильма. Таким образом, устройство 40 назначения (фиг.1) может извлекать все кодированные сэмплы видео до конкретного иерархического слоя из одного из фрагментов 112 фильма посредством представления единственного запроса, например, частичного GET HTTP, который задает байтовый диапазон, включающий в себя требуемый диапазон иерархических уровней. Аналогично, устройство 40 назначения может извлекать кодированные сэмплы видео общего иерархического слоя, используя единственный запрос, и может представлять один запрос для каждого требуемого иерархического слоя.

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

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

Фиг.4A представляет собой блок-схему, иллюстрирующую примерный фрагмент 180A фильма. Фрагмент 180A фильма может соответствовать одному из фрагментов 112 фильма (фиг.3). В примере на фиг.4A фрагмент 180A фильма включает в себя различные фрагменты субтрека. В частности, в данном примере фрагмент 180A фильма включает в себя фрагмент 182 субтрека слоя 0, фрагмент 188 субтрека слоя 1 и фрагмент 192 субтрека слоя 2.

Фрагмент 182 субтрека слоя 0 может включать в себя кодированные сэмплы видео, имеющие временный иерархический слой кодирования нуля. В данном примере этот слой включает в себя I-кадр 184 и P-кадры 186A-186N (P-кадры 186). P-кадры 186 могут кодироваться относительно предыдущих p-кадров 186 и/или I-кадра 184. Например, макроблоки P-кадра 186A могут кодироваться относительно I-кадра 184, тогда как макроблоки P-кадра 186B могут кодироваться относительно I-кадра 184 или P-кадра 186A.

Фрагмент 188 субтрека слоя 1 в данном примере включает в себя B-кадры 190A-190N (B-кадры 190). Каждый из B-кадров 190 имеет временную иерархию кодирования слоя 1. Следовательно, B-кадры 190 могут кодироваться относительно одного или более кадров фрагмента 182 субтрека слоя 0, т.е. I-кадра 184 и/или P-кадров 186.

Фрагмент 192 субтрека слоя 2 в данном примере включает в себя B-кадры 194A-194N (B-кадры 194). Каждый из B-кадров 194 имеет временную иерархию кодирования слоя 2. Следовательно, B-кадры 194 могут кодироваться относительно одного или более кадров фрагмента 188 субтрека слоя 1, т.е. B-кадров 190. Кроме того, фрагмент 180 видео может включать в себя дополнительные фрагменты субтрека, соответствующие более высоким временным слоям кодирования, как указано многоточием, следующим за фрагментом 192 субтрека слоя 2.

Хотя кардинальное число каждых из P-кадров 186, B-кадров 190 и B-кадров 194 выражено переменной «N», необходимо понимать, что N является переменной в каждом случае. Т.е. количество P-кадров 186 необязательно равно количеству B-кадров 190, которое дополнительно необязательно равно количеству B-кадров 194.

Устройство 40 назначения может определять извлечение фрагментов субтрека до конкретного иерархического слоя. Следовательно, устройство 40 назначения может представлять один или более запросов на извлечение фрагментов субтрека, соответствующих иерархическим слоям менее и/или равных определенному слою. Например, предполагая, что устройство 40 назначения определило извлечение фрагментов субтрека до слоя один, устройство 40 назначения может представить запросы частичного GET HTTP для извлечения фрагмента 182 субтрека слоя 0 и фрагмента 188 субтрека слоя 1. В некоторых примерах устройство 40 назначения может представлять максимально два запроса частичного GET HTTP на извлечение фрагмента 182 субтрека слоя 0 и фрагмента 188 субтрека слоя 1. В примере на фиг.4A устройство 40 назначения может альтернативно представить единственный запрос частичного GET HTTP на извлечение как фрагмента 182 субтрека слоя 0, так и фрагмента 188 субтрека слоя 1, так как фрагмент 182 субтрека слоя 0 и фрагмент 188 субтрека слоя 1 размещены рядом во фрагменте 180 видео, в данном примере.

Фиг.4B представляет собой блок-схему, иллюстрирующую примерный фрагмент 180B фильма. Фрагмент 180B фильма аналогичен фрагменту 180A фильма на фиг.4A, за исключением того, что в примере на фиг.4B фрагменты субтрека более высокого слоя могут включать в себя объекты повторного сборщика. Например, фрагмент 196 субтрека слоя 1 в данном примере включает в себя объекты 198A, 198B и 198C повторного сборщика. Объект 198A повторного сборщика идентифицирует I-кадр 184 фрагмента 182 субтрека слоя 0, объект 198B повторного сборщика идентифицирует P-кадр 186A фрагмента 182 субтрека слоя 0, и объект 198C повторного сборщика идентифицирует P-кадр 186B фрагмента 182 субтрека слоя 0 в данном примере. Фрагменты субтрека более высоких слоев могут включать в себя повторные сборщики, которые идентифицируют кадры фрагмента 182 субтрека слоя 0, и повторные сборщики, которые идентифицируют B-кадры 199 фрагмента 196 субтрека слоя 1.

Устройство 40 назначения может использовать повторные сборщики 198, чтобы способствовать переупорядочению кадров в порядок декодирования. Например, блок 38 декапсуляции может переупорядочивать кадры фрагмента 182 субтрека слоя 0 и фрагмента 196 субтрека слоя 1 для вырабатывания набора кадров в порядке декодирования I-кадра 184, P-кадра 186A, B-кадра 199A, P-кадра 186B, B-кадра 199B и т.д. Блок 38 декапсуляции затем может направлять кадры в порядке декодирования на видеодекодер 48. Видеодекодер 48 затем может декодировать кадры, и видеодисплей 44 может, в конечном счете, отображать кадры в порядке отображения, который может быть отличен от порядка декодирования и порядка кадров, размещенных во фрагменте 180B видео.

Фиг.5 представляет собой блок-схему, иллюстрирующую примерный фрагмент 200 видео SVC. В данном примере фрагмент 200 видео SVC включает в себя фрагмент 202 субтрека базового слоя, фрагмент 206 субтрека улучшающего слоя 1 и фрагмент 210 субтрека улучшающего слоя 2. Фрагмент 202 субтрека базового слоя включает в себя кадры 204A-204N базового слоя (кадры 204 базового слоя). Фрагмент 206 субтрека улучшающего слоя 1 включает в себя улучшающие кадры 208A-208N (улучшающие кадры 208). Фрагмент 210 субтрека улучшающего слоя 2 включает в себя улучшающие кадры 212A-212N (улучшающие кадры 212). Опять-таки, необходимо понимать, что N является потенциально разным для любого из кадров 204 базового слоя, улучшающих кадров 208 и улучшающих кадров 212.

Кадры 204 базового слоя могут соответствовать кадрам формата «четверть общего промежуточного формата» (QCIF). Улучшающие кадры 208 могут соответствовать кадрам пространственного улучшающего слоя CIF. Улучшающие кадры 212 могут соответствовать дополнительным кадрам пространственного улучшающего слоя.

Таким образом, методы данного раскрытия могут применяться в контексте SVC. Кроме того, улучшающие слои в SVC также могут включать в себя объекты повторного сборщика, которые ссылаются на кадры базового слоя и/или более низких улучшающих слоев. Следовательно, устройство 40 назначения может выбирать максимальный требуемый слой и представлять один или более запросов (например, запросы частичного GET HTTP) на извлечение данных для слоев до выбранного слоя.

Фиг.6 представляет собой блок-схему, иллюстрирующую примерный фрагмент 220 видео MVC. В данном примере фрагмент 220 видео MVC включает в себя фрагмент 222 субтрека вида 0, фрагмент 226 субтрека вида 1 и фрагмент 230 субтрека вида 2. Каждый вид может включать в себя некоторое количество составляющих вида. Например, фрагмент 222 субтрека вида 0 включает в себя кадры 224A-224N вида 0 (кадры 224 вида 0), фрагмент 226 субтрека вида 1 включает в себя кадры 228A-228N вида 1 (кадры 228 вида 1), и фрагмент 230 субтрека вида 2 включает в себя кадры 232A-232N вида 2 (кадры 232 вида 2).

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

Устройство 40 назначения может извлекать составляющие вида конкретного вида посредством выдачи запроса частичного GET HTTP, который задает байтовый диапазон для фрагмента субтрека вида, соответствующего виду. Например, чтобы извлечь составляющие вида у вида 0, устройство 40 назначения может представить запрос частичного GET HTTP, задающий байтовый диапазон фрагмента 222 субтрека вида 0 во фрагменте 220 видео MVC. Аналогично, устройство 40 назначения может выдать индивидуальные запросы на извлечение любых или всех из других видов фрагмента 220 видео MVC. При приеме запрошенных видов устройство 40 назначения может упорядочить составляющие вида в порядке декодирования, декодировать составляющие вида и отобразить декодированные видеоданные.

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

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

Устройство 20 источника затем может разделять сэмплы для фрагмента видео на соответствующие слои (212). Например, для AVC устройство 20 источника может разделять сэмплы видео на слои временного кодирования. В качестве другого примера, для SVC устройство 20 источника может разделять сэмплы видео на базовый слой и один или более улучшающих слоев. В качестве еще другого примера, для MVC устройство 20 источника может разделять сэмплы на соответствующие виды. В любом случае, устройство 20 источника может вырабатывать фрагменты субтрека для каждого соответствующего слоя, так что фрагменты субтрека включают в себя кодированные сэмплы видео для соответствующего слоя (214). Устройство 20 источника затем может выводить фрагмент фильма (216). Т.е. устройство 20 источника может включать в себя фрагмент фильма в видеофайле, хранимом на считываемом компьютером носителе.

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

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

Имеются случаи, когда объектам повторного сборщика необязательно переупорядочивать блоки доступа в разных фрагментах субтрека для поддержания правильного порядка декодирования. Например, в TS MPEG-2 пакеты, содержащие видеоданные, могут включать в себя временную метку декодирования. Таким образом, может определяться время декодирования каждого блока доступа, и такой процесс переупорядочения не потребует дополнительной сигнализации. Также, в некоторых примерах чередование иерархического слоя с индексом i и иерархического слоя с индексом i+1 может следовать фиксированному шаблону и, таким образом, может сигнализироваться очень незначительная сигнализация, например, некоторое количество сэмплов видео в иерархическом слое i и другое количество сэмплов видео, следующих за сэмплами видео в иерархическом слое i+1 в периоде. Например, если изображениями временного слоя 0 являются I, P₄, P₈ и т.д., и изображениями временного слоя 1 являются B₂, B₆ и т.д., простая сигнализация (1, 1) может быть достаточна для сэмплов видео в двух временных слоях, подлежащих правильному переупорядочению. Сигнализируемая информация о переупорядочении для каждого фрагмента субтрека, поэтому, может соответствовать идентификатору фрагмента субтрека и количеству изображений во фрагменте субтрека.

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

Устройство 20 источника может подавать фрагменты субтрека запроса(ов) на устройство 40 назначения (222). После приема фрагментов субтрека фрагмента фильма устройство 40 назначения может переупорядочивать сэмплы видео фрагмента фильма, так что сэмплы видео размещаются в порядке декодирования (224). Затем устройство 40 назначения может декодировать и отображать принятые сэмплы (226).

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

Первоначально устройство 40 назначения может принимать запрос на доступ к видеофайлу (230). Например, пользователь может выполнить веб-браузера, используя устройство 40 назначения для запроса URL или URN видеофайла. В ответ на этот запрос устройство 40 назначения может загрузить данные заголовка видеофайла (232). Данные заголовка могут описывать, как организован видеофайл, и могут сигнализировать, что видеофайл размещен в соответствии с методами данного раскрытия, так что кодированные сэмплы видео фрагментов фильма размещаются в соответствии с иерархическими слоями кодированных сэмплов видео. Данные заголовка дополнительно могут описывать каждый из иерархических слоев видеофайла, например, байтовые диапазоны для фрагментов субтрека во фрагменте фильма. Данные заголовка также могут указывать, что фрагменты субтрека фрагментов фильма видеофайла включают в себя кодированные сэмплы видео общего иерархического слоя, как описано в данном раскрытии.

Устройство 40 назначения затем может определить, какой из иерархических слоев извлекать (234). Основываясь на этом определении, устройство 40 назначения может определить байтовые диапазоны каждого из фрагментов субтрека, соответствующих иерархическому слоям, подлежащим извлечению (236). Устройство 40 назначения может продолжать выдавать индивидуальные запросы, которые задают байтовый диапазон соответствующего фрагмента субтрека, подлежащего извлечению (238), пока не будут приняты все требуемые фрагменты субтрека (240).

После приема всех требуемых фрагментов субтрека блок 38 демультиплексирования устройства 40 назначения может переупорядочивать принятые сэмплы, так что сэмплы находятся в порядке декодирования (242). Блок 38 демультиплексирования затем может направить сэмплы на видеодекодер 48 для декодирования, который может направить декодированные сэмплы видео на вывод 44 видео для отображения (244).

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

Фиг.9 представляет собой схему концептуального представления, иллюстрирующую примерный шаблон предсказания MVC. В примере на фиг.9 изображено восемь видов (имеющих ID вида «S0» - «S7»), и двенадцать временных расположений («T0» - «T11») изображены для каждого вида. Т.е. каждый ряд на фиг.9 соответствует виду, тогда как каждый столбец указывает временное расположение.

Хотя MVC имеет так называемый базовый вид, который является декодируемым декодерами H.264/AVC, и пара стерео видов может поддерживаться также MVC, преимущество MVC заключается в том, что он может поддерживать пример, который использует более двух видов в качестве ввода 3D-видео и декодирует это 3D-видео, представленное многими видами. Визуализатор клиента, имеющий декодер MVC, может ожидать контент 3D-видео с многими видами. Составляющая опорного вида и составляющая неопорного вида в виде могут иметь разные зависимости вида. Например, составляющие опорного вида на виде S2 зависят от составляющих вида на виде S0. Однако составляющие неопорного вида на виде S2 не зависят от составляющих вида на других видах.

Кадры на фиг.9 указаны для каждого ряда и каждого столбца на фиг.9 с использованием заштрихованных блоков, включающих в себя букву, обозначающую, является ли соответствующий кадр внутренне кодированным (т.е. I-кадром), или внешне кодированным в одном направлении (т.е. P-кадром), или в многочисленных направлениях (т.е. B-кадром). Обычно, предсказания указываются стрелками, при этом кадр, на который выполняется указание, использует объект, от которого выполняется указание, для опорного изображения для предсказания. Например, P-кадр вида S2 во временном расположении T0 предсказывается из I-кадра вида S0 во временном расположении T0.

Как и с видеокодированием единственного вида, кадры видеопоследовательности многовидового видеокодирования могут кодироваться с предсказанием в отношении кадров в разных временных расположениях. Например, b-кадр вида S0 во временном расположении T1 имеет стрелку, указываемую на него от I-кадра вида S0 во временном расположении T0, указывая, что b-кадр предсказывается из I-кадра. Дополнительно, однако в контексте многовидового видеокодирования кадры могут предсказываться межвидовым образом. Т.е. составляющая вида может использовать составляющие вида в других видах для опорного изображения. В MVC, например, межвидовое предсказание реализуется, как если бы составляющая вида в другом виде являлась опорным изображением внешнего предсказания. Потенциальные межвидовые опорные изображения могут сигнализироваться в расширении MVC набора параметров последовательности (SPS) и могут модифицироваться процессом составления списка опорных изображений, который позволяет выполнять гибкое упорядочение опорных изображений внешнего предсказания или межвидового предсказания. Таблица 3 ниже обеспечивает примерное определение для набора параметров последовательности расширения MVC.

Фиг.9 обеспечивает различные примеры межвидового предсказания. Кадры вида S1 в примере на фиг.9 изображены как предсказываемые из кадров в разных временных расположениях вида S1, а также получаемые посредством межвидового предсказания из кадров видов S0 и S2 в этих же временных расположениях. Например, b-кадр вида S1 во временном расположении T1 предсказывается из каждого из B-кадров вида S1 во временных расположениях T0 и T2, а также из b-кадров видов S0 и S2 во временном расположении T1.

В примере на фиг.9 прописная буква «B» и строчная буква «b» предназначены, чтобы указывать разные иерархические зависимости между кадрами, а не разные методологии кодирования. В общем, кадры с прописной буквой «B» являются относительно более высокими в иерархии предсказания, чем кадры со строчной буквой «b». Т.е. в примере на фиг.9 «b»-кадры кодируются с ссылкой на «B»-кадры. Могут быть добавлены дополнительные иерархические уровни, имеющие дополнительные двунаправлено кодированные кадры, которые могут ссылаться на «b»-кадры фиг.9. Фиг.9 также иллюстрирует варианты в иерархии предсказания с использованием разных уровней штриховки, при этом кадры с большей степенью штриховки (т.е. относительно более темные) являются более высокими в иерархии предсказания, чем те кадры, которые имеют меньшую штриховку (т.е. относительно более светлые). Например, все I-кадры на фиг.9 изображены с полной штриховкой, тогда как P-кадры имеют несколько более светлую штриховку, и B-кадры (и кадры со строчной буквой b) имеют различные уровни штриховки относительно друг друга, но всегда более светлые, чем штриховка P-кадров и I-кадров.

В общем, иерархия предсказания связана с индексами порядка вида так, что кадры относительно более высокие в иерархии предсказания должны декодироваться перед декодированием кадров, которые являются относительно более низкими в иерархии, так что те кадры, которые являются относительно более высокими в иерархии, могут использоваться в качестве опорных кадров при декодировании кадров, которые являются относительно более низкими в иерархии. Индекс порядка вида представляет собой индекс, который указывает порядок декодирования составляющих вида в блоке доступа. Индексы порядка вида предполагаются в расширении MVC SPS, как определено в Дополнении H к стандарту H.264/AVC (исправление MVC). В SPS для каждого индекса i сигнализируется соответствующий view_id. Декодирование составляющих вида должно следовать в возрастающем порядке индекса порядка вида. Если представлены все виды, тогда индексы порядка вида находятся в последовательном порядке от 0 до num_views_minus_1.

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

Для некоторых кадров на равных уровнях иерархии порядок декодирования может не иметь значения относительно друг друга. Например, I-кадр вида S0 во временном расположении T0 используется в качестве опорного кадра для P-кадра вида S2 во временном расположении T0, который, в свою очередь, используется в качестве опорного кадра для P-кадра вида S4 во временном расположении T0. Следовательно, I-кадр вида S0 во временном расположении T0 должен декодироваться перед P-кадром вида S2 во временном расположении T0, который должен декодироваться перед P-кадром вида S4 во временном расположении T0. Однако между видами S1 и S3 не имеет значения порядок декодирования, так как виды S1 и S3 не основываются друг на друге для предсказания, но, вместо этого, предсказываются только из видов, которые являются более высокими в иерархии предсказания. Кроме того, вид S1 может декодироваться перед видом S4, поскольку вид S1 декодируется после видов S0 и S2.

Ясно, что может быть иерархическая зависимость между кадрами каждого вида, а также временными расположениями кадров каждого вида. Что касается примера на фиг.9, кадры во временном расположении T0 являются или с внутренним предсказанием, или с межвидовом предсказанием из кадров других видов во временном расположении T0. Аналогично, кадры во временном расположении T8 являются или с внутренним предсказанием или с межвидовом предсказанием из кадров других видов во временном расположении T8. Следовательно, что касается временной иерархии, временные расположения T0 и T8 находятся вверху временной иерархии.

Кадры во временном расположении T4 в примере на фиг.9 находятся ниже во временной иерархии, чем кадры временных расположений T0 и T8, так как кадры временного расположения T4 кодируются двунаправлено с ссылкой на кадры временных расположений T0 и T8. Кадры во временных расположениях T2 и T6 находятся ниже во временной иерархии, чем кадры во временном расположении T4. Наконец, кадры во временных расположениях T1, T3, T5 и T7 находятся ниже во временной иерархии, чем кадры временных расположений T2 и T6.

В соответствии с методами данного раскрытия каждый из видов, изображенный на фиг.9, может рассматриваться соответствующим соответствующему иерархическому уровню. Методы данного раскрытия могут использоваться для разделения сэмплов видео для каждого вида на соответствующие фрагменты субтрека. Т.е. фрагмент фильма, включающий в себя сэмплы видео видов 1-N, может составляться так, что сэмплы вида X (где 1<=X<=N) сохраняются во фрагменте субтрека, и сэмплы могут сохраняться рядом во фрагменте фильма.

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

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

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

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

Были описаны различные примеры. Эти и другие примеры находятся в пределах объема нижеследующей формулы изобретения.