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

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

Иллюстрации

Показать все

Реферат

Область техники

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

Предпосылки изобретения

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

Базовый формат мультимедийных файлов ISO и его модификации, например, формат файлов SVC, поддерживают указание характеристик для иерархически организованных подмножеств битовых потоков. Например, характеристики подмножества битового потока масштабируемого видеокодирования (scalable video coding, SVC) могут быть указаны для ярусов (tiers) (которые, по сути, аналогичны масштабируемым уровням) или для треков в целом (которые соответствуют масштабируемым уровням). Однако в базовом формате мультимедийных файлов ISO отсутствует поддержка указания различных иерархических разбиений и наложенных подмножеств битовых потоков (не имеющих многократно вложенной структуры). Для многоракурсного видекодирования (multiview video coding, MVC), вследствие имеющейся гибкости при выборе ракурсов для отображения, необходимы оба упомянутых типа указаний.

В базовом формате мультимедийных файлов ISO и его модификациях треки могут быть связаны друг с другом посредством трековых ссылок (track references), существует также возможность указания характеристик трека или подмножества треков (например, яруса SVC), при этом, однако, отсутствует механизм указания характеристик группы треков или подмножеств треков. Такими характеристиками могут быть, например, требуемый профиль, уровень или параметры буферизации декодера.

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

Сущность изобретения

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

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

Фиг.1 иллюстрирует иерархию форматов мультимедийных файлов;

Фиг.2 иллюстрирует бокс, соответствующий базовому формату мультимедийных файлов ISO;

Фиг.3А является примером бокса, иллюстрирующим группирование сэмплов;

Фиг.3В иллюстрирует пример бокса, содержащего фрагмент фильма с включением бокса SampleToGroup;

Фиг.4 иллюстрирует пример порядка декодирования MVC;

Фиг.5 иллюстрирует пример структуры предсказания MVC для многоракурсного видеокодирования;

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

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

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

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

На фиг.10 представлена блок-схема алгоритма процедуры в соответствии с вариантами осуществления настоящего изобретения.

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

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

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

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

Фиг.16 иллюстрирует пример многоракурсного битового потока, включающего сообщение SEI, связанное с различными ветвями иерархии ракурсов, в соответствии с вариантами осуществления настоящего изобретения;

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

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

Фиг.19 схематично изображает электронные схемы, которые могут входить в состав электронного устройства фиг.18; и

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

Подробное описание различных вариантов осуществления изобретения

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

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

Существующие стандарты форматов мультимедийных файлов включают базовый формат медиа-файлов ISO (ISO/IEC 14496-12), файловый формат MPEG-4 (ISO/IEC 14496-14, также известный как формат МР4), файловый формат AVC (ISO/IEC 14496-15) и файловый формат 3GPP (3GPP TS 26.244, известный также как формат 3GP). Внесенная недавно поправка к формату файлов AVC определяет формат файлов для масштабируемого видеокодирования (SVC). Группа экспертов по движущемуся изображению (moving picture experts group, MPEG) продолжает работу по определению формата файлов для многоракурсного видеокодирования (MVC), как поправки к формату файлов AVC. Группа MPEG также определила формат трека указаний (hint track) для FLUTE (IETF RFC 3926) и сеансов ALC (IETF RFC 3450), которые вошли во вторую поправку к версии 2005 базового формата мультимедийных файлов ISO. Эта версия, со всеми поправками и исправлениями, недавно была опубликована как новое издание (издание 3) базового формата мультимедийных файлов ISO, при этом ее называют также версией 2008 базового формата мультимедийных файлов ISO или третьим изданием базового формата мультимедийных файлов ISO. Еще одной модификацией базового формата мультимедийных файлов ISO является формат файлов DVB, опубликованный недавно в виде "синей книги" DVB A121. Основной целью определения формата файлов DVB является упрощение переносимости контента между различными реализациями технологий DVB, например, приставками, соответствующими нынешним (DVB-T, DVB-C, DVB-S) и будущим стандартам DVB, телевизионными приемниками на основе протокола Интернета (Internet Protocol, IP) и приемниками мобильного телевидения, соответствующими стандарту DVB-Handheld (наладонный DVB), а также его будущим стадиям развития. Формат файлов DVB делает возможным хранение любого DVB-контента на стороне терминала. При этом не подразумевается, что его обязательно используют в качестве формата внутреннего хранения в DVB-совмествимых устройствах. Такой формат файлов должен работать с любыми типами мультимедийной информации или данных, используемыми другими спецификациями вещания DVB. Формат файлов DVB позволит осуществлять обмен записанными мультимедийными данными между устройствами различных производителей, обмен контентом с использованием USB-накопителей или аналогичных записывающих/считывающих устройств, а также обеспечит возможность совместного доступа к разделяемому дисковому хранилищу в домашней сети и множество других функций. В настоящее время наиболее вероятным кандидатом, претендующим стать основой для разработки формата файлов DVB, является базовый формат мультимедийных ISO.

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

