Область техники
Настоящее изобретение относится, в общем, к области мультимедийных данных реального времени, и в частности к организации таких мультимедийных данных.
Предпосылки изобретения
Данный раздел имеет целью описание предпосылок или контекста настоящего изобретения, изложенного в формуле изобретения. Описание может включать идеи, не все из которых уже были предложены или разработаны ранее. Таким образом, если не указано обратное, описанное в настоящем разделе не является существующим уровнем техники для описания и формулы изобретения настоящей заявки, и не признается таковым вследствие включения в настоящий раздел.
Базовый формат мультимедийных файлов 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. Другими словами, не разрешается определять ярусы, не используемые в треке. Каждый блок NAL в элементарном потоке связан с tierlD в соответствии со следующим описанием. Сначала каждый сэмпл связывают с картой значений grouplD посредством группирования сэмплов типа "scnm", в соответствии с дальнейшим определением. Группирование сэмплов типа "scnm" указывает на связь между блоками NAL и значениями grouplD в каждом сэмпле. Значения grouplD могут затем быть связаны со значениями tierlD с использованием бокса описания группы сэмплов с типом "scif или "mvif". Для блоков NAL, связанных со значением tierlD, чтобы декодирование было корректным, могут потребоваться блоки NAL, связанные со всеми меньшими значениями tierlD, но никогда не требуются блоки NAL, связанные с большими значениями tierlD (то есть зависимость существует только в направлении нижних ярусов). Сервер или проигрыватель может выбирать подмножество значений tierlD, необходимое для корректного процесса декодирования, на основе значения полей с описаниями в упомянутых записях (например, частота смены кадров и т.п.) бокса описания группы сэмплов типа "scif или "mvif". Запись многоракурсной группы определяют следующим образом:
Синтаксис записи многоракурсной группы имеет следующий вид:
Семантика записи многоракурсной группы следующая:
Параметр GroupID задает идентификатор записи группы. Значения идентификаторов групп (grouplD) могут быть произвольными, однако должны быть уникальными.
Параметр Primary_grouplD определяет группу, содержащую основное определение данного яруса. Если это значение равно значению grouplD, значит, эта группа является основным определением яруса. Параметр is_tl_switching_point, когда он установлен в 1, указывает на то, что члены этой группы, значения temporal_id которых максимальны, в соответствии с определением в приложении Н к стандарту ISO/IEC 14496-10, являются точками переключения временного уровня. Если обозначить максимальное значение temporal_id членов данной группы как tlD, то битовый поток может быть переключен в любом из упомянутых членов, имеющих temporal_id равным tld, с временного уровня с temporal_id, равным tld-1, на временной уровень с temporal_id, равным tld, при условии, что члены с temporal_id, равным tld-1, указанные с помощью tl_switching_distance, были обработаны (переданы и декодированы). Значение is_tl_switching_point, равное 0, указывает на то, что члены данной группы с максимальным значениями temporal_id, в соответствии с определением в приложении Н к стандарту ISO/IEC 14496-10 могут быть или не быть точками переключения временных уровней.
Параметр tl_switching_distance используют, когда значение is_l_switching_point равно 1. Он указывает количество сэмплов временного уровня с temporal_id, равным tld-1, которые необходимо декодировать, чтобы гарантировать возможность декодирования потока на вышележащем временном уровне tld от точки переключения и далее. Значение, равное О, указывает на то, что временная точка переключения не зависит от низлежащего временного уровня. Необходимое расстояние для определенного сэмпла может быть уменьшено путем задания расстояния переключения временных уровней в параллельном по времени треке метаданных этого сэмпла.
Блоки NAL соответствуют группам отображения и ярусам следующим образом. Для описания иерархии масштабирования или ракурсов в блоке доступа SVC или MVC используют два вида групп сэмплов: а) Группа для описания секций сэмпла. Для каждой из таких групп присутствуют записи ScalableGroupEntry или MultiviewGroupEntry, определяющие свойства группы. Следует отметить, что они описывают ярусы, а не поток в целом, и следовательно, в любой момент времени описывают блоки NAL, принадлежащие одному ярусу, а не блок доступа в целом. b) Группа отображения, которая описывает соответствие между каждым блоком NAL в блоке доступа и группой отображения (с типом группирования (параметр grouping_type) 'scnm'). Для каждой отдельной последовательности блоков NAL, принадлежащей какой-либо группе отображения, существует запись ScalableNALUMapEntry. Вместе с блоком доступа, группа отображения включает все блоки NAL яруса.
Определение групп отображения требует, чтобы количество шаблонов группирования для всех блоков доступа было ограничено. Если в каком-либо ярусе количество блоков NAL в последовательных блоках доступа варьируется, могут применяться агрегаторы, чтобы сделать эти изменчивые структуры постоянными, а также уменьшить необходимое количество групп отображения. И для формата файлов SVC, и для формата файлов МУС используют одно и то же определение группы отображения - запись ScalableNALUMapEntry. Когда конфигурационную запись декодера применяют для потока, который может интерпретироваться и как поток MVC, и как поток AVC, конфигурационная запись декодера AVC должна отражать свойства AVC-совместимого базового уровня, например, она должна содержать только те наборы параметров, которые необходимы для декодирования базового уровня AVC. Поток наборов параметров может быть использован и с потоками MVC, и с потоками AVC. В таком случае наборы параметров не включают в конфигурационную запись декодера. Запись MVCDecoderConfigurationRecord структурно идентична и семантически эквивалентна записи SVCDecoderConfigurationRecord.
Многоракурсный видеопоток в файле представлен одним или более видеотреками. Каждый трек представляет один или более ракурсов этого потока. Если ракурс, представленный каким-либо треком, использует другой ракурс, представленный другим треком, в качестве опорного для межтрекового предсказания, то в трек, ссылающийся на исходный трек с целью межтрекового предсказания, должна быть включена трековая ссылка типа 'mpvr'.
Сэмпл MVC состоит из одного или более компонентов ракурсов и связанных с ними блоков NAL, не принадлежащих уровню VCL. Для восстановления блока доступа из сэмплов одного или более треков MVC сначала определяют отображаемые ракурсы. Ракурсы, необходимые для декодирования упомянутых отображаемых ракурсов могут быть получены с помощью трековых ссылок типа 'mpvr' или боксов зависимостей яруса. Если данные для блока доступа содержатся в нескольких треках, выравнивание соответствующих сэмплов в треках выполняют по времени декодирования, то есть с использованием только таблицы соответствия "время-сэмпл", без учета списков редактирования. Блок доступа восстанавливают из соответствующих сэмплов в требуемых треках и ярусах путем упорядочивания их блоков NAL в порядке, соответствующем стандарту MVC, как показано, на общем уровне, ниже:
Все блоки NAL с набором параметров из соответствующих треков наборов параметров, а также из соответствующих треков элементарного потока.
Компоненты ракурсов - в порядке возрастания порядкового номера ракурса. Блоки NAL в компоненте ракурса располагаются в порядке их появления в сэмпле.
Следует отметить, что экстракторы, определенные в формате файлов SVC, могут использоваться для задания формата сэмплов, включающего блок доступа. Однако такой формат сэмплов не совсем подходит для MVC, поскольку для отображения могут быть выбраны любые ракурсы. Набор отображаемых ракурсов и иерархия межракурсных зависимостей определяет, какие ракурсы необходимы для декодирования. Количество подмножеств битового потока, каждое из которых подходит для отображения различного набора ракурсов, может быть очень большим. Например, из стандартно организованного 9-ракурсного битового потока MVC может быть получено 36 подмножеств со стереоизображениями. При применении экстракторов потребовалось бы создание отдельного трека для каждой комбинации отображаемых ракурсов, что привело бы к излишне большому размеру файла. Для стандартно организованного 9-ракурсного битового потока MVC экстракторы для всех подмножеств со стереоизображениями потребуют по меньшей мере около 500 кбит/с, что приводит к значительному увеличению размера файла. Различные варианты осуществления настоящего изобретения так или иначе применимы для форматов сэмплов, в которых сэмпл включает блок доступа, а экстракторы используют аналогично формату файлов SVC.
Формат записи сэмпла для MVC определяют следующим образом:
Если элементарный поток MVC содержит пригодный к использованию AVC-совместимый базовый уровень, то следует использовать запись визуального сэмпла AVC ('avc1' или 'avc2'). В таком случае запись будет изначально содержать конфигурационный бокс AVC (AVC Configuration Box), за которым может следовать конфигурационный бокс MVC, в соответствии с приведенным ниже определением. Конфигурационный бокс AVC описывает информацию профиля, уровня и набора параметров, которая относится ко всему потоку, содержащему небазовые ракурсы, в соответствии с определением в записи MVCDecoderConfigurationRecord, хранящейся в боксе MVCConfigurationBox.
Если базовый поток MVC не содержит пригодного к использованию базового ракурса AVC, то следует использовать запись визуального сэмпла MVC ('mvc1'). Запись визуального сэмпла MVC должна содержать конфигурационный бокс MVC, в соответствии с приведенным ниже определением. Он включает MVCDecoderConfigurationRecord.
URI назначения приоритета задает имя (в пространстве URI) способа, который используют для выбора значений параметра priority_id. Если он встречается в записи сэмпла AVC или MVC, то должен присутствовать один URI, описывающий назначения priority_id в данном потоке. URI здесь трактуется исключительно как имя; оно может быть разыменуемым, однако это не обязательно. Программы чтения файлов могут быть способны распознавать некоторые из упомянутых способов и, следовательно, на основании priority_id знать, какие операции по извлечению потока будут уместны.
Имя 'avc1' записи сэмпла может быть использовано лишь тогда, когда весь поток является AVC-совместимым и пригодным к использованию потоком с точки зрения AVC-декодера, работающего с конфигурацией (включая профиль и уровень), заданной в боксе AVCConfigurationBox. Допускается присутствие структур, специфичных для текущего формата файлов, аналогичных блокам NAL, однако они не должны использоваться для доступа к базовым данным AVC; то есть, данные AVC не должны быть включены в агрегаторы (хотя они могут содержаться в байтах, на которые осуществляют ссылку с помощью поля additional_bytes). Имя 'avc2' записи сзмпла указывает на то, что для образования целевого потока AVC следует проанализировать агрегаторы на предмет содержащихся в них блоков NAL. Агрегаторы могут использоваться для блоков NAL MVC VCL в треках 'avd', 'avc2' или 'mvd'.
В записи сэмпла 'avd' или 'avc2' может присутствовать любой из боксов MVCConfigurationBox, ViewScalabiIitylnfoSEIBox, IntrinsicCameraParametersBox или ExtrinsicCameraParametersBox. В этих случаях применимо приведенное ниже определение записи AVCMVCSampIeEntry или AVC2MVCSampleEntry, соответственно.
Приведенная ниже таблица демонстрирует все возможные варианты использования записей сэмплов для видеотрека, когда элементарный поток MVC хранится в одном или более треков, конфигураций или инструментов MVC (включая синхронизированные метаданные, которые всегда используют в другом треке):
Синтаксис записей сэмплов определяют следующим образом:
Семантика полей записей сэмплов эквивалентна записям формата файлов SVC для параметров method, bitrate и descr, а в остальном -определена ниже. Параметр view_scalability содержит блок NAL SEI, который включает только сообщения SEI с информацией о масштабируемости ракурсов, в соответствии с определением в приложении Н документа ISO/IEC 14496-10.
Бокс внутренних параметров камеры определяют следующим образом:
Синтаксис бокса внутренних параметров камеры определяют следующим образом.
Семантика бокса внутренних параметров камеры эквивалентна семантике сообщения SEI для получения многоракурсной информации MVC. Бокс внешних параметров камеры определяют следующим образом:
Синтаксис бокса внешних параметров камеры определяют следующим образом:
Семантика бокса внешних параметров камеры эквивалентна семантике сообщения SEI для получения многоракурсной информации MVC. Бокс идентификаторов ракурсов определяют следующим образом:
Ноль для определений неосновных групп в записях многоракурсных групп
При включении в запись сэмпла данный бокс указывает на ракурсы, включенные в трек посредством значений синтаксического элемента view_id MVC. При включении в запись многоракурсной группы данный бокс указывает на ракурсы, включенные в соответствующий ярус посредством значений синтаксического элемента view_id MVC. В этом боксе также указывают порядковый номер каждого из перечисленных ракурсов. Кроме того, бокс включает минимальное и максимальное значения temporal_id, входящие в трек или ярус, при включении этого бокса, соответственно, в запись сэмпла или в запись многоракурсной группы.
Синтаксис бокса идентификаторов ракурсов определяют следующим образом:
Семантику бокса идентификаторов ракурсов определяют следующим образом:
Параметр num_view, если бокс идентификаторов ракурсов находится в записи сэмпла, указывает количество включенных в данный трек ракурсов. Если же бокс находится в записи многоракурсной группы, num_view указывает количество ракурсов, включенных в соответствующий ярус.
Параметр view_id указывает значение синтаксического элемента view_id MVC для ракурса, включенного в трек или ярус, если бокс идентификаторов ракурсов включен в запись сэмпла или многоракурсной группы соответственно.
Параметр view_order_index указывает значение переменной VOIdx, в соответствии с определением в MVC, для ракурса, включенного в трек или ярус, если бокс идентификаторов ракурсов включен в запись сэмпла или запись многоракурсной группы, соответственно.
Параметры min_temporal_id, max_temporal_id принимают минимальное или максимальное значения синтаксического элемента temporal_id, присутствующего в расширении заголовка блоков NAL, которые поставлены в соответствие данному треку или ярусу, если бокс идентификаторов ракурсов включен в запись сэмпла или запись многоракурсной группы, соответственно. Для потоков AVC он принимает значение, которое может находиться в префиксном блоке NAL.
Если трек, который связан с записью сэмпла 'avc1' или 'avc2' и содержит элементарный поток MVC, включен в альтернативную группу, то остальные члены группы представляют собой альтернативы базовому ракурсу, содержащемуся в данном треке. Если в альтернативную группу включен трек, который связан с записью сэмпла 'mvc1', то остальные члены группы представляют собой многоракурсные видеотреки, содержащие такое же количество ракурсов, что и трек 'mvc1', при этом каждый ракурс трека 'mvc1' имеет соответствующий ему ракурс в остальных треках.
Кодер с множественным описанием формирует из исходного сигнала множество независимых потоков, которые называют описаниями. Все описания, как правило, равнозначны, любого из них достаточно для воспроизведения декодируемого сигнала с базовым качеством, при этом качество воспроизведения растет в зависимости от принятых описаний. Очевидно, что описания являются коррелированными, при этом кодирование с множественным описанием (Multiple Description Coding, MDC) страдает недостатком эффективности сжатия, по сравнению с кодированием с единственным описанием. Корреляция также позволяет декодеру скрывать потерю описаний. Для кодирования с множественным описанием было предложено множество алгоритмов, в которых применяют разделение сигналов в пространственной, частотной и временной областях.
В базовом формате мультимедийных файлов ISO средства для создания альтернативных и переключаемых групп определены следующим образом. Параметр alternate_group представляет собой целочисленный параметр в боксе заголовка трека, определяющий группу или набор треков. Если это поле равно 0, то информация о возможных отношениях с другими треками отсутствует. Если это поле не равно 0, оно должно быть одинаковым для треков, содержащих данные, альтернативные друг другу, и отличающимся для треков, принадлежащих другой такой группе. В любой момент времени в альтернативной группе может быть воспроизведен или передан в потоке только один трек, при этом он должен отличаться от других треков в группе такими атрибутами как битрейт, кодек, язык, размер пакетов и т.п. Альтернативная группа может состоять только из одного члена.
Типичная презентация, которую хранят в файле, содержит по одной альтернативной группе для каждого типа мультимедийных данных: одну для видео, одну для аудио и т.п. Такой файл может включать несколько видеотреков, хотя в любой момент времени только один из них может быть воспроизведен или передан в потоке. Это достигается путем назначения всех видеотреков в одну альтернативную группу.
Все треки в альтернативной группе являются кандидатами при выборе мультимедийной информации. Тем не менее может не иметь смысла переключение между некоторыми из этих треков во время сеанса. Например, может разрешаться переключение между видеотреками с различным битрейтом при одинаковом размере кадра, но не разрешаться переключение между треками с отличающимся размером кадра. Аналогично, может позволяться выбор (но не переключение) треков с различными видеокодеками, или со звуковым сопровождением на разных языках.
Различение треков для выбора и треков для переключения, осуществляют путем назначения треков, в дополнение к альтернативным группам, в переключаемые группы. Альтернативная группа может включать одну или более переключаемых групп. В то время как треки в альтернативной группе являются кандидатами для выбора мультимедийной информации, для треков из переключаемой (под-) группы дополнительно доступно переключение в течение сеанса. Переключаемые группы представляют различные рабочие точки, такие как различный размер кадра, высокое/низкое качество и т.п.
В случае немасштабируемых битовых потоков в переключаемую группу может включаться несколько треков. Это применимо также для масштабируемых битовых потоков, не разделенных на уровни, например, традиционных потоков AVC.
Треки можно характеризовать путем их пометки с помощью атрибутов. Каждый трек может быть отмечен списком атрибутов, который может использоваться для описания треков в переключаемой группе или для различения треков, принадлежащих различным переключаемым группам.
Бокс выбора трека, располагающийся в боксе пользовательских данных трека, содержит параметры switch_group и attributejist (переключаемая группа и список атрибутов).
Параметр switch_group представляет собой целое число и определяет группу или набор треков. Если это поле равно 0 (значение по умолчанию) или бокс выбора трека отсутствует, то нет информации о том, может ли этот трек быть использован для переключения во время воспроизведения или потоковой передачи. Если это целое число не равно 0, оно должно быть одинаковым для всех треков, которые могут быть использованы для переключения друг между другом. Треки, принадлежащие к одной переключаемой группе, должны принадлежать к одной альтернативной группе. Переключаемая группа может состоять только из одного члена.
Параметр attribute_list представляет собой список атрибутов. Атрибуты в этом списке должны использоваться как описания треков или отличительные критерии для треков в одной альтернативной или переключаемой группе. Каждый атрибут, позволяющий различить треки, связан с указателем на информационное поле, отличающее этот трек от других.
В заявке на патент США №11/844300, озаглавленной "Система и способ указания взаимоотношений треков в мультимедийном файле" предложен бокс отношений треков, который обеспечивает возможность формирования одной или нескольких групп треков в соответствии с определенным типом группирования. Определены типы группирования:
"альтернативные треки", "переключаемые треки", "многоуровневое кодирование" и "кодирование с множественным описанием". Тип группирования "альтернативные треки" обеспечивает возможность перечисления треков, принадлежащих к различным альтернативным группам, то есть в боксе заголовка трека присутствует по одной группе треков для каждого значения alternate_group. Такой тип группирования (альтернативные треки) предоставляет программам-анализаторам механизм обнаружения (идентификации) альтернативных групп, заменяющий проход по боксам заголовков всех треков. Тип группирования "переключаемые треки" обеспечивает способ обнаружения переключаемых групп, заменяющий проход по всем боксам выбора треков для всех треков. Тип группирования "многоуровневое кодирование" обеспечивает способ обнаружения треков, образующих многоуровневый (масштабируемый) битовый поток. Данный механизм может быть использован в программах-анализаторах, что позволяет избежать прохода по боксам трековых ссылок всех треков. Тип группирования "кодирование с множественным описанием" обеспечивает способ, позволяющий указать отношения между связанными треками, содержащими битовые потоки с множественным описанием.
Бокс отношений треков (track relation box) определяют следующим образом:
Синтаксис бокса отношений треков выглядит следующим образом:
В приведенной выше синтаксической структуре "version" (версия) - целое число, определяющее версию бокса отношений треков (0, в соответствии с приведенным выше).
Flags (флаги) - 24-битное целое число с флагами. Определены описанные ниже биты, при этом бит 0 - это бит с наименьшим значением, бит 1 - второй от наименьшего и т.д. Когда бит 0 равен 1, это означает, что в данном боксе присутствует информация о группе альтернативных треков. Когда бит 0 равен 0, это означает, что информация о группе альтернативных треков в данном боксе отсутствует.
Когда бит 1 равен 1, это означает, что в данном боксе присутствует информация о группах переключаемых треков. Когда бит 1 равен 0, это означает, что информация о группах переключаемых треков в данном боксе отсутствует.
Когда бит 2 равен 1, это означает, что в данном боксе присутствует информация о группах многоуровневых треков. Когда бит 2 равен 0, это означает, что информация о группах многоуровневых треков в данном боксе отсутствует.
Когда бит 3 равен 1, это означает, что в данном боксе присутствует информация о группах MDC треков. Когда бит 3 равен 0, это означает, что информация о группах MDC треков в данном боксе отсутствует.
Параметр "num_alternate_groups" указывает количество групп альтернативных треков, о которых сигнализируют.
Параметр "alternate_group_id" указывает идентификатор i-ой группы альтернативных треков, о которой сигнализируют. Это величина, не равная 0. Любой трек, связанный с alternate_group_id, имеет значение alternate_group (в боксе заголовке трека) равное значению alternate_group_id. Любой трек, имеющий значение alternate_group (в боксе заголовка трека) не равное 0, имеет соответствующий alternative_group_id.
Параметр "num_tracks_in_alternate_group" указывает количество треков в i-ой группе альтернативных треков, о которой сигнализируют.
Параметр "alternate_track_id" указывает идентификатор j-го трека в i-ой группе альтернативных треков, о которой сигнализируют.
Параметр "num_switch_groups" указывает количество групп переключаемых треков, о которых сигнализируют.
Параметр "switch_group_id" указывает идентификатор i-ой группы переключаемых треков, о которой сигнализируют. Это величина, не равная 0. Для любого трека, соответствующего switch_group_id, в случае, если присутствует бокс выбора трека, значение switch_group, указанное в боксе выбора трека, равно значению switch_group_id. Для любого трека, имеющего бокс выбора трека, если значение alternate_group не равно 0, будет иметься соответствующий ему switch_group_id.
Параметр "num_tracks_in_switch_group" указывает количество треков в i-ой группе переключаемых треков, о которой сигнализируют.
Параметр "switch_track_id" указывает идентификатор j-го трека в 1-ой группе переключаемых треков, о которой сигнализируют.
Параметр "num_layered_groups" указывает количество групп многоуровневых треков, о которых сигнализируют."layered_group_id" обозначает идентификатор i-ой группы многоуровневых треков, о которой сигнализируют.
Параметр "num_tracks_in_layered_group" указывает количество треков в i-ой группе многоуровневых треков, о которой сигнализируют.
Параметр "layered_track_id" указывает идентификатор j-го трека в i-ой группе многоуровневых треков, о которой сигнализируют.
Параметр "num_dependent_on_tracks" указывает количество треков от которых j-тый трек в 1-ой группе многоуровневых треков прямо или косвенно зависит. Параметр "dependent_on_track_id" указывает идентификатор к-го трека от которого j-тый трек в i-ой группе многоуровневых треков прямо или косвенно зависит.
Параметр "num_mdc_groups" указывает число групп MDC треков о которой сигнализируют.
Параметр "mdc_group_id" указывает идентификатор i-ой группы MDC треков, о которой сигнализируют.
Параметр "num_tracks_in_mdc_group" указывает количество треков в i-ой группе MDC треков, о которой сигнализируют.
Параметр "mdc_track_id" указывает идентификатор j-го трека в i-ой группе MDC треков, о которой сигнализируют.
В одном из вариантов осуществления упомянутого бокса отношений треков используют бокс сеанса доставки файлов (FDSessionGroupBox) для перечисления треков указаний по доставке файлов (FLUTE/ALC), связанных с идентификатором группы сеанса доставки файлов (например, треков, представляющих различные объекты, к примеру, изображения одной веб-страницы). Бокс FDSessionGroupBox определяют следующим образом:
Бокс группы сеанса доставки файлов является опциональным, однако он обязателен для файлов, содержащих более одного трека указаний по доставке файлов. Он содержит список сеансов, а также все группы файлов и треки указаний, принадлежащие каждому сеансу. В течение сеанса, доставка файлов осуществляется одновременно по всем трекам указаний доставки файлов (каналам), перечисленным в боксе группы сеанса доставки файлов данного сеанса доставки файлов. В любой момент времени может обрабатываться только одна сеансовая группа. Трек указаний, расположенный первым в списке сеансовой группы, определяет базовый канал. Если сервер не имеет предпочтений среди сеансовых групп, выбором по умолчанию станет первая сеансовая группа. Идентификаторы всех файловых групп, содержащих файлы, на которые ссылаются треки указаний, должны быть внесены в список файловых групп. Идентификаторы файловых групп могут, в свою очередь, быть преобразованы в имена файловых групп (с использованием бокса, устанавливающего соответствие между идентификатором группы и ее именем (group ID to name box)), которые могут включаться в FDT сервером.
Синтаксис бокса FDSessionGroupBox имеет следующий вид:
Параметр "num_session_groups" определяет количество сеансовых групп. Параметр "entry_count" задает количество записей в последующем списке, включающем все файловые группы, с которыми совместима данная сеансовая группа. Сеансовая группа содержит все файлы из перечисленных файловых групп, в соответствии с определением в записи информации об элементе для каждого исходного файла. Следует отметить, что FDT для сеансовой группы должно содержать только перечисленные в рассматриваемой структуре группы.
Параметр "group_ID" указывает файловую группу, с которой совместима данная сеансовая группа.
Параметр "num_channels_in_session_groups" определяет количество каналов в сеансовой группе. Значение параметра "num_channels_in_session_groups" должно быть целочисленным и положительным.
Параметр "hint_track_ID" определяет идентификатор трека указаний по доставке файлов, принадлежащего к определенной сеансовой группе. Следует отметить, что один трек указаний по доставке файлов соответствует одному каналу LCT.
Когда комбинации масштабируемых мультимедийных потоков доставляют по каналу с ограниченной пропускной способностью, необходимо обеспечить средства указания способа динамического извлечения фрагментов данных из всей массы совместно доставляемых мультимедийных данных. Таким образом, файл, содержащий один или более масштабируемых мультимедийных потоков может быть модифицирован, чтобы также содержать информацию о доле скорости в группах сэмплов "доля скорости", описываемых с помощью записей с описанием групп сэмплов "доля скорости" (RateShareEntry). Целью информации о доле скорости является информирование сервера о способе извлечения мультимедийных данных из каждого масштабируемого мультимедийного потока в любой момент времени. Это позволяет обеспечить управляемый или рекомендуемый способ масштабирования мультимедийной информации на сервере, что, в свою очередь, позволяет формировать элементарные мультимедийные потоки. Синхронизированная информация о доле скорости может добавляться в масштабируемые мультимедийные потоки, которые хранят в мультимедийных треках, с помощью связывания частей (то есть интервалов времени) мультимедийных данных с записями информации о доле скорости, которые определяют целевое значение доли скорости. Целевое значение доли скорости указывает целевую процентную долю доступного битрейта, которая будет выделена для определенного типа мультимедийных данных. В самом простом случае, в соответствии с иллюстрацией на фиг.6, для каждого типа мультимедийных данных и временного интервала задают только одно целевое значение доли скорости.
Тем не менее, для подстройки значений долей скорости, изменяющихся вместе с доступным битрейтом, существует возможность определения более одного рабочего диапазона. Например, можно указать, что определенному фрагменту аудиопотока требуется более высокий процент доступного битрейта (чем для видеоданных) при низких значениях доступного битрейта. Это осуществляют путем определения двух рабочих точек для доли скорости в записи группы сэмплов "доля скорости", в соответствии с фиг.7. Каждая рабочая точка на фиг.7 определяет целевую долю скорости. Для более сложных ситуаций можно определять большее количество рабочих точек. Кроме того, первая и последняя рабочие точки определяют целевую долю скорости в этих точках, а также в точках для более низких и более высоких значений доступного битрейта, соответственно. Целевая доля скорости в промежутке между двумя рабочими точками должна иметь значение, лежащее между целевыми долями скорости этих рабочих точек. Вычислить целевую долю скорости между двумя рабочими точками можно, например, с помощью линейной интерполяции.
Целевая доля скорости указывает целевой процент доступного битрейта, который должен быть выделен для мультимедийных данных. Если это выделение выполнено, для определения границ используют максимальный и минимальный битрейт. Максимальный битрейт задает верхний предел значения доступного битрейта для заданных мультимедийных данных и отрезка времени. Альтернативно, его можно использовать для определения верхнего порога, для которого выделенный битрейт является приоритетом мультимедийных данных. Минимальный битрейт указывает нижний порог, который считают применимым. Например, если выделяемый битрейт опускается ниже этого минимального значения, рекомендация для сервера - совсем не выделять битрейта этим мультимедийным данным. Битрейт в этом случае может быть или отдан другому мультимедийному потоку (потокам), или альтернативному потоку, если таковой имеется.
Для указания целевой доли битрейта в различных треках может применяться механизм группирования сэмплов для информации о доле скорости. Информация о доле скорости, задаваемая с помощью механизма группирования сэмплов, применима на всем протяжении мультимедийного сэмпла. Однако, поскольку эта же информация о доле скорости, вероятно, применима ко многим последовательным сэмплам в треке и изменяется, скорее всего, только в двух или трех различных записях, информацию о доле скорости удобно хранить в треке с использованием групп сэмплов. Каждый сэмпл трека может быть связан с одним описанием (или с нулем описаний) группы сэмплов, в каждом из которых определена запись с информацией о доле скорости. В заявке на патент США №11/874138 описана структура формата файлов, которую называют "функциональный бокс доли скорости", она предназначена для указания, какие рабочие точки адаптации для кодированных мультимедийных данных доступны в файле. Группирование сэмплов по доле скорости в базовом формате медиафайлов ISO основано на двух фундаментальных предпосылках:
1. Предполагают, что общий битрейт канала, по которому передают комбинированную мультимедийную информацию (например, аудио- и видеоданные) является кусочно-постоянной функцией времени. Однако, вместо указания оптимальной доли битрейта для аудио-видеоданных при заданном общем битрейте, в некоторых приложениях было бы удобнее указывать путь адаптации (adaptation path), что в результате дает стабильное качество аудио-видеосигнала или его восприятия. Например, если в широковещательных приложениях используют статистическое мультиплексирование, то битрейт одной из аудиовизуальных услуг может меняться, цель при этом - поддерживать стабильное качество. В то же время, общий битрейт, выделенный на все мультиплексируемые аудиовизуальные услуги должен оставаться неизменным. На сегодняшний день не существует возможности указания информации о доле скорости для поддержания стабильного качества.
2. Задают только целевую долю битрейта среди треков, однако не предоставляют указаний или инструкций о том, как получить указанную долю посредством адаптации. Следовательно, так как есть множество способов адаптации масштабируемой мультимедийной информации, например, масштабирование частоты смены кадров или качества, результат процедуры адаптации в различных реализациях может сильно отличаться. Этот факт снижает значение группирования сэмплов по доле скорости.
Для решения указанных выше затруднений предлагается функциональный бокс доли скорости, включающий характеристики рабочих точек адаптации. Рабочая точка адаптации может быть связана с рабочей точкой доли скорости, включенной в запись описания группы сэмплов "доля скорости", которая в остальном остается практически неизменной по сравнению с базовым форматом мультимедийных файлов ISO. Альтернативно, рабочая точка адаптации может быть связана с определенным путем адаптации, о котором сигнализируют в предлагаемом настоящим изобретением треке синхронизированных метаданных, указывающем различные пути адаптации. Для того, чтобы сделать это решение пригодным для треков указаний и всех будущих форматов с масштабируемым кодированием мультимедийных данных, предлагается структуру сэмпла метаданных, независимая от SVC. Каждый сэмпл метаданных предоставляет инструкции - для каждого связанного с ним пути адаптации - с целью создания адаптированного сэмпла. Инструкции диктуют, какие части данных сэмпла, на который осуществляют ссылку, обязательно должны присутствовать в адаптированном сэмпле и какие части, например, масштабируемый кодированный слайс с подробной детализацией (fine granular scalable coded slice), могут быть свободно отброшены на произвольном расстоянии от заголовка этого слоя.
Рабочая точка адаптации определяет, каким образом кодированный мультимедийный ролик, состоящий из одного или более кодированных мультимедийных битовых потоков, масштабируют путем выбора соответствующих частей упомянутых обрабатываемых мультимедийных битовых потоков. Обработка одного или более мультимедийных битовых потоков может включать одно или более из следующего: сборку передаваемых пакетов, передачу и декодирование масштабированных мультимедийных битовых потоков. В заявке на патент США №11/874138 описана структура формата файлов, которую называют "функциональный бокс доли скорости", она предназначена для указания, какие рабочие точки адаптации кодированных мультимедийных данных присутствуют в файле.
Кроме того, функциональный бокс доли скорости может включать характеристику результата адаптации для каждой рабочей точки адаптации, например, получают ли в результате адаптации требуемое разделение общего битрейта между всеми связанными треками, или получают ли стабильное качество в каждом из связанных треков. Также функциональный бокс доли скорости может включать идентификатор, указывающий, какой алгоритм был использован для формирования каждой рабочей точки адаптации. Рабочая точка адаптации при этом соответствует пути адаптации в каждом треке, связанном с этой рабочей точкой адаптации. Рабочая точка адаптации и определенный путь адаптации могут быть охарактеризованы в функциональном боксе доли скорости, например, с помощью минимального и максимального битрейта, достижимого при этом пути адаптации, Направлений, используемых для адаптации, например, пространственная адаптация изображений, качественная адаптация изображений, адаптации скорости передачи изображений или любая их комбинация.
Один из вариантов осуществления настоящего изобретения представлен ниже в виде функционального бокса доли скорости, следующего за псевдокодовым описанием, используемым в базовом формате медиафайлов ISO. Бокс ('moov') фильма содержит ноль или один функциональных боксов ('rsop') доли скорости, в соответствии со следующим определением:
Семантика синтаксических элементов в функциональном боксе доли скорости следующая:
Параметр operation_point_count представляет собой целое число, задающее количество рабочих точек.
Параметр operation_description указывает выходные характеристики адаптации скорости передачи для данной рабочей точки. Для параметра operation_description определены следующие флаги:
0×1 суммарный выходной битрейт всех треков, связанных с данной рабочей точкой, фиксирован и равен доступному битрейту.
0×2 индивидуальное качество каждого трека, связанного с данной точкой, остается постоянным на протяжении трека.
Параметр track_count указывает количество треков, связанных с данной рабочей точкой. Если значение track_count равно 1, то информация, сигнализируемая для данной рабочей точки, задает правило адаптации для единственного типа мультимедийных данных, содержащихся в единственном указанном треке. Если значение track_count больше 1, и все указанные треки содержат один тип мультимедийных данных, тогда информация, сигнализируемая для данной рабочей точки, описывает правило адаптации для одного упомянутого типа мультимедийных данных, содержащихся в нескольких указанных треках.
Параметр track_id указывает параметр track_ID для трека, связанного с данной рабочей точкой.
Параметр adaptation_path_id должен быть нулевым, если track_id не ссылается на трек синхронизированных метаданных, содержащий общие метаданные масштабируемой мультимедийной информации. В противном случае параметр adaptation_path_id указывает, какой путь адаптации следует использовать в данной рабочей точке.
Нулевое значение параметра rate_adaptation_algorithm указывает на то, что ни один трек, связанный с данной рабочей точкой адаптации, не следует адаптировать, вместо этого все сэмплы этих треков следует обработать следующим образом. Если связанный с рабочей точкой адаптации трек является треком указаний, следует сформировать пакеты, соответствующие всем сэмплам указаний. Если же связанный трек является мультимедийным треком SVC, следует провести синтаксический анализ всех сэмплов, включая потенциальные блоки NAL экстракторов. Для всех других треков анализ должен выполняться стандартным образом. Выходная информация такой обработки должна быть совместима с характеристиками рабочей точки, указанными в данном боксе. Если параметр rate_adaptation_algorithm равен 1, это указывает на то, что для получения целевой доли скорости, указанной в группе сэмплов "доля скорости", должен быть использован неизвестный алгоритм адаптации. Другие значения параметра rate_adaptation_algorithm не определены в настоящем описании, но обозначают алгоритмы, используемые для получения путей адаптации в стандартных треках метаданных масштабируемой мультимедийной информации.
Параметр num_constants_in_operation_points определяет количество характеристик, которые остаются постоянными при данном пути адаптации.
Параметр constant_list (список констант) представляет собой четырехсимвольный код, явно указывающий на бокс или структуры, которые определяют постоянные характеристики данного пути адаптации. Четырехсимвольные коды включают коды, определенные для бокса выбора трека SVC. Список констант позволяет осуществить выбор подходящей рабочей точки в соответствии с возможностями устройства и/или программного обеспечения, которое воспроизводит файл или принимает поток пакетов, собранных в соответствии с треками указаний, включенными в этот файл.
Параметр minimum_bitrate предсталяет собой ненулевое значение (в килобитах в секунду), указывающее нижнее значение суммарного битрейта, при котором должна быть применена данная рабочая точка.
Параметр maximiim_bitrate предсталяет собой ненулевое значение (в килобитах в секунду), указывающее высшее значение суммарного битрейта, при котором должна быть применена данная рабочая точка.
Механизм группирования сэмплов для информации о доли скорости может быть использован для указания целевой доли битрейта среди треков. Алгоритм разрежения треков для приведения к целевому битрейту не определен. Если параметр track_id в рабочей точке адаптации ссылается на трек, не являющийся треком синхронизированных метаданных, который включает стандартные метаданные масштабируемой мультимедийной информации, то этот трек может содержать группирование сэмплов типа 'rash' в соответствии с дальнейшим описанием.
Запись группы сэмплов "доля скорости" базового формата файлов ISO расширяется параметром operation_point_id, в соответствии со следующим определением:
Параметр num_adaptation_paths указывает количество обеспечиваемых треком путей адаптации.
Параметр adaptation_path_id ссылается на путь адаптации, охарактеризованный в функциональном боксе доли скорости и идентифицирует путь адаптации.
Значение параметра truncation_flag, равное 1, указывает на то, что части, обозначенные этим идентификатором пути адаптации, в любом сэмпле могут быть отброшены. Значение truncation_flag, равное 0, указывает на то, что ни одна из частей, отмеченная этим идентификатором пути адаптации, ни в одном из сэмплов отброшена быть не может.
Запись сэмпла стандартного трека масштабируемой мультимедийной информации выглядит следующим образом:
Поля записи сэмпла используют для определения размера (8, 16, 24, или 32 бита, которые соответствуют значениям 0, 1, 2 и 3, соответственно) синтаксических элементов, используемых в структуре сэмпла для данного трека.
В сэмпле стандартного трека метаданных масштабируемой мультимедийной информации используют следующую структуру:
Запись стандартного масштабируемого мультимедийного сэмпла содержит значения параметров log2_num_parts_minus_one, log2_num_paths_minus_one, log2_path_id_minus_one, log2_offset_minus_one, и log2_size_minus_one.
Сэмплы метаданных выровнены по времени (времени декодирования) с сэмплами в треках указаний или мультимедийных треках, на которые они ссылаются. Каждый сэмпл метаданных (их также называют сэмплами адаптации) связан с соответствующим адаптированным сэмплом, который получают из исходного адаптированного сэмпла следующим образом.
Исходный адаптированный сэмпл может быть получен из кодированного мультимедийного сэмпла или сэмпла указаний, связанного с некоторым сэмплом адаптации. Если соответствующий трек является мультимедийным треком, исходный адаптированный сэмпл получают из связанного с ним мультимедийного сэмпла. Если мультимедийный сэмпл не содержит блоков NAL с агрегаторами или экстракторами, соответствующими описанию формата файлов SVC, то исходный адаптированный мультимедийный сэмпл идентичен упомянутому мультимедийному сэмплу. В обратном случае данные, на которые ссылаются блоки NAL с экстракторами, вставляют в исходный адаптированный сэмпл на их место, а заголовки блоков NAL с агрегаторами удаляют, при этом все оставшиеся фрагменты исходного адаптированного мультимедийного сэмпла содержат данные мультимедийного сэмпла в оригинальном виде. Если же трек является треком указаний, исходный адаптированный сэмпл получают из соответствующего сэмпла указаний. Исходный адаптированный сэмпл идентичен полезной нагрузке пакетов, формируемой с использованием конструкторов полезной нагрузки данного сэмпла. Сэмпл адаптации включает информацию, для каждого пути адаптации, о том, в какое место адаптированного сэмпла включены части исходного адаптированного сэмпла. Указание на эти части может быть выполнено с помощью списка байтовых диапазонов в исходном адаптированном сэмпле. Решение, включающее использование байтовых диапазонов, позволяет не брать в расчет синтаксис мультимедийного сэмпла и полезной нагрузки пакетов, в результате чего оно применимо к любому формату кодирования или полезной нагрузки пакетов. Сэмпл может также содержать указание, для каждого указанного байтового диапазона, о том, может ли байтовый диапазон быть свободно отброшен на произвольном расстоянии от начала указанного диапазона.
Представленная структура сэмпла стандартных метаданных масштабируемой мультимедийной информации отображает указанные байтовые диапазоны исходного адаптированного сэмпла на адаптированные сэмплы. Для различных путей адаптации могут быть указаны различные байтовые диапазоны. Также может быть указано, разрешается ли отбросить определенный байтовый диапазон, то есть, что в адаптированный сэмпл может быть включено любое количество байтов из упомянутого байтового диапазона. Семантика структуры сэмпла для стандартного трека метаданных масштабируемой мультимедийной информации следующая:
Параметр num_parts указывает количество частей в исходном адаптированном сэмпле. Точного описания частей не дается, но, как правило, это байтовый диапазон в исходном адаптированном сэмпле, соответствующий опорному блоку предсказания, например, кодированному изображению в случае масштабируемого видео.
Параметр num_paths_whole_part указывает количество путей адаптации, в которые включена вся данная часть.
Значение параметра truncatable_part_flag, равное 0, указывает на то, что данная часть не может быть отброшена.
Значение параметра truncatable_part_flag, равное 1, указывает на то, что по меньшей мере одна подчасть данной части может быть отброшена.
Параметр path_id_whole_part указывает идентификатор пути адаптации для данной части, в соответствии с представлением в функциональном боксе доли скорости.
Параметр offset_whole_part указывает байтовый сдвиг в исходном адаптированном сэмпле, с которого начинается данная часть. Первый байтовый сдвиг исходного адаптированного сэмпла имеет значение, равное 0.
Параметр num_bytes_whole_part указывает количество байтов, содержащееся в данной части.
Параметр num_partitionings указывает количество разбиений, которыми данная часть поделена на подчасти. Каждый уникальный способ разделить часть на подчасти представляет собой разбиение. Например, если часть соответствует масштабируемому изображению с подробной детализацией, и при этом определены два пути адаптации, позволяющие осуществить масштабирование битрейта в диапазоне от 50 до 100% и от 80 до 100% от общего размера изображения, соответственно, то в этом случае для данной части будет два разбиения. В первом разбиении подчасть, соответствующая байтовому диапазону, составляющему 50% от размера изображения, будет обозначена с помощью нулевого значения параметра free_truncation_flag, а оставшаяся подчасть изображения будет отмечена значением free_truncation_flag, равного 1. Подчасти второго разбиения обозначают аналогично.
Параметр num_paths указывает количество путей адаптации, совместно использующих одно разбиение части на подчасти.
Параметр path_id указывает идентификатор пути адаптации для подчастей, определенных для разбиения, в соответствии с представлением в функциональном боксе доли скорости.
Параметр num_subparts указывает количество подчастей. Точного определение подчасти не дано, однако она является байтовым диапазоном части, соответствующим, например, заголовку и данным масштабируемого кодированного слоя с подробной детализацией.
Параметр offset указывает байтовый сдвиг от исходного адаптированного сзмпла, после которого начинается данная подчасть. Первый байтовый сдвиг исходного адаптированного сэмпла имеет значение, равное 0.
Параметр num_bytes указывает количество байтов, содержащееся в данной подчасти.
Значение параметра free_truncation_flag, равное 0, указывает на то, что данная часть не должна сокращаться.
Значение параметра free_truncation_flag, равное 1, указывает на то, что данная подчасть может сокращена до любой длины, путем исключения сэмплов, начиная от сконца данной подчасти.
Адаптированный сэмпл создают следующим образом. Допустим, что currPathld равен идентификатору требуемого пути адаптации. Для сэмпла, содержащего данные об этом пути адаптации, в соответствии с указанием в группе сэмплов с информацией о доле скорости, выполняется следующая процедура. Для каждой указанной части, список path_id_whole_part сравнивают сначала с currPartld. Если значение path_id_whole_part, равное currPathld, существует, то всю часть, указанную с помощью значений offset_whole_part и num_bytes_whole_part, включают в адаптированный сэмпл. Если нет значения path_id_whole_part, равного currPartld, а значение truncatable_part_flag равно 1, выполняется цикл указанных разбиений на подчасти до тех пор, пока не будет найдено значение path_id, равное currPathld. Затем, каждую подчасть, указанную с помощью значений offset и num_bytes, включают в адаптированный сэмпл. Если требуется дальнейшее сокращение адаптированного сэмпла, например, для достижения заданного битового размера, то подчасти, для которых free_truncation_flag равен 1, сокращают до необходимой длины.
Адаптированные сэмплы образуют адаптированный трек. Если трек, на который ссылаются, является треком указаний, то адаптированные сэмплы представляют собой действительную полезную нагрузку пакетов. Если трек, на который ссылаются, является мультимедийным треком, то адаптированные сэмплы представляют собой действительные мультимедийные сэмплы.
Следует отметить, что кодированные сэмплы при кодировании видеоданных являются, как правило, кодированными изображениями или блоками доступа. Кодированные сэмплы при кодировании аудиоданных представляют собой, как правило, кодированные аудиокадры. Также, в соответствии с предшествующим описанием, правильность потока не гарантирована, если внутри кодированной видеопоследовательности порог simple_priority_id изменяется. Для указания корректных (действительных) точек переключения между путями адаптации используют механизм группирования сэмплов по точкам переключения путей адаптации с целью указания адаптированных сэмплов, которые можно использовать для переключения с одного пути адаптации на другой. Необходимость подобного механизма группирования сэмплов вытекает из того факта, что в SVC применяется однопроходное декодирование, то есть опорные изображения декодируют только для высшего декодируемого уровня. Следовательно, переключение между уровнями в произвольных точках невозможно, так как в некоторых точках опорные изображения переключаемого уровня не декодированы. Упомянутый механизм группирования сэмплов может, в соответствии с этим, быть использован для указания точек переключения уровней или, в более общем виде, точек переключения между путями адаптации.
Если присутствует описание группы сэмплов "точка переключения путей адаптации", то каждый сэмпл трека поставлен в соответствие одной записи точки переключения путей адаптации, определенной ниже:
Семантика записи группы сэмплов "точка переключения путей адаптации" следующая:
Параметр num_refresh указывает количество путей адаптации, на которые возможно переключение в данном сэмпле, если ранее, при формировании адаптированных сэмплов, применялись пути адаптации.
Параметр refresh_adaptation_path_id указывает идентификаторы для путей адаптации, на которые может быть выполнено переключение, если ранее, при формировании адаптированных сэмплов, применялись пути адаптации.
Необходимую рабочую точку адаптации может выбирать устройство, компьютерная программа, компонент или любой другой соответствующий блок, выполняющий обработку файла с функциональным боксом доли скорости. Выбор осуществляется в зависимости от того, насколько ограничения или возможности устройства и потенциального приемного блока отвечают характеристикам рабочей точки адаптации или необходимого для вычисления данной рабочей точки адаптации алгоритма. Далее приведено описание примера системы для выбора рабочей точки адаптации. Сервер потоковой передачи данных имеет доступ к файлу, включающему функциональный бокс доли скорости. Файл содержит немасштабируемый битовый аудиопоток и битовый видеопоток, который является масштабируемым по качеству и по времени. В функциональном боксе доли скорости указаны две рабочие точки адаптации, целью которых является разделение общего битрейта между аудио- и видеоданными. Каждая рабочая точка адаптации ссылается на пару треков указаний: трек указаний для аудио и трек указаний для видео. Функциональный бокс доли скорости указывает, что в первой рабочей точке адаптации видео масштабируют по времени, а во второй рабочей точке адаптации применяют масштабирование по качеству. Между принимающей стороной и сервером устанавливают сеанс потоковой передачи данных "точка-точка" (то есть одноадресный). Блок приемника может включать в составе своего пользовательского интерфейса переключатель для выбора пользовательских предпочтений между частотой смены кадров (временное масштабирование) или детализацией изображения (масштабирование качества). На основе пользовательского выбора блок приемника указывает серверу, какой путь адаптации следует использовать. Сервер затем формирует пакеты на основе соответствующего трека указаний и указанного приемником пути адаптации.
В соответствии с этим, фиг.8 иллюстрирует краткое упрощенное изложение способов обработки треков, обеспечивающих возможность организации мультимедийных данных в треки, идентификации подмножеств треков, указания характеристик треков и подмножеств треков а также организации треков в многотрековые группы в соответствии с заданным критерием группирования.
Синхронизированные мультимедийные данные (как и синхронизированные метаданные) логически организуют в треки. Каждый трек обеспечивает репрезентацию мультимедийного контента, который может быть декодирован и воспроизведен. Различные типы метаданных для трека представлены в боксе заголовка трека или элементах того же уровня. Бокс выбора трека содержит атрибуты, описывающие его содержимое, или атрибуты, отличающие содержимое данного трека от других треков в одной альтернативной группе (см. далее). Сэмплы в треках описывают путем заполнения записей сэмплов.
Для треков могут формироваться подмножества. Подмножество трека является подмножеством мультимедийных данных целого трека и связано с ним. Подмножество трека представляет собой мультимедийный контент, который, как правило, может быть декодирован и воспроизведен.
Как отмечалось ранее, базовый формат мультимедийных файлов ISO и поправки к нему, например, формат файлов SVC, поддерживают указание характеристик иерархически организованных подмножеств битового потока. Например, характеристики подмножеств масштабируемого битового видеопотока (SVC) могут быть указаны для ярусов (которые практически аналогичны масштабируемым уровням) или для треков целиком (которые, собственно, и являются масштабируемыми уровнями). Однако в базовом формате мультимедийных файлов ISO отсутствует поддержка указания различных иерархических разбиений, а также наложенных подмножеств битового потока (не имеющих вложенной структуры). Для многоракурсного видеокодирования, вследствие возможности гибкого выбора ракурсов для отображения, необходимы оба упомянутых типа указаний.
Треки могут быть связаны друг с другом посредством трековых ссылок, при этом могут указываться характеристики трека или подмножества трека (например, яруса SVC), однако в базовом формате мультимедийных файлов ISO и его производных отсутствует механизм для указания характеристик группы треков или подмножеств треков. Подобными характеристиками могут быть например, требуемый профиль, уровень и параметры буферизации декодера.
В базовом формате мультимедийных файлов ISO отсутствует механизм указания отношений (общих черт и различий) группы треков или подмножеств треков с другой группой треков или подмножеств треков. Подобный механизм необходим при выборе группы треков или подмножеств треков для обработки с игнорированием остальных аналогичных групп. Группа треков или подмножеств треков может быть необходима, например, для указания необходимых отображаемых ракурсов многоракурсного потока.
Многоракурсные битовые видепотоки могут храниться в контейнерном файле множеством различных способов, начиная с хранения одного ракурса для каждого трека и заканчивая хранением всех ракурсов для единственного трека. В семействе файловых форматов, происходящих от базового формата мультимедийных файлов ISO, отсутствует механизм указания отношений между одним подмножеством трека и другим подмножеством (возможно, другого) трека.
В соответствии с вариантами осуществления настоящего изобретения предложен механизм группирования многотрековых групп в множества многотрековых групп. Варианты осуществления настоящего изобретения позволяют указать объединенные характеристики и критерий группирования для множества многотрековых групп, а также отношения между множествами многотрековых групп. Один из примеров варианта осуществления настоящего изобретения проиллюстрирован на фиг.9.
В соответствии с вариантами осуществления настоящего изобретения может обеспечиваться группирование многотрековых групп в множества многотрековых групп. Также, может быть обеспечена возможность указания объединенных характеристик и критерия группирования для множества многотрековых групп. Могут быть указаны отношения между множествами многотрековых групп, при этом многотрековая группа может быть образована на базе подмножества треков.
Следует отметить, что значения K, L, М и N на фиг.9 могут быть любыми положительными целыми числами, которые независимы друг от друга. Символ "#" на фиг.9 обозначает номер идентификатора для соответствующей структуры формата файлов.
Далее, со ссылками на фиг.10, проиллюстрирована блок-схема алгоритма примера процедуры организации мультимедийных данных. В соответствии с вариантами осуществления настоящего изобретения проиллюстрированная процедура 400 сохраняет мультимедийные данные реального времени в множестве треков и/или подмножеств треков (блок 402). Треки и/или подмножества треков показаны на фиг.9 под числовым обозначением 302. Как показано на фиг.10, одну или более многотрековых групп, состоящую из треков и/или подмножеств треков, определяют на основе отношений между треками и/или подмножествами треков (блок 404). В варианте осуществления изобретения, проиллюстрированном на фиг.9, группы показаны под числовым обозначением 304. Определение групп может включать, например, сохранение или передачу связанной с ними информации. В некоторых вариантах осуществления настоящего изобретения процедура 400 может включать также формирование по меньшей мере одного множества многотрековых групп (блок 406). Множества многотрековых групп могут быть связаны с одной или более характеристиками многотрековых групп. На фиг.9 множества многотрековых групп показаны под числовым обозначением 306.
Варианты осуществления настоящего изобретения применимы к многоракурсному видео и многоракурсному аудио. В частности, множественные ракурсы одного и того же контента могут быть критерием группирования для многотрековой группы. При этом могут быть указаны характеристики многотрековой группы, определенные для многоракурсного видео или многоракурсного аудио. Также варианты осуществления настоящего изобретения позволяют организовать несколько многотрековых групп в множество многотрековых групп с характеристиками, аналогичными с точки зрения отображения, кодирования или захвата мультимедийных данных. Могут быть указаны объединенные многоракурсные характеристики для множества многотрековых групп и многоракурсные отношения между множествами многотрековых групп.
Ниже описан пример реализации вариантов осуществления настоящего изобретения на примере синтаксиса и семантики базового формата мультимедийных файлов ISO. Также, для MVC добавлены боксы многотрековых групп.
В соответствии с вариантами осуществления настоящего изобретения предлагается абстрактный бокс многотрековой группы, который используют для группирования треков или подмножеств треков и указания отношений между ними. Критерий группирования указывают с помощью четырехсимвольного кода бокса, наследуемого от бокса многотрековой группы. В одном из вариантов осуществления изобретения описан критерий группирования для многоракурсного видео, однако могут быть созданы и другие критерии, например, для кодирования с множественным описанием. Четырехсимвольный код "mvcg" используют для многотрековой группы многоракурсного видео. Входящие в нее треки или подмножества треков соответствуют предназначенным для отображения (вывода) ракурсам. Подмножеством трека может быть, например, ярус, определяемый с помощью механизма группирования сэмплов.
В соответствии с вариантами осуществления настоящего изобретения бокс отношений многотрековых групп используют для указания отношений между указанными многотрековыми группами. Основной критерий для внесения в список какого-либо множества многотрековых групп указывают с помощью четырехсимвольного кода бокса, наследуемого от бокса отношений многотрековых групп. В соответствии с вариантами осуществления настоящего изобретения, одним из критериев может быть "переключение" - 'swtc', указывающий на то, что в один момент времени должна быть обработана (воспроизведена или передана) только одна из указанных многотрековых групп, при этом, если есть необходимость, в любое время допускается переключение между многотрековыми группами.
Отношения между треками или подмножествами треков в многотрековой группе, а также отношения между многотрековыми группами, включающими производный бокс отношений многотрековых групп, указывают посредством бокса атрибутов отношений ("ratr"). В одном из вариантов осуществления изобретения существуют два типа отношений: общие для всех указанных блоков и те, которые отличают указанные блоки. Для упрощения анализа информации о многотрековом группировании все боксы многотрековых групп и боксы отношений многотрековых групп должны входить в состав одного контейнерного бокса многотрековых групп ("mtgc"), включаемого в бокс фильма ("moov").
Далее, на фиг.11 проиллюстрирован упрощенный пример файла с двумя боксами многотрековых групп многотрекового видео, которые ссылаются на частично отличающиеся треки. В данном примере один трек создан для одного из ракурсов многоракурсного битового потока. Бокс отношений многотрековых групп "переключение" включен для указания подобий и отличий между многоракурсными потоками, образованными этими двумя многотрековыми группами. Пунктирная стрелка на фиг.11 обозначает ссылку.
Бокс атрибутов отношений определяют следующим образом:
Если бокс атрибутов отношений содержится в боксе многотрековой группы, он указывает на отношения между треками или подмножествами треков соответствующей многотрековой группы. Если бокс атрибутов отношений содержится в боксе отношений многотрековых групп, он указывает на отношения между многотрековыми группами. Что касается семантики бокса атрибутов отношений, то некоторый блок определен как трек или подмножество трека, если бокс атрибутов отношений содержится в боксе многотрековых групп, и как многотрековая группа, если бокс атрибутов отношений содержится в боксе отношений многотрековых групп.
Синтаксис и семантика синтаксических элементов в боксе атрибутов отношений следующая:
Параметры common_attribute и differentiating_attribute выбирают из приведенного ниже списка. Атрибуты, которые могут быть использованы в качестве отличительных атрибутов, связаны с указателем на отличающееся поле или информацию
Все блоки имеют одинаковые общие атрибуты, или, другими словами, общие атрибуты совместно характеризуют все блоки. Отличительные атрибуты указывают на то, что по меньшей один блок отличается от других блоков этим атрибутом. Указатель отличительного атрибута указывает на местоположение информации, отличающей какой-либо блок от других блоков с тем же атрибутом.
Контейнерный бокс многотрековых групп определяют следующим образом:
Этот бокс содержит типизированные боксы многотрековых групп. Синтаксис и семантика синтаксических элементов в контейнерном боксе многотрековых групп следующие:
Бокс многотрековых групп определяют следующим образом
Синтаксис и семантика синтаксических элементов в боксе мультитрековой группы следующая:
Параметр multi_track_group_id предоставляет уникальный идентификатор для многотрековой группы в файле. Параметр relation_attribute_box содержит отношения между указанными треками или подмножествами треков. Параметр num_entries представляет количество треков и подмножеств треков, входящих в состав данной многотрековой группы.
Параметр entry_type указывает, какому типу соответствует трек или подмножество трека. Определены следующие значения параметра entry_type:
0 - трек целиком;
1 - ярус в треке;
2 - сэмплы, связанные с определенной группой определенного группирования сэмплов;
3 - приоритетный уровень SVC;
4 - подмножество битового потока SVC/MVC в заданном диапазоне priority_id;
5 - поток, содержащий только определенные подсэмплы всех сэмплов;
6 - поток, содержащий только сэмплы в определенном диапазоне приоритетов деградации;
7 - поток, содержащий только определенный путь адаптации. Параметр track_id указывает трек. Параметр tier_id указывает ярус в треке (SVC или MVC).
Параметр grouping_type указывает, какие бокс описания группы сэмплов и бокс соответствия "сэмпл-группа" (Sample to Group) связаны друг с другом.
Младший бит параметра grouping_flags должен быть установлен, если имеется параметр grouping_type_parameter, определенный в третьей редакции проекта поправки к базовому формату мультимедийных файлов ISO (документы группы MPEG N9826). Параметр grouping_type_parameter используют также для указания, какой бокс описания группы и бокс соответствия "сэмпл-группа" являются связанными друг с другом.
Параметр group_description_index указывает перечень сэмплов в связанном боксе (или боксах) соответствия "сэмпл-группа", образующих подмножество трека.
Параметр priority_layer указывает, какой уровень приоритета используют для образования подмножества треков. При ссылке на уровень приоритета параметр track_id должен указывать на трек синхронизированных метаданных для SVC, содержащий соответствующие значения уровня приоритетов.
Параметр num_subsample_entries указывает количество записей, определяющих, какие подсэмплы включают в подмножество трека. Параметры min_subsample_priority и max_subsample_priority указывают диапазон приоритетов подсэмплов, содержащийся в подмножестве трека.
Значение параметра discardable_required, равное 0, указывает на то, что сэмплы со значением поля "отбрасываемый" (discardable), равным 0, не включают в подмножество трека. Значение параметра discardable_required, равное 1, указывает на то, что сэмплы со значением поля "отбрасываемый", равным 1, не включают в подмножество трека. Значение discardable_required, равное 2, указывает на то, что поле "отбрасываемый" игнорируют при выборе сэмплов для подмножества треков.
mask_one_bit_required предоставляет маску для поля "зарезервировано" бокса информации подсэмпла. Когда (mask_one_bit_required & reserved)=mask_one_bit_required (операция & - побитовая), соответствующий подсэмпл включают в подмножество трека (при условии, что все остальные критерии также выполнены).
mask_zero_bit_required представляет собой маску для поля "зарезервировано) бокса информации подсэмпла. Если (mask_zero_bit_required & reserved) = 0, соответствующий подсэмпл включают в подмножество трека (при условии, что все остальные критерии также выполнены).
Когда параметр entry_type равен 6, сэмплы с приоритетом деградации в диапазоне от 0 до max_degradation_priority включают в подмножество трека. (Это предполагает, что приоритетом деградации, равным 0, отмечены наиболее важные данные, при этом степень важности уменьшается с ростом приоритета деградации).
Параметр adaptation_path_id indicates указывает, какой путь адаптации представляет данное подмножество трека.
Бокс многотрековой группы для многоракурсного видео определяют следующим образом:
Данный бокс определяет многотрековую группу для отображаемых ракурсов многоракурсного видеопотока. Предполагается, что каждый трек или подмножество трека, включенные в данный бокс, будут отображены. Если трек или подмножество трека содержат несколько ракурсов, все содержащиеся в них ракурсы предназначены для отображения.
Декодирование отображаемых ракурсов может потребовать декодирования и других ракурсов, не предназначенных для отображения.
Ракурсы, необходимые для декодирования, но не предназначенные для отображения, могут быть выявлены с помощью трековых ссылок 'mvpr', a также по содержимому бокса зависимостей ярусов.
Синтаксис и семантика синтаксических элементов в боксе многотрековой групп для многоракурсного видео следующие:
Следует отметить, что должно быть разрешено также присутствие бокса информации яруса, бокса битрейта яруса и бокса многотрековой группы для многоракурсного видео, в дополнение к разрешенным контейнерным боксам, упомянутым в определении бокса информации яруса, бокса битрейта яруса и бокса буферизации, описанных выше.
Параметр relation_attribute_box, входящий в состав бокса многотрековой группы, указывает отношения между отображаемыми ракурсами. Если в качестве общего атрибута используют 'ecam', то все отображаемые ракурсы связаны с внешними параметрами камер, имеющих идентичный угол поворота и находящихся на постоянном одинаковом расстоянии друг от друга.
Параметр subset_stream_info указывает характеристики подмножества битового потока, в котором содержатся указанные отображаемые ракурсы и ракурсы, от которых они зависят.
Параметр subset_stream_bit_rate указывает статистику битрейта для подмножества битового потока, содержащего отображаемые ракурсы и ракурсы, от которых они зависят. Значения параметров tierBaseBitRate, tierMaxBitRate, и tierAvgBitRate в боксе TierBitRateBox не определены.
Параметр subset_stream_buffering указывает параметры гипотетического референсного декодера (Hypothetical Reference Decoder, HRD) применимые к подмножеству битового потока, в котором содержатся указанные отображаемые ракурсы и ракурсы, от которых они зависят.
Параметр subset_stream_initial_parameter_sets включает наборы параметров, необходимые для декодирования подмножества битового потока, в котором содержатся указанные отображаемые ракурсы и ракурсы, от которых они зависят.
Параметр multiview_scene_info содержит максимальное расхождение, в целочисленных единицах пиксельного разрешения, между любыми смежными отображаемыми ракурсами в любом из блоков доступа.
Бокс отношений многотрековых групп определяют следующим образом:
Этот абстрактный бокс обеспечивает механизм указания многотрековых групп и их отношений друг с другом. Параметр "тип бокса" в производных от него боксах указывает критерий для группирования указанных многотрековых групп в единое целое. Синтаксис и семантика синтаксических элементов в боксе отношений многотрековых групп следующие:
Параметр num_entries указывает количество связанных многотрековых групп. Параметр multi_track_group_id представляет собой идентификатор связанной многотрековой группы. Параметр relation_attributes указывает отношения между связанными многотрековыми группами.
Бокс отношений многотрековых групп типа "переключение" определяют следующим образом:
Этот бокс определяет набор многотрековых групп, из которого в любой момент времени декодируется и воспроизводится одна многотрековая группа. Заданные атрибуты отношений определяют, какие свойства являются общими во всех связанных многотрековых группах и какие факторы определяют различия между многотрековыми группами. Атрибуты отношений могут применяться с целью выбора подходящего набора многотрековых групп для воспроизведения, например, в случае многоракурсного видеоконтента, на основе количества отображаемых ракурсов. Отличительные атрибуты могут использоваться для выбора из данного множества многотрековых групп тех, что подходят для воспроизведения проигрывателем, например, на основе требуемого для декодирования уровня.
Синтаксис бокса отношений многотрековых групп типа "переключение" следующий:
Порядок многотрековых групп, перечисленных в боксе отношений многотрековых групп, может указывать на порядок предпочтения. Например, многотрековая группа, указанная первой, может быть предпочтительной для воспроизведения (по мнению создателя контента).
Использование представленных выше структур форматов файлов описано со ссылками на пример, проиллюстрированный на фиг.12. Пример битового потока содержит три ракурса. Ракурс 0 является AVC-совместимым базовым ракурсом. Опорные изображения для интер-предсказания в ракурсе 2 получены с использованием межракурсного предказания по ракурсу 0, а опорные изображения для интер-предсказания в ракурсе 1 получены с использованием межракурсного предсказания по ракурсам 0 и 1. Каждый ракурс имеет два временных уровня, что обеспечивается кодированием всех остальных компонентов ракурса как не-опорных изображений. Камеры, используемые для получения ракурсов, были размещены в одну линию, при этом расстояние между двумя соседними камерами в системе захвата не менялось. Камеры направлены в одну сторону (то есть угол их поворота одинаков), при этом они одного типа (то есть внутренние параметры камер идентичны).
Фиг.13-15 иллюстрируют возможные способы хранения упомянутого примера потока в контейнерном файле. На фиг.13 трек для каждого ракурса формируют отдельно. Запись сэмпла для этого трека, в котором хранится базовый ракурс, - 'avc'. Два остальных трека помечены трековой ссылкой типа 'mvpr', которая указывает на трек, необходимый для декодирования трека с этой трековой ссылкой.
Приведенный ниже фрагмент псевдокода определяет четыре многотрековые группы. Многотрековая группа 1 состоит из ракурсов 0 и 1 (трек #1 и #2), многотрековая группа 2 состоит из ракурсов 1 и 2 (треки #2 и #3), многотрековая группа 3 состоит из ракурсов 0 и 2 (треки #1 и #3), а многотрековая группа 4 состоит из всех ракурсов. Для каждой многотрековой группы определены одни и те же общие и отличительные атрибуты. Частота смены кадров, а также внутренние и внешние параметры камер указаны в качестве общих параметров, так как они остаются одинаковыми для всех ракурсов. Кодек меняется, с AVC (запись сэмпла 'avc') в треке#1 на MVC (запись сэмпла 'mvc1) в остальных треках; следовательно, он отмечен как отличительный атрибут. В данном примере также принято допущение, что требуемый уровень меняется в зависимости от того, какие ракурсы декодируют (что очень вероятно для большинства систем декодирования).
В приведенном ниже псевдокоде определены три бокса отношений многотрековых групп типа "переключение". В первом боксе отношений перечислены все определенные многотрековые группы. Их общими атрибутами являются частота смена кадров, внутренние параметры камер, кодек (так как множество записей сэмплов во всех случаях состоит из 'avd' и 'mvc1), и профиль (то есть множество профилей состоит из профиля для базового ракурса и выбранного многоракурсного профиля). Отличительными параметрами являются количество отображаемых ракурсов (которое в данном примере изменяется в диапазоне от 2 до 3), внешние параметры камер (так как расстояние между камерами для отображаемых ракурсов в многотрековой группе 3 отличается от других многотрековых групп), и уровень. Проигрыватель, способный к отображению любого многоракурсного контента, может выбирать многотрековую группу для воспроизведения на основе этого бокса отношений.
Во втором боксе отношений перечислены многотрековые группы 1, 2 и 3. Общие и отличительные параметры - те же, что и для первого бокса отношений, за исключением того, что количество отображаемых ракурсов теперь является общим атрибутом (значение которого равно 2 во всех перечисленных многотрековых группах). Проигрыватель, способный воспроизводить 2-ракурсный контент (например, с использованием очков с оптическими затворами) может выбирать многотрековую группу для воспроизведения на основе этого бокса отношений.
В третьем боксе отношений перечислены многотрековые группы 1 и 2. Общие и отличительные параметры - те же, что и для второго бокса отношений, за исключением того, что внешние параметры камер теперь являются общим атрибутом (так как расстояние между камерами для отображаемых ракурсов идентично в перечисленных многотрековых группах). Проигрыватель, требующий определенной взаимосвязи отображаемых ракурсов (например, для отображения на автостереоскопическом дисплее) может выбирать многотрековую группу для воспроизведения на основе этого бокса отношений.
На фиг.14 представлен файл, в котором трек включает все ракурсы. Запись сэмпла для этого трека, в которой хранится базовый ракурс, - 'avc1', поскольку программа чтения файлов AVC способна провести анализ и декодировать этот трек. Запись сэмпла содержит конфигурационную запись декодера MVC. Для этого трека, с использованием механизма группирования сэмплов, определены три яруса, при этом каждый ярус включает один ракурс. Приведенный ниже псевдокод семантически идентичен псевдокоду для фиг.13. Обозначение '===' указывает, что содержимое структуры не меняется относительно псевдокода фиг.13. Очевидно, структуры остались те же, за исключением обозначения элементов многотрековой группы, где необходим другой механизм указания яруса в треке, по сравнению с указанием всего трека в примере на фиг.13.
Следует отметить, что продемонстрированный механизм является достаточно гибким в отношении треков, содержащих различное количество ракурсов. На фиг.15 пример битового потока хранят таким образом, что базовые ракурсы образуют один трек, а остальные ракурсы - другой трек.
Для второго трека, с использованием механизма группирования сэмплов, определены два яруса, при этом каждый ярус включает один ракурс.
Приведенный ниже псевдокод семантически идентичен фрагментам превдокода на фиг.13 и 14.
Ниже описан еще один пример реализации вариантов осуществления настоящего изобретения, на примере синтаксиса и семантики базового формата мультимедийных файлов ISO.
Контейнерный бокс многоракурсных групп определяют следующим образом:
Этот бокс содержит боксы многоракурсных групп и боксы отношений многоракурсных групп. Синтаксис контейнерного бокса многоракурсных групп определяют следующим образом.
Бокс многоракурсной группы определяют следующим образом:
Данный бокс определяет многотрековую группу для отображаемых ракурсов многоракурсного видеопотока. Предполагается, что каждый трек или подмножество трека, включенные в данный бокс, будут отображены. Если трек или подмножество трека содержат несколько ракурсов, все содержащиеся в них ракурсы предназначены для отображения.
Декодирование отображаемых ракурсов может потребовать декодирования и других ракурсов, не предназначенных для отображения.
Ракурсы, необходимые для декодирования, но не предназначенные для отображения, могут быть выявлены с помощью трековых ссылок 'mvpr', a также по содержимому бокса зависимостей ярусов.
Синтаксис и семантика синтаксических элементов в боксе многотрековой группы для многоракурсного видео следующие:
Следует отметить, что в боксе многотрековой группы должно быть разрешено также присутствие бокса информации яруса, бокса битрейта яруса и бокса многотрековой группы, в дополнение к разрешенным контейнерным боксам, упомянутым в определении бокса информации яруса, бокса битрейта яруса и бокса буферизации, описанных выше.
Семантика боса многоракурсной группы определена следующим образом:
Параметр multiview_group_id представляет собой уникальный идентификатор для многоракурсной группы в файле.
Параметр num_entries представляет собой количество треков и ярусов, включенных в эту многоракурсную группу.
Параметр entry_type указывает, какой тип - трек или ярус - следует далее. Определены следующие значения параметра entry_type: 0 - трек целиком, 1 - ярус в треке.
Параметр track_id указывает на трек.
Параметр tier_id указывает на ярус в треке
Параметр subset_stream_info указывает характеристики подмножества битового потока, в котором содержатся указанные отображаемые ракурсы и ракурсы, от которых они зависят.
Параметр relation_attribute_box указывает отношения между отображаемыми ракурсами. Если в качестве общего атрибута используют 'ecam', то все отображаемые ракурсы связаны с внешними параметрами камер, это показывает, что все камеры имеют идентичный угол поворота и располагаются на одной линии с постоянным расстоянием между ними. Если 'ecam' используют в качестве отличительного атрибута, один из отображаемых ракурсов связан с внешними параметрами камеры, которая имеет отличающийся от других угол поворота, или отображаемые ракурсы связаны с внешними параметрами камер, расстояние между которыми не постоянно.
Параметр subset_stream_bit_rate указывает статистику битрейта для подмножества битового потока, содержащего указанные отображаемые ракурсы и ракурсы, от которых они зависят. Значения параметров tierBaseBitRate, tierMaxBitRate, и tierAvgBitRate в боксе TierBitRateBox не определены,
Параметр subset_stream_buffering указывает параметры HRD, которые применимы к подмножеству битового потока, содержащего указанные отображаемые ракурсы и ракурсы, от которых они зависят.
Параметр multiview_scene_info содержит максимальное расхождение, в целочисленных единицах пиксельного разрешения, между любыми смежными отображаемыми ракурсами в любом из блоков доступа.
Бокс отношений многотрековых групп определяют следующим образом:
Этот бокс определяет набор многоракурсных групп, из которого в любой момент времени декодируется и воспроизводится одна многоракурсная группа. Заданные атрибуты отношений определяют, какие свойства являются общими во всех связанных многоракурсных группах, и какие показатели порождают отличия между многоракурсными группами. Атрибуты отношений могут применяться для выбора в упомянутом наборе подходящей для воспроизведения проигрывателем многотрековой группы, например, на основе уровня, необходимого для декодирования.
Синтаксис бокса отношений многотрековых групп типа "переключение" следующий:
Семантику бокса отношений многотрековых групп определяют следующим образом. Параметр num_entries указывает количество связанных многоракурсных групп. Параметр multiview_group_id представляет собой идентификатор связанной многоракурсной группы. Параметр relation_attributes указывает отношения между связанными многоракурсными группами.
Бокс атрибутов многоракурсных отношений определяют следующим образом:
Если бокс атрибутов многоракурсных отношений содержится в боксе многоракурсной группы, он указывает отношения между треками или ярусами в соответствующей многотрековой группе. Если бокс атрибутов многоракурсных отношений содержится в боксе отношений многоракурсных групп, он указывает отношения между многоракурсными группами.
Синтаксис бокса атрибутов многоракурсных отношений определяют следующим образом.
Что касается семантики бокса атрибутов отношений, то блок определен как трек или ярус, если бокс атрибутов отношений содержится в боксе многоракурсных групп, или как группа отображаемых ракурсов, если бокс атрибутов отношений содержится в боксе отношений многоракурсных групп. Параметры common_attribute и differentiating_attribute выбирают из приведенного ниже списка. Атрибуты, которые могут быть использованы в качестве отличительных, связаны с различительным указателем на поле или информацию
Все блоки имеют одни и те же общие атрибуты, или, другими словами, общие атрибуты совместно характеризуют все блоки. Отличительные атрибуты указывают на то, что по меньшей один блок отличается от других этим атрибутом. Указатель отличительного атрибута указывает на местоположение информации, которая отличает один из блоков от других блоков, имеющих этот же атрибут.
Приведенный ниже фрагмент псевдокода, аналогично предыдущему примеру, определяет четыре многотрековые группы (отдельные поля, например, num_entries, num_common_attributes и num_defferentiating_attributes опущены). Многотрековая группа 1 состоит из ракурсов 0 и 1 (трек #1 и #2), многотрековая группа 2 состоит из ракурсов 1 и 2 (треки #2 и #3), многотрековая группа 3 состоит из ракурсов 0 и 2 (треки #1 и #3), а многотрековая группа 4 состоит из всех ракурсов. Для каждой многотрековой группы определены одни и те же общие и отличительные атрибуты. Частота кадров, а также внутренние и внешние параметры камер указаны в качестве общих параметров, так как они остаются одинаковыми для всех ракурсов. В данном примере также принято допущение, что требуемый уровень меняется в зависимости от того, какие ракурсы декодируют (что весьма вероятно в большинстве систем декодирования).
В приведенном ниже псевдокоде определены три бокса отношений многоракурсных групп. В первом боксе отношений перечислены все определенные многоракурсные группы. Их общими атрибутами являются частота кадров, внутренние параметры камер и профиль (так как множество профилей состоит из профиля для базового ракурса и выбранного многоракурсного профиля). Отличительными параметрами являются количество отображаемых ракурсов (которое в данном примере изменяется в диапазоне от 2 до 3), внешние параметры камер (так как расстояние между камерами для отображаемых ракурсов в многотрековой группе 3 отличается от других многотрековых групп) и уровень. Проигрыватель, способный к отображению любого многоракурсного контента, может выбирать многоракурсную группу для воспроизведения на основе этого бокса отношений.
Во втором боксе отношений перечислены многотрековые группы 1, 2 и 3. Общие и отличительные параметры - те же, что и для первого бокса отношений, за исключением того, что количество отображаемых ракурсов теперь является общим атрибутом (значение которого равно 2 во всех перечисленных многоракурсных группах). Проигрыватель, способный воспроизводить 2-ракурсный контент (например, с использованием очков с оптическими затворами) может выбирать многоракурсную группу для воспроизведения на основе этого бокса отношений.
В третьем боксе отношений перечислены многоракурсные группы 1 и 2. Общие и отличительные параметры - те же, что и для второго бокса отношений, за исключением того, что внешние параметры камер теперь являются общим атрибутом (так как расстояние между камерами для отображаемых ракурсов идентично в перечисленных многоракурсных группах). Проигрыватель, которому необходимо, чтобы отображаемые ракурсы имели определенную взаимосвязь (например, для отображения на автостереоскопическом дисплее) может выбирать многоракурсную группу для воспроизведения на основе этого бокса отношений.
Еще один пример реализации вариантов осуществления настоящего изобретения описан ниже на примере синтаксиса и семантики базового формата мультимедийных файлов ISO.
В частности, применяют свойство grouping_type_parameter будущей поправки 1 к третьему изданию стандарта базового формата мультимедийных файлов ISO. Параметр grouping_type_parameter включают в бокс соответствия "сэмпл-группа" и бокс описания группы сэмплов с номерами версий, большими, чем в приведенном выше описании. Когда параметр grouping_type_parameter присутствует, в одном контейнерном боксе допускается существование нескольких экземпляров бокса соответствия "сэмпл-группа" и бокса описания группы сэмплов с одинаковыми значениями grouping_type. Каждый из экземпляров идентифицируют по значению grouping_type_parameter. В данном варианте осуществления изобретения grouping_type_parameter при группировании сэмплов типа 'mvif' используют для указания набора отображаемых ракурсов, который отличается, по сравнению с группированием сэмплов типа 'mvif' при другом значении grouping_type_parameter. Параметр grouping_type_parameter эквивалентен параметру multiview_group_id предыдущего примера. Запись многоракурсной группы модифицируют таким образом, что становится возможным указание значений grouplD или tierlD, не предназначенных для отображения, или не требующихся для декодирования. Бокс описания группы сэмплов типа 'mvif' может при этом содержать общие и отличительные характеристики указанных ракурсов, а также отношения между ними, с применением, например, бокса атрибутов многоракурсных отношений. В других случаях для указания характеристик многотрековых групп и отношений между ними, вместе с настоящим примером, может быть использован любой из предыдущих примеров.
В различных вариантах осуществления настоящего изобретения указание многотрековой группы используют для связывания друг с другом двух структур формата файлов. Ранее для связывания структур друг с другом использовали трековые ссылки (или указатель на список, включенный в специальный бокс трековых ссылок). Например, в экстракторе файлового формата SVC для идентификации трека, из которого в текущий трек включают данные путем ссылки, применяется указатель на бокс трековых ссылок типа 'seal'. Аналогично, имеются конструкторы для сэмплов треков указаний RTP, которые включают данные путем ссылки из мультимедийных треков с использованием их идентификаторов.
Один из вариантов осуществления изобретения, проиллюстрированный на фиг.16, описан с использованием примера ссылки с помощью многотрековых групп,. На чертеже показан многоракурсный битовый поток и иерархия межракурсных предсказаний в нем. Ракурсы 1 и 2 предсказывают по базовому ракурсу, тогда как ракурс 3 предсказывают по ракурсам 0 и 1, а ракурс 4 предсказывают по ракурсам 0 и 2. Приведено сообщение SEI, одновременно связанное и с ракурсом 1, и с ракурсом 2, например, посредством включения этого сообщения SEI в сообщение SEI MVC с масштабируемой вложенностью.
Когда представленный на фиг.16 битовый поток хранят в файле таким образом, что ракурсы 1 и 2 содержатся в различных треках, возникает вопрос, где хранить блок NAL SEI.
Возможны несколько вариантов хранения блока NAL SEI, среди которых присутствуют по меньшей мере следующие.
Блок NAL SEI может дублироваться и включаться в каждый трек, к которому он применим. Это ведет к росту размера файла. Кроме того, и ракурс 1, и ракурс 2 включены в декодируемый битовый поток, следовательно, может возникнуть неопределенность: каким образом декодеру обрабатывать дубликаты сообщений SEI. Также, кодер порождает битовый поток, включающий только одну копию сообщения SEI, а буферная совместимость этого битового потока была настроена и сигнализирована, соответственно. Следовательно, дубликаты сообщений SEI могут привести к нарушению буферной совместимости потока, создаваемого анализатором файлов.
Блок NAL SEI может быть включен в трек наборов параметров. Треки для ракурсов 1 и 2 могут явно включать (путем ссылки) блок NAL SEI посредством включения экстрактора (или аналогичного элемента) в соответствующие сэмплы треков для ракурсов 1 и 2.
Блок NAL SEI может быть включен в трек наборов параметров. Формат сэмпла для трека наборов параметров может включать список идентификаторов многотрековых групп, к которым применим блок NAL SEI. Альтернативно, формат сэмпла для трека наборов параметров может включать список идентификаторов ракурсов, к которым применим блок NAL SEI. При воспроизведении файла анализатор выбирает для декодирования соответствующую многотрековую группу. Если указано, что блок SEI NAL является действительным для этой многотрековой группы, его включают в блок доступа, восстанавливаемый декодером.
Далее описан еще одни вариант осуществления изобретения, в котором для связывания двух структур формата файлов используют указание многотрековой группы. Время декодирования сэмпла эквивалентно времени удаления из буфера кодированных изображений (coded picture buffer, СРВ) HRD стандартов H.264/AVC, SVC и MVC. Время удаления из СРВ для блока доступа зависит от блоков NAL, имеющихся для него и для предшествующих ему блоков доступа. Следовательно, если извлечено подмножество битового потока, значения времени удаления из СРВ исходного битового потока, скорее всего, будут уже неверными. В соответствии с этим, для каждого подмножества битового потока должен быть обеспечен отдельный набор значений времени удаления из СРВ и, соответственно, времени декодирования для сэмплов. Поскольку связывание сэмплов MVC из различных треков с одним и тем же блоком доступа выполняют по времени декодирования сэмплов, удобно установить значение времени декодирования идентичным для всех сэмплов в одном блоке доступа, при этом оно может не соответствовать времени удаления из СРВ ни одного из подмножеств битового потока (и может быть равно времени удаления из СРВ, применимого к потоку в целом). Может быть определен бокс пересинхронизации многоракурсного декодирования (Multiview Decode Retiming box) с включением идентификатора многоракурсной группы и временного дельта-значения, которое при сложении с временем декодирования сэмпла дает время удаления из СРВ для соответствующего блока доступа, применимое к подмножеству битового потока, определенного упомянутый многоракурсной группой. Альтернативно, может быть определена группа сэмплов пересинхронизации многоракурсного декодирования, аналогично группам пересинхронизации декодирования формата файлов SVC, но связанная с конкретной многоракурсной группой посредством ее идентификатора.
На фиг.17 изображена система 10, в которой могут использоваться различные варианты осуществления настоящего изобретения, она включает множество устройств связи, способных осуществлять связь посредством одной или нескольких сетей. В систему 10 может входить любая комбинация проводных и беспроводных сетей, включая (но не ограничиваясь данным списком) беспроводную локальную сеть (local area network, LAN), персональную сеть Bluetooth, LAN Ethernet, LAN типа «маркерное кольцо», глобальную сеть, Интернет и т.п. Система 10 может включать как проводные так и беспроводные устройства связи.
В качестве примера, система 10 фиг.17 включает сеть 11 мобильной связи и Интернет 28. Соединение с Интернетом 28 может осуществляться посредством (не ограничиваясь приведенном списком) беспроводных соединений с большим радиусом действия, беспроводных соединений с малым радиусом действия, а также различных проводных соединений, включая (но не ограничиваясь данным списком) телефонные линии, кабельные линии, линии электропередачи и т.п.
Примерами устройств связи системы 10 могут служить (не ограничиваясь приведенным списком) электронное устройство 50 мобильной связи в виде мобильного телефона, комбинации карманного персонального компьютера (personal digital assistant, PDA) и мобильного телефона 14, PDA 16, интегрированного устройства 18 обмена сообщениями (integrated messaging device, IMD), настольного компьютера 20, ноутбука 22 и т.п. Устройства связи могут быть как стационарными, так и мобильными, например, они могут переноситься передвигающимися субъектами. Устройства связи могут быть также расположены в транспортных средствах, включая (но не ограничиваясь приведенным списком) автомобиль, грузовик, такси, автобус, поезд, судно, самолет, велосипед, мотоцикл и т.п. Все, или некоторые, устройства связи могут как посылать, так и принимать вызовы и сообщения, а также осуществлять связь с поставщиками услуг посредством беспроводного соединения 25 с базовой станцией 24. Базовая станция 24 способна соединяться с сетевым сервером 26, обеспечивающим связь между средствами 11 связи и Интернетом 28. Система 10 может включать дополнительные устройства связи, а также устройства связи других типов.
Устройства связи могут осуществлять связь с использованием различных технологий передачи данных, включая (но не ограничиваясь приведенными примерами): множественный доступ с кодовым разделением (Code Division Multiple Access, CDMA), глобальную систему мобильной связи (Global System for Mobile Communications, GSM), универсальную систему мобильной связи (Universal Mobile Telecommunication System, UMTS), множественный доступ с разделением по времени (Time Division Multiple Access, TDMA), множественный доступ с разделением по частоте (Frequency Division Multiple Access, FDMA), протокол управления передачей/протокол Интернета (Transmission Control Protocol/Internet Protocol, TCP/IP), службу коротких сообщений (Short Messaging Service, SMS), службу мультимедийных сообщений (Multimedia Messaging Service, MMS), электронную почту, сервис мгновенной передачи сообщений (Instant Messaging Service, IMS), Bluetooth, IEEE 802.11, и др. Устройство связи, задействованное в реализации различных вариантов осуществления настоящего изобретения, способно осуществлять связь с использованием различных каналов связи, включая (не обязательно ограничиваясь данным списком): радио, инфракрасных, лазерных, кабельного соединения и т.п.
На фиг.18 и 19 изображено типовое электронное устройство 28, которое может быть использовано в качестве сетевого узла в соответствии с различными вариантами осуществления настоящего изобретения. Необходимо, тем не менее, понимать, что настоящее изобретение не является ограниченным одним конкретным видом устройства. Электронное устройство 28 на фиг.18 и 19 включает: корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, головной телефон 38, аккумулятор 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде UICC, в соответствии с одним из вариантов осуществления изобретения, картридер 48, электронные цепи радиоинтерфейса 52, электронные цепи кодека 54, контроллер 56 и память 58. Описанные выше компоненты обеспечивают возможность передачи/приема электронным устройством 28 различных сообщений на/от различных устройств, которые могут присутствовать в сети в соответствии с различными вариантами осуществления настоящего изобретения. Все отдельно взятые цепи и элементы широко известны на текущем уровне развития техники и применяются, например, в модельном ряду мобильных телефонов Nokia.
Фиг.20 является графическим представлением типовой мультимедийной системы связи, в которой могут быть реализованы различные варианты осуществления настоящего изобретения. В соответствии с изображением фиг.20, источник данных 100 поставляет исходный сигнал в аналоговом, несжатом цифровом, сжатом цифровом формате, или любой комбинации этих форматов. Кодер 110 кодирует исходный сигнал в кодированный битовый поток мультимедийных данных. Следует отметить, что предназначенный для декодирования битовый поток может приниматься прямо или опосредовано от удаленных устройств сетей практически любых видов. При этом битовый поток может приниматься от локального аппаратного или программного обеспечения. Кодер 110 может кодировать более одного типа мультимедийных данных, например аудиоданные и видеоданные, или же более одного кодера 110 может потребоваться для кодирования различных типов мультимедийных данных исходного сигнала. Кодер 110 может также получать на вход синтезированную информацию, такую, например, как графику или текст, или быть способным порождать кодированный битовый поток синтезированных мультимедийных данных. В дальнейшем, для простоты описания, будет рассматриваться обработка кодированного битового потока только одного типа мультимедийных данных. Тем не менее, следует отметить, что службы вещания реального времени, как правило, содержат несколько потоков (в большинстве случаев, как минимум, по одному аудиопотоку, видеопотоку и текстовому потоку субтитров). Также следует отметить, что система может включать несколько кодеров, однако на фиг.20 для простоты описания продемонстрирован только один кодер 110, что не исключает применимости сказанного к остальным случаям. Необходимо также понимать, что хотя текст и примеры, содержащиеся в настоящем документе, могут описывать именно процесс кодирования, те же самые идеи и принципы применимы для соответствующего процесса декодирования и наоборот, что должно быть очевидно специалистам в данной области.
Кодированный битовый поток мультимедийных данных передается в устройство 120 хранения. Устройство 120 хранения может включать память большой емкости любого типа для хранения кодированного битового потока мультимедийных данных. Формат кодированного битового потока мультимедийных данных в устройстве 120 хранения может быть простым самостоятельным форматом, или же один или несколько кодированных битовых потоков мультимедийных данных могут инкапсулироваться в контейнерный файл. Если один или более мультимедийных битовых потоков инкапсулируют в контейнерный файл, для хранения упомянутых одного или более мультимедийных битовых потоков в упомянутом файле, и для создания метаданных формата файлов, также хранящихся в этом файле, используют генератор файлов (не показан на чертеже). Генератор файлов может входить в состав кодера 110 или хранилища 120, альтернативно, генератор файлов может быть функционально связан или с кодером 110 или с хранилищем 120. Некоторые системы могут функционировать в режиме «на лету», то есть передавать кодированный битовый поток мультимедийных данных передатчику 130, минуя устройство хранения. Затем кодированный мультимедийный битовый поток передают передатчику 130, который, в зависимости от контекста, называют также сервером. Формат битового потока, используемый при передаче, может быть простым самостоятельным форматом, форматом пакетного потока, или же один или несколько кодированных битовых потоков мультимедийных данных могут инкапсулироваться в контейнерный файл. Кодер 110 и передатчик 130 могут оперировать контентом реального времени в режиме «на лету», в этом случае кодированный битовый поток мультимедийных данных обычно не сохраняется на постоянной основе, а буферизуется на короткие промежутки времени в кодере 110 контента и/или в передатчике 130 с целью сгладить отклонения в задержках обработки, передачи, а также в битрейте кодированных мультимедийных данных.
Сервер 130 передает кодированный битовый поток мультимедийных данных с использованием стека протоколов передачи данных. Стек может включать (не обязательно ограничиваясь данным списком): транспортный протокол реального времени (Real-Time Transport Protocol, RTP), протокол пользовательских датаграмм (User Datagram Protocol, UDP), протокол Интернета (Internet Protocol, IP). В случае, если стек протоколов передачи данных пакетно-ориентирован, сервер 130 инкапсулирует кодированный битовый поток мультимедийных данных в пакеты. Например, когда используется RTP, сервер 130 инкапсулирует кодированный битовый поток мультимедийных данных в пакеты RTP в соответствии с форматом полезной нагрузки RTP. Как правило, для каждого типа мультимедийных данных имеется свой выделенный формат полезной нагрузки RTP. Следует еще раз отметить, что система может содержать более одного сервера 130, но для простоты в дальнейшем описании рассматривается случай, когда присутствует только один сервер 130.
Если мультимедийный контент инкапсулирован в контейнерный файл для хранилища 120 или для ввода данных в передатчик 130, передатчик 130 может включать или быть функционально связан с "передающим анализатором файлов" (не показан). В частности, если контейнерный файл как таковой не передают, а по меньшей мере один из содержащихся в нем кодированных мультимедийных потоков инкапсулируют для передачи по транспортному протоколу, передающий анализатор файлов находит соответствующие части кодированного мультимедийного потока, предназначенные для передачи по протоколу связи. Передающий анализатор файлов может быть полезен также при создании корректного формата для протокола связи, например, заголовков пакетов и их полезной нагрузки. Мультимедийный контейнерный файл может содержать инструкции по инкапсуляции, например, треки указаний в базовом формате мультимедийных файлов ISO, для инкапсуляции по меньшей мере одного из содержащихся в нем мультимедийных битовых потоков в протокол связи.
Сервер 130 может быть соединен или не соединен со шлюзом 140 посредством сети связи. Шлюз 140 может выполнять различные функции, такие, как преобразование потока пакетов, соответствующего одному стеку протоколов передачи данных, в другой стек протоколов передачи данных, слияние и разветвление потоков данных, и обработку потоков данных в соответствии с возможностями нисходящей линии связи и/или приемника, такую, например, как управление битрейтом пересылаемого потока в соответствии с преобладающими условиями в сети нисходящей линии связи. Примерами шлюзов 140 могут служить: устройства для реализации многоточечных аудио- и видеоконференций (multipoint conference control units, MCUs), шлюзы между видеотелефонией с коммутацией каналов и коммутацией пакетов, серверы системы «нажми и говори в сотовой сети» (Push-to-talk over Cellular servers, Рос), инкапсуляторы IP в портативных широковещательных системах цифрового видео (digital video broadcasting-handheld, DVB-H), или устройствах (приставках, set-top boxes), перенаправляющих широковещательные передачи локально в домашние беспроводные сети. В случае, когда используется RTP, шлюз 140 называют микшером RTP или транслятором RTP, при этом он выполняет функции конечной точки соединения RTP.
Система содержит один или несколько приемников 150, способных, как правило, к приему, демодуляции и декапсулированию переданного сигнала в кодированный битовый поток мультимедийных данных. Этот кодированный битовый поток мультимедийных данных передается на записывающее устройство 155 хранения. Записывающее устройство 155 хранения может включать любой тип памяти большого объема для хранения кодированного битового потока мультимедийных данных. Вместо этого, или в качестве дополнения, записывающее устройство хранения может включать вычислительную память, например, оперативную память с произвольным доступом. Формат кодированного битового потока мультимедийных данных в записывающем устройстве 155 хранения может быть простым самостоятельным форматом, или же один или несколько кодированных битовых потоков мультимедийных данных могут инкапсулироваться в контейнерный файл. В случае нескольких связанных между собой битовых потоков мультимедийных данных, например видеопотока и аудиопотока, обычно используется контейнерный файл, при этом в состав приемника 150 входит генератор контейнерных файлов (или приемник 150 подключен к нему) для формирования контейнерного файла из входных потоков. Некоторые системы функционируют в режиме «на лету», то есть передают кодированный битовый поток мультимедийных данных непосредственно декодеру 160, минуя записывающее устройство 155 хранения. В некоторых системах, только самая новая часть записываемого потока, например, последний 10-минутный отрывок записываемого потока, содержится в записывающем устройстве 155 хранения, при этом все ранее записанные данные из него удаляют.
Кодированный битовый поток мультимедийных данных из записывающего устройства 155 хранения передается декодеру 160. В случае нескольких связанных между собой битовых потоков мультимедийных данных, например видеопотока и аудиопотока, инкапсулированных при этом в контейнерный файл, для извлечения каждого кодированного битового потока мультимедийных данных из указанного контейнерного файла применяется анализатор файлов (не показан) Анализатор файлов может входить в состав записывающего устройства 155 хранения или декодера 160, или же может быть подключен к любому из этих устройств.
Кодированный битовый поток мультимедийных данных затем, как правило, обрабатывается декодером 160, на выходе которого оказывается один или несколько несжатых мультимедийных потоков. Наконец, рендерер 170 может воспроизводить несжатые мультимедийные потоки, с помощью, например, громкоговорителя или дисплея. Приемник 150, записывающее устройство 155 хранения, декодер 160 и рендерер 170 могут находиться на одном физическом устройстве или могут входить в состав различных устройств.
Генератор файлов в соответствии с различными вариантами осуществления изобретения идентифицирует многотрековые группы в битовых потоках кодированных мультимедийных данных или принимает идентификационную информацию многотрековых групп от кодера 110. Генератор файлов может формировать многотрековые группы на различной основе, например, на основе предназначенных для отображения ракурсов многоракурсного битового видеопотока. Генератор файлов включает информацию о том, какие части кодированных мультимедийных битовых потоков входят в определенную многотрековую группу в файле. Одним из примеров формата для такой информации является бокс многотрековой группы. Генератор файлов может также указывать отношения между многотрековыми группами в файле, например, с применением бокса отношений многотрековых групп. Приемный генератор файлов в соответствии с различными вариантами осуществления изобретения функционирует аналогично описанному выше генератору файлов, с единственным отличием в том, что кодированные мультимедийные битовые потоки он принимает от приемника 150.
Передающий анализатор файлов в соответствии с различными вариантами осуществления изобретения может считывать характеристики многотрековых групп и отношения между ними для определения, какие части файла инкапсулировать для передачи. Также в генераторе файлов может создаваться информация о многотрековых группах для формирования информации об инкапсуляции, предназначенной для передачи по протоколу связи. Подобной информацией об инкапсуляции могут быть, например, инструкции (такие как треки указаний) по формированию пакетов для передачи многоракурсного видеопотока по нескольким сеансам передачи, при этом в каждом сеансе передают один или более ракурсов этого многоракурсного видеопотока.
Передатчик 130 в соответствии с различными вариантами осуществления изобретения может быть сконфигурирован для выбора переданных ракурсов с различными целями, например, в качестве реакции на запросы приемника 150 или преобладающих условий в сети, по которой передают битовый поток. Запрос от приемника может быть, например, запросом на смену отображаемых ракурсов или на изменение отображающего устройства, имеющего отличающиеся, по сравнению с предыдущим, возможности. Передатчик 130 сконфигурирован для выбора передаваемых ракурсов, при этом при выборе передаваемых ракурсов он может использовать передающий анализатор файлов или быть с ним функционально связанным.
Анализатор файлов в соответствии с различными вариантами осуществления изобретения определяет многотрековые группы в файле на основе включенных в файл соответствующих указаний. Анализатор файлов считывает информацию о характеристиках многотрековых групп и отношениях между ними (общие и отличительные атрибуты). На основе этих характеристик и отношений анализатор файлов выбирает многотрековую группу для обработки. Анализатор файлов может, например, выбирать многотрековую группу многоракурсной видеоинформации, имеющую подходящее количество отображаемых ракурсов и внешние параметры камер, соответствующие характеристикам дисплея, используемого для отображения. Обработка, как правило, включает извлечение из файла мультимедийных данных, соответствующих многотрековой группе, потенциальное переформатирование извлеченных мультимедийных данных и передачу переформатированных мультимедийных данных декодеру 160 для декодирования и отображения.
Редактор файлов в соответствии с различными вариантами осуществления изобретения идентифицирует многотрековые группы в файле на основе включенных в файл соответствующих указаний. Редактор файлов считывает информацию о характеристиках многотрековых групп и отношениях между ними (общие и отличительные атрибуты). На основе этих характеристик и отношений анализатор файлов принимает решение, какие многотрековые группы сохраняются в файле и какие удаляются. Редактор файлов может, например, выбирать многотрековую группу многоракурсной видеоинформации, имеющую подходящее количество отображаемых ракурсов для целевого файла. Редактор файлов идентифицирует мультимедийные данные, которые будут удалены из файла и не сохранятся в нем. Затем редактор файлов удаляет эти мультимедийные данные и связанные с ними метаданные из файла. Редактор файлов может также добавлять мультимедийные данные в файл. Если мультимедийные данные связаны с имеющимися в файле другими мультимедийными данными, или многотрековые группы можно сформировать на основе добавленных мультимедийных данных, редактор файлов идентифицирует многотрековые группы по кодированным мультимедийным данным в файле. Редактор файлов включает в файл информацию о том, какие части кодированных мультимедийных потоков следует включить в определенную многотрековую группу. Редактор файлов может также указывать отношения между многотрековыми группами в файле.
Различные варианты настоящего изобретения в настоящем документе описаны в общем контексте шагов и процедур способа, который может быть реализован в одном из вариантов осуществления изобретения с помощью программного продукта на компьютерно-читаемом носителе, включающего машинные команды, такие как, например, программный код, выполняемый компьютерами в сетевой среде. Машиночитаемый носитель может быть выполнен в виде съемного или несъемного запоминающего устройства, включая (в качестве неограничивающих примеров) постоянное запоминающее устройство (Read Only Memory, ROM), оперативное запоминающее устройство (Random Access Memory, RAM), компакт-диски (Compact Discs, CD), цифровые универсальные диски (Digital Versatile Discs, DVD) и т.д. Как правило, программные модули могут включать процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют определенные задачи или представляют определенные типы абстрактных данных. Машинные команды, связанные с ними структуры данных и программные модули служат примерами программного кода для осуществления шагов способа, описанного в настоящем документе. Заданная последовательность подобных исполняемых инструкций или связанных структур данных является примером соответствующих действий по реализации функций, описанных в этих шагах и процедурах.
Варианты осуществления настоящего изобретения могут быть реализованы в виде программного, аппаратного обеспечения или логики приложений, а также в виде комбинации программного обеспечения, аппаратного обеспечения и логики приложений. Программное обеспечение, логика приложений и/или аппаратное обеспечение могут быть размещены, например, на чипсете, мобильном устройстве, настольном или портативном компьютере, или сервере. Программные и сетевые реализации различных вариантов осуществления настоящего изобретения могут быть выполнены с применением стандартных технологий программирования, использующих основанную на правилах или иную логику для выполнения различных шагов или процедур поиска в базе данных, шагов или процедур по сопоставлению, сравнению и принятию решений. Различные варианты осуществления изобретения могут также быть полностью или частично реализованы в сетевых элементах или модулях. Следует отметить, что слова «компонент» и «модуль», при использовании их в настоящем документе и в формуле изобретения, нацелены на охват различных реализации с использованием одной или более строк программного кода и/или аппаратные реализации, и/или оборудования для приема ручного ввода.
Вышеизложенное описание вариантов осуществления настоящего изобретения было приведено с целью иллюстрации и описания. Оно не имеет целью быть исчерпывающим или ограничить варианты осуществления настоящего изобретения точно описанной формой, изменения и модификации могут осуществляться на основании приведенных выше идей или вытекать из практики применения различных вариантов осуществления настоящего изобретения. Варианты осуществления изобретения, выбранные и описанные для разъяснения принципов различных вариантов осуществления настоящего изобретения и их практического применения, предназначены для того, чтобы позволить специалистам использовать настоящее изобретение в различных вариантах его осуществления и с различными модификациями, соответствующими планируемому конкретному применению.
Изобретение относится к области обработки мультимедийных данных реального времени, и в частности, к организации формата мультимедийных файлов. Техническим результатом является обеспечение способа для указания отношений (общих и отличительных черт) группы треков или подмножеств треков с другой группой треков или подмножеств треков. Технический результат достигается тем, что предложен способ обработки многоракурсных мультимедийных данных в множестве треков и/или подмножестве треков, включающий: хранение мультимедийных данных реального времени в множестве треков и/или подмножеств треков; определение одной или более многотрековых групп, при этом каждую многотрековую группу определяют по меньшей мере частично на основе отношений среди одного или более из множества треков и/или подмножеств треков; и формирование по меньшей мере одного множества многотрековых групп по меньшей мере частично на основе сходства характеристик с точки зрения отображения, кодирования или захвата многоракурсных мультимедийных данных. 3 н. и 12 з.п. ф-лы, 21 ил., 1 табл.
1. Способ обработки многоракурсных мультимедийных данных в множестве треков и/или подмножеств треков, включающий:
хранение многоракурсных мультимедийных данных в множестве треков и/или подмножеств треков;
определение одной или более многотрековых групп, при этом каждую многотрековую группу определяют по меньшей мере частично на основе отношений среди одного или более из множества треков и/или подмножеств треков; и
формирование по меньшей мере одного множества многотрековых групп на основании одной или более характеристик многотрековых групп, заданных для многоракурсных мультимедийных данных.
2. Способ по п.1, также включающий: определение по меньшей мере одного отношения между двумя или более многотрековыми группами.
3. Способ по любому из пп.1 и 2, в котором определение одной или более многотрековой группы включает по меньшей мере одно из следующего: определение многотрековой группы на основе по меньшей мере одного подмножества трека, группирование нескольких треков и/или подмножеств треков, соответствующих мультимедийным данным, представляющим различные ракурсы сцены, использование контейнера для передачи данных многотрековой группы для указания отношений между треками и/или подмножествами треков.
4. Способ по п.1 или 2, также включающий: указание по меньшей мере одного отношения между двумя или более множествами многотрековых групп.
5. Способ по п.4, в котором формирование по меньшей мере одного множества многотрековых групп включает по меньшей мере одно из следующего: формирование по меньшей мере одного множества многотрековых групп по меньшей мере частично на основе общих и/или отличительных характеристик, описывающих захват, кодирование и/или отображение многоракурсных мультимедийных данных; формирование по меньшей мере одного множества многотрековых групп с использованием контейнера для передачи данных об отношениях многотрековых групп для указания отношений между многотрековыми группами.
6. Способ по п.5, в котором, когда используют контейнер для передачи данных об отношениях многотрековых групп для указания отношений между многотрековыми группами, один или более критериев используют для указания отношений между многотрековыми группами.
7. Способ по п.6, в котором критерий указывает, что только одна из многотрековых групп должна обрабатываться в один момент времени.
8. Машиночитаемый носитель, содержащий компьютерную программу, включающую машинные команды, которые при исполнении процессором обеспечивают выполнение процессов по любому из пп.1-7.
9. Устройство для обработки многоракурсных мультимедийных данных в множестве треков и/или подмножеств треков, включающее:
память для хранения многоракурсных мультимедийных данных и компьютерного программного кода; и процессор,
при этом память и компьютерный программный код сконфигурированы для обеспечения, при работе с процессором, выполнения устройством по меньшей мере следующего:
хранения многоракурсных мультимедийных данных в множестве треков и/или подмножеств треков;
определения одной или более многотрековой группы, при этом каждую многотрековую группу определяют по меньшей мере частично на основе отношений среди одного или более из множества треков и/или подмножеств треков; и
формирования по меньшей мере одного множества многотрековых групп на основании одной или более характеристик многотрековых групп, заданных для многоракурсных мультимедийных данных.
10. Устройство по п.9, в котором память и компьютерный программный код сконфигурированы для обеспечения, при работе с процессором, выполнения устройством также: определения по меньшей мере одного отношения между двумя или более многотрековыми группами.
11. Устройство по п.9 или 10, в котором память и компьютерный программный код сконфигурированы для обеспечения, при работе с процессором, выполнения устройством, при определении одной или более многотрековых групп, также по меньшей мере следующего: определения многотрековой группы на основе по меньшей мере одного подмножества треков, группирования нескольких треков и/или подмножеств треков, соответствующих мультимедийным данным, представляющим различные ракурсы сцены, и использования контейнера для передачи данных многотрековой группы для указания отношений между треками и/или подмножествами треков.
12. Устройство по п.9 или 10, в котором память и компьютерный программный код сконфигурированы для обеспечения, при работе с процессором, выполнения устройством также: указания по меньшей мере одного отношения между двумя или более множествами многотрековых групп.
13. Устройство по п.12, в котором формирование по меньшей мере одного множества многотрековых групп включает по меньшей мере одно из следующего: формирование по меньшей мере одного множества многотрековых групп по меньшей мере частично на основании общих и/или отличительных характеристик, описывающих захват, кодирование и/или отображение многоракурсных мультимедийных данных; формирование по меньшей мере одного множества многотрековых групп с использованием контейнера для передачи данных об отношениях многотрековых групп для указания отношений между многотрековыми группами.
14. Устройство по п.13, в котором, при использовании контейнера для передачи данных об отношениях многотрековых групп для указания отношений между многотрековыми группами, один или более критериев используется для указания отношений между многотрековыми группами.
15. Устройство по п.14, в котором критерий указывает, что только одна из многотрековых групп должна обрабатываться в один момент времени.
| US 2008052306 A1, 28.02.2008 | |||
| WO 2007081150 A1, 19.07.2007 | |||
| WO 2006104351 A1, 05.10.2006 | |||
| WO 2008130500 A2, 30.10.2008 | |||
| СПОСОБ ЗАПИСИ, ВОСПРОИЗВЕДЕНИЯ ИЛИ СЧИТЫВАНИЯ ЦИФРОВЫХ ИЛИ АНАЛОГОВЫХ, ВЫБОРОЧНЫХ ИЛИ НЕПРЕРЫВНЫХ АУДИО И/ИЛИ ВИДЕОЗАПИСЕЙ | 2000 |
|
RU2226745C2 |
| PETER AMON et al | |||
| File Format for Scalable Video Coding, IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, vol.17, №9, September 2007, abstract | |||
| Y.-K | |||
| WANG and T | |||
| SCHIERL, RTP Payload | |||