На фиг.2 показана упрощенная файловая структура 200, соответствующая базовому формату мультимедийных файлов ISO. Элементарный строительный блок этого формата называют боксом (box). Каждый бокс содержит заголовок и полезную нагрузку. В заголовке бокса указывается тип бокса и его размер в байтах. Бокс может включать другие боксы, причем для каждого типа бокса в формате файлов ISO определены типы боксов, которые могут находиться в нем. При этом некоторые боксы должны присутствовать в каждом файле обязательно, тогда как другие боксы могут быть опциональными. При этом боксов некоторых типов в файле может быть несколько. Итак, базовый формат мультимедийных файлов ISO определяет иерархическую структуру боксов.

В соответствии с форматом файлов семейства ISO, файл 200 включает мультимедийные данные и метаданные, размещенные в различных боксах - боксе 210 метаданных (mdat) и боксе 220 фильма (moov), соответственно. Для того, чтобы файл мог быть обработан, обязательно должны присутствовать оба указанных бокса. Бокс 210 мультимедийных данных содержит видео- и аудиокадры, которые могут чередоваться и быть упорядоченными по времени. Бокс фильма может содержать один или несколько треков, при этом каждый трек занимает один бокс. Трек может быть одного из следующих типов: трек мультимедийных данных, трек указаний, трек синхронизированных метаданных. Треком мультимедийных данных называют сэмплы данных, формат которых соответствует формату сжатия мультимедийных данных (и их инкапсуляции в базовый формат мультимедийных файлов ISO). Треком указаний называют сэмплы указаний, содержащие инструкции по сборке пакетов с целью передачи по заданному протоколу связи. Инструкции могут включать указания по сборке заголовка пакета и охватывать также сборку его полезной нагрузки. При сборке полезной нагрузки пакета возможны ссылки на данные, находящиеся в других треках или иных элементах, то есть при этом с помощью ссылки указывают: какой блок данных в конкретном треке или ином элементе предназначен для копирования в пакет во время его сборки. Треком синхронизированных метаданных называют сэмплы, описывающие мультимедийные данные и/или сэмплы указаний, на которые осуществляют ссылку. Для представления какого-либо одного типа мультимедийных данных, выбирается, как правило, один трек. Сэмплы в треке явным образом ассоциированы с номерами сэмплов, которые увеличивают на 1 в указанном порядке их декодирования.

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

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

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

Мультимедийные сэмплы для фрагментов фильма, как обычно, располагаются в боксе mdat 220, если они находятся в том же файле, что и блок moov. Тем не менее для метаданных фрагментов фильма предусмотрен бокс moof. Он содержит информацию для определенного отрезка времени воспроизведения, которая ранее хранилась в боксе moov. Бокс moov по-прежнему представляет собой самостоятельный действительный фильм, но, кроме того, он включает бокс mvex, указывающий на то, что в этом же файле за ним следуют фрагменты фильма. Фрагменты фильма увеличивают временную протяженность связанной с боксом moov презентации.

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

Далее, со ссылками на фиг.3А и 3В, проиллюстрировано группирование сэмплов в боксы. Группирование сэмплов в базовом формате файлов ISO и его производных, таких как формат файлов AVC и формат файлов масштабируемого видеокодирования (SVC), представляет собой назначение каждого сэмпла какого-либо трека в качестве члена одной из групп сэмплов на основе критерия группирования. Группа сэмплов при их группировании не требует непрерывного следования сэмплов друг за другом и может содержать несмежные сэмплы. Так как для сэмплов любого трека существует более одного группирования, каждая группа сэмплов имеет поле типа для указания типа группирования. Группы сэмплов представлены двумя связанными структурами данных: (1) бокс SampleToGroup (соответствие "сэмпл-группа") (бокс sbgp) представляет назначение сэмплов группам сэмплов; и (2) бокс SampleGroupDescription (описание группы сэмплов) (бокс sgpd) содержит запись "группа сэмплов" с описанием свойств каждой группы сэмплов. Боксы SampleToGroup и SampleGroupDescription могут существовать в нескольких экземплярах, каждый из которых основан на различных критериях группирования. Их отличает поле типа, используемое для указания типа группирования.

На фиг.3А представлена упрощенная иерархия боксов, отражающая структуру вложенности боксов групп сэмплов. Боксы групп сэмплов (SampleGroupDescription Box и SampleToGroup Box) находятся в боксе таблицы сэмплов (stbl), содержащемся в боксах мультимедийной информации (minf), медиа (mdia) и треков (trak) (в указанном порядке) внутри бокса фильма (moov).

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

Базовый формат мультимедийных файлов ISO поддерживает два типа операций редактирования: модификация во время воспроизведения с помощью боксов списков редактирования (Edit List) и реавторинг (reauthoring) метаданных файла. Бокс списка редактирования определяет как временная шкала (timeline) мультимедийной композиции преобразуется во временную шкалу воспроизведения, а также обеспечивает возможность разбиения временной шкалы на секции и отображения этих секций на отрезки временной шкалы воспроизведения. Таким образом, боксы списков редактирования обеспечивают возможность исключать некоторые мультимедийные сэмплы из воспроизведения, изменять порядок мультимедийных секций при воспроизведении, а также изменять скорость воспроизведения мультимедийных секций. Однако боксы списков редактирования поддерживаются не всеми проигрывателями, так как, например, обеспечиваемая этими боксами гибкость затрудняет реализацию проигрывателей. Кроме того, применение боксов списков редактирования не позволяет освобождать дисковое пространство, задействованное для хранения не воспроизводимых в данный момент мультимедийных сэмплов и их описаний в боксе moov и боксах moof. Как следствие, в редакторах файлов не используют боксы списков редактирования, а файлы изменяют только путем реавторинга их метаданных.

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

При многоракурсном видеокодировании последовательности видеоданных на выходе различных камер, соответствующих различным ракурсам, кодируют в один битовый поток. После декодирования для отображения какого-либо ракурса, восстанавливают и показывают изображения, принадлежащие этому ракурсу. Многоракурсное видеокодирование имеет широкий спектр применений, включая видео/телевидение со свободной точкой наблюдения, 30-телевидение и видеонаблюдение. В настоящее время объединенное видеоподразделение (Joint Video Team) группы MPEG ISO/IEC и группа экспертов по видеокодированию ITU-Т работают над созданием стандарта MVC, планируется, что он станет надстройкой над H.264/AVC. В дальнейшем упомянутые два (разрабатываемых) стандарта будут называться MVC и AVC, соответственно.

Наиболее поздний совместный проект MVC описан в документе JVT-АА209, "Объединенный проект 7.0 многоракурсного видеокодирования", 27-я встреча JVT, Женева, Швейцария, апрель 2008 г., который доступен по адресу: http://ftp3.itu.ch/av-arch/jvt-site/2008_04_Geneva/JVT-AA209.zip.

Многоракурсный битовый видеопоток может быть декодирован различными способами, в зависимости от того, какие ракурсы необходимо отображать, и от их количества. Один набор из N ракурсов может быть наиболее предпочтителен для вывода на N-ракурсный автостереоскопический дисплей с определенными характеристиками в одном промежутке времени, тогда как другой набор ракурсов может быть наиболее предпочтителен для N-ракурсного стереоскопического дисплея с другим набором характеристик или в другом промежутке времени. Часто имеется несколько предпочтительных наборов из N ракурсов, между которыми пользователь может выбирать или осуществлять навигацию. Значение N может меняться в диапазоне от 1 до общего числа ракурсов в битовом потоке и должно выбираться во время декодирования/воспроизведения в соответствии с характеристиками дисплея. Следует отметить, что для отображения предпочтительного набора из N ракурсов, вследствие межракурсных зависимостей, может потребоваться декодирование более чем N ракурсов.

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

Далее, со ссылками на фиг.5, проиллюстрирован пример структуры предсказания MVC (включая как межкадровое (inter-picture) предсказание в каждом ракурсе, так и межракурсное (inter-view) предсказание) для многоракурсного видеокодирования. В рассматриваемой структуре предсказания обозначены стрелками, при этом для объекта, на который направлена стрелка, объект, из которого стрелка выходит, используют в качестве опоры для предсказания.

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

Битовые потоки H.264/AVC, SVC содержат блоки уровня сетевой абстракции (Network Abstraction Layer, NAL) в битовой последовательности декодирования, которая может иметь формат битового потока, или быть вложенной во внешние кадры. Блоки NAL состоят из заголовка и полезной нагрузки. Заголовок блока NAL указывает тип этого блока NAL, а также указывает, является ли кодовый фрагмент, включенный в блок NAL, частью опорного изображения или изображения, не являющегося опорным. За первым байтом в заголовке блока NAL следует расширение заголовка блока NAL (3 байта). Расширение заголовка блока NAL включает синтаксические элементы, описывающие свойства блока NAL в контексте MVC. Сообщения дополнительной уточняющей информации (Supplemental Enhancement Information, SEI) представляют собой синтаксические структуры, которые могут включаться в битовые потоки H.264/AVC, SVC и MVC. Сообщения SEI не являются необходимыми для декодирования значений сэмплов в выводимых изображениях, но помогают выполнять связанные с этим процедуры, например, синхронизацию вывода изображений, отображение, обнаружение ошибок, скрытие ошибок и резервирование ресурсов. Набор сообщений SEI определен в H.264/AVC, SVC и MVC. Сообщения SEI с пользовательскими данными обеспечивают возможность, для организаций или компаний определять сообщения SEI, предназначенные для собственного использования. В стандарты H.264/AVC, SVC и MVC включены синтаксис и семантика определенных сообщений SEI, однако не определена процедура обработки этих сообщений в декодере. Следовательно, кодер обязан, при создании сообщений SEI, следовать релевантным стандартам, а декодер, соответствующий релевантным стандартам, чтобы обеспечить правильный порядок отображения, не должен обрабатывать сообщения SEI. Блок NAL сообщений SEI содержит одно или более сообщений SEI. Сообщение SEI с масштабируемой вложенностью (scalable nesting SEI message) в MVC содержит одно или более стандартных H.264/AVC сообщений SEI и указывает на ракурсы, к которым относится данное сообщение. Соответственно, сообщение SEI с масштабируемой вложенностью MVC обеспечивает возможность повторного использования синтаксиса сообщений SEI H.264/AVC для ракурсов, не являющихся базовыми ракурсами.

Для корректной реконструкции трехмерного восприятия в системе отображения необходима информация от системы получения многоракурсной видеоинформации. Параметры системы получения многоракурсной видеоинформации можно разделить на внутренние и внешние параметры. Внутренние параметры задают характеристики отдельных камер как индивидуальных блоков, независимых от других камер системы получения многоракурсной видеоинформации. Следует отметить, что внутренние параметры могут включать характеристики любого звена обработки информации в камере, например, оптики (в частности, объектива) или датчика изображения. Как правило, внутренние параметры камер включают, без ограничения приведенным списком, фокус или фокусное расстояние, главную точку и радиальную дисторсию (являющиеся общеизвестными терминами в области оптики и фотографии). С помощью внешних параметров указывают характеристики камеры, связанные с окружающим пространством. Как правило, внешние параметры камер включают, без ограничения приведенным списком, относительное местоположение камеры во внешней системе координат (х, у, z) и поворот камеры относительно каждой из трех осей (то есть панорамирование и наклоны относительно поперечной и продольной осей). Внешние параметры камер задают относительно выбранных опорных точек, например, начала координат. Сообщение SEI получения многоракурсной информации (Multiview Acquisition Information) в проекте стандарта MVC представляет собой пример формата для получения многоракурсной видеоинформации.

В группе MPEG продолжается работа по определению формата файлов для многоракурсного видеокодирования (MVC) как поправки к формату файлов AVC. Вероятно, многие структуры из состава формата файлов SVC будут также использованы и в формате файлов MVC. Некоторые из этих структур формата файлов SVC, которые, вероятно, будут использованы в формате файлов MVC, описаны ниже.

Для группирования блоков NAL, принадлежащих одному сэмплу, используют агрегаторы. В агрегаторах применяют те же заголовки блоков NAL, что и в блоках NAL SVC VCL или блоках NAL MVC VCL, однако, с отличающимся значением типа блока NAL. Агрегаторы представляют собой внутренние структуры формата файлов, обеспечивающие возможность эффективного группирования блоков NAL. В контексте структуры сэмпла агрегаторы можно рассматривать как блок NAL. При доступе к сэмплу (то есть извлечении сэмпла из файла и передаче его декодеру) агрегаторы должны быть удалены (при этом остаются содержащиеся в них блоки NAL, или блоки NAL, на которые они ссылались). В потоке, внешнем по отношению к формату файлов, агрегаторов быть не должно. Агрегаторы способны выполнять агрегирование путем включения в себя блоков NAL (в пределах области, которая определяется их длиной) а также путем ссылки на следующие за ними блоки NAL (область при этом задают с помощью имеющегося в них поля additional_bytes (дополнительные байты)). При сканировании потока программой чтения файлов AVC, "внутри" агрегатора видны только включенные в него блоки NAL, это позволяет, например, программе чтения файлов AVC пропускать целое множество ненужных блоков NAL SVC VCL или блоков NAL MVC VCL. Аналогично, если блоки NAL агрегированы путем ссылки, программа чтения AVC их не пропустит, и они останутся для нее в составе потока. При сканировании потока а) если агрегатор неопознан (например, программой чтения AVC или декодером) он, вместе с его контентом, может быть просто отброшен; b) если агрегатор не нужен (то есть, если он принадлежит к ненужному уровню или ракурсу) он и его контент, как включенный в него, так и на который он ссылается, может быть просто отброшен (с использованием его поля length или additional_bytes) и с) если агрегатор нужен, его заголовок отбрасывают, а содержимое сохраняют. Как и любой другой блок NAL, агрегатор хранится в сэмпле. Все блоки NAL в агрегаторе остаются расположенными в порядке их декодирования.

Описанные ниже группы сэмплов могут использоваться в треках SVC или MVC для описания структуры соответствующих потоков (потока SVC или MVC), а также для более простого получения информации о подмножествах потока и для извлечения любого из этих подмножеств. Есть определенный набор боксов, описанный ниже, который может встречаться в описании группы сэмплов, то есть в записи масштабируемой группы (Scalable Group Entry) для потока SVC или в записи многоракурсной группы (Multiview Group Entry) для потока MVC. Обе упомянутые записи - масштабируемой группы и многоракурсной группы - описывают определенное подмножество потока SVC и MVC, соответственно. Каждое из этих подмножеств связывают с определенным ярусом, при этом оно может содержать одну или более рабочих точек (operating points). Рабочая точка представляет собой одно из подмножеств потока. Рабочая точка для потока MVC представляет собой определенное множество ракурсов с заданным временным разрешением. В контексте MVC, ярус представляет собой набор временных подмножеств одного из множеств ракурсов. Для определения записей масштабируемых групп или записей многоракурсных групп, соответственно, используют тип группирования 'scif или 'mvif. Для каждого яруса в боксе SampleGroupDescriptionBox (описание группы сэмплов) может присутствовать более одной записи масштабируемой группы или записи многоракурсной группы с типом группирования 'scif или "mvif, соответственно. При этом лишь одна из таких записей является основным определением яруса.

Несмотря на то, что записи масштабируемых или многоракурсных групп содержатся в боксе SampleGroupDescription, это группирование не является истинным группированием сэмплов, поскольку каждый сэмпл может быть связан более чем с одним ярусом, когда эти группы используют для описания секций сэмплов - блоков NAL. В результате, бокс SampleToGroup с типом группирования 'scif или 'mvif может отсутствовать до тех пор, пока группа не будет фактически описывать полный сэмпл. Даже если этот бокс (SampleToGroup с типом группирования 'scif' или 'mvif') присутствует, его информация не является необходимой для извлечения блоков NAL различных ярусов; вместо этого, группы соответствий (map groups) должны всегда описывать шаблон блоков NAL в сэмплах и предоставлять информацию о соответствии "блок NAL - ярус", которая может потребоваться при извлечении блоков NAL.

Бокс информации яруса, бокс битрейта яруса, бокс диапазона приоритетов SVC, бокс набора начальных параметров, бокс буферизации, бокс зависимостей яруса - определены для формата файлов MVC аналогично формату файлов SVC. В частности, они могут включаться в записи многоракурсных групп. Каждая запись масштабируемой или многоракурсной группы связана с идентификатором группы и идентификатором яруса (grouplD и tierlD). Записи tierlD упорядочены в соответствии с их зависимостями, о которых сигнализирует значение tierlD. Большее значение tierlD указывает на более высокий ярус. Значение О указывает на самый нижний ярус. Декодирование яруса не зависит от вышележащих ярусов, но может зависеть от нижних. Следовательно, самый нижний ярус может быть декодирован независимо, декодирование яруса 1 может зависеть от яруса 0, декодирование яруса 2 может зависеть от ярусов 0 и 1, и т.д. Ярус может включать данные одного или более уровней или ракурсов видеопотока.

Для каждого яруса должно присутствовать только одно основное определение. Для каждой записи масштабируемой или многоракурсной группы, в которой значение поля primary_grouplD равно значению поля grouplD, эта группа является основным описанием соответствующего яруса, при этом к ней применимо следующее: необходимо присутствие боксов TierInfoBox (бокс информации яруса) и SVCPriorityRangeBox (бокс диапазона приоритетов SVC). Если для какого-либо яруса нет одного из опциональных боксов, то соответствующая информация является неопределенной для этого яруса (отсутствует наследование информации ярусов). Если для какого-либо яруса отсутствует бокс TierDependencyBox (бокс зависимостей яруса), то этот ярус может зависеть от всех ярусов с меньшим tierlD. Если имеется бокс InitialParameterSetBox (бокс с набором начальных параметров), то в нем указаны наборы параметров, необходимые для декодирования этого и более низких ярусов, от которых он зависит. Если этот бокс отсутствует, значит не указано, необходимы ли наборы параметров, заданные в записях SVCDecoderConfigurationRecord (конфигурационная запись декодера SVC) или MVCDecoderConfigurationRecord (конфигурационная запись декодера MVC). Если используют потоки наборов параметров (parameter set streams), тогда присутствие бокса InitialParameterSetBox не требуется. Значения tierlD не обязательно должны быть непрерывными. Кроме того, для каждой записи масштабируемых групп, если значение поля primary_grouplD равно значению поля grouplD, должен присутствовать бокс SVCDependencyRangeBox (бокс диапазона зависимостей SVC). Дополнительно, для каждой записи многоракурсной группы, если значение поля primary_grouplD равно значению поля grouplD, должен присутствовать бокс ViewldentifierBox (бокс идентификатора ракурса).

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