УПАКОВКА КАДРОВ ДЛЯ КОДИРОВАНИЯ ВИДЕО
FRAME PACKING FOR VIDEO CODING

Перекрестная ссылка на родственные заявки
«Spatial Interleaving»
«Пространственное перемежение»
«Communicating Filter Parameters For Frame Packing Applications»
(«Передача параметров фильтра для приложений упаковки кадров»
Эта заявка испрашивает преимущество по каждой из (1) предварительной заявки на выдачу патента США под порядковым № 61/205938, озаглавленной  () и поданной 26 января 2009 года (досье поверенного PU090010), и (2) предварительной заявки на выдачу патента США под порядковым № 61/269955, озаглавленной ) и поданной 1 июля 2009 года (досье поверенного PU090084). Каждая из этих двух заявок в явной форме включена в материалы настоящей заявки посредством ссылки во всей своей полноте для всех целей.
«Tiling In Video Encoding And Decoding»
«Мозаичное размещение при кодировании и декодировании видео»
Эта заявка также родственна международной заявке под № PCT/US2008/004747, озаглавленной  () и имеющей дату международной подачи 11 апреля 2008 года. Эта заявка также идентифицирована в качестве заявки на выдачу патента США под порядковым № 12/450829 (досье поверенного № PU070078).
Область техники
Описаны реализации, которые в целом относятся к областям кодирования и/или декодирования видео.
Уровень техники
С появлением устройств трехмерного (3D) отображения на рынке, в том числе, устройств стереоскопического и автостереоскопического отображения, есть большой спрос на трехмерный контент, который должен быть доступен. Типично, задача исследования состоит в том, чтобы кодировать трехмерный контент, обычно включающий в себя многочисленные проекции и, возможно, также соответствующие карты глубин. Каждый кадр трехмерного контента может требовать, чтобы система обрабатывала огромный объем данных. В типичных применениях трехмерного видео, многопроекционным видеосигналам требуется эффективно передаваться или храниться, например, вследствие ограничений по ширине полосы пропускания, ограничений по памяти и ограничения обработки. Многопроекционное кодирование видео (MVC) расширяет стандарт H.264/усовершенствованного кодирования видео (AVC) с использованием высокоуровневого синтаксиса для содействия кодированию многочисленных проекций. Этот синтаксис помогает в последующей обработке трехмерных изображений процессорами изображений.
H.264/AVC, хотя и разработанный как будто бы для двухмерного видео, также может использоваться для передачи стереоскопического контента посредством применения технологии упаковки кадров. Технология упаковки кадров представлена просто, как изложено ниже: на стороне кодера, две проекции или картинки обычно подвергаются понижающей дискретизации для упаковки в один единственный видеокадр, который затем подается в кодер H.264/AVC для вывода в качестве битового потока; на стороне декодера, битовый поток декодируется, и восстановленный кадр затем распаковывается. Распаковка предоставляет возможность извлечения двух исходных проекций из восстановленного кадра и, обычно, включает в себя операцию повышающей дискретизации для возвращения исходного размера каждой проекции, так что проекции могут воспроизводиться для отображения. Этот подход способен использоваться для двух или более проекций, таких как при многопроекционных изображениях или с информацией о глубине, и тому подобным.
Упаковка кадров может полагаться на существование вспомогательной информации, ассоциативно связанной с кадром и его проекциями. Сообщения дополнительной расширительной информации (SEI) могут использоваться для передачи некоторой информации об упаковке кадров. В качестве примера, в проекте поправки AVC, было предложено, чтобы сообщение SEI использовалось для информирования декодера о различных характеристиках пространственного перемежения упакованной картинки, в том числе, чтобы составляющие картинки формировались посредством шахматного пространственного перемежения. Посредством применения сообщения SEI, можно кодировать подвергнутую шахматному перемежению картинку стереоскопических видеоизображений непосредственно с использованием AVC. Фиг.26 показывает известный пример шахматного перемежения. До настоящего времени, однако, контент сообщения SEI и контент других высокоуровневых синтаксисов был ограничен передачей информации, релевантной для картинок или проекций, которые были подвергнуты упаковке кадра.
Сущность изобретения
Согласно общему аспекту, кодируется видеокартинка, которая включает в себя многочисленные картинки, объединенные в единую картинку. Генерируется информация, указывающая, каким образом объединены многочисленные картинки в подвергнутой доступу видеокартинке. Сгенерированная информация включает в себя информацию о пространственном перемежении и информацию о дискретизации. Информация о пространственном перемежении указывает пространственное перемежение, примененное к многочисленным картинкам при формировании единой картинки. Информация о дискретизации указывает один или более параметров, относящихся к фильтру повышающей дискретизации для восстановления каждой из многочисленных картинок в требуемое разрешение. Один или более параметров, относящихся к фильтру повышающей дискретизации, включают в себя указание направления фильтрации. Формируется битовый поток, который включает в себя кодированную видеокартинку и сгенерированную информацию. Сгенерированная информация предоставляет информацию для использования при обработке кодированной видеокартинки.
Согласно еще одному общему аспекту, структура видеосигнала или видео включает в себя секцию кодированной картинки и секцию сигнализации. Секция кодированной картинки включает в себя кодирование видеокартинки, видеокартинка включает в себя многочисленные картинки, объединенные в единую картинку. Секция сигнализации включает в себя кодирование сгенерированной информации, указывающей, каким образом объединены многочисленные картинки в подвергнутой доступу видеокартинке. Сгенерированная информация включает в себя информацию о пространственном перемежении и информацию о дискретизации. Информация о пространственном перемежении указывает пространственное перемежение, примененное к многочисленным картинкам при формировании единой картинки. Информация о дискретизации указывает один или более параметров, относящихся к фильтру повышающей дискретизации для восстановления каждой из многочисленных картинок в требуемое разрешение. Один или более параметров, относящихся к фильтру повышающей дискретизации, включают в себя указание направления фильтрации. Сгенерированная информация предоставляет информацию для использования при декодировании кодированной видеокартинки.
Согласно еще одному общему аспекту, подвергается доступу видеокартинка, которая включает в себя многочисленные картинки, объединенные в единую картинку, видеокартинка является частью принятого видеопотока. Подвергается доступу информация, которая является частью принятого видеопотока, подвергнутая доступу информация указывает, каким образом объединены многочисленные картинки в подвергнутой доступу видеокартинке. Подвергнутая доступу информация включает в себя информацию о пространственном перемежении и информацию о дискретизации. Информация о пространственном перемежении указывает пространственное перемежение, примененное к многочисленным картинкам при формировании единой картинки. Информация о дискретизации указывает один или более параметров, относящихся к фильтру повышающей дискретизации для восстановления каждой из многочисленных картинок в требуемое разрешение. Один или более параметров, относящихся к фильтру повышающей дискретизации, включают в себя указание направления фильтрации. Видеокартинка декодируется для предоставления декодированного представления по меньшей мере одной из многочисленных картинок.
Подробности одной или более реализаций изложены на прилагаемых чертежах и в описании, приведенном ниже. Даже если описаны одним конкретным образом, должно быть ясно, что реализации могут быть сконфигурированы или воплощены различными способами. Например, реализация может быть выполнена в качестве способа или воплощена в качестве устройства, сконфигурированного для выполнения набора операций, либо воплощена в качестве устройства, хранящего команды для выполнения набора операций, или воплощена в сигнале. Другие аспекты и признаки станут очевидными из последующего подробного описания, рассмотренного совместно с прилагаемыми чертежами и формулой изобретения.
Краткое описание чертежей
Фиг.1 - схема, показывающая пример четырех проекций, подвергнутых мозаичному размещению в едином кадре.
Фиг.2 - схема, показывающая пример четырех проекций, транспонированных и подвергнутых мозаичному размещению в едином кадре.
Фиг.3 показывает структурную схему для реализации видеокодера, к которому могут быть применены настоящие принципы.
Фиг.4 показывает структурную схему для реализации видеодекодера, к которому могут быть применены настоящие принципы.
Фиг.5 - схема последовательности операций для реализации способа для кодирования картинок для множества проекций с использованием стандарта AVC MPEG-4.
Фиг.6 - схема последовательности операций для реализации способа для декодирования картинок для множества проекций с использованием стандарта AVC MPEG-4.
Фиг.7 - схема последовательности операций для реализации способа для кодирования картинок для множества проекций и глубин с использованием стандарта AVC MPEG-4.
Фиг.8 - схема последовательности операций для реализации способа для декодирования картинок для множества проекций и глубин с использованием стандарта AVC MPEG-4.
Фиг.9 - схема, показывающая пример сигнала глубины.
Фиг.10 - схема, показывающая пример сигнала глубины, добавленного в качестве мозаики.
Фиг.11 - схема, показывающая пример 5 проекций, подвергнутых мозаичному размещению в едином кадре.
Фиг.12 - структурная схема для примерного кодера многопроекционного кодирования видео (MVC), к которому могут быть применены настоящие принципы.
Фиг.13 - структурная схема для примерного кодера многопроекционного кодирования видео (MVC), к которому могут быть применены настоящие принципы.
Фиг.14 - схема последовательности операций для реализации способа для обработки картинок для множества проекций при подготовке к кодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.15 - схема последовательности операций для реализации способа для кодирования картинок для множества проекций с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.16 - схема последовательности операций для реализации способа для обработки картинок для множества проекций при подготовке к декодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.17 - схема последовательности операций для реализации способа для декодирования картинок для множества проекций с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.18 - схема последовательности операций для реализации способа для обработки картинок для множества проекций и глубин при подготовке к кодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.19 - схема последовательности операций для реализации способа для кодирования картинок для множества проекций и глубин с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.20 - схема последовательности операций для реализации способа для обработки картинок для множества проекций и глубин при подготовке к декодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.21 - схема последовательности операций для реализации способа для декодирования картинок для множества проекций и глубин с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4.
Фиг.22 - схема, показывающая примеры мозаичного размещения на уровне пикселей.
Фиг.23 показывает структурную схему для реализации устройства обработки видео, к которому могут быть применены настоящие принципы.
Фиг.24 показывает упрощенную схему для примерной трехмерной видеосистемы.
Фиг.25 показывают примерные левую и правую карты глубин для изображения из разных опорных проекций.
Фиг.26 показывает примерную структурную схему для пространственного перемежения двух составляющих картинок в единую картинку или кадр с использованием шахматного перемежения.
Фиг.27 показывает примерную картинку поперечного пространственного перемежения двух составляющих картинок.
Фиг.28 показывает примерную картинку верхне-нижнего пространственного перемежения двух составляющих картинок.
Фиг.29 показывает примерную картинку построчного пространственного перемежения двух составляющих картинок.
Фиг.30 показывает примерную картинку постолбцового пространственного перемежения двух составляющих картинок.
Фиг.31 показывает примерную картинку поперечного пространственного перемежения двух составляющих картинок, в котором правая картинка транспонирована горизонтально.
Фиг.32 показывает примерную картинку верхне-нижнего пространственного перемежения двух составляющих картинок, в котором нижняя картинка транспонирована вертикально.
Фиг.33 показывает примерную перемеженную картинку или кадр, в котором составляющие картинки представляют формат видео с многослойной глубиной (LDV).
Фиг.34 показывает примерную перемеженную картинку или кадр, в котором составляющие картинки представляют формат в двух измерениях плюс глубина.
Фиг.35-38 показывают примерные блок-схемы последовательностей операций разных вариантов осуществления для обработки кодирования и декодирования видеоизображений с использованием сообщений SEI для информации об упаковке пакетов.
Фиг.39 показывает примерную систему передачи видео, к которой могут быть применены настоящие принципы.
Фиг.40 показывает примерную систему приема видео, к которой могут быть применены настоящие принципы.
Фиг.41 показывает примерное устройство обработки видео, к которому могут быть применены настоящие принципы.
Примерные варианты осуществления, изложенные в материалах настоящей заявки, иллюстрируют различные варианты осуществления, и такие примерные варианты осуществления не должны истолковываться в качестве ограничивающих объем этого раскрытия никоим образом.
Подробное описание
Различные реализации направлены на способы и устройство для мозаичного размещения проекций при кодировании и декодировании видео. Таким образом, должно быть принято во внимание, что специалисты в данной области техники будут способны разработать различные компоновки, которые, хотя и не описаны и не показаны в материалах настоящей заявки явным образом, воплощают настоящие принципы и включены в пределы ее сущности и объема.
Все примеры и условные формулировки, изложенные в материалах настоящей заявки, предназначены для образовательных целей, чтобы помочь читателю в понимании представленных принципов и концепций, внесенных изобретателем(ями) в развитие данной области техники, и должны истолковываться в качестве существующих без ограничения такими конкретно изложенными примерами и условиями.
Более того, все выражения в материалах настоящей заявки, излагающие принципы, аспекты и варианты осуществления настоящих принципов, а также их специфичные примеры, предназначены для охвата как конструктивных, так и функциональных их эквивалентов. Дополнительно, подразумевается, что такие эквиваленты включают в себя известные в настоящее время эквиваленты, а также эквиваленты, разработанные в будущем, то есть, любые разработанные элементы, которые выполняют идентичную функцию, независимо от конструкции.
Таким образом, например, специалистами в данной области техники должно приниматься во внимание, что структурные схемы, представленные в материалах настоящей заявки, изображают концептуальные представления иллюстративных компонентов и/или компоновки схем системы. Подобным образом, должно приниматься во внимание, что любые блок-схемы последовательностей операций, схемы последовательностей операций, диаграммы переходов, псевдокод, и тому подобное, изображают различные последовательности операций, которые, по существу, могут быть представлены на машиночитаемых носителях и, значит, выполняться компьютером или процессором, показан или нет такой компьютер или процессор явным образом.
Функции различных элементов, показанных на фигурах, могут обеспечиваться благодаря использованию специализированных аппаратных средств, а также аппаратных средств, допускающих выполнение программного обеспечения при ассоциативной связи с надлежащим программным обеспечением. При обеспечении процессором, функции могут обеспечиваться одиночным выделенным процессором, одиночным совместно используемым процессором или множеством отдельных процессоров, некоторые из которых могут совместно использоваться. Более того, явное использование термина «процессор» или «контроллер» не должно толковаться указывающим исключительно на аппаратные средства, допускающие выполнение программного обеспечения, и может неявно включать в себя, без ограничения, аппаратные средства цифрового сигнального процессора («ЦСП», «DSP»), постоянное запоминающее устройство («ПЗУ», «ROM») для хранения программного обеспечения, оперативное запоминающее устройство («ОЗУ», «RAM») и энергонезависимую память.
Другие аппаратные средства, стандартные и/или специализированные, также могут быть включены в осуществление различных реализаций. Например, любые переключатели, показанные на фигурах, являются всего лишь абстрактными. Их функция может выполняться благодаря работе программной логики, благодаря специализированной логике, благодаря взаимодействию программного управления и специализированной логики, или даже вручную, конкретная технология является выбираемой конструктором в качестве более точно понятной из контекста.
В формуле изобретения из этого документа, любой элемент, выраженный в качестве средства для выполнения предписанной функции, предназначен для охвата любого способа выполнения такой функции, в том числе, например, а) комбинации элементов схемы, которые выполняют такую функцию, или b) программного обеспечения в любой форме, поэтому включающего в себя аппаратно реализованное программное обеспечение, микрокод или тому подобное, объединенные с надлежащей схемой для выполнения такого программного обеспечения, чтобы выполнять функцию. Настоящим принципам, как определено такой формулой изобретения, свойственно то обстоятельство, что функциональные возможности, предусмотренные различными перечисленными средствами, комбинируются и сведены вместе таким образом, к которому обязывает формула изобретения. Соответственно, считается, что любые средства, которые могут обеспечивать такие функциональные возможности, эквивалентны показанным в материалах настоящей заявки.
Ссылка в описании изобретения на «один из вариантов осуществления» (либо «одну из реализаций») или «вариант осуществления» (либо «реализацию») настоящих принципов означает, что конкретный признак, конструкция, характеристика и так далее, описанные в связи с вариантом осуществления, включены в по меньшей мере один вариант осуществления настоящих принципов. Таким образом, появление фразы «в одном из вариантов осуществления» или «в варианте осуществления», фигурирующей в различных местах по всему описанию изобретения, не обязательно является всецело указывающим на один и тот же вариант осуществления.
Должно быть принято во внимание, что, несмотря на то, что один или более вариантов осуществления представленных принципов описаны в материалах настоящей заявки относительно стандарта AVC MPEG-4, принципы, описанные в этой заявке, не ограничены только этим стандартом, и, соответственно, могут использоваться по отношению к другим стандартам, рекомендациям и их расширениям, более точно, стандартам, рекомендациям кодирования видео и их расширениям, в том числе, расширениям стандарта AVC MPEG-4, наряду с сохранением сущности принципов этой заявки.
Кроме того, должно быть принято во внимание, что, несмотря на то, что один или более других вариантов осуществления описаны в материалах настоящей заявки относительно расширения многопроекционного кодирования видео стандарта AVC MPEG-4, настоящие принципы не ограничены только этим расширением и/или этим стандартом и, таким образом, могут использоваться по отношению к другим стандартам, рекомендациям кодирования видео и их расширениям, относящимся к многопроекционному кодированию видео, наряду с сохранением сущности принципов этой заявки. Многопроекционное кодирование видео (MVC) является инфраструктурой сжатия для кодирования многопроекционных последовательностей. Последовательность многопроекционного кодирования видео (MVC) является набором из двух или более видеопоследовательностей, которые фиксируют одну и ту же сцену с разных точек обзора.
К тому же, должно быть принято во внимание, что, несмотря на то, что в материалах настоящей заявки описаны один или более других вариантов осуществления, которые используют информацию о глубине по отношению к видеоконтенту, принципы этой заявки не ограничены такими вариантами осуществления и, таким образом, могут быть реализованы другие варианты осуществления, которые не используют информацию о глубине, наряду с сохранением сущности настоящих принципов.
Дополнительно, используемый в материалах настоящей заявки термин «высокоуровневый синтаксис» указывает на синтаксис, присутствующий в битовом потоке, который находится иерархически выше уровня макроблоков. Например, термин высокоуровневый синтаксис, используемый в материалах настоящей заявки, может указывать, но не в качестве ограничения, на синтаксис на уровне заголовка секции, уровне дополнительной расширительной информации (SEI), уровне набора параметров картинки (PPS), уровне набора параметров последовательности (SPS), набора параметров проекции (VPS) и уровне заголовка блока сетевого уровня абстракции (NAL).
В текущей реализации многопроекционного кодирования видео (MVC), основанной на стандарте усовершенствованного кодирования видео (AVC) части 10 стандарта 4 Экспертной группы по движущемуся изображению (MPEG-4) Международной организации по стандартизации/Международной электротехнической комиссии (ISO/IEC)/рекомендациях H.264 Международного союза электросвязи, сектора телекоммуникаций (ITU-T) (в дальнейшем, «стандарт AVC MPEG4/H.264»), справочное программное обеспечение добивается многопроекционного предсказания, кодируя каждую проекцию одиночным кодером и принимая во внимание межпроекционные ссылки. Каждая проекция кодируется в качестве отдельного битового потока кодером при своем исходном разрешении, а позже, все битовые потоки объединяются, чтобы сформировать одиночный битовый поток, который затем декодируется. Каждая проекция создает отдельный декодированный выходной сигнал YUV.
Примерная видеосистема, поддерживающая выработку и использование трехмерных изображений, схематически представлена на фиг.24. Сторона выработки контента системы показывает фиксацию изображения различными средствами, в том числе, но не в качестве ограничения, стереокамерами, камерами глубины, многочисленными камерами, работающими одновременно, и преобразование двухмерных изображений в трехмерные изображения. Пример информации о карте глубин (например, Z-информации), зафиксированной для левой и правой проекций одной и той же сцены, показан на фиг.25. Каждый из этих подходов не только фиксирует контент видеоизображения, но некоторые также генерируют определенную информацию о глубине, ассоциативно связанную с записанными видеоизображениями. После обработки и кодирования, вся эта информация доступна для того, чтобы распространяться, передаваться и, в конечном счете, визуализироваться. Метаданные также генерируются с видеоконтентом для использования при последующей визуализации трехмерного видео. Визуализация может происходить с использованием двухмерных систем отображения или трехмерных устройств отображения. Трехмерные устройства отображения могут варьироваться от стереоскопических устройств отображения до много проекционных трехмерных устройств отображения, как показано на фигуре.
Еще один подход для многопроекционного предсказания включает в себя группировку набора проекций в псевдопроекции. В одном из примеров этого подхода, мы можем мозаично размещать картинки из каждых N проекций из суммарных M проекций (подвергнутых одновременной выборке) в большем кадре или суперкадре с возможной понижающей дискретизацией или другими операциями. Обращаясь к фиг.1, пример четырех проекций, мозаично размещенных в едином кадре, в целом указан номером 100 ссылки. Верхние четыре проекции находятся в своей нормальной ориентации.
Обращаясь к фиг.2, пример четырех проекций, транспонированных и мозаично размещенных в едином кадре, в целом указан номером 200 ссылки. Верхняя левая проекция находится в своей нормальной ориентации. Верхняя правая проекция транспонирована горизонтально. Нижняя левая проекция транспонирована вертикально. Нижняя правая проекция транспонирована как горизонтально, так и вертикально. Таким образом, если есть четыре проекции, то картинка из каждой проекции компонуется в суперкадре подобно мозаике. Это дает в результате единую некодированную входную последовательность с большим разрешением.
В качестве альтернативы, мы можем осуществлять понижающую дискретизацию изображения для создания меньшего разрешения. Таким образом, мы создаем многочисленные последовательности, каждая из которых включает в себя разные проекции, которые мозаично размещаются вместе. Каждая такая последовательность, в таком случае, формирует псевдопроекцию, где каждая псевдопроекция включает в себя N разных мозаичных проекций. Фиг.1 показывает одну псевдопроекцию, а фиг.2 показывает еще одну псевдопроекцию. Эти псевдопроекции затем могут кодироваться с использованием существующих стандартов кодирования видео, таких как стандарт MPEG-2 ISO/IEC и стандарт AVC MPEG-4.
Еще один другой подход к многопроекционному кодированию просто включает в себя независимое кодирование разных проекций с использованием нового стандарта, и, после декодирования, мозаичное размещение проекций, как требуется проигрывателем.
Кроме того, в еще одном подходе, проекции также могут подвергаться мозаичному размещению попиксельным образом. Например, в суперпроекции, которая состоит из четырех проекций, пиксель (x, y) может быть из проекции 0, наряду с тем, что пиксель (x+1, y) может быть из проекции 1, пиксель (x, y+1) может быть из проекции 2, а пиксель (x+1, y+1) может быть из проекции 3.
Многие производители устройств отображения используют такую инфраструктуру компоновки или мозаичного размещения разных проекций в едином кадре, а затем извлечения из их соответственных местоположений и визуализации их. В таких случаях, нет стандартного способа, чтобы определять, имеет ли битовый поток такое свойство. Таким образом, если система использует способ мозаичного размещения картинок разных проекций в большом кадре, то способ извлечения разных проекций является специализированным.
Однако, нет стандартного способа, чтобы определять, имеет ли битовый поток такое свойство. Мы предлагаем высокоуровневый синтаксис, для того чтобы облегчать визуализатору или проигрывателю извлечение такой информации, для того чтобы содействовать в отображении или другой постобработке. Также возможно, субкартинки имеют разные разрешения, и некоторая повышающая дискретизация может быть необходима, чтобы визуализировать проекцию в конечном счете. Пользователь также может пожелать иметь способ повышающей дискретизации, указанной в высокоуровневом синтаксисе. Дополнительно, также могут передаваться параметры для изменения фокуса глубины.
В варианте осуществления, мы предлагаем новое сообщение дополнительной расширительной информации (SEI) для сигнализации информации о многих проекциях в совместимом со стандартом AVC MPEG-4 потоке, где каждая картинка включает в себя субкартинки, которые принадлежат к разным проекциям. Вариант осуществления, например, предназначен для легкого и удобного отображения многопроекционных видеопотоков на трехмерных (3D) мониторах, которые могут использовать такую инфраструктуру. Концепция может быть распространена на другие стандарты и рекомендации кодирования видео, сигнализирующие такую информацию с использованием высокоуровневого синтаксиса.
Более того, в варианте осуществления, мы предлагаем способ сигнализации того, каким образом следует компоновать проекции перед тем, как они отправлены в многопроекционный видеокодер и/или декодер. Преимущественно, вариант осуществления может приводить к упрощенной реализации многопроекционного кодирования и может давать выгоду в эффективности кодирования. Определенные проекции могут быть собраны вместе и формировать псевдопроекцию или суперпроекцию, а затем, подвергнутая мозаичному размещению суперпроекция обрабатывается как нормальная проекция обычным многопроекционным видекодером и/или декодером, например, согласно основанной на текущем стандарте AVC MPEG-4 реализации многопроекционного кодирования видео. Новый флаг, показанный в таблице 1, предложен в расширении набора параметров последовательности (SPS) многопроекционного кодирования видео, чтобы сигнализировать об использовании технологии псевдопроекций. Вариант осуществления предназначен для легкого и удобного отображения многопроекционных видеопотоков на трехмерных мониторах, которые могут использовать такую инфраструктуру.
Еще один подход к многопроекционному кодированию включает в себя мозаичное размещение картинок из каждой проекции (подвергнутых одновременной выборке) в большем кадре или суперкадре с возможной операцией понижающей дискретизации. Обращаясь к фиг.1, пример четырех проекций, мозаично размещенных в едином кадре, в целом указан номером 100 ссылки. Обращаясь к фиг.2, пример четырех проекций, транспонированных и мозаично размещенных в едином кадре, в целом указан номером 200 ссылки. Таким образом, если есть четыре проекции, то картинка из каждой проекции компонуется в суперкадре подобно мозаике. Это дает в результате единую некодированную входную последовательность с большим разрешением. Этот сигнал затем может кодироваться с использованием существующих стандартов кодирования видео, таких как стандарт MPEG-2 ISO/IEC и стандарт AVC MPEG-4.
Обращаясь к фиг.3, видеокодер, способный к выполнению кодирования видео в соответствии со стандартом AVC MPEG-4, в целом указан номером 300 ссылки.
Видеокодер 300 включает в себя буфер 310 упорядочения кадров, имеющий выход в сигнальной связи с неинвертирующим входом объединителя 385. Выход объединителя 385 соединен по сигнальной связи с первым входом преобразователя и квантователя 325. Выход преобразователя и квантователя 325 соединен по сигнальной связи с первым входом энтропийного кодера 345 и первым входом обратного преобразователя и обратного квантователя 350. Выход энтропийного кодера 345 соединен по сигнальной связи с первым неинвертирующим входом объединителя 390. Выход объединителя 390 соединен по сигнальной связи с первым входом выходного буфера 335.
Первый выход контроллера 305 кодера присоединен по сигнальной связи ко второму входу буфера 310 упорядочения кадров, второму входу обратного преобразователя и обратного квантователя 350, входу модуля 315 принятия решения о типе картинки, входу модуля 320 принятия решения о типе макроблока (типа MB), второму входу модуля 360 внутреннего предсказания, второму входу деблокинг-фильтра 365, первому входу компенсатора 370 движения, первому входу блока 375 оценки движения и второму входу буфера 380 опорных картинок.
Второй выход контроллера 305 кодера соединен по сигнальной связи с первым входом блока 330 вставки дополнительной расширительной информации (SEI), вторым входом преобразователя и квантователя 325, вторым входом энтропийного кодера 345, вторым входом выходного буфера 335 и входом блока 340 вставки набора параметров последовательности (SPS) и набора параметров картинки (PPS).
Первый выход модуля 315 принятия решения о типе картинки соединен по сигнальной связи с третьим входом буфера 310 упорядочения кадров. Второй выход модуля 315 принятия решения о типе картинки соединен по сигнальной связи со вторым входом модуля 320 принятия решения о типе макроблока.
Выход блока 340 вставки набора параметров последовательности (SPS) и набора параметров картинки (PPS) соединен по сигнальной связи с третьим неинвертирующим входом объединителя 390. Выход блока 330 вставки SEI соединен по сигнальной связи со вторым неинвертирующим входом объединителя 390.
Выход обратного квантователя и обратного преобразователя 350 соединен по сигнальной связи с первым неинвертирующим входом объединителя 319. Выход объединителя 319 соединен по сигнальной связи с первым входом модуля 360 внутреннего предсказания и первым входом деблокинг-фильтра 365. Выход деблокинг-фильтра 365 соединен по сигнальной связи с первым входом буфера 380 опорных картинок. Выход буфера 380 опорных картинок соединен по сигнальной связи со вторым входом блока 375 оценки движения и с первым входом блока 370 компенсатора движения. Первый выход блока 375 оценки движения соединен по сигнальной связи со вторым входом компенсатора 370 движения. Второй выход блока 375 оценки движения соединен по сигнальной связи с третьим входом энтропийного кодера 345.
Выход компенсатора 370 движения соединен по сигнальной связи с первым входом переключателя 397. Выход модуля 360 внутреннего предсказания соединен по сигнальной связи со вторым входом переключателя 397. Выход модуля 320 принятия решения о типе макроблока соединен по сигнальной связи с третьим входом переключателя 397, для того чтобы предоставлять управляющий входной сигнал на переключатель 397. Третий вход переключателя 397 определяет, должен или нет входной сигнал «данные» переключателя (по сравнению с управляющим входным сигналом, то есть, третьим входом) предоставляться компенсатором 370 движения или модулем 360 внутреннего предсказания. Выход переключателя 397 соединен по сигнальной связи со вторым неинвертирующим входом объединителя 319 и с инвертирующим входом объединителя 385.
Входы буфера 310 упорядочения кадров и контроллера 105 кодера доступны в качестве входа кодера 300, для приема входной картинки 301. Более того, вход блока 330 вставки дополнительной расширительной информации (SEI) доступен в качестве входа кодера 300, для приема метаданных. Выход выходного буфера 335 доступен в качестве выхода кодера 300 для вывода битового потока.
Обращаясь к фиг.4, видеодекодер, способный к выполнению декодирования видео в соответствии со стандартом AVC MPEG-4, в целом указан номером 400 ссылки.
Видеодекодер 400 включает в себя входной буфер 410, имеющий выход, соединенный по сигнальной связи с первым входом энтропийного декодера 445. Первый выход энтропийного декодера 445 соединен по сигнальной связи с первым входом обратного преобразователя и обратного квантователя 450. Выход обратного преобразователя и обратного квантователя 450 соединен по сигнальной связи со вторым неинвертирующим входом объединителя 425. Выход объединителя 425 соединен по сигнальной связи со вторым входом деблокинг-фильтра 465 и первым входом модуля 460 внутреннего предсказания. Второй выход деблокинг-фильтра 465 соединен по сигнальной связи с первым входом буфера 480 опорных картинок. Выход буфера 480 опорных картинок соединен по сигнальной связи со вторым входом компенсатора 470 движения.
Второй выход энтропийного декодера 445 соединен по сигнальной связи с третьим входом компенсатора 470 движения и первым входом деблокинг-фильтра 465. Третий выход энтропийного декодера 445 соединен по сигнальной связи с входом контроллера 405 декодера. Первый выход контроллера 405 декодера соединен по сигнальной связи со вторым входом энтропийного декодера 445. Второй выход контроллера 405 декодера соединен по сигнальной связи со вторым входом обратного преобразователя и обратного квантователя 450. Третий выход контроллера 405 декодера соединен по сигнальной связи с третьим входом деблокинг-фильтра 465. Четвертый выход контроллера 405 декодера соединен по сигнальной связи со вторым входом модуля 460 внутреннего предсказания, с первым входом компенсатора 470 движения и со вторым входом буфера 480 опорных картинок.
Выход компенсатора 470 движения соединен по сигнальной связи с первым входом переключателя 497. Выход модуля 460 внутреннего предсказания соединен по сигнальной связи со вторым входом переключателя 497. Выход переключателя 497 соединен по сигнальной связи с первым неинвертирующим входом объединителя 425.
Вход входного буфера 410 доступен в качестве входа декодера 400, для приема входного битового потока. Первый выход деблокинг-фильтра 465 доступен в качестве выхода декодера 400, для вывода выходной картинки.
Обращаясь к фиг.5, примерный способ для кодирования картинок для множества проекций с использованием стандарта AVC MPEG-4 в целом указан номером 500 ссылки.
Способ 500 включает в себя начальный этап 502, который передает управление на функциональный этап 504. Функциональный этап 504 компонует каждую проекцию в конкретный момент времени в качестве субкартинки в мозаичном формате и передает управление на функциональный этап 506. Функциональный этап 506 устанавливает элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 508. Функциональный этап 508 устанавливает элементы org_pic_width_in_mbs_minus1 и org_pic_height_in_mbs_minus1 синтаксиса и передает управление на функциональный этап 510. Функциональный этап 510 устанавливает переменную i равной нулю и передает управление на этап 512 принятия решения. Этап 512 принятия решения определяет, является или нет переменная i меньшей, чем количество проекций. Если так, то управление передается на функциональный этап 514. Иначе, управление передается на функциональный этап 524.
Функциональный этап 514 устанавливает элемент view_id[i] синтаксиса и передает управление на функциональный этап 516. Функциональный этап 516 устанавливает элемент num_parts[view_id[i]] синтаксиса и передает управление на функциональный этап 518. Функциональный этап 518 устанавливает переменную j равной нулю и передает управление на этап 520 принятия решения. Этап 520 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 522. Иначе, управление передается на функциональный этап 528.
Функциональный этап 522 устанавливает следующие элементы синтаксиса, инкрементирует переменную j, а затем, возвращает управление на этап 520 принятия решения: depth_flag[view_id[i]][j]; flip_dir[view_id[i]][j]; loc_left_offset[view_id[i]][j]; loc_top_offset[view_id[i]][j]; frame_crop_left_offset[view_id[i]][j]; frame_crop_right_offset[view_id[i]][j]; frame_crop_top_offset[view_id[i]][j]; и frame_crop_bottom_offset[view_id[i]][j].
Функциональный этап 528 устанавливает элемент upsample_view_flag[view_id[i]] синтаксиса и передает управление на этап 530 принятия решения. Этап 530 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 532. Иначе, управление передается на этап 534 принятия решения.
Функциональный этап 532 устанавливает элемент upsample_filter[view_id[i]] синтаксиса и передает управление на этап 534 принятия решения.
Этап 534 принятия решения определяет, является или нет текущее значение элемента upsample_filter[view_id[i]] синтаксиса равным трем. Если так, то управление передается на функциональный этап 536. Иначе, управление передается на функциональный этап 540.
Функциональный этап 536 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 538: vert_dim[view_id[i]]; hor_dim[view_id[i]]; и quantizer[view_id[i]].
Функциональный этап 538 устанавливает коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 540.
Функциональный этап 540 инкрементирует переменную i и возвращает управление на этап 512 принятия решения.
Функциональный этап 524 записывает эти элементы синтаксиса в по меньшей мере одно из набора параметров последовательности (SPS), набора параметров картинки (PPS), сообщения дополнительной расширительной информации (SEI), заголовка блока сетевого уровня абстракции (NAL) и заголовка секции, и передает управление на функциональный этап 526. Функциональный этап 526 кодирует каждую картинку с использованием кодека стандарта AVC MPEG-4 или другого кодека с одиночной проекцией и передает управление на конечный этап 599.
Обращаясь к фиг.6, примерный способ для декодирования картинок для множества проекций с использованием стандарта AVC MPEG-4 в целом указан номером 600 ссылки.
Способ 600 включает в себя начальный этап 602, который передает управление на функциональный этап 604. Функциональный этап 604 синтаксически анализирует элементы синтаксиса в по меньшей мере одном из набора параметров последовательности (SPS), набора параметров картинки (PPS), сообщения дополнительной расширительной информации (SEI), заголовка блока сетевого уровня абстракции (NAL) и заголовка секции, и передает управление на функциональный этап 606. Функциональный этап 606 синтаксически анализирует элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 608. Функциональный этап 608 синтаксически анализирует элементы org_pic_width_in_mbs_minus1 и org_pic_height_in_mbs_minus1 синтаксиса и передает управление на функциональный этап 610. Функциональный этап 610 устанавливает переменную i равной нулю и передает управление на этап 612 принятия решения. Этап 612 принятия решения определяет, является или нет переменная i меньшей, чем количество проекций. Если так, то управление передается на функциональный этап 614. Иначе, управление передается на функциональный этап 624.
Функциональный этап 614 синтаксически анализирует элемент view_id[i] синтаксиса и передает управление на функциональный этап 616. Функциональный этап 616 синтаксически анализирует элемент num_parts_minus1[view_id[i]] синтаксиса и передает управление на функциональный этап 618. Функциональный этап 618 устанавливает переменную j равной нулю и передает управление на этап 620 принятия решения. Этап 620 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 622. Иначе, управление передается на функциональный этап 628.
Функциональный этап 622 синтаксически анализирует следующие элементы синтаксиса, инкрементирует переменную j, а затем, возвращает управление на этап 620 принятия решения: depth_flag[view_id[i]][j]; flip_dir[view_id[i]][j]; loc_left_offset[view_id[i]][j]; loc_top_offset[view_id[i]][j]; frame_crop_left_offset[view_id[i]][j]; frame_crop_right_offset[view_id[i]][j]; frame_crop_top_offset[view_id[i]][j]; и frame_crop_bottom_offset[view_id[i]][j].
Функциональный этап 628 синтаксически анализирует элемент upsample_view_flag[view_id[i]] синтаксиса и передает управление на этап 630 принятия решения. Этап 630 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 632. Иначе, управление передается на этап 634 принятия решения.
Функциональный этап 632 синтаксически анализирует элемент upsample_filter[view_id[i]] синтаксиса и передает управление на функциональный этап 634.
Этап 634 принятия решения определяет, является или нет текущее значение элемента upsample_filter[view_id[i]] синтаксиса равным трем. Если так, то управление передается на функциональный этап 636. Иначе, управление передается на функциональный этап 640.
Функциональный этап 636 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 638: vert_dim[view_id[i]]; hor_dim[view_id[i]]; и quantizer[view_id[i]].
Функциональный этап 638 синтаксически анализирует коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 640.
Функциональный этап 640 инкрементирует переменную i и возвращает управление на этап 612 принятия решения.
Функциональный этап 624 декодирует каждую картинку с использованием кодека стандарта AVC MPEG-4 или другого кодека с одиночной проекцией и передает управление на функциональный этап 626. Функциональный этап 626 выделяет каждую проекцию из картинки с использованием высокоуровневого синтаксиса и передает управление на конечный этап 699.
Обращаясь к фиг.7, примерный способ для кодирования картинок для множества проекций и глубин с использованием стандарта AVC MPEG-4 в целом указан номером 700 ссылки.
Способ 700 включает в себя начальный этап 702, который передает управление на функциональный этап 704. Функциональный этап 704 компонует каждую проекцию и соответствующую глубину в конкретный момент времени в качестве субкартинки в мозаичном формате и передает управление на функциональный этап 706. Функциональный этап 706 устанавливает элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 708. Функциональный этап 708 устанавливает элементы org_pic_width_in_mbs_minus1 и org_pic_height_in_mbs_minus1 синтаксиса и передает управление на функциональный этап 710. Функциональный этап 710 устанавливает переменную i равной нулю и передает управление на этап 712 принятия решения. Этап 712 принятия решения определяет, является или нет переменная i меньшей, чем количество проекций. Если так, то управление передается на функциональный этап 714. Иначе, управление передается на функциональный этап 724.
Функциональный этап 714 устанавливает элемент view_id[i] синтаксиса и передает управление на функциональный этап 716. Функциональный этап 716 устанавливает элемент num_parts[view_id[i]] синтаксиса и передает управление на функциональный этап 718. Функциональный этап 718 устанавливает переменную j равной нулю и передает управление на этап 720 принятия решения. Этап 720 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 722. Иначе, управление передается на функциональный этап 728.
Функциональный этап 722 устанавливает следующие элементы синтаксиса, инкрементирует переменную j, а затем, возвращает управление на этап 720 принятия решения: depth_flag[view_id[i]][j]; flip_dir[view_id[i]][j]; loc_left_offset[view_id[i]][j]; loc_top_offset[view_id[i]][j]; frame_crop_left_offset[view_id[i]][j]; frame_crop_right_offset[view_id[i]][j]; frame_crop_top_offset[view_id[i]][j]; и frame_crop_bottom_offset[view_id[i]][j].
Функциональный этап 728 устанавливает элемент upsample_view_flag[view_id[i]] синтаксиса и передает управление на этап 730 принятия решения. Этап 730 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 732. Иначе, управление передается на этап 734 принятия решения.
Функциональный этап 732 устанавливает элемент upsample_filter[view_id[i]] синтаксиса и передает управление на этап 734 принятия решения.
Этап 734 принятия решения определяет, является или нет текущее значение элемента upsample_filter[view_id[i]] синтаксиса равным трем. Если так, то управление передается на функциональный этап 736. Иначе, управление передается на функциональный этап 740.
Функциональный этап 736 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 738: vert_dim[view_id[i]]; hor_dim[view_id[i]]; и quantizer[view_id[i]].
Функциональный этап 738 устанавливает коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 740.
Функциональный этап 740 инкрементирует переменную i и возвращает управление на этап 712 принятия решения.
Функциональный этап 724 записывает эти элементы синтаксиса в по меньшей мере одно из набора параметров последовательности (SPS), набора параметров картинки (PPS), сообщения дополнительной расширительной информации (SEI), заголовка блока сетевого уровня абстракции (NAL) и заголовка секции, и передает управление на функциональный этап 726. Функциональный этап 726 кодирует каждую картинку с использованием кодека стандарта AVC MPEG-4 или другого кодека с одиночной проекцией и передает управление на конечный этап 799.
Обращаясь к фиг.8, примерный способ для декодирования картинок для множества проекций и глубин с использованием стандарта AVC MPEG-4 в целом указан номером 800 ссылки.
Способ 800 включает в себя начальный этап 802, который передает управление на функциональный этап 804. Функциональный этап 804 синтаксически анализирует элементы синтаксиса в по меньшей мере одном из набора параметров последовательности (SPS), набора параметров картинки (PPS), сообщения дополнительной расширительной информации (SEI), заголовка блока сетевого уровня абстракции (NAL) и заголовка секции, и передает управление на функциональный этап 806.
Функциональный этап 806 синтаксически анализирует элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 808. Функциональный этап 808 синтаксически анализирует элементы org_pic_width_in_mbs_minus1 и org_pic_height_in_mbs_minus1 синтаксиса и передает управление на функциональный этап 810. Функциональный этап 810 устанавливает переменную i равной нулю и передает управление на этап 812 принятия решения. Этап 812 принятия решения определяет, является или нет переменная i меньшей, чем количество проекций. Если так, то управление передается на функциональный этап 814. Иначе, управление передается на функциональный этап 824.
Функциональный этап 814 синтаксически анализирует элемент view_id[i] синтаксиса и передает управление на функциональный этап 816. Функциональный этап 816 синтаксически анализирует элемент num_parts_minus1[view_id[i]] синтаксиса и передает управление на функциональный этап 818. Функциональный этап 818 устанавливает переменную j равной нулю и передает управление на этап 820 принятия решения. Этап 820 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 822. Иначе, управление передается на функциональный этап 828.
Функциональный этап 822 синтаксически анализирует следующие элементы синтаксиса, инкрементирует переменную j, а затем, возвращает управление на этап 820 принятия решения: depth_flag[view_id[i]][j]; flip_dir[view_id[i]][j]; loc_left_offset[view_id[i]][j]; loc_top_offset[view_id[i]][j]; frame_crop_left_offset[view_id[i]][j]; frame_crop_right_offset[view_id[i]][j]; frame_crop_top_offset[view_id[i]][j]; и frame_crop_bottom_offset[view_id[i]][j].
Функциональный этап 828 синтаксически анализирует элемент upsample_view_flag[view_id[i]] синтаксиса и передает управление на этап 830 принятия решения. Этап 830 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 832. Иначе, управление передается на этап 834 принятия решения.
Функциональный этап 832 синтаксически анализирует элемент upsample_filter[view_id[i]] синтаксиса и передает управление на функциональный этап 834.
Этап 834 принятия решения определяет, является или нет текущее значение элемента upsample_filter[view_id[i]] синтаксиса равным трем. Если так, то управление передается на функциональный этап 836. Иначе, управление передается на функциональный этап 840.
Функциональный этап 836 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 838: vert_dim[view_id[i]]; hor_dim[view_id[i]]; и quantizer[view_id[i]].
Функциональный этап 838 синтаксически анализирует коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 840.
Функциональный этап 840 инкрементирует переменную i и возвращает управление на этап 812 принятия решения.
Функциональный этап 824 декодирует каждую картинку с использованием кодека стандарта AVC MPEG-4 или другого кодека с одиночной проекцией и передает управление на функциональный этап 826. Функциональный этап 826 выделяет каждую проекцию и соответствующую глубину из картинки с использованием высокоуровневого синтаксиса и передает управление на функциональный этап 827. Функциональный этап 827 потенциально выполняет синтез проекции с использованием извлеченных сигналов проекции и глубины, и передает управление на конечный этап 899.
Что касается глубины, используемой на фиг.7 и 8, фиг.9 показывает пример сигнала 900 глубины, где глубина предоставляется в качестве значения пикселя для каждого соответствующего местоположения изображения (не показано). Кроме того, фиг.10 показывает пример двух сигналов глубины, включенных в мозаику 1000. Верхний правый участок мозаики 1000 является сигналом глубины, имеющим значения глубины, соответствующие изображению сверху слева мозаики 1000. Нижний правый участок мозаики 1000 является сигналом глубины, имеющим значения глубины, соответствующие изображению снизу слева мозаики 1000.
Обращаясь к фиг.11, пример 5 проекций, мозаично размещенных в едином кадре, в целом указан номером 1100 ссылки. Верхние четыре проекции находятся в нормальной ориентации. Пятая проекция также находится в нормальной ориентации, но разделена на два участка по низу мозаики 1100. Левый участок пятой проекции показывает «верх» пятой проекции, а правый участок пятой проекции показывает «низ» пятой проекции.
Обращаясь к фиг.12, примерный кодер многопроекционного кодирования видео (MVC) в целом указан номером 1200 ссылки. Кодер 1200 включает в себя объединитель 1205, имеющий выход, соединенный по сигнальной связи с входом преобразователя 1210. Выход преобразователя 1210 соединен по сигнальной связи с входом квантователя 1215. Выход квантователя 1215 соединен по сигнальной связи с входом энтропийного кодера 1220 и входом обратного квантователя 1225. Выход обратного квантователя 1225 соединен по сигнальной связи с входом обратного преобразователя 1230. Выход обратного преобразователя 1230 соединен по сигнальной связи с первым неинвертирующим входом объединителя 1235. Выход объединителя 1235 соединен по сигнальной связи с входом внутреннего предсказателя 1245 и входом деблокинг-фильтра 1250. Выход деблокинг-фильтра 1250 соединен по сигнальной связи с входом хранилища 1255 опорных картинок (для проекции i). Выход хранилища 1255 опорных картинок соединен по сигнальной связи с первым входом компенсатора 1275 движения и первым входом блока 1280 оценки движения. Выход блока 1280 оценки движения соединен по сигнальной связи со вторым входом компенсатора 1275 движения.
Выход хранилища 1260 опорных картинок (для других проекций) соединен по сигнальной связи с первым входом блока 1270 оценки несоразмерности и первым входом компенсатора 1265 несоразмерности. Выход блока 1270 оценки несоразмерности соединен по сигнальной связи со вторым входом компенсатора 1265 несоразмерности.
Выход энтропийного декодера 1220 доступен в качестве выхода кодера 1200. Неинвертирующий вход объединителя 1205 доступен в качестве входа кодера 1200 и соединен по сигнальной связи со вторым входом блока 1270 оценки несоразмерности и вторым входом блока 1280 оценки движения. Выход переключателя 1285 соединен по сигнальной связи со вторым неинвертирующим входом объединителя 1235 и с инвертирующим входом объединителя 1205. Переключатель 1285 включает в себя первый вход, соединенный по сигнальной связи с выходом компенсатора 1275 движения, второй вход, соединенный по сигнальной связи с выходом компенсатора 1265 несоразмерности, и третий вход, соединенный по сигнальной связи с выходом внутреннего предсказателя 1245.
Модуль 1240 принятия решения о режиме имеет выход, присоединенный к переключателю 1285 для управления, какой вход выбран переключателем 1285.
Обращаясь к фиг.13, примерный декодер многопроекционного кодирования видео (MVC) в целом указан номером 1300 ссылки. Декодер 1300 включает в себя энтропийный декодер 1305, имеющий выход, соединенный по сигнальной связи с входом обратного квантователя 1310. Выход обратного квантователя соединен по сигнальной связи с входом обратного преобразователя 1315. Выход обратного преобразователя 1315 соединен по сигнальной связи с первым неинвертирующим входом объединителя 1320. Выход объединителя 1320 соединен по сигнальной связи с входом деблокинг-фильтра 1325 и входом внутреннего предсказателя 1330. Выход деблокинг-фильтра 1325 соединен по сигнальной связи с входом хранилища 1340 опорных картинок (для проекции i). Выход хранилища 1340 опорных картинок соединен по сигнальной связи с первым входом компенсатора 1335 движения.
Выход хранилища 1345 опорных картинок (для других проекций) соединен по сигнальной связи с первым входом компенсатора 1350 несоразмерности.
Вход энтропийного кодера 1305 доступен в качестве входа в декодер 1300 для приема остаточного битового потока. Более того, вход модуля 1360 режима также доступен в качестве входа в декодер 1300, для приема управляющего синтаксиса, чтобы управлять тем, какой вход выбран переключателем 1355. Кроме того, второй вход компенсатора 1335 движения доступен в качестве входа декодера 1300, для приема векторов движения. К тому же, второй вход компенсатора 1350 несоразмерности доступен в качестве входа в декодер 1300, для приема векторов несоразмерности.
Выход переключателя 1355 соединен по сигнальной связи со вторым неинвертирующим входом объединителя 1320. Первый вход переключателя 1355 соединен по сигнальной связи с выходом компенсатора 1350 несоразмерности. Второй вход переключателя 1355 соединен по сигнальной связи с выходом компенсатора 1335 движения. Третий вход переключателя 1355 соединен по сигнальной связи с выходом внутреннего предсказателя 1330. Выход модуля 1360 режима соединен по сигнальной связи с переключателем 1355 для управления, какой вход выбран переключателем 1355. Выход деблокинг-фильтра 1325 доступен в качестве выхода декодера 1300.
Обращаясь к фиг.14, примерный способ для обработки картинок для множества проекций при подготовке к кодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1400 ссылки.
Способ 1400 включает в себя начальный этап 1405, который передает управление на функциональный этап 1410. Функциональный этап 1410 компонует каждые N проекций, в числе суммарных M проекций, в конкретный момент времени в качестве суперкартинки в мозаичном формате и передает управление на функциональный этап 1415. Функциональный этап 1415 устанавливает элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 1420. Функциональный этап 1420 устанавливает элемент view_id[i] синтаксиса для всех (num_coded_views_minus1 + 1) проекций и передает управление на функциональный этап 1425. Функциональный этап 1425 устанавливает информацию о зависимости межпроекционных ссылок для картинок привязки и передает управление на функциональный этап 1430. Функциональный этап 1430 устанавливает информацию о зависимости межпроекционных ссылок для картинок не привязки и передает управление на функциональный этап 1435. Функциональный этап 1435 устанавливает элемент pseudo_view_present_flag синтаксиса и передает управление на этап 1440 принятия решения. Этап 1440 принятия решения определяет, является или нет текущее значение элемента pseudo_view_present_flag синтаксиса равным истине. Если так, то управление передается на функциональный этап 1445. Иначе, управление передается на конечный этап 1499.
Функциональный этап 1445 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 1450: tiling_mode; org_pic_width_in_mbs_minus1; и org_pic_height_in_mbs_minus1. Функциональный этап 1450 вызывает элемент pseudo_view_info(view_id) синтаксиса для каждой кодированной проекции и передает управление на конечный этап 1499.
Обращаясь к фиг.15, примерный способ для кодирования картинок для множества проекций с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1500 ссылки.
Способ 1500 включает в себя начальный этап 1502, который получает входной параметр pseudo_view_id и передает управление на функциональный этап 1504. Функциональный этап 1504 устанавливает элемент num_sub_views_minus1 синтаксиса и передает управление на функциональный этап 1506. Функциональный этап 1506 устанавливает переменную i равной нулю и передает управление на этап 1508 принятия решения. Этап 1508 принятия решения определяет, является или нет переменная i меньшей, чем количество подпроекций. Если так, то управление передается на функциональный этап 1510. Иначе, управление передается на функциональный этап 1520.
Функциональный этап 1510 устанавливает элемент sub_view_id[i] синтаксиса и передает управление на функциональный этап 1512. Функциональный этап 1512 устанавливает элемент num_parts_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1514. Функциональный этап 1514 устанавливает переменную j равной нулю и передает управление на этап 1516 принятия решения. Этап 1516 принятия решения определяет, является или нет переменная j меньшей, чем элемент num_parts_minus1[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1518. Иначе, управление передается на этап 1522 принятия решения.
Функциональный этап 1518 устанавливает следующие элементы синтаксиса, инкрементирует переменную j и возвращает управление на этап 1516 принятия решения: loc_left_offset[sub_view_id[i]][j]; loc_top_offset[sub_view_id[i]][j]; frame_crop_left_offset[sub_view_id[i]][j]; frame_crop_right_offset[sub_view_id[i]][j]; frame_crop_top_offset[sub_view_id[i]][j]; и frame_crop_bottom_offset[sub_view_id[i][j].
Функциональный этап 1520 кодирует текущую картинку для текущей проекции с использованием многопроекционного кодирования видео (MVC) и передает управление на функциональный этап 1599.
Этап 1522 принятия решения определяет, равен или нет нулю элемент tiling_mode синтаксиса. Если так, то управление передается на функциональный этап 1524. Иначе, управление передается на функциональный этап 1538.
Функциональный этап 1524 устанавливает элемент flip_dir[sub_view_id[i]] синтаксиса и элемент upsample_view_flag[sub_view_id[i]] синтаксиса, и передает управление на этап 1526 принятия решения. Этап 1526 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[sub_view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 1528. Иначе, управление передается на этап 1530 принятия решения.
Функциональный этап 1528 устанавливает элемент upsample_filter[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1530. Этап 1530 принятия решения определяет, является или нет значение элемента upsample_filter[sub_view_id[i]] синтаксиса равным трем. Если так, управление передается на функциональный этап 1532. Иначе, управление передается на функциональный этап 1536.
Функциональный этап 1532 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 1534: vert_dim[sub_view_id[i]]; hor_dim[sub_view_id[i]]; и quantizer[sub_view_id[i]]. Функциональный этап 1534 устанавливает коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 1536.
Функциональный этап 1536 инкрементирует переменную i и возвращает управление на этап 1508 принятия решения.
Функциональный этап 1538 устанавливает элемент pixel_dist_x[sub_view_id[i]] синтаксиса и элемент flip_dist_y[sub_view_id[i]] синтаксиса, и передает управление на функциональный этап 1540. Функциональный этап 1540 устанавливает переменную j равной нулю и передает управление на этап 1542 принятия решения. Этап 1542 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1544. Иначе, управление передается на функциональный этап 1536.
Функциональный этап 1544 устанавливает элемент num_pixel_tiling_filter_coeffs_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1546. Функциональный этап 1546 устанавливает коэффициенты для всех фильтров мозаичного размещения пикселей и передает управление на функциональный этап 1536.
Обращаясь к фиг.16, примерный способ для обработки картинок для множества проекций при подготовке к кодированию картинок с использованием расширения многопроекционного декодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1600 ссылки.
Способ 1600 включает в себя начальный этап 1605, который передает управление на функциональный этап 1615. Функциональный этап 1615 синтаксически анализирует элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 1620. Функциональный этап 1620 синтаксически анализирует элемент view_id[i] синтаксиса для всех (num_coded_views_minus1 + 1) проекций и передает управление на функциональный этап 1625. Функциональный этап 1625 синтаксически анализирует информацию о зависимости межпроекционных ссылок для картинок привязки и передает управление на функциональный этап 1630. Функциональный этап 1630 синтаксически анализирует информацию о зависимости межпроекционных ссылок для картинок не привязки и передает управление на функциональный этап 1635. Функциональный этап 1635 синтаксически анализирует элемент pseudo_view_present_flag синтаксиса и передает управление на этап 1640 принятия решения. Этап 1640 принятия решения определяет, является или нет текущее значение элемента pseudo_view_present_flag синтаксиса равным истине. Если так, то управление передается на функциональный этап 1645. Иначе, управление передается на конечный этап 1699.
Функциональный этап 1645 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 1650: tiling_mode; org_pic_width_in_mbs_minus1; и org_pic_height_in_mbs_minus1. Функциональный этап 1650 вызывает элемент pseudo_view_info(view_id) синтаксиса для каждой кодированной проекции и передает управление на конечный этап 1699.
Обращаясь к фиг.17, примерный способ для декодирования картинок для множества проекций с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1700 ссылки.
Способ 1700 включает в себя начальный этап 1702, который начинается с входного параметра pseudo_view_id и передает управление на функциональный этап 1704. Функциональный этап 1704 синтаксически анализирует элемент num_sub_views_minus1 синтаксиса и передает управление на функциональный этап 1706. Функциональный этап 1706 устанавливает переменную i равной нулю и передает управление на этап 1708 принятия решения. Этап 1708 принятия решения определяет, является или нет переменная i меньшей, чем количество подпроекций. Если так, то управление передается на функциональный этап 1710. Иначе, управление передается на функциональный этап 1720.
Функциональный этап 1710 синтаксически анализирует элемент sub_view_id[i] синтаксиса и передает управление на функциональный этап 1712. Функциональный этап 1712 синтаксически анализирует элемент num_parts_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1714. Функциональный этап 1714 устанавливает переменную j равной нулю и передает управление на этап 1716 принятия решения. Этап 1716 принятия решения определяет, является или нет переменная j меньшей, чем элемент num_parts_minus1[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1718. Иначе, управление передается на этап 1722 принятия решения.
Функциональный этап 1718 устанавливает следующие элементы синтаксиса, инкрементирует переменную j и возвращает управление на этап 1716 принятия решения: loc_left_offset[sub_view_id[i]][j]; loc_top_offset[sub_view_id[i]][j]; frame_crop_left_offset[sub_view_id[i]] [j]; frame_crop_right_offset[sub_view_id[i]][j]; frame_crop_top_offset[sub_view_id[i]][j]; и frame_crop_bottom_offset[sub_view_id[i][j].
Функциональный этап 1720 декодирует текущую картинку для текущей проекции с использованием многопроекционного кодирования видео (MVC) и передает управление на функциональный этап 1721. Функциональный этап 1721 выделяет каждую проекцию из картинки с использованием высокоуровневого синтаксиса и передает управление на конечный этап 1799.
Выделение каждой проекции из декодированной картинки выполняется с использованием высокоуровневого синтаксиса, указанной в битовом потоке. Этот высокоуровневый синтаксис может указывать точное местоположение и возможную ориентацию проекций (и возможную соответствующую глубину), присутствующих в картинке.
Этап 1722 принятия решения определяет, равен или нет нулю элемент tiling_mode синтаксиса. Если так, то управление передается на функциональный этап 1724. Иначе, управление передается на функциональный этап 1738.
Функциональный этап 1724 синтаксически анализирует элемент flip_dir[sub_view_id[i]] синтаксиса и элемент upsample_view_flag[sub_view_id[i]] синтаксиса, и передает управление на этап 1726 принятия решения. Этап 1726 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[sub_view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 1728. Иначе, управление передается на этап 1730 принятия решения.
Функциональный этап 1728 синтаксически анализирует элемент upsample_filter[sub_view_id[i]] синтаксиса и передает управление на этап 1730 принятия решения. Этап 1730 принятия решения определяет, является или нет значение элемента upsample_filter[sub_view_id[i]] синтаксиса равным трем. Если так, управление передается на функциональный этап 1732. Иначе, управление передается на функциональный этап 1736.
Функциональный этап 1732 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 1734: vert_dim[sub_view_id[i]]; hor_dim[sub_view_id[i]]; и quantizer[sub_view_id[i]]. Функциональный этап 1734 синтаксически анализирует коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 1736.
Функциональный этап 1736 инкрементирует переменную i и возвращает управление на этап 1708 принятия решения.
Функциональный этап 1738 синтаксически анализирует элемент pixel_dist_x[sub_view_id[i]] синтаксиса и элемент flip_dist_y[sub_view_id[i]] синтаксиса, и передает управление на функциональный этап 1740. Функциональный этап 1740 устанавливает переменную j равной нулю и передает управление на этап 1742 принятия решения. Этап 1742 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1744. Иначе, управление передается на функциональный этап 1736.
Функциональный этап 1744 синтаксически анализирует элемент num_pixel_tiling_filter_coeffs_minusl[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1746. Функциональный этап 1776 синтаксически анализирует коэффициенты для всех фильтров мозаичного размещения пикселей и передает управление на функциональный этап 1736.
Обращаясь к фиг.18, примерный способ для обработки картинок для множества проекций и глубин при подготовке к кодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1800 ссылки.
Способ 1800 включает в себя начальный этап 1805, который передает управление на функциональный этап 1810. Функциональный этап 1810 компонует каждые N проекций и карт глубин, в числе суммарных M проекций и карт глубин, в конкретный момент времени в качестве суперкартинки в мозаичном формате и передает управление на функциональный этап 1815. Функциональный этап 1815 устанавливает элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 1820. Функциональный этап 1820 устанавливает элемент view_id[i] синтаксиса для всех (num_coded_views_minus1 + 1) глубин, соответствующих view_id[i], и передает управление на функциональный этап 1825. Функциональный этап 1825 устанавливает информацию о зависимости межпроекционных ссылок для картинок глубины привязки и передает управление на функциональный этап 1830. Функциональный этап 1830 устанавливает информацию о зависимости межпроекционных ссылок для картинок глубины не привязки и передает управление на функциональный этап 1835. Функциональный этап 1835 устанавливает элемент pseudo_view_present_flag синтаксиса и передает управление на этап 1840 принятия решения. Этап 1840 принятия решения определяет, является или нет текущее значение элемента pseudo_view_present_flag синтаксиса равным истине. Если так, то управление передается на функциональный этап 1845. Иначе, управление передается на конечный этап 1899.
Функциональный этап 1845 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 1850: tiling_mode; org_pic_width_in_mbs_minus1; и org_pic_height_in_mbs_minus1. Функциональный этап 1850 вызывает элемент pseudo_view_info(view_id) синтаксиса для каждой кодированной проекции и передает управление на конечный этап 1899.
Обращаясь к фиг.19, примерный способ для кодирования картинок для множества проекций и глубин с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 1900 ссылки.
Способ 1900 включает в себя начальный этап 1902, который передает управление на функциональный этап 1904. Функциональный этап 1904 устанавливает элемент num_sub_views_minus1 синтаксиса и передает управление на функциональный этап 1906. Функциональный этап 1906 устанавливает переменную i равной нулю и передает управление на этап 1908 принятия решения. Этап 1908 принятия решения определяет, является или нет переменная i меньшей, чем количество подпроекций. Если так, то управление передается на функциональный этап 1910. Иначе, управление передается на функциональный этап 1920.
Функциональный этап 1910 устанавливает элемент sub_view_id[i] синтаксиса и передает управление на функциональный этап 1912. Функциональный этап 1912 устанавливает элемент num_parts_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1914. Функциональный этап 1914 устанавливает переменную j равной нулю и передает управление на этап 1916 принятия решения. Этап 1916 принятия решения определяет, является или нет переменная j меньшей, чем элемент num_parts_minus1[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1918. Иначе, управление передается на этап 1922 принятия решения.
Функциональный этап 1918 устанавливает следующие элементы синтаксиса, инкрементирует переменную j и возвращает управление на этап 1916 принятия решения: loc_left_offset[sub_view_id[i]][j]; loc_top_offset[sub_view_id[i]][j]; frame_crop_left_offset[sub_view_id[i]] [j]; frame_crop_right_offset[sub_view_id[i]][j]; frame_crop_top_offset[sub_view_id[i]][j]; и frame_crop_bottom_offset[sub_view_id[i][j].
Функциональный этап 1920 кодирует текущую глубину для текущей проекции с использованием многопроекционного кодирования видео (MVC) и передает управление на функциональный этап 1999. Сигнал глубины может кодироваться подобно способу, которым кодируется его соответствующий видеосигнал. Например, сигнал глубины для проекции может быть включен в мозаику, которая включает в себя только другие сигналы глубины или только видеосигналы, или как сигналы глубины, так и видеосигналы. Мозаика (псевдопроекция) затем обрабатывается в качестве одиночной проекции для MVC, и также предположительно есть другие мозаики, которые обрабатываются в качестве других проекций для MVC.
Этап 1922 принятия решения определяет, равен или нет нулю элемент tiling_mode синтаксиса. Если так, то управление передается на функциональный этап 1924. Иначе, управление передается на функциональный этап 1938.
Функциональный этап 1924 устанавливает элемент flip_dir[sub_view_id[i]] синтаксиса и элемент upsample_view_flag[sub_view_id[i]] синтаксиса и передает управление на этап 1926 принятия решения.
Этап 1926 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[sub_view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 1928. Иначе, управление передается на этап 1930 принятия решения.
Функциональный этап 1928 устанавливает элемент upsample_filter[sub_view_id[i]] синтаксиса и передает управление на этап 1930 принятия решения. Этап 1930 принятия решения определяет, является или нет значение элемента upsample_filter[sub_view_id[i]] синтаксиса равным трем. Если так, управление передается на функциональный этап 1932. Иначе, управление передается на функциональный этап 1936.
Функциональный этап 1932 устанавливает следующие элементы синтаксиса и передает управление на функциональный этап 1934: vert_dim[sub_view_id[i]]; hor_dim[sub_view_id[i]]; и quantizer[sub_view_id[i]]. Функциональный этап 1934 устанавливает коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 1936.
Функциональный этап 1936 инкрементирует переменную i и возвращает управление на этап 1908 принятия решения.
Функциональный этап 1938 устанавливает элемент pixel_dist_x[sub_view_id[i]] синтаксиса и элемент flip_dist_y[sub_view_id[i]] синтаксиса, и передает управление на функциональный этап 1940. Функциональный этап 1940 устанавливает переменную j равной нулю и передает управление на этап 1942 принятия решения. Этап 1942 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 1944. Иначе, управление передается на функциональный этап 1936.
Функциональный этап 1944 устанавливает элемент num_pixel_tiling_filter_coeffs_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 1946. Функциональный этап 1946 устанавливает коэффициенты для всех фильтров мозаичного размещения пикселей и передает управление на функциональный этап 1936.
Обращаясь к фиг.20, примерный способ для обработки картинок для множества проекций и глубин при подготовке к декодированию картинок с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 2000 ссылки.
Способ 2000 включает в себя начальный этап 2005, который передает управление на функциональный этап 2015. Функциональный этап 2015 синтаксически анализирует элемент num_coded_views_minus1 синтаксиса и передает управление на функциональный этап 2020. Функциональный этап 2020 синтаксически анализирует элемент view_id[i] синтаксиса для всех (num_coded_views_minus1 + 1) глубин, соответствующих view_id[i], и передает управление на функциональный этап 2025. Функциональный этап 2025 синтаксически анализирует информацию о зависимости межпроекционных ссылок для картинок глубины привязки и передает управление на функциональный этап 2030. Функциональный этап 2030 синтаксически анализирует информацию о зависимости межпроекционных ссылок для картинок глубины непривязки и передает управление на функциональный этап 2035. Функциональный этап 2035 синтаксически анализирует элемент pseudo_view_present_flag синтаксиса и передает управление на этап 2040 принятия решения. Этап 2040 принятия решения определяет, является или нет текущее значение элемента pseudo_view_present_flag синтаксиса равным истине. Если так, то управление передается на функциональный этап 2045. Иначе, управление передается на конечный этап 2099.
Функциональный этап 2045 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 2050: tiling_mode; org_pic_width_in_mbs_minus1; и org_pic_height_in_mbs_minus1. Функциональный этап 2050 вызывает элемент pseudo_view_info(view_id) синтаксиса для каждой кодированной проекции и передает управление на конечный этап 2099.
Обращаясь к фиг.21, примерный способ для декодирования картинок для множества проекций и глубин с использованием расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 в целом указан номером 2100 ссылки.
Способ 2100 включает в себя начальный этап 2102, который начинается с входного параметра pseudo_view_id и передает управление на функциональный этап 2104. Функциональный блок 2104 синтаксически анализирует элемент num_sub_views_minus1 синтаксиса и передает управление в функциональный блок 2106. Функциональный этап 2106 устанавливает переменную i равной нулю и передает управление на этап 2108 принятия решения. Этап 2108 принятия решения определяет, является или нет переменная i меньшей, чем количество подпроекций. Если так, то управление передается на функциональный этап 2110. Иначе, управление передается на функциональный этап 2120.
Функциональный этап 2110 синтаксически анализирует элемент sub_view_id[i] синтаксиса и передает управление на функциональный этап 2112. Функциональный этап 2112 синтаксически анализирует элемент num_parts_minus1[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 2114. Функциональный этап 2114 устанавливает переменную j равной нулю и передает управление на этап 2116 принятия решения. Этап 2116 принятия решения определяет, является или нет переменная j меньшей, чем элемент num_parts_minus1[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 2118. Иначе, управление передается на этап 2122 принятия решения.
Функциональный этап 2118 устанавливает следующие элементы синтаксиса, инкрементирует переменную j и возвращает управление на этап 2116 принятия решения: loc_left_offset[sub_view_id[i]][j]; loc_top_offset[sub_view_id[i]][j]; frame_crop_left_offset[sub_view_id[i]][j]; frame_crop_right_offset[sub_view_id[i]][j]; frame_crop_top_offset[sub_view_id[i]][j]; и frame_crop_bottom_offset[sub_view_id[i][j].
Функциональный этап 2120 декодирует текущую картинку с использованием многопроекционного кодирования видео (MVC) и передает управление на функциональный этап 2121. Функциональный этап 2121 выделяет каждую проекцию из картинки с использованием высокоуровневого синтаксиса и передает управление на конечный этап 2199. Выделение каждой проекции с использованием высокоуровневого синтаксиса происходит, как описано ранее.
Этап 2122 принятия решения определяет, равен или нет нулю элемент tiling_mode синтаксиса. Если так, то управление передается на функциональный этап 2124. Иначе, управление передается на функциональный этап 2138.
Функциональный этап 2124 синтаксически анализирует элемент flip_dir[sub_view_id[i]] синтаксиса и элемент upsample_view_flag[sub_view_id[i]] синтаксиса, и передает управление на этап 2126 принятия решения. Этап 2126 принятия решения определяет, является или нет текущее значение элемента upsample_view_flag[sub_view_id[i]] синтаксиса равным единице. Если так, то управление передается на функциональный этап 2128. Иначе, управление передается на этап 2130 принятия решения.
Функциональный этап 2128 синтаксически анализирует элемент upsample_filter[sub_view_id[i]] синтаксиса и передает управление на этап 2130 принятия решения. Этап 2130 принятия решения определяет, является или нет значение элемента upsample_filter[sub_view_id[i]] синтаксиса равным трем. Если так, управление передается на функциональный этап 2132. Иначе, управление передается на функциональный этап 2136.
Функциональный этап 2132 синтаксически анализирует следующие элементы синтаксиса и передает управление на функциональный этап 2134: vert_dim[sub_view_id[i]]; hor_dim[sub_view_id[i]]; и quantizer[sub_view_id[i]]. Функциональный этап 2134 синтаксически анализирует коэффициенты фильтра для каждой компоненты YUV и передает управление на функциональный этап 2136.
Функциональный этап 2136 инкрементирует переменную i и возвращает управление на этап 2108 принятия решения.
Функциональный этап 2138 синтаксически анализирует элемент pixel_dist_x[sub_view_id[i]] синтаксиса и элемент flip_dist_y[sub_view_id[i]] синтаксиса, и передает управление на функциональный этап 2140. Функциональный этап 2140 устанавливает переменную j равной нулю и передает управление на этап 2142 принятия решения. Этап 2142 принятия решения определяет, является или нет текущее значение переменной j меньшим, чем текущее значение элемента num_parts[sub_view_id[i]] синтаксиса. Если так, то управление передается на функциональный этап 2144. Иначе, управление передается на функциональный этап 2136.
Функциональный этап 2144 синтаксически анализирует элемент num_pixel_tiling_filter_coeffs_minusl[sub_view_id[i]] синтаксиса и передает управление на функциональный этап 2146. Функциональный этап 2146 синтаксически анализирует коэффициенты для всех фильтров мозаичного размещения пикселей и передает управление на функциональный этап 2136.
Обращаясь к фиг.22, примеры мозаичного размещения на уровне пикселей в целом указаны номером 2200 ссылки. Фиг.22 дополнительно описана ниже.
Применением многопроекционного кодирования видео является телевидение со свободной точкой обзора (или FTV). Это применение требует, чтобы пользователь мог свободно переходить между двумя или более проекциями. Для того чтобы достигать этого, «виртуальным» проекциям между двумя проекциями необходимо интерполироваться или синтезироваться. Есть несколько способов для выполнения интерполяции проекций. Один из способов использует глубину для интерполяции/синтеза проекций.
Каждая проекция может иметь ассоциативно связанный сигнал глубины. Таким образом, глубина может считаться еще одной формой видеосигнала. Фиг.9 показывает пример сигнала 900 глубины. Для того чтобы обеспечить возможность применения, такого как FTV, сигнал глубины передается наряду с видеосигналом. В предложенной инфраструктуре мозаичного размещения, сигнал глубины также может добавляться в качестве одной из мозаик.
Фиг.10 показывает пример сигналов глубины, добавленных в качестве мозаик. Сигналы/мозаики глубины показаны на правой стороне фиг.10.
Как только глубина кодируется в качестве мозаики полного кадра, высокоуровневый синтаксис должен указывать, какая мозаика является сигналом глубины, так что визуализатор может использовать сигнал глубины надлежащим образом.
В случае, когда входная последовательность (такая, как показанная на фиг.1) кодируется с использованием кодера стандарта AVC MPEG-4 (или кодера, соответствующего другим стандарту и/или рекомендации кодирования видео), предложенный высокоуровневый синтаксис, например, может присутствовать в наборе параметров последовательности (SPS), наборе параметров картинки (PPS), заголовке секции и/или сообщении дополнительной расширительной информации (SEI). Вариант осуществления предложенного способа показан в таблице 1, где синтаксис присутствует в сообщении дополнительной расширительной информации (SEI).
В случае, когда входные последовательности псевдопроекций (таких как показанные на фиг.1) кодируются с использованием кодера расширения многопроекционного кодирования видео (MVC) стандарта AVC MPEG-4 (или кодера, соответствующего стандарту многопроекционного кодирования видео по другим стандарту и/или рекомендации кодирования видео), предложенный высокоуровневый синтаксис может присутствовать в SPS, PPS, заголовке секции, сообщении SEI или заданном профиле. Вариант осуществления предложенного способа показан в таблице 1. Таблица 1 показывает элементы синтаксиса, присутствующие в структуре набора параметров последовательности (SPS), в том числе, элементы синтаксиса, реализованные в соответствии с настоящими принципами.
<b>Таблица 1</b>
seq_parameter_set_mvc_extension() {
C
Дескриптор
num_views_minus_1
ue(v)
for(i=0; i<= num_views_minus_1; i++)
view_id[i]
ue(v)
for(i=0; i<= num_views_minus_1; i++) {
num_anchor_refs_10[i]
ue(v)
for(j=0; j<num_anchor_refs_10[i]; j++)
anchor_ref_10[i][j]
ue(v)
num_anchor_refs_11 [i]
ue(v)
for(j=0; j<num_anchor_refs_11[i]; j++)
anchor_ref_11[i][j]
ue(v)
}
for(i=0; i <= num_views_minus_1; i++) {
num_non_anchor_refs_10[i]
ue(v)
for(j=0; j<num_non_anchor_refs_10[i];j++)
non_anchor_ref_10[i][j]
ue(v)
num_non_anchor_refs_11 [i]
ue(v)
for(j=0; j<num_non_anchor_refs_11[i]; j++)
non_anchor_ref_11 [i][j]
ue(v)
}
pseudo_view_present_flag
u(1)
if (pseudo_view_present_flag) {
tiling_mode
org_pic width in_mbs_minus1
org_pic_height_in_mbs_minus1
for (i=0; i<num_views_minus_1; i++)
pseudo_view_info(i);
}
}
Таблица 2 показывает элементы синтаксиса для элемента pseudo_view_info синтаксиса по таблице 1
<b>Таблица 2</b>
pseudo_view_info (pseudo_view_id) {
C
Дескриптор
num_sub_views_minus_1[pseudo_view_id]
5
ue(v)
if(num sub_views_minus_1 !=0){
for (i=0; i<num_sub_views_minus_1[pseudo_view_id]; i++) {
sub_view_id[i]
5
ue(v)
num_parts_minusl[sub_view_id[i]]
5
ue(v)
for(j=0; j<=num_parts_minusl[sub_view_id[i]]; j++) {
loc_left_offset[sub_view_id[i]] [j]
5
ue(v)
loc_top_offset[sub_view_id[i]] [j]
5
ue(v)
frame_crop_left_offset[sub_view_id[i]] [j]
5
ue(v)
frame_crop_right_offset[sub_view_id[i]] [j]
5
ue(v)
frame crop top offset[sub_view id[i]] [j]
5
ue(v)
frame_crop_bottom_offset[sub_view_id[i]] [j]
5
ue(v)
}
if(tiling_mode= =0) {
flip_dir[sub_view_id[i][j]
5
u(2)
upsample_view_flag[sub_view_id[i]]
5
u(1)
if(upsample_view_flag[sub_view_id[i]])
upsample_filter[sub view_id[i]]
5
u(2)
if(upsample_fiter[sub_view_id[i]] = = 3) {
vert_dim[sub_view_id[i]]
5
ue(v)
hor_dim[sub_view_id[i]]
5
ue(v)
quantizer[sub_view_id[i]]
5
ue(v)
for (yuv=0; yuv< 3; yuv++) {
for (y=0; y<vert_dim[sub_view_id[i]]-1; y ++) {
for (x=0; x<hor_dim[sub_view_id[i]]-1; x ++)
filter_coeffs[sub_view_id[i]] [yuv][y][x]
5
se(v)
}
}
}
}// if(tiling_mode = = 0)
else if (tiling_mode = = 1){
pixel_dist x[sub_view_id[i] ]
pixel_dist_y[sub_view_id[i]]
for(j=0; j<= num_parts[sub_view_id[i]]; j++) {
num_pixel_tiling_filter_coeffs_minus1[sub_view_id[i]][j]
for (coeff_idx=0; coeff_idx <= num_pixel_tiling_filter_coeffs_minus1[sub_view_id[i]][j]; j++)
pixel_tiling_filter_coeffs[sub_view_id[i]][j]
}// for (j=0; j<= num_parts[sub_view_id[i]]; j++)
}// else if (tiling_mode = = 1)
}// for (i=0; i< num_sub_views_minus_1; i++)
}// if (num_sub_views_minus_1 != 0)
}
Семантика элементов синтаксиса, представленных в таблице 1 и таблице 2, описана ниже:
pseudo_view_present_flag
флаг_наличия_псевдопроекции
(), равный значению «истина», указывает, что некоторая проекция является суперпроекцией многочисленных подпроекций.
tiling_mode
режим_мозаичного_размещения
(), равный 0, указывает, что подпроекции подвергаются мозаичному размещению на уровне картинок. Значение 1 указывает, что мозаичное размещение выполняется на уровне пикселей.
Новое сообщение SEI могло бы использовать значение для типа полезной нагрузки SEI, который не был использован в стандарте AVC MPEG-4 или расширении стандарта AVC MPEG-4. Новое сообщение SEI включает в себя несколько элементов синтаксиса со следующей семантикой.
num_coded_views_minus1
количество_кодированных_проекций_минус1
() плюс 1 указывает количество кодированных проекций, поддерживаемых битовым потоком. Значение num_coded_views_minus1 находится в объеме от 0 до 1023 включительно.
org_pic_width_in_mbs_minus1
ширина_картинки_структуры_в_макроблоках_минус1
() плюс 1 задает ширину картинки в каждой проекции в единицах макроблоков.
Переменная для ширины картинки в единицах макроблоков выводится, как изложено ниже:
PicWidthInMbs = org_pic_width_in_mbs_minus1 + 1
Переменная для ширины картинки для компоненты яркости выводится, как изложено ниже:
PicWidthInSamplesL = PicWidthInMbs * 16
Переменная для ширины картинки для компоненты цветности выводится, как изложено ниже:
PicWidthInSamplesC = PicWidthInMbs * MbWidthC
org_pic_height_in_mbs_minus1
высота_картинки_структуры_в_макроблоках_минус1
() плюс 1 задает высоту картинки в каждой проекции в единицах макроблоков.
Переменная для высоты картинки в единицах макроблоков выводится, как изложено ниже:
PicHeightInMbs = org_pic_height_in_mbs_minus1 + 1
Переменная для высоты картинки для компоненты яркости выводится, как изложено ниже:
PicHeightInSamplesL = PicHeightInMbs * 16
Переменная для высоты картинки для компоненты цветности выводится, как изложено ниже:
PicHeightInSamplesC = PicHeightInMbs * MbHeightC
num_sub_views_minus1
количество_подпроекций_минус1
() плюс 1 указывает количество кодированных подпроекций, включенных в текущую проекцию. Значение num_coded_views_minus1 находится в объеме от 0 до 1023 включительно.
sub_view_id[i]
идентификатор_подпроекции[i]
() задает sub_view_id подпроекции с очередностью декодирования, указанной посредством i.
num_parts[sub_view_id[i]]
количество_частей[идентификатор_подпроекции[i]]
() задает количество частей, на которое разделяется картинка у sub_view_id[i].
loc_left_offset[sub_view_id[i]][j]
местное_левое_смещение[идентификатор_подпроекции[i]][j]
loc_top_offset[sub_view_id[i]][j]
местное_верхнее_смещение[идентификатор_подпроекции[i]][j]
() и  () задают местоположения в левом и верхнем смещениях пикселей, соответственно, где текущая часть j расположена в реконструированной картинке проекции с sub_view_id, равным sub_view_id[i].
view_id[i]
идентификатор_проекции[i]
() задает view_id проекции с очередностью декодирования, указанной посредством i.
frame_crop_left_offset[view_id[i]][j]
левое_смещение_вырезки_кадра[идентификатор_проекции[i]][j]
frame_crop_right_offset[view_id[i]][j]
правое_смещение_вырезки_кадра[идентификатор_проекции[i]][j]
frame_crop_top_offset[view_id[i]][j]
верхнее_смещение_вырезки_кадра[идентификатор_проекции[i]][j]
frame_crop_bottom_offset[view_id[i]][j]
нижнее_смещение_вырезки_кадра[идентификатор_проекции[i]][j]
(),  (),  (), и  () задают выборки картинок в кодированной видеопоследовательности, которые являются частью num_part j и view_id i, в выражении прямоугольных областей, заданных в координатах кадра для вывода.
Переменные CropUnitX и CropUnitY выводятся, как изложено ниже:
- Если chroma_format_idc равно 0, CropUnitX и CropUnitY выводятся, как изложено ниже:
CropUnitX = 1
CropUnitY = 2 - frame_mbs_only_flag
- Иначе (chroma_format_idc равно 1, 2 или 3) CropUnitX и CropUnitY выводятся, как изложено ниже:
CropUnitX = SubWidthC
CropUnitY = SubHeightC * (2 - frame_mbs_only_fiag)
Прямоугольник вырезки кадра включает в себя выборки яркости с горизонтальными координатами кадра из следующего:
с CropUnitX * frame_crop_left_offset по PicWidthInSamplesL - (CropUnitX * frame_crop_right_offset + 1), и вертикальными координатами кадра с CropUnitY * frame_crop_top_offset по (16 * FrameHeightInMbs) - (CropUnitY * frame_crop_bottom_offset + 1) включительно. Значение frame_crop_left_offset будет находиться в диапазоне от 0 до (PicWidthInSamplesL/CropUnitX) - (frame_crop_right_offset + 1) включительно; а значение frame_crop_top_offset будет находиться в диапазоне от 0 до (16 * FrameHeightInMbs/CropUnitY) - (frame_crop_bottom_offset + 1) включительно.
Когда chroma_format_idc не равно 0, соответствующие заданные выборки двух массивов цветности являются выборками, имеющими координаты кадра (x/SubWidthC, y/SubHeightC), где (x, y) - координаты кадра заданных выборок яркости.
Для декодированных областей, заданные выборки декодированной области являются выборками, которые попадают внутрь прямоугольника, заданного в координатах кадра.
num_parts[sub_view_id[i]]
количество_частей[идентификатор_проекции[i]]
() задает количество частей, на которое разделяется картинка у view_id[i].
depth_flag[view_id[i]]
флаг_глубины[идентификатор_проекции[i]]
() задает, является или нет текущая часть сигналом глубины. Если depth_flag равен 0, то текущая часть не является сигналом глубины. Если depth_flag равен 1, то текущая часть является сигналом глубины, ассоциативно связанным с проекцией, идентифицированной посредством view_id[i].
flip_dir[sub_view_id[i]][j]
направление_транспонирования[идентификатор_подпроекции[i]][j]
() задает направление транспонирования для текущей части. flip_dir, равное 0, указывает отсутствие транспонирования, flip_dir, равное 1, указывает транспонирование в горизонтальном направлении, flip_dir, равное 2, указывает транспонирование в вертикальном направлении, а flip_dir, равное 3, указывает транспонирование в горизонтальном и вертикальном направлениях.
flip_dir[view_id[i]][j]
направление_транспонирования[идентификатор_проекции[i]][j]
() задает направление транспонирования для текущей части, flip_dir, равное 0, указывает отсутствие транспонирования, flip_dir, равное 1, указывает транспонирование в горизонтальном направлении, flip_dir, равное 2, указывает транспонирование в вертикальном направлении, а flip_dir, равное 3, указывает транспонирование в горизонтальном и вертикальном направлениях.
loc_left_offset[view_id[i]][j]
местное_левое_смещение[идентификатор_проекции[i]][j]
loc_top_offset[view_id[i]][j]
местное_верхнее_смещение[идентификатор_проекции[i]][j]
(),  () задают местоположение в смещениях пикселей, где текущая часть j расположена в заключительной реконструированной картинке проекции с view_id, равным view_id[i].
upsample_view_flag[view_id[i]]
флаг_проекции_повышающей_дискретизации[идентификатор_проекции[i]]
() указывает, необходимо ли подвергаться повышающей дискретизации картинке, принадлежащей проекции, заданной посредством view_id[i]. upsample_view_flag[view_id[i]], равное 0, предписывает, что картинка с view_id, равным view_id[i], не будет подвергаться повышающей дискретизации. upsample_view_flag[view_id[i]], равное 1, предписывает, что картинка с view_id, равным view_id[i], будет подвергнута повышающей дискретизации.
upsample_filter[view_id[i]]
фильтр_повышающей_дискретизации[идентификатор_проекции[i]]
() указывает тип фильтра, который должен использоваться для повышающей дискретизации. upsample_filter[view_id[i]] равно 0 указывает, что должен использоваться 6-отводный фильтр AVC, upsample_filter[view_id[i]] равно 1 указывает, что должен использоваться 4-отводный фильтр SVC, upsample_filter[view_id[i]] равно 2 указывает, что должен использоваться билинейный фильтр, upsample_filter[view_id[i]] равно 3 указывает, что передаются специализированные коэффициенты фильтра. Когда upsample_filter[view_id[i]] не присутствует, он устанавливается в 0. В этом варианте осуществления, мы используем двухмерный специализированный фильтр. Он может быть легко расширен до одномерного фильтра и некоторого другого нелинейного фильтра.
vert_dim[view_id[i]]
вертикальный_размер[идентификатор_проекции[i]]
() задает вертикальный размер специализированного двухмерного фильтра.
hor_dim[view_id[i]]
горизонтальный_размер[идентификатор_проекции[i]
() задает горизонтальный размер специализированного двухмерного фильтра.
quantizer[view_id[i]]
квантователь[идентификатор_проекции[i]]
() задает коэффициент квантования для каждого коэффициента фильтра.
filter_coeffs[view_id[i]][yuv][y][x]
коэффициенты_фильтра[идентификатор_проекции[i]][yuv][y][x]
() задает квантованные коэффициенты фильтра, yuv сигнализирует компоненту, к которой применяются коэффициенты фильтра. yuv, равное 0, задает компоненту Y, yuv, равное 1, задает компоненту U, а yuv, равное 2, задает компоненту V.
pixel_dist_x[sub_view_id[i]]
расстояние_в_пикселях_по_оси_x[идентификатор_подпроекции[i]][j]
pixel_dist_y[sub_view_id[i]]
расстояние_в_пикселях_по_оси_y[идентификатор_подпроекции[i]][j]
() и  () соответственно задают расстояние в горизонтальном направлении и вертикальном направлении в заключительной реконструированной псевдопроекции между соседними пикселями в проекции с sub_view_id, равным sub_view_id[i].
num_pixel_tiling_filter_coeffs_minus1[sub_view_id[i]][j]
количество_коэффициентов_фильтра_мозаичного_размещения_пикселей_минус1[идентификатор_подпроекции[i]][j]
() плюс единица указывает количество коэффициентов фильтра, когда режим мозаичного размещения установлен равным 1.
pixel_tiling_filter_coeffs[sub_view_id[i]][j]
коэффициенты_фильтра_мозаичного_размещения_пикселей
идентификатор_подпроекции[i]][j]
([) сигнализирует коэффициенты фильтра, которые требуются для представления фильтра, который может использоваться для фильтрации подвергнутого мозаичному размещению картинки.
Обращаясь к фиг.22, два примера, показывающие компоновку псевдопроекции посредством мозаичного размещения пикселей из четырех проекций, соответственно указаны номерами 2210 и 2220 ссылки, соответственно. Четыре проекции совместно указываются номером 2250 ссылки. Значения синтаксиса для первого примера на фиг.22 предоставлены в таблице 3, приведенной ниже.
<b>Таблица 3</b>
pseudo_view_info (pseudo_view_id) {
Значение
num_sub_views_minus l[pseudo_view_id]
3
sub_view_id[0]
0
num_parts_minus1[0]
0
loc_left_offset[0][0]
0
loc_top_offset[0][0]
0
pixel_dist_x[0][0]
0
pixel_dist_y[0][0]
0
sub_view_id[l]
0
num_parts_minusl[l]
0
loc_left_offset[l][0]
1
loc_top_offset[1][0]
0
pixel_dist_x[l][0]
0
pixel_dist_y[l][0]
0
sub_view_id[2]
0
num_parts_minus1 [2]
0
loc_left_offset[2][0]
0
loc_top_offset[2][0]
1
pixel_dist_x[2][0]
0
pixel_dist_y[2][0]
0
sub_view_id[3]
0
num_parts_minus1[3]
0
loc_left_offset[3][0]
1
loc_top_offset[3][0]
1
pixel_dist_x[3][0]
0
pixel_dist_y[3][0]
0
Значения синтаксиса для второго варианта осуществления на фиг.22 являются всецело прежними, за исключением следующих двух элементов синтаксиса: loc_left_offset[3][0], равный 5, и loc_top_offset[3][0], равный 3.
Смещение указывает, что пиксели, соответствующие проекции, должны начинаться в определенном смещенном местоположении. Это показано на фиг.22 (2220). Это может делаться, например, когда две проекции создают изображения, в которых появляются объекты, смещенные с одной проекции на другую. Например, если первая и вторая камеры (представляющие первую и вторую проекции) снимают картинки объекта, объект может появляться смещенным на пять пикселей вправо на второй проекции по сравнению с первой проекцией. Это означает, что пиксель (i-5, j) в первой проекции соответствует пикселю (i, j) по второй проекции. Если пиксели двух проекций мозаично размещены просто пиксель за пикселем, то может не быть большой корреляции между соседними пикселями в мозаике, и выигрыш от пространственного кодирования может быть небольшим. Наоборот, посредством сдвига мозаичного размещения, так что пиксель (i-5, j) из проекции один помещается возле пикселя(i, j) из проекции два, пространственная корреляция может быть увеличена, а пространственное кодирование также вновь может быть увеличено. Это, например, следует потому, что соответствующие пиксели для объекта в первой и второй проекциях мозаично размещены рядом друг с другом.
Таким образом, наличие loc_left_offset и loc_top_offset могут приносить выгоду в эффективности кодирования. Информация о смещении может быть получена внешним средством. Например, информация о положении камер или векторы глобальной несоразмерности между проекциями могут использоваться для определения такой информации о смещении.
В результате смещения, некоторым пикселям в псевдопроекции не назначены значения пикселя из какой-нибудь проекции. Продолжая пример, приведенный выше, при мозаичном размещении пикселя(i-5, j) из проекции один около пикселя(i, j) из проекции два, для значений i=0... 4 нет пикселя (i-5, j) из проекции один для мозаичного размещения, поэтому, такие пиксели пусты в мозаике. Что касается тех пикселей в псевдопроекции (мозаике), которым не назначены значения пикселей из какой-нибудь проекции, по меньшей мере одна реализация использует процедуру интерполяции, подобную процедуре интерполяции подпикселя при компенсации движения в AVC. То есть, пустые пиксели мозаики могут интерполироваться из соседних пикселей. Такая интерполяция может иметь результатом большую пространственную корреляцию в мозаике и большую эффективность кодирования для мозаики.
При кодировании видео, можем выбирать разный тип кодирования для каждой картинки, такой как I-, P- и B-картинки. Для многопроекционного кодирования видео, в дополнение, определяем привязку для картинок без привязки. В варианте осуществления, предположим, что выбор группировки может производиться на основании типа картинки. Эта информация группировки сигнализируется в высокоуровневом синтаксисе.
Обращаясь к фиг.11, пример 5 проекций, мозаично размещенных в едином кадре, в целом указан номером 1100 ссылки. В частности, последовательность танцевального зала показана с 5 проекциями, мозаично размещенными в едином кадре. Дополнительно, может быть видно, что пятая проекция разделена на две части, так что она может быть скомпонована в прямоугольном кадре. Здесь, каждая проекция имеет размер QVGA, поэтому, общим размером кадра является 640×600. Поскольку 600 не является кратным 16, оно должно быть расширено до 608.
Для этого примера, возможное сообщение SEI могло бы быть как показанное в таблице 4
<b>Таблица 4</b>
multiview_display_info(payloadSize) {
Значение
num_coded_views_minusl
5
org_pic_width_in_mbs_minus1
40
org_pic_height_in_mbs_minus1
30
view_id[0]
0
num_parts[view_id[0]]
1
depth_flag[view_id[0]][0]
0
flip_dir[view_id[0]][0]
0
loc_left_offset[view_id[0]] [0]
0
loc_top_offset[view_id[0]] [0]
0
frame_crop_left_offset[view_id[0]] [0]
0
frame_crop_right_offset[view_id[0]][0]
320
frame_crop_top_offset[view_id[0]][0]
0
frame_crop_bottom_offset[view_id[0]][0]
240
upsample_view_flag[view_id[0]]
1
if(upsample_view_flag[view_id[0]]) {
vert_dim [view_id[0]]
6
hor_dim[view_id[0]]
6
quantizer[view_id[0]]
32
for (yuv=0; yuv<3; yuv++) {
for (y=0; y<vert_dim[view_id[i]]-1; y ++) {
for (x=0; x<hor_dim[view_id[i]]-1; x ++)
filter_coeffs[view_id[i]] [yuv][y][x]
XX
view_id[l]
1
num_parts[view_id[1]]
1
depth_flag[view_id[0]][0]
0
flip_dir[view_id[1]][0]
0
loc_left_offset[view_id[1]][0]
0
loc_top_offset[view_id[1]][0]
0
frame_crop_left_offset[view_id[1]][0]
320
frame_crop_right_offset[view_id[1]][0]
640
frame_crop_top_offset[view_id[1]][0]
0
frame_crop_bottom_offset[view_id[1]][0]
320
upsample_view_flag[view_id[1]]
1
if(upsample_view_flag[view_id[1]]) {
vert_dim[view_id[1]]
6
hor_dim[view_id[1]]
6
quantizer[view_id[1]]
32
for (yuv=0; yuv<3; yuv++) {
for (y=0; y<vert_dim[view_id[i]]-1; y ++) {
for (x=0; x<hor_dim[view_id[i]]-1; x ++)
filter_coeffs[view_id[i]] [yuv][y][x]
XX
......(similarly for view 2,3)
view_id[4]
4
num_parts[view_id[4]]
2
depth_flag[view_id[0]][0]
0
flip_dir[view_id[4]][0]
0
loc_left_offset[view_id[4]][0]
0
loc_top_offset[view_id[4]][0]
0
frame_crop_left_offset[view_id[4]] [0]
0
frame_crop_right_offset[view_id[4]][0]
320
frame_crop_top_offset[view_id[4]] [0]
480
frame_crop_bottom_offset[view_id[4]][0]
600
flip_dir[view_id[4]][1]
0
loc_left_offset[view_id[4]][1]
0
loc_top_offset[view_id[4]][1]
120
frame_crop_left_offset[view_id[4]][1]
320
frame_crop_right_offset[view_id[4]][1]
640
frame_crop_top_offset[view_id[4]][1]
480
frame_crop_bottom_offset[view_id[4]][1]
600
upsample_view_flag[view_id[4]]
1
if(upsample_view_flag[view_id[4]]) {
vert_dim[view_id[4]]
6
hor_dim[view_id[4]]
6
quantizer[view_id[4]]
32
for (yuv=0; yuv<3; yuv++) {
for (y=0; y<vert_dim[view_id[i]]-1; y ++) {
for (x=0; x<hor_dim[view_id[i]]-1; x ++)
filter_coeffs[view_id[i]] [yuv][y][x]
XX
Таблица 5 показывает общую синтаксическую структуру для передачи информации о многочисленных проекциях для примера, показанного в таблице 4.
<b>Таблица 5</b>
multiview_display_info(payloadSize) {
C
Дескриптор
num_coded_views_minus1
5
ue(v)
org_pic_width_in_mbs_minus1
5
ue(v)
org_pic_height_in_mbs_minus1
5
ue(v)
for(i=0; i<= num_coded_views_minus1; i++) {
view_id[i]
5
ue(v)
num_parts[view_id[i]]
5
ue(v)
for(j=0; j<= num_parts[i]; j++) {
depth_flag[view_id[i]][j]
flip_dir[view_id[i]][j]
5
u(2)
loc_left_offset[view_id[i]][j]
5
ue(v)
loc_top_offset[view_id[i]][j]
5
ue(v)
frame_crop_left_offset[view_id[i]][j]
5
ue(v)
frame_crop_right_offset[view_id[i]][j]
5
ue(v)
frame_crop_top_offset[view_id[i]][j]
5
ue(v)
frame_crop_bottom_offset[view_id[i]][j]
5
ue(v)
}
upsample_view_flag[view_id[i]]
5
u(1)
if(upsample_view_flag[view_id[i]])
upsample_filter[view_id[i]]
5
u(2)
if(upsample_fiter[view_id[i]] == 3) {
vert_dim[view_id[i]]
5
ue(v)
hor_dim[view_id[i]]
5
ue(v)
quantizer[view_id[i]]
5
ue(v)
for (yuv=0; yuv<3; yuv++) {
for (y=0; y<vert_dim[view_id[i]]-1; y ++) {
for (x=0; x<hor_dim[view_id[i]]-1; x ++)
filter_coeffs[view_id[i]] [yuv][y][x]
5
se(v)
}
}
}
}
}
Со ссылкой на фиг.23, показано устройство 2300 обработки видео. Устройство 2300 обработки видео, например, может быть телевизионной абонентской приставкой или другим устройством, которое принимает кодированное видео и, например, предоставляет декодированное видео для отображения пользователю или для сохранения. Таким образом, устройство 2300 может предоставлять их вывод на телевизор, компьютерный монитор, либо компьютер или другое устройство обработки.
Устройство 2300 включает в себя декодер 2310, который принимает сигнал 2320 данных. Сигнал 2320 данных, например, может включать в себя совместимый с AVC или MVC поток. Декодер 2310 декодирует весь или часть принятого сигнала 2320 и предоставляет, в качестве выходных данных, декодированный видеосигнал 2330 и информацию 2340 о мозаичном размещении. Декодированное видео 2330 и информация 2340 о мозаичном размещении предоставляются в селектор 2350. Устройство 2300 также включает в себя пользовательский интерфейс 2360, который принимает пользовательский ввод 2370. Пользовательский интерфейс 2360 предоставляет сигнал 2380 выбора картинки, на основании пользовательского ввода 2370, в селектор 2350. Сигнал 2380 выбора картинки и пользовательский ввод 2370 указывают, какие из многочисленных картинок пользователь желает иметь отображенными. Селектор 2350 предоставляет выбранную картинку(и) в качестве выходных данных 2390. Селектор 2350 использует информацию 2380 о выборе картинки для выбора, какие картинки в декодированном видео 2330 предоставлять в качестве выходных данных 2390. Селектор 2350 использует информацию 2340 о мозаичном размещении для определения местоположения выбранной картинки(ок) в декодированном видео 2330.
В различных реализациях, селектор 2350 включает в себя пользовательский интерфейс 2360, а в других реализациях, никакой пользовательский интерфейс 2360 не нужен, так как селектор 2350 принимает пользовательский ввод 2370 непосредственно без того, чтобы выполнялась отдельная интерфейсная функция. Селектор 2350, например, может быть реализован в программном обеспечении или в качестве интегральной схемы. Селектор 2350 также может заключать в себе декодер 2310.
В более общем смысле, декодеры различных реализаций, описанных в этой заявке, могут предоставлять декодированные выходные данные, которые включают в себя полностью мозаику. Дополнительно или в качестве альтернативы, декодеры могут предоставлять декодированные выходные данные, которые включают в себя только одну или более выбранных картинок (например, изображений и сигналов глубины) из мозаики.
Как отмечено выше, высокоуровневый синтаксис может использоваться для выполнения сигнализации в соответствии с одним или более вариантами осуществления настоящих принципов. Высокоуровневый синтаксис, например, может использоваться, но не в качестве ограничения, для сигнализации любого из следующего: количества кодированных проекций, присутствующих в большем кадре; исходных ширины и высоты всех проекций; для каждой кодированной проекции, идентификатора проекции, соответствующего проекции; для каждой кодированной проекции, количества частей, на которое делится кадр проекции; для каждой части проекции, направления транспонирования (которым, например, может быть отсутствие транспонирования, только горизонтальное транспонирование, только вертикальное транспонирование или горизонтальное и вертикальное транспонирование); для каждой части проекции, левого положения в пикселях или количестве макроблоков, где находится текущая часть в заключительном кадре для проекции; для каждой части проекции, верхнего положения части в пикселях или количестве макроблоков, где находится текущая часть в заключительном кадре для проекции; для каждой части проекции, левого положения, в текущем большом декодированном/кодированном кадре, окна вырезки в пикселях или количестве макроблоков; для каждой части проекции, правого положения, в текущем большом декодированном/кодированном кадре, окна вырезки в пикселях или количестве макроблоков; для каждой части проекции, верхнего положения, в текущем большом декодированном/кодированном кадре, окна вырезки в пикселях или количестве макроблоков; и для каждой части проекции, нижнего положения, в текущем большом декодированном/кодированном кадре, окна вырезки в пикселях или количестве макроблоков; для каждой кодированной проекции, необходимо ли проекции подвергаться повышающей дискретизации перед выводом (где, если повышающей дискретизации нужно выполняться, высокоуровневый синтаксис может использоваться для указания способа для повышающей дискретизации, в том числе, но не в качестве ограничения, 6-отводный фильтр AVC, 4-отводный фильтр SVC, билинейный фильтр или специализированный одномерный, двумерный линейный или нелинейный фильтр).
Должно быть отмечено, что термины «кодер» и «декодер» подразумевают обобщенные конструкции и не ограничены никакими конкретными функциями или признаками. Например, декодер может принимать модулированную несущую, которая несет кодированный битовый поток, и демодулировать кодированный битовый поток, а также декодировать битовый поток.
Были описаны различные способы. Многие из этих способов детализированы, чтобы дать пространное раскрытие. Однако, отмечено, что предполагаются варианты, которые могут менять один или более специфичных признаков, описанных для этих способов. Кроме того, многие из признаков, которые перечислены, известны в данной области техники и, соответственно, более детально не описаны.
Кроме того, была сделана ссылка на использование высокоуровневого синтаксиса для отправки определенной информации в некоторых реализациях. Должно быть понятно, однако, что другие реализации используют более низкоуровневый синтаксис, или действительно в целом другие механизмы (например, такие как отправка информации в качестве части кодированных данных) для предоставления той же самой информации (или вариантов такой информации).
Различные реализации предусматривают мозаичное размещение и надлежащую сигнализацию, чтобы предоставить многочисленным проекциям (в более общем смысле, картинкам) возможность мозаично размещаться в единую картинку, кодироваться в качестве единой картинки и отправляться в качестве единой картинки. Сигнальная информация может предоставлять постпроцессору возможность извлекать проекции/картинки порознь. К тому же, многочисленные картинки, которые подвергаются мозаичному размещению, могли бы быть проекциями, но по меньшей мере одна из картинок могла бы быть информацией о глубине. Эти реализации могут давать одно или более преимуществ. Например, пользователи могут пожелать отображать многочисленные проекции мозаичным образом, и эти различные реализации дают эффективный способ для кодирования и передачи или сохранения таких проекций посредством их мозаичного размещения перед кодированием и передачей/сохранением их мозаичным образом.
Реализации, которые мозаично размещают многочисленные проекции в контексте AVC и/или MVC, также дают дополнительные преимущества. AVC, по видимому, используется только для одиночной проекции, поэтому, дополнительная проекция не ожидается. Однако, такие основанные на AVC реализации могут предусматривать многочисленные проекции в среде AVC, так как мозаично размещенные проекции, например, могут компоноваться так, что декодер знает, что такие мозаичные картинки принадлежат разным проекциям (например, верхняя левая картинка в псевдопроекции является проекцией 1, верхняя правая картинка является проекцией 2, и т.д.).
Дополнительно, MVC уже включает в себя многочисленные проекции, значит, не ожидается, что многочисленные проекции должны быть включены в одиночную псевдопроекцию. Кроме того, MVC имеет ограничение на количество проекций, которое может поддерживаться, и такие основанные на MVC реализации эффективно увеличивают количество проекций, которые могут поддерживаться посредством предоставления возможности (как в основанных на AVC реализациях) мозаично размещаться дополнительным проекциям. Например, каждая псевдопроекция может соответствовать одной из поддерживаемых проекций MVC, и декодер может знать, что такая «поддерживаемая проекция» фактически включает в себя четыре проекции в предварительно скомпонованном мозаичном порядке. Таким образом, в такой реализации, количество возможных проекций в четыре раза больше количества «поддерживаемых проекций».
В описании, которое следует, более высокоуровневый синтаксис, такой как сообщение SEI, расширяется в различных реализациях, чтобы включать в себя информацию о том, какие из множества режимов пространственного перемежения являются приписываемыми картинкам, которые подвергнуты мозаичному размещению в качестве единой картинки. Пространственное перемежение может происходить во множестве режимов, например, таких как поперечный, верхне-нижнее, вертикальное чередование, горизонтальное чередование и шахматный порядок. Дополнительно, синтаксис расширен, чтобы включать в себя информацию о соотношении касательно контента в подвергнутых мозаичному размещению картинках. Информация о соотношении может включать в себя обозначение левой и правой картинок в стереоскопическом изображении или идентификацию в качестве картинки с глубинами, когда два измерения плюс глубина используются для картинок, или даже указание, что картинки формируют сигнал видео с многослойной глубиной (LDV).
Как уже отмечено выше в материалах настоящей заявки, синтаксис предполагается в качестве реализуемого в любом высокоуровневом синтаксисе помимо сообщения SEI, таком как синтаксис на уровне заголовка секции, уровне набора параметров картинок (PPS), уровне набора параметров последовательности (SPS), уровне набора параметров проекции (VPS) и уровне заголовка блока сетевого уровня абстракции (NAL). Дополнительно, предполагается, что низкоуровневый синтаксис может использоваться для сигнализации информации. Даже еще предполагается, что информация может сигнализироваться вне полосы различными способами.
Синтаксис сообщения SEI для шахматного пространственного перемежения, описанный в вышеупомянутом проекте поправки AVC, определен в таблице 6, как изложено ниже:
<b>Таблица 6</b>
spatially_interleaved_pictures(payloadSize) {
C
Дескриптор
<b>spatially_interleaved_pictures_id</b>
5
ue(v)
<b>spatially_interleaved_pictures_cancel_flag</b>
5
u(1)
if(!spatially_interleaved_pictures_cancel_flag) {
<b>basic_spatial_interleaving_type_id</b>
5
u(8)
<b>spatially_interleaved_pictures_repetition_period</b>
5
ue(v)
}
<b>additional_extension_flag</b>
5
u(1)
}
Это сообщение SEI информирует декодер, что выходные декодированные картинки сформированы пространственным перемежением многочисленных отдельных картинок с использованием указанной схемы пространственного перемежения. Информация в этом сообщении SEI может использоваться декодером для надлежащего обращенного перемежения и обработки данных картинки для отображения и других целей.
Семантика для определенных значений синтаксиса сообщения SEI пространственно перемеженных картинок в таблице 6 является следующей:
spatially_interleaved_pictures_id
идентификатор_пространственно_перемеженных_картинок
() содержит в себе номер идентификации, который может использоваться для идентификации использования сообщения SEI пространственно перемеженных картинок.
spatially_interleaved_pictures_cancel_flag
флаг_отмены_пространственно_перемеженных_картинок
(), равный 1, указывает, что сообщение SEI пространственно перемеженных картинок отменяет последействие любого предыдущего сообщения SEI пространственно перемеженных картинок в выходной команде. spatially_interleaved_pictures_cancel_flag, равный 0, указывает, что информация о пространственно перемеженных картинках соблюдается.
basic_spatial_interleaving_type_id
идентификатор_основного_типа_пространственного_перемежения
() указывает тип пространственного перемежения многочисленных картинок, включенных в единой мозаичной картинке.
basic_spatial_interleaving_type_id, равный 0, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «шахматном порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.26.
basic_spatial_interleaving_type_id, равный 1, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «шахматном порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.26, и дополнительно указывает, что две составляющих картинки образуют левую и правую проекции сцены стереоскопического обзора, как проиллюстрировано на фиг.26.
spatially_interleaved_pictures_repetition_period
период_повторения_пространственно_перемеженных_картинок
() задает последействие сообщения SEI пространственно перемеженных картинок и может задавать интервал счета очередности картинки, в пределах которого другое сообщение SEI пространственно перемеженных картинок с тем же самым значением spatially_interleaved_pictures_id или конец кодированной видеопоследовательности будет присутствовать в битовом потоке.
spatially_interleaved_pictures_repetition_period, равный 0, предписывает, что сообщение SEI пространственно перемеженных картинок применяется только к текущей декодированной картинке. spatially_interleaved_pictures_repetition_period, равный 1, предписывает, что сообщение SEI пространственно перемеженных картинок продолжает действовать в выходной команде до тех пор, пока истинно любое из следующих условий:
- Начинается новая кодированная видеопоследовательность.
- Картинка в блоке доступа, содержащая в себе сообщение SEI пространственно перемеженных картинок с тем же самым значением spatially_interleaved_pictures_id, выводится, обладая PicOrderCnt(), большим чем PicOrderCnt(CurrPic).
spatially_interleaved_pictures_repetition_period, равный 0 или равный 1, указывает, что другое сообщение SEI пространственно перемеженных картинок с тем же самым значением spatially_interleaved_pictures_id может или не может быть присутствующим.
spatially_interleaved_pictures_repetition_period, больший чем 1, предписывает, что сообщение SEI пространственно перемеженных картинок продолжает действовать до тех пор, пока истинно любое из следующих условий:
- Начинается новая кодированная видеопоследовательность.
- Картинка в блоке доступа, содержащая в себе сообщение SEI пространственно перемеженных картинок с тем же самым значением spatially_interleaved_pictures_id, выводится, обладая PicOrderCnt(), большим чем PicOrderCnt(CurrPic), и меньшим чем или равным PicOrderCnt(CurrPic) + spatially_interleaved_pictures_repetition_period.
spatially_interleaved_pictures_repetition_period, больший чем 1, указывает, что другое сообщение SEI пространственно перемеженных картинок с тем же самым значением spatially_interleaved_pictures_id будет присутствовать для картинки в блоке доступа, которая выводится имеющей PicOrderCnt(), большее чем PicOrderCnt(CurrPic), и меньшее чем или равное PicOrderCnt(CurrPic) + spatially_interleaved_pictures_repetition_period; если не заканчивается битовый поток и новая кодированная видеопоследовательность не начинается без вывода такой картинки.
additional_extension_flag
флаг_дополнительного_расширения
(), равный 0, указывает, что никакие дополнительные данные не следуют в пределах сообщения SEI пространственно перемеженных картинок.
basic_spatial_interleaving_type_id
basic_spatial_interleaving_type_id
Без изменения синтаксиса, показанного в таблице 6, реализация по этой заявке предоставляет информацию о соотношении и информацию о пространственном перемежении в пределах примерного сообщения SEI. Диапазон возможных значений для  модифицируется и расширяется в этой реализации, чтобы указывать скорее множество способов пространственного перемежения, чем только одного способа шахматного порядка. Более того, параметр  применяется, чтобы указывать, что конкретный тип пространственного перемежения присутствует в картинке, и что составляющие перемеженные картинки связаны друг с другом. В этой реализации, для basic_spatial_interleaving_type_id, семантика является следующей:
Значение 2 или 3 означает, что единая картинка содержит в себе «поперечное» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.27. Значение 3 дополнительно означает, что две составляющих картинки образуют левую и правую проекции сцены стереоскопического обзора. Что касается поперечного перемежения, одна картинка помещается с одной стороны другой картинки, так что комбинированная картинка включает в себя два изображения рядом.
Значение 4 или 5 означает, что единая картинка содержит в себе «верхне-нижнее» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.28. Значение 5 дополнительно означает, что две составляющих картинки образуют левую и правую проекции сцены стереоскопического обзора. Что касается верхне-нижнего перемежения, одна картинка помещается над другой картинкой, так что комбинированная картинка выглядит имеющей одно изображение над другим.
Значение 6 или 7 означает, что единая картинка содержит в себе «построчное» перемежение или просто чередование строк соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.29. Значение 7 дополнительно означает, что две составляющих картинки образуют левую и правую проекции сцены стереоскопического обзора. Что касается построчного перемежения, следующие друг за другом строки единой картинки чередуются от одной составляющей картинки к другому. В своей основе, единая картинка является чередованием горизонтальных секций составляющих изображений.
Значение 8 или 9 означает, что единая картинка содержит в себе «постолбцовое» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.30. Значение 9 дополнительно означает, что две составляющих картинки образуют левую и правую проекции сцены стереоскопического обзора. Что касается постолбцового перемежения, следующие друг за другом столбцы единой картинки чередуются от одной составляющей картинки к другой. В своей основе, единая картинка является чередованием вертикальных секций составляющих изображений.
В еще одном варианте осуществления синтаксиса для использования в примерном сообщении SEI, чтобы передавать информацию об ассоциативно связанной картинке, несколько дополнительных элементов синтаксиса были включены в таблицу 7 для указания дополнительной информации. Такие дополнительные элементы синтаксиса, например, включены в состав, чтобы указывать ориентацию одной или более составляющих картинок (например, транспонирование), чтобы отдельно указывать, существует ли соотношение левой-правой стереоскопической пары для изображений, чтобы указывать, необходима ли повышающая дискретизация для обеих составляющих картинок, и чтобы указывать возможную степень и направление повышающей дискретизации.
<b>Таблица 7</b>
spatially_interleaved_pictures(payloadSize) {
<b>C</b>
<b>Дескриптор</b>
<b>spatially_interleaved_pictures_id</b>
<b>5</b>
ue(v)
<b>spatially_interleaved_pictures_cancel_flag</b>
<b>5</b>
U(l)
if (!spatially_interleaved_pictures_cancel_flag) {
<b>basic_spatial_interleaving_type_id</b>
<b>5</b>
<b>U(8)</b>
<b>stereo_pair_flag</b>
<b>5</b>
U(1)
<b>upsample_conversion_horizontal_flag</b>
<b>5</b>
U(1)
<b>upsample_conversion_vertical_flag</b>
<b>5</b>
U(1)
if (basic_spatial_interleaving_type_id = = 1 or basic_spatial_interleaving_type_id = = 2) <b>{</b>
<b>flip_flag</b>
<b>5</b>
U(1)
<b>}</b>
<b>spatially_interleaved_pictures_repetition_period</b>
<b>5</b>
ue(v)
<b>}</b>
<b>additional_extension_flag</b>
<b>5</b>
U(1)
<b>}</b>
Семантика определена, как приведено ниже:
basic_spatial_interleaving_type_id
идентификатор_основного_типа_пространственного_перемежения
() указывает тип пространственного перемежения картинок.
basic_spatial_interleaving_type_id, равный 0, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «шахматном порядке» перемежение соответствующих плоскостей двух картинок, как в более раннем предложении (см. фиг.26).
basic_spatial_interleaving_type_id, равный 1, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «поперечном порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.27.
basic_spatial_interleaving_type_id, равный 2, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «верхне-нижнем порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.28.
basic_spatial_interleaving_type_id, равный 3, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «построчном порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.29.
basic_spatial_interleaving_type_id, равный 4, указывает, что каждая составляющая плоскость декодированных картинок содержит в себе основанное на «постолбцовом порядке» перемежение соответствующих плоскостей двух картинок, как проиллюстрировано на фиг.30.
stereo_pair_flag
флаг_стереоскопической_пары
() указывает, имеют ли две составляющих картинки соотношение в качестве формирующих левую и правую проекцию сцены стереоскопического обзора. Значение 0 указывает, что составляющие картинки не формируют левую и правую проекции. Значение 1 указывает, что они связаны в качестве формирующих левую и правую проекции изображения.
upsample_conversion_horizontal_flag
флаг_горизонтального_преобразования_повышающей_дискретизации
() указывает, необходима ли двум составляющим картинкам повышающая дискретизация в горизонтальном направлении после того, как они извлечены из единой картинки во время кодирования. Значение 0 указывает, что повышающая дискретизации не нужна. Таковое соответствует коэффициенту повышающей дискретизации ноль. Значение 1 указывает, что требуется повышающая дискретизация согласно коэффициенту дискретизации два.
upsample_conversion_vertical_flag
флаг_вертикального_преобразования_повышающей_дискретизации
() указывает, необходима ли двум составляющим картинкам повышающая дискретизация в вертикальном направлении после того, как они извлечены из единой картинки во время кодирования. Значение 0 указывает, что повышающая дискретизации не нужна. Таковое соответствует коэффициенту повышающей дискретизации ноль. Значение 1 указывает, что требуется повышающая дискретизация согласно коэффициенту дискретизации два.
Как подробнее описано ниже, предполагается, что многие аспекты операции повышающей дискретизации могут передаваться в сообщении SEI, так что операция повышающей дискретизации надлежащим образом обрабатывается во время декодирования картинки. Например, может указываться дополнительный диапазон коэффициентов для повышающей дискретизации; также может указываться тип фильтра повышающей дискретизации; также может указываться фильтр понижающей дискретизации, так что декодер может определять надлежащий, или даже оптимальный, фильтр для повышающей дискретизации. Также предполагается, что информация о коэффициентах фильтра, включающая в себя количество и значение коэффициентов фильтра повышающей дискретизации, дополнительно может указываться в сообщении SEI, так что приемник выполняет предпочтительную операцию повышающей дискретизации.
Коэффициент дискретизации указывает отношение между исходным размером и дискретизированным размером видеокартинки. Например, когда коэффициент дискретизации имеет значение 2, исходный размер картинки в два раза больше размера дискретизированной картинки. Размер картинки обычно является показателем разрешения в пикселях. Поэтому, подвергнутая горизонтальной понижающей дискретизации картинка требует соответствующей горизонтальной повышающей дискретизации согласно тому же коэффициенту для восстановления разрешения исходной видеокартинки. Если исходные картинки имеют ширину в 1024 пикселя, например, они могут быть подвергнуты горизонтальной понижающей дискретизации согласно коэффициенту дискретизации 2, чтобы становиться подвергнутой понижающей дискретизации картинкой с шириной 512 пикселей. Размер картинки обычно является показателем разрешения в пикселях. Подобный анализ может быть показан для вертикальной понижающей дискретизации или повышающей дискретизации. Коэффициент дискретизации может применяться к понижающей дискретизации или повышающей дискретизации, которым полагаются комбинированный, горизонтальный и вертикальный, подход.
flip_flag
флаг_транспонирования
() указывает, транспонирована или нет вторая составляющая картинка. Значение 0 указывает, что транспонирование не присутствует в такой картинке. Значение 1 указывает, что транспонирование выполняется. Специалистами в данной области техники должно пониматься, что транспонирование должно влечь за собой поворот на 180° вокруг центральной оси в плоскости картинки. Направление транспонирования, в этом варианте осуществления, определяется типом перемежения. Например, когда поперечное перемежение (basic_spatial_interleaving_type_id равен 1), присутствует в составляющих картинках, предпочтительно транспонировать правую картинку в горизонтальном направлении (то есть вокруг вертикальной оси), если указано надлежащим значением flip_flag (см. фиг.31). Когда верхне-нижнее перемежение (basic_spatial_interleaving_type_id равен 2) присутствует в составляющих картинках, предпочтительно транспонировать нижнюю картинку в вертикальном направлении (то есть вокруг центральной горизонтальной оси), если указано надлежащим значением flip_flag (см. фиг.32). Несмотря на то, что транспонирование второй составляющей картинки было описано в материалах настоящей заявки, предполагается, что другие примерные варианты осуществления могут влечь за собой транспонирование первой картинки, такой как верхняя картинка при верхне-нижнем перемежении или левая картинка при поперечном перемежении. Конечно, для того чтобы обрабатывать эти дополнительные степени свободы для flip_flag, может быть необходимым увеличить диапазон значений или привнести другую семантику, относящуюся к нему.
Также предполагается, что дополнительные варианты осуществления могут предоставлять возможность транспонирования картинки в обоих, горизонтальном и вертикальном, направлениях. Например, когда четыре проекции подвергнуты мозаичному размещению вместе в единой картинке с одной проекцией (то есть картинкой) на квадрант, как показано на фиг.2, можно заставлять верхний левый квадрант включать в себя первую проекцию, которая не транспонирована, наряду с тем, что верхний правый квадрант включает в себя третью проекцию, которая транспонирована только вертикально, и тогда как нижний правый квадрант включает в себя четвертую проекцию, которая транспонирована как горизонтально, так и вертикально. Посредством мозаичного размещения или перемежения этим способом, может быть видно, что границы на стыке между проекциями имеют большую вероятность обладания общим контентом сцены по обеим сторонам границ от соседних проекций в картинке. Этот тип транспонирования может обеспечивать дополнительную эффективность при сжатии. Указание этого типа транспонирования предполагается в пределах объема этого раскрытия.
Кроме того, предполагается, что синтаксис в таблице 7 может быть перенят для использования при обработке перемежения в двух измерениях плюс глубина. Например, могут быть разработаны коммерческие устройства отображения, которые допускают такой формат в качестве входных данных. Примерный синтаксис для такого применения изложен в таблице 8. Многое из семантики уже было определено выше. Только вновь привнесенная семантика описана ниже.
<b>Таблица 8</b>
spatially_interleaved_pictures(payloadSize) {
<b>Дескриптор</b>
<b>spatially_interleaved_pictures_id</b>
ue(v)
<b>spatially_interleaved_pictures_cancel_flag</b>
<b>u(1)</b>
if(!spatially_interleaved_pictures_cancel_flag) {
<b>basic_spatial_interleaving_type_id</b>
u(8)
<b>semantics_id</b>
u(1)
<b>upsample_conversion_horizontal_flag</b>
u(1)
<b>upsample_conversion_vertical_flag</b>
u(1)
<b>spatially_interleaved_pictures_repetition_period</b>
ue(v)
if (basic_spatial_interleaving_type_id = = 1 or basic_spatial_interleaving_type_id = = 2) {
<b>flip_flag</b>
u(1)
}
if (semantics_id = = 1) {
camera_parameter_set()
}
}
<b>additional_extension_flag</b>
u(1)
}
semantics_id
идентификатор_семантики
() замещает stereo_pair_flag в предыдущем примерном варианте осуществления и используется для указания, какое соотношение подразумевается для двух перемеженных картинок, другими словами, какие две картинки физически имеют значение. Значение 0 указывает, что две составляющих картинки образуют левую и правую проекцию изображения. Значение 1 указывает, что вторая картинка представляет соответствующую карту глубин первой составляющей картинки. Фиг.34 показывает примерную единую картинку, в которой составляющие изображения с видео и глубиной (например, 2D + Z) перемежаются поперечным образом. Должно быть принято во внимание, что другие способы перемежения могут указываться конкретным значением basic_spatial_interleaving_type_id. Значение 2 указывает, что соотношение между двумя перемеженными картинками не задано. Значения, большие чем 2, могут использоваться для указания дополнительных соотношений.
camera_parameter_set
(набор_параметров_камеры) указывает параметры сцены, относящиеся к камере. Параметры могут появляться в этом же самом сообщении SEI, или параметры могут передаваться в другом сообщении SEI, либо они могут появляться в пределах других синтаксисов, таких как SPS, PPS, заголовки секций, и тому подобное. Параметры камеры обычно включают в себя по меньшей мере фокусное расстояние, длину базовой линии, положение(я) камеры, Znear (минимальное расстояние между сценой и камерами) и Zfar (максимальное расстояние между сценой и камерами). Набор параметров камеры также может включать в себя полный набор параметров для каждой камеры, в том числе, матрицу внутренней калибровки 3×3, матрицу поворота 3×3 и вектор трехмерного смещения. Параметры камеры, например, используются при визуализации, а также, возможно, при кодировании.
При использовании сообщения SEI или другого синтаксиса, сопоставимого с показанным в таблице 8, может быть возможным избежать необходимости для синхронизации на уровне системы между видео и глубиной. Это получается, так как видео и ассоциативно связанная глубина уже подвергнуты мозаичному размещению в один единый кадр.
Формат видео с многослойной глубиной (LDV) для картинок показан на фиг.33. На этой фигуре, перемежаются четыре картинки - поперечным и верхне-нижним образом - для формирования комбинированной картинки. Картинка верхнего левого квадранта представляет уровень центральной проекции, тогда как картинка верхнего правого квадранта представляет уровень центральной глубины. Подобным образом, картинка нижнего левого квадранта представляет уровень проекции смыкания, тогда как картинка нижнего правого квадранта представляет уровень глубины смыкания. Формат, показанный на фиг.33, может использоваться в качестве входного формата для промышленного автостереоскопического устройства отображения.
semantics_id
Наличие LDV указано с использованием синтаксиса, подобного показанному в предыдущих вариантах осуществления. Главным образом, семантика  расширена для привнесения варианта выбора LDV, как изложено ниже:
<b>Таблица 9</b>
spatially_interleaved_pictures( payloadSize) {
<b>C</b>
<b>Дескриптор</b>
<b>spatially_interleaved_pictures_id</b>
<b>5</b>
ue(v)
<b>spatially_interleaved_pictures_cancel_flag</b>
<b>5</b>
u(1)
if( !spatially_interleaved_pictures_cancel_flag) {
<b>basic_spatial_interleaving_type_id</b>
<b>5</b>
u(8)
<b>semantics_id</b>
<b>5</b>
u(1)
<b>upsample_conversion_horizontal_flag</b>
<b>5</b>
u(1)
<b>upsample_conversion_vertical_flag</b>
5
u(1)
<b>spatially_interleaved_pictures_repetition_period</b>
5
ue(v)
if (basic_spatial_interleaving_type_id = = 1 or basic_spatial_interleaving_type_id = = 2) {
<b>flip_flag</b>
5
u(1)
}
if (semantics_id = = 1 || semantics_id = = 3) {
camera_parameter_set()
}
}
<b>additional_extension_flag</b>
5
u(1)
}
semantics_id
указывает соотношение между картинками, то есть, какие перемеженные картинки физически имеют значение по отношению друг к другу.
Значения от 0 до 2 означают, что две картинки связаны, как определено выше. Значение 0 указывает, что две картинки формируют левую и правую проекции. Это значение также указывает, что проекции являются стереоскопическими проекциями сцены. Значение 1 указывает, что вторая картинка обозначает соответствующую карту глубин первой картинки, то есть набор картинок 2D+Z. Значение 2 указывает, что соотношение между двумя перемеженными картинками не задано.
Значение 3 указывает, что четыре составляющих картинки перемежаются, и они соответствуют четырем составляющим картинкам представления LDV, например, как показано на фиг.33. Значения, большие чем 3, могут применяться для указаний дополнительных соотношений.
Указания дополнительных соотношений, предполагаемые в материалах настоящей заявки, включают в себя, но не в качестве ограничения: указание, что многочисленные проекции являются многочисленными наборами картинок 2D+Z, также известными как «много проекций плюс глубина» (MVD); указание, что многочисленные проекции представляют изображения в двух наборах картинок LDV, которое известно как расширенное глубиной стереоизображение (DES).
Когда semantics_id равен 3, а basic_spatial_interleaving_type_id равен 1 (поперечное) или 2 (верхне-нижнее), четыре составляющих картинки перемежаются, как показано на фиг.33.
Когда semantics_id равен 3, а basic_spatial_interleaving_type_id равен 0, четыре картинки перемежаются, как проиллюстрировано на фиг.22, в качестве примера 1 (элемент 2210) или примера 2 (элемент 2220), если смещения проекций 1, 2 и 3 относительно проекции 0 дополнительно сигнализируются конкретным указанием, таким как посредством новой семантики в синтаксисе. Предполагается, что, когда semantics_id равен 3, перемежение выполняется для картинок LDV, как показано в примере 1 (элемент 2210) по фиг.22. Кроме того, предполагается, что, когда semantics_id равен 4, перемежение выполняется для картинок LDV, как показано в примере 2 (элемент 2220) по фиг.22. Перемежение для LDV с и без смещения уже было описано выше по фиг.22.
Как отмечено выше, контент трехмерного/стереоскопического видео может кодироваться с использованием стандартов кодирования двухмерного видео. Способ упаковки кадра предоставляет подвергнутым понижающей дискретизации пространственно или даже по времени проекциям возможность упаковываться в один кадр для кодирования. Декодированный кадр распаковывается в составляющие многочисленные проекции, которые, затем, обычно подвергаются повышающей дискретизации в исходное разрешение.
Повышающая дискретизация, а более точно, фильтр повышающей дискретизации, играет важную роль в качестве реконструкции составляющих проекций или картинок. Выбор фильтра повышающей дискретизации типично зависит от фильтра понижающей дискретизации, используемого в кодере. Качество каждого подвергнутого повышающей дискретизации декодированной картинки может улучшаться, если информация о фильтре понижающей дискретизации или повышающей дискретизации передается в декодер в битовом потоке или посредством другого нестандартизованного средства. Хотя характеристики фильтра повышающей дискретизации в декодере не обязательно ограничены характеристиками фильтра понижающей дискретизации в кодере, такими, как согласно обратному или взаимному соотношению, может ожидаться, что согласованный фильтр повышающей дискретизации должен обеспечивать оптимальную реконструкцию сигнала. В по меньшей мере одной реализации из экспериментальной практики, было определено, что сообщение SEI может использоваться для сигнализирования параметров повышающей дискретизации в декодер. В других реализациях, предполагается, что параметры фильтра повышающей дискретизации и понижающей дискретизации указываются видеодекодеру в пределах сообщения SEI. Типичные видеокодеры и видеодекодеры AVC H.264/MPEG-4 изображены на фиг.3 и 4, соответственно, как описано выше. Эти устройства пригодны для осуществления на практике аспектов различных реализаций, раскрытых в материалах настоящей заявки. Дополнительно, другие устройства, не изготовленные для специального применения или даже не работающие с AVC H.264/MPEG-4, пригодны для осуществления на практике различных реализаций, описанных в этой заявке.
Как описано выше, сообщение SEI повышающей дискретизации упаковки кадра определено ниже в пределах инфраструктуры упаковки кадров AVC H.264/MPEG-4 для сигнализирования различных фильтров повышающей дискретизации. Этот синтаксис не подразумевается быть ограниченным только сообщением SEI, поскольку предполагается, что информация сообщения также может поставляться другим средством, например, таким как использование в других высокоуровневых синтаксисах, например, таких как SPS, PPS, VPS, заголовок секции и заголовок NAL.
k
В примерном варианте осуществления, применяющем информацию о повышающей дискретизации, фильтр повышающей дискретизации выбирается в качестве 2-мерного симметричного КИХ-фильтра с нечетным количеством отводов, определенных  ненулевыми коэффициентами, представленными в следующей форме:
c
c
i
i
i
Коэффициенты  фильтра нормализованы, из условия чтобы сумма всех коэффициентов  имела значение 0,5 для в диапазоне {1,...,k}.
m×n
n×
2k+n
Примерная последовательность операций горизонтальной повышающей дискретизации, использующая параметры фильтра, показанные выше, описана на протяжении последовательности этапов, как более подробно представлено ниже. Исходное изображение изображено в качестве матрицы X . Матрица A определена в качестве матрицы (), имеющей следующие атрибуты:
где
k×k
- антидиагональная единичная матрица . Исходное изображение X преобразуется в новую матрицу X' изображения с использованием операции тензорного произведения, как изложено ниже:
n×
4k+n-
k
Матрица H определена в качестве матрицы (1), включающей в себя  ненулевых коэффициентов отводов, как показано выше (то есть, ), сдвинутых вдоль каждой следующей одна за другой строки и заполненных находящимися впереди и/или замыкающими нулями, как изложено ниже:
Выходная матрица Y изображения после горизонтальной повышающей дискретизации, в таком случае, представлена в качестве:
Подобным образом, примерная последовательность операций вертикальной повышающей дискретизации описана, как изложено ниже. Новая матрица A' определена подобно такой матрице, как:
Изображение Y затем преобразуется в новую матрицу Y' изображения посредством операции тензорного произведения, как показано ниже:
Выходная матрица изображения после вертикальной повышающей дискретизации, в таком случае, представлена в качестве:
Матрица F - заключительная матрица изображения после преобразования горизонтальной и вертикальной повышающей дискретизации.
Повышающая дискретизация в примере, приведенном выше, была изображена в качестве как горизонтальной, так и вертикальной операции. Предполагается, что очередность операций может быть изменена на обратную, так что вертикальная повышающая дискретизация выполняется перед горизонтальной повышающей дискретизацией. Более того, предполагается, что только один тип повышающей дискретизации может выполняться в определенных случаях.
Для того, чтобы применять сообщение SEI для передачи информации о повышающей дискретизации в декодер, предполагается, что некоторая семантика может быть включена в пределы синтаксисов, представленных выше. Синтаксис, показанный ниже в таблице 10, включает в себя информацию, полезную для повышающей дискретизации в видеодекодере. Синтаксис, приведенный ниже, был сокращен, чтобы показывать только параметры, необходимые для передачи информации о повышающей дискретизации. Специалистами в данной области техники должно быть принято во внимание, что синтаксис, показанный ниже, может комбинироваться с любым одним или более из предыдущих синтаксисов, чтобы передавать существенный объем информации об упаковке кадра, например, относящейся к указанию о соотношении, указанию ориентации, указанию повышающей дискретизации и указанию пространственного перемежения.
<b>Таблица 10</b>
Frame_packing_filter( payloadSize) {
<b>Дескриптор</b>
for(c=0;c<3;c++)
{
<b>number_of_horizontal_filter_parameters[c]</b>
ue(v)
for <b>(i=0; i<number_of_horizontal_filter parameters[c];</b>i++)
{
h[c][i]
s(16)
}
<b>number_of_vertical_filter_parameters[c]</b>
ue(v)
for <b>(i=0; i<number_of_horizontal_filter parameters[c]</b>;i++)
{
v[c][i]
s(16)
}
<b>}</b>
<b>}</b>
Семантика элементов синтаксиса определена ниже, как изложено ниже:
number_of_horizontal_filter_parameters[c]
количество_параметров_горизонтального_фильтра[c]
() указывает порядок (4k-1)-отводного горизонтального фильтра для цветовой компоненты c, где c - одна из трех разных цветовых компонент.
ый
15
15
16
h[c][i] задает i коэффициент горизонтального фильтра для цветовой компоненты c при 16-битной точности, которая находится в диапазоне от -2 до 2-1. Норма фильтра имеет значение 2.
number_of_vertical_filter_parameters
(количество_параметров_вертикального_фильтра) указывает порядок (4k-1)-отводного вертикального фильтра для цветовой компоненты c.
ый
15
15
16
v[c][i] задает i коэффициент вертикального фильтра для цветовой компоненты c при 16-битной точности, которая находится в диапазоне от -2 до 2-1. Норма фильтра имеет значение 2.
Для этого синтаксиса, предполагается, что известный тип фильтра присутствует в декодере. Однако, ожидается, что различные другие типы фильтров повышающей дискретизации могут использоваться в дополнение к, или вместо, вышеописанного 2-мерного симметричного КИХ-фильтра. Такие другие фильтры повышающей дискретизации включают в себя, но не в качестве ограничения, конструкции интерполяционных фильтров, такие как билинейный фильтр, кубический фильтр, сплайновый фильтр, фильтр Винера или фильтр наименьших квадратов. Когда другие типы фильтров доступны для использования, предполагается, что синтаксис, приведенный выше, должен быть расширен, чтобы включать в себя одну или более семантик для указания информации о типе фильтра для повышающей дискретизации.
Специалистами в данной области техники должно быть принято во внимание, что параметры фильтра повышающей дискретизации могут выводиться в кодере для включения в сообщение SEI на основании различных входных данных, таких как информация о фильтре понижающей дискретизации, или тому подобное. В дополнение, также должно быть принято во внимание, что такая информация может просто поставляться в кодер для включения в сообщение SEI.
Дополнительно предполагается, что синтаксис, показанный в таблице 10, мог бы быть модифицирован для передачи параметров фильтра понижающей дискретизации вместо параметров фильтра повышающей дискретизации. В этом варианте осуществления, указание параметров фильтра понижающей дискретизации декодеру дает декодирующему приложению способность определять оптимальные параметры фильтра повышающей дискретизации на основании параметров фильтра понижающей дискретизации. Подобный синтаксис и семантика могут использоваться для сигнализации фильтра понижающей дискретизации. Может быть включена в состав семантика для указания, что параметры являются представляющими фильтр понижающей дискретизации или фильтр повышающей дискретизации.
Если оптимальный фильтр повышающей дискретизации должен быть определен декодером, декодер может выполнять такое определение любым образом, известным в данной области техники. Дополнительно, декодер может определять фильтр повышающей дискретизации, который не оптимален, или который не обязательно оптимален. Определение в декодере может быть основано на ограничениях обработки данных или анализе параметров устройства отображения, или тому подобном. В качестве дополнительного примера, декодер изначально мог бы выбирать многочисленные разные типы фильтров повышающей дискретизации, а затем, в итоге, выбирать один фильтр, который дает результат, определенный некоторыми критериями декодера оптимальным для декодера.
Блок-схема последовательности операций, показывающая примерную технологию кодирования, относящуюся к указанию информации о фильтре повышающей дискретизации, показана на фиг.35 и кратко описана ниже. Вначале определяется конфигурация кодера и создается высокоуровневый синтаксис. Картинки (например, проекции) подвергаются понижающей дискретизации фильтром понижающей дискретизации для упаковки в кадры. Повергнутые понижающей дискретизации картинки пространственно перемежаются в кадры. Параметры фильтра повышающей дискретизации определяются кодером или поставляются непосредственно в кодер. В одном из вариантов осуществления, параметры фильтра повышающей дискретизации, такие как тип, размер и значения коэффициентов, выводятся из фильтра понижающей дискретизации. Для каждой цветовой компоненты (например, YUV, RGB), параметры фильтра повышающей дискретизации определяются по количеству и значению. Это показано на фиг.35 тремя циклами: первым циклом для компонент, вторым циклом (вложенным в первый цикл) для параметров горизонтального фильтра для компоненты и третьим циклом (вложенным в первый цикл) для параметров вертикального фильтра для компоненты. Параметры фильтра повышающей дискретизации затем записываются в сообщение SEI. Сообщение SEI затем отправляется в декодер отдельно (внеполосным образом) от битового потока видеоизображения, либо вместе (внутриполосным образом) с битовым потоком видеоизображения. Кодер объединяет сообщение с последовательностью упакованных кадров, когда необходимо.
В противоположность способу кодирования, изображенному на фиг.35, альтернативный вариант осуществления, показанный на фиг.37, показывает, что параметры фильтра понижающей дискретизации включены в сообщение SEI вместо параметров фильтра повышающей дискретизации. В этом варианте осуществления, параметры фильтра повышающей дискретизации не выводятся кодером и не передаются в декодер с упакованными кадрами.
Блок-схема последовательности операций, показывающая примерную технологию декодирования, относящуюся к указанию информации о фильтре повышающей дискретизации, показана на фиг.36 и кратко описана ниже. В начале, сообщение SEI и другие связанные сообщения принимаются декодером, и синтаксисы читаются декодером. Сообщение SEI синтаксически анализируется, чтобы определить информацию, включенную в него, в том числе, информацию о дискретизации, информацию о перемежении, и тому подобное. В этом примере, определено, что информация о фильтре повышающей дискретизации для каждой цветовой компоненты включена в сообщение SEI. Информация о вертикальном и горизонтальном фильтре повышающей дискретизации извлекается для получения количества и значения каждого коэффициент горизонтального и вертикального фильтра повышающей дискретизации. Это извлечение показано на фиг.36 тремя циклами: первым циклом для компонент, вторым циклом (вложенным в первый цикл) для параметров горизонтального фильтра для компоненты и третьим циклом (вложенным в первый цикл) для параметров вертикального фильтра для компоненты. Сообщение SEI затем сохраняется, и последовательность упакованных кадров декодируется для получения картинок, упакованных в них. Картинки затем подвергаются повышающей дискретизации с использованием восстановленных параметров фильтра повышающей дискретизации для восстановления картинок в их исходное полное разрешение.
В противоположность способу декодирования, изображенному на фиг.36, альтернативный вариант осуществления, показанный на фиг.38, показывает, что параметры фильтра понижающей дискретизации включены в сообщение SEI вместо параметров фильтра повышающей дискретизации. В этом варианте осуществления, параметры фильтра повышающей дискретизации не выводятся кодером и не передаются в декодер с упакованными кадрами. Отсюда, декодер применяет принятые параметры фильтра понижающей дискретизации для выведения параметров фильтра повышающей дискретизации, которые должны использоваться для возвращения полного исходного разрешения картинкам, извлеченным из перемежения в упакованных видеокадрах.
Фиг.39 показывает примерную систему 2500 передачи видео, к которой могут быть применены настоящие принципы, в соответствии с реализацией настоящих принципов. Система 2500 передачи видео, например, может быть головной системой или системой передачи для передачи сигнала с использованием любого из многообразия средств связи, например, спутникового, кабельного, по телефонной линии или наземного вещания. Передача может быть предусмотрена через сеть Интернет или некоторую другую сеть.
Система 2500 передачи видео способна к генерированию и доставке сжатых видео с глубиной. Это достигается генерированием кодированного сигнала(ов), включающего в себя информацию о глубине или информацию, допускающую использование для синтеза информации о глубине на стороне приемника, которая, например, может иметь декодер.
Система 2500 передачи видео включает в себя кодер 2510 и передатчик 2520, способный к передаче кодированного сигнала. Кодер 2510 принимает видеоинформацию и генерирует кодированный сигнал(ы) с глубиной. Кодер 2510 может включать в себя подмодули, например, включающие в себя блок сборки для приема и сборки различных порций информации в структурированный формат для сохранения или передачи. Различные порции информации, например, могут включать в себя кодированное или некодированное видео, кодированную или некодированную информацию о глубине и кодированные или некодированные элементы, например, такие как векторы движения, индикаторы режима кодирования и элементы синтаксисов.
Передатчик 2520, например, может быть приспособлен для передачи сигнала вещательной программы, имеющего один или более битовых потоков, представляющих кодированные картинки и/или информацию, относящуюся к ним. Типичные передатчики выполняют функции, например, такие как одно или более из обеспечения кодирования с исправлением ошибок, перемежения данных в сигнале, рандомизации энергии в сигнале и/или модулирования сигнала в одну или более несущих. Передатчик может включать в себя или сопрягаться по интерфейсу с антенной (не показана). Соответственно, реализации передатчика 2520 могут включать в себя или ограничиваться модулятором.
Фиг.40 показывает примерную систему 2600 приема видео, к которой могут быть применены настоящие принципы, в соответствии с вариантом осуществления настоящих принципов. Система 2600 приема видео может быть сконфигурирована для приема сигналов через многообразие средств связи, например, таких как спутниковое, кабельное, по телефонной линии или наземное вещание. Сигналы могут приниматься через сеть Интернет или некоторую другую сеть.
Система 2600 приема видео, например, может быть сотовым телефоном, компьютером, телевизионной абонентской приставкой, телевизором или другим устройством, которое принимает кодированное видео и, например, предоставляет декодированное видео для отображения пользователю или для сохранения. Таким образом, система 2600 приема видео может предусматривать его вывод, например, на экран телевизора, компьютерный монитор, компьютер (для сохранения, обработки или отображения), или некоторое другое устройство хранения, обработки или отображения.
Система 2600 приема видео способна к приему и обработке видеоконтента, включающего в себя видеоинформацию. Система 2600 приема видео включает в себя приемник 2610, способный к приему кодированного сигнала, например, такого как сигналы, описанные в реализациях этой заявки, и декодер 2620, способный к декодированию принятого сигнала.
Приемник 2610, например, может быть приспособлен для приема сигнала вещательной программы, имеющего множество битовых потоков, представляющих кодированные картинки. Типичные приемники выполняют функции, например, такие как одно или более из приема модулированного и кодированного сигнала данных, демодулирования сигнала данных из одной или более несущих, дерандомизации энергии в сигнале, обращенного перемежения данных в сигнале и/или декодирования с исправлением ошибок сигнала. Приемник 2610 может включать в себя или сопрягаться с антенной (не показана). Реализации приемника 2610 могут включать в себя или ограничиваться демодулятором. Декодер 2620 выводит видеосигналы, включающие в себя видеоинформацию и информацию о глубине.
Фиг.41 показывает примерное устройство 2700 обработки видео, к которому могут быть применены настоящие принципы, в соответствии с вариантом осуществления настоящих принципов. Устройство 2700 обработки видео, например, может быть телевизионной абонентской приставкой или другим устройством, которое принимает кодированное видео и, например, предоставляет декодированное видео для отображения пользователю или для сохранения. Таким образом, устройство 2700 обработки видео может предусматривать его вывод на телевизор, компьютерный монитор, либо компьютер или другое устройство обработки.
Устройство 2700 обработки видео включает в себя устройство 2705 входного каскада (FE) и декодер 2710. Устройство 2705 входного каскада, например, может быть приемником, приспособленным для приема сигнала вещательной программы, имеющего множество битовых потоков, представляющих кодированные картинки, и для выбора одного или более битовых потоков для декодирования из множества битовых потоков. Типичные приемники выполняют функции, например, такие как одно или более из приема модулированного и кодированного сигнала данных, демодулирования сигнала данных, декодирования одного или более кодирований (например канального кодирования и/или исходного кодирования) сигнала данных и/или исправления ошибок сигнала данных. Устройство 2705 входного каскада может принимать сигнал вещательной программы, например, с антенны (не показана). Устройство 2705 входного каскада предоставляет принятый сигнал данных в декодер 2710.
Декодер 2710 принимает сигнал 2720 данных. Сигнал 2720 данных, например, может включать в себя один или более совместимых с усовершенствованным кодированием видеосигнала (AVC), масштабируемым кодированием видео (SVC), или многопроекционным кодированием видео (MVC) потоков.
Декодер 2710 декодирует весь или часть принятого сигнала 2720 и предоставляет, в качестве выходных данных, декодированный видеосигнал 2730. Декодированное видео 2730 предоставляется в селектор 2750. Устройство 2700 также включает в себя пользовательский интерфейс 2760, который принимает пользовательский ввод 2770. Пользовательский интерфейс 2760 предоставляет сигнал 2780 выбора картинки, на основании пользовательского ввода 2770, в селектор 2750. Сигнал 2780 выбора картинки и пользовательский ввод 2770 указывают, что из многочисленных картинок, последовательностей, масштабированных вариантов, проекций или других вариантов выбора доступных декодированных данных пользователь желает иметь отображенным. Селектор 2750 предоставляет выбранную картинку(ы) в качестве выходных данных 2790. Селектор 2750 использует информацию 2780 о выборе картинки для выбора, какие картинки в декодированном видео 2730 предоставлять в качестве выходных данных 2790.
В различных реализациях, селектор 2750 включает в себя пользовательский интерфейс 2760, а в других реализациях, никакой пользовательский интерфейс 2760 не нужен, так как селектор 2750 принимает пользовательский ввод 2770 непосредственно без того, чтобы выполнялась отдельная интерфейсная функция. Селектор 2750, например, может быть реализован в программном обеспечении или в качестве интегральной схемы. В одной из реализаций, селектор 2750 включен в состав декодером 2710, а в другой реализации, декодер 2710, селектор 2750 и пользовательский интерфейс 2760 являются полностью интегрированными.
В одном из применений, входной каскад 2705 принимает вещание различных телевизионных показов и выбирает один для обработки. Выбор одного показа основан на пользовательском вводе требуемого канала для просмотра. Хотя пользовательский ввод в устройство 2705 входного каскада не показан на фиг.41, устройство 2705 входного каскада принимает пользовательский ввод 2770. Входной каскад 2705 принимает вещание и обрабатывает требуемый показ, демодулируя релевантную часть вещательного спектра и декодируя какое-нибудь внешнее кодирование демодулированного показа. Входной каскад 2705 предоставляет декодированный показ в декодер 2710. Декодер 2710 является интегрированным блоком, который включает в себя устройства 2760 и 2750. Декодер 2710, таким образом, принимает пользовательский ввод, который является поданным пользователем указанием требуемой проекции для просмотра в показе. Декодер 2710 декодирует выбранную проекцию, а также любые требуемые опорные картинки из других проекций, и предоставляет декодированную проекцию 2790 для отображения на телевизоре (не показан).
Продолжая вышеприведенное применение, пользователь может пожелать переключить проекцию, которая отображается, а затем, может предоставлять новые входные данные в декодер 2710. После приема «изменения проекции» от пользователя, декодер 2710 декодирует обе, старую проекцию и новую проекцию, а также любые проекции, которые находятся между старой проекцией и новой проекцией. То есть, декодер 2710 декодирует любые проекции, которые берутся с камер, которые физически расположены между камерой, снимающей старую проекцию, и камерой, снимающей новую проекцию. Устройство 2705 входного каскада также принимает информацию, идентифицирующую старую проекцию, новую проекцию, и проекции между ними. Такая информация, например, может предоставляться контроллером (не показан на фиг.41), имеющим информацию о местоположениях проекций, или декодером 2710. Другие реализации могут использовать устройство входного каскада, которое имеет контроллер, интегрированный с устройством входного каскада.
Декодер 2710 предоставляет все из этих декодированных проекций в качестве выходных данных 2790. Постпроцессор (не показан на фиг.41) осуществляет интерполяцию между проекциями, чтобы обеспечивать плавный переход от старой проекции к новой проекции, и отображает этот переход пользователю. После перехода к новой проекции, постпроцессор информирует (через одну или более линий связи, не показанные) декодер 2710 и устройство 2705 входного каскада, что необходима только новая проекция. После этого, декодер 2710 предоставляет в качестве выходных данных 2790 только новую проекцию.
Система 2700 может использоваться для приема многочисленных проекций последовательности изображений и для представления одиночной проекции для отображения, а также для переключения между различными проекциями плавным образом. Плавный образ действий может включать в себя интерполяцию между проекциями для перехода к другой проекции. Дополнительно, система 2700 может предоставлять пользователю возможность поворачивать объект или сцену, или иначе, видеть трехмерное представление объекта или сцены. Поворачивание объекта, например, может соответствовать переходу от проекции к проекции и интерполяции между проекциями для получения плавного перехода между проекциями или просто для получения трехмерного представления. То есть, пользователь может «выбирать» интерполированную проекцию в качестве «проекции», которая должна отображаться.
Как представлено в материалах настоящей заявки, реализации и признаки, описанные в этой заявке, могут использоваться в контексте кодирования видео, кодирования глубины и/или кодирования других типов данных. Дополнительно, эти реализации и признаки могут использоваться в контексте или быть приспособленными для использования в контексте стандарта AVC H.264/MPEG-4 (AVC), стандарта AVC с расширением MVC, стандарта AVC с расширением SVC, стандарта 3DV и/или с другим стандартом (существующим или будущим), или в контексте, который не касается стандарта. Соответственно, должно быть понятно, что специфичные реализации, описанные в этой заявке, которые действуют в соответствии с AVC, не подразумеваются ограниченными AVC и могут быть приспособлены для использования вне AVC.
К тому же, как отмечено выше, реализации могут сигнализировать или указывать информацию с использованием многообразия технологий, в том числе, но не в качестве ограничения, сообщений SEI, заголовков секций, другого высокоуровневого синтаксиса, невысокоуровневого синтаксиса, внеполосной информации, данных потока данных и неявной сигнализации. Хотя реализации, описанные в материалах настоящей заявки, могут быть описаны в конкретном контексте, такие описания никоим образом не должны браться в качестве ограничения признаков и концепций в отношении таких реализаций или контекстов.
Различные реализации включают в себя декодирование. Термин «декодирование», используемый в этой заявке, может охватывать все или часть последовательностей операций, например, выполняемых над принятой кодированной последовательностью, для того чтобы вырабатывать окончательные выходные данные, пригодные для отображения. Такие последовательности операций могут включать в себя последовательности операций, типично выполняемые декодером, например, такие как энтропийное декодирование, обратное преобразование, обратное квантование, дифференциальное кодирование. Такие последовательности операций, к тому же, или в качестве альтернативы, могут включать в себя последовательности операций, выполняемые декодером различных реализаций, описанных в этой заявке, например, такие как извлечение картинки из подвергнутой мозаичному размещению (упакованной) картинки, определение фильтра повышающей дискретизации для использования, а затем, повышающая дискретизация картинки и транспонирование картинки обратно в ее планируемую ориентацию.
Различные реализации, описанные в этой заявке, объединяют многочисленные картинки в единую картинку. Последовательность операций объединения картинок, например, может влечь за собой выбор картинок, например, на основании соотношения между картинками, пространственное перемежение, дискретизацию и изменение ориентации картинки. Соответственно, информация, описывающая последовательность операций объединения, например, может включать в себя информацию о соотношении, информацию о пространственном перемежении, информацию о дискретизации и информацию об ориентации.
Пространственное перемежение указывается при описании различных реализаций. Термин «перемежение», используемый в этой заявке, например, также указывается как «мозаичное размещение» и «упаковка». Перемежение включает в себя многообразие типов перемежения, в том числе, например, поперечное размещение рядом картинок, верхне-нижнее размещение картинок, комбинированное поперечное и верхне-нижнее (например, для объединения 4 картинок), построчное чередование, постолбцовое чередование и различные схемы уровня пикселей (также указываемые как попиксельные или основанные на пикселях).
К тому же, используемые в материалах настоящей заявки слова «картинка» и «изображение» используются взаимозаменяемо и, например, указывают на все или часть неподвижного изображения, либо всю или часть картинки из видеопоследовательности. Как известно, картинка может быть кадром или областью. Дополнительно, используемый в материалах настоящей заявки термин картинка также может быть подмножеством кадра, например, таким как верхняя половина кадра, одиночный макроблок, чередующиеся столбцы, чередующиеся строки или периодические пиксели. В качестве еще одного примера, картинка глубин, например, может быть полной картой глубин или частичной картой глубин, которая включает в себя только информацию о глубине, например, одиночного макроблока или соответствующего видеокадра.
Ссылка в описании изобретения на «один из вариантов осуществления» или «вариант осуществления», либо «одну из реализаций» или «реализацию» настоящих принципов, а также другие ее варианты, означают, что конкретный признак, конструкция, характеристика, и так далее, описанные в связи с вариантом осуществления, включены в по меньшей мере один вариант осуществления настоящих принципов. Таким образом, появление фразы «в одном из вариантов осуществления» или «в варианте осуществления», либо «в одной из реализаций» или «в реализации», а также любых других ее вариантов, фигурирующих в различных местах по всему описанию изобретения, не обязательно является всецело указывающим на один и тот же вариант осуществления.
Должно быть принято во внимание, что использование любого из следующего: «/», «и/или» и «по меньшей мере один из», например, в случаях «A/B», «A и/или B» и «по меньшей мере одно из A и B», подразумевается охватывающим выбор только первого перечисленного варианта (A) или выбор только второго перечисленного варианта (B), либо выбор обоих вариантов (A и B). В качестве дополнительного примера, в случаях «A, B и/или C» и «по меньшей мере одно из A, B и C», а также «по меньшей мере одно из A, B или C», такое выражение подразумевается охватывающим выбор только первого перечисленного варианта (A) или выбор только второго перечисленного варианта (B), или выбор только третьего перечисленного варианта (C), или выбор только первого и второго перечисленных вариантов (A и B), или выбор только первого и третьего перечисленных вариантов (A и C), или выбор только второго и третьего перечисленных вариантов (B и C), или выбор всех трех вариантов (A и B, и C). Как без труда очевидно рядовому специалисту в этой и связанных областях техники, это можно расширять на столько элементов, сколько перечислено.
Дополнительно, эта заявка или ее формула изобретения может указывать на «определение» различных порций информации. Определение информации может включать в себя, например, одно или более из оценивания информации, расчета информации, предсказания информации или извлечения информации из памяти.
Подобным образом, «осуществление доступа» подразумевается широким термином. Осуществление доступа к порции информации может включать в себя любую операцию, которая, например, использует, сохраняет, отправляет, передает, принимает, извлекает, модифицирует или предоставляет информацию.
Должно быть понятно, что элементы, показанные на фигурах, могут быть реализованы в различных формах аппаратных средств, программного обеспечения или их комбинации. Предпочтительно, эти элементы реализованы в комбинации аппаратных средств и программного обеспечения на одном или более надлежащим образом запрограммированных устройств общего применения, которые могут включать в себя процессор, память и интерфейсы ввода/вывода. Более того, реализации, описанные в материалах настоящей заявки, например, могут быть реализованы в качестве способа или последовательности операций, устройства или программно реализованной программы. Даже если обсуждена только в контексте одиночной формы реализации (например, обсужденной исключительно в качестве способа), реализация обсужденных признаков также может быть реализована в других формах (например, устройстве или программе). Устройство может быть реализовано, как упомянуто выше. Способы, например, могут быть реализованы на устройстве, например, таком как процессор, который указывает на устройства обработки вообще, в том числе, например, компьютер, микропроцессор, интегральную схему или программируемое логическое устройство. Устройства обработки также включают в себя устройства связи, например, такие как компьютеры, сотовые телефоны, портативные/персональные цифровые секретари («PDA») и другие устройства, которые содействуют передаче информации между конечными пользователями.
Реализации различных последовательностей операций и признаков, описанных в материалах настоящей заявки, могут быть воплощены в многообразии разного оборудования или приложений, более точно, например, оборудовании или приложениях, ассоциативно связанных с кодированием и декодированием данных. Примеры оборудования включают в себя видеокодеры, видеодекодеры, видеокодеки, веб-серверы, телевизионные абонентские приставки, переносные компьютеры, персональные компьютеры, сотовые телефоны, PDA, другие устройства связи, персональные записывающие устройства (например, PVR (программируемые видеозаписывающие устройства), компьютеры, выполняющие записывающее программное обеспечение, устройства записи VHS), записывающие видеокамеры, потоковую передачу данных через сеть Интернет или другие линии связи, и видео по запросу. Как должно быть ясно, оборудование может быть мобильным или даже установленным на движущемся транспортном средстве.
Дополнительно, способы могут быть реализованы командами, являющимися выполняемыми процессором, и такие команды могут храниться на читаемом процессором носителе, например, таком как интегральная схема, носитель программного обеспечения или другое запоминающее устройство, например, такое как жесткий диск, гибкий магнитный компакт-диск, оперативное запоминающее устройство («ОЗУ») или постоянное запоминающее устройство («ПЗУ»). Команды могут формировать прикладную программу, реально воплощенную на читаемом процессором носителе. Как должно быть ясно, процессор может включать в себя читаемый процессором носитель, например, имеющий команды для выполнения последовательности операций. Такие прикладные программы могут выгружаться в, и выполняться машиной, содержащей любую подходящую архитектуру. Предпочтительно, машина реализована на компьютерной платформе, содержащей аппаратные средства, такие как один или более центральных процессорных устройств («ЦПУ», «CPU»), оперативное запоминающее устройство («ОЗУ»), и интерфейсы ввода/вывода («I/O»). Компьютерная платформа также может включать в себя операционную систему и микрокомандный код. Различные последовательности операций и функции, описанные в материалах настоящей заявки, могут быть частью микрокомандного кода либо частью прикладной программы, или любой их комбинацией, которая может выполняться ЦПУ. В дополнение, различные другие периферийные устройства могут быть присоединены к компьютерной платформе, такие как дополнительное устройство хранения данных и печатающее устройство.
Как должно быть очевидно специалисту в данной области техники, реализации также могут вырабатывать сигнал, форматированный для несения информации, которая, например, может сохраняться или передаваться. Информация, например, может включать в себя команды для выполнения способа или данные, выработанные одной из описанных реализаций. Такой сигнал, например, может быть форматирован в качестве электромагнитной волны (например, с использованием радиочастотного участка спектра) или в качестве сигнала основной полосы. Форматирование, например, может включать в себя кодирование потока данных, создание синтаксиса и модулирование несущей кодированным потоком данных или синтаксисом. Информация, которую несет сигнал, например, может быть аналоговой или цифровой информацией. Сигнал, как известно, может передаваться через многообразие разных проводных или беспроводных линий связи.
Кроме того, должно быть понятно, что, так как некоторые из составляющих компонентов и способов системы, изображенных на прилагаемых чертежах, предпочтительно реализованы в программном обеспечении, реальные связи между компонентами системы или функциональными блоками последовательности операций могут отличаться в соотношении от образа действий, которым запрограммированы настоящие принципы. При заданных доктринах, приведенных в материалах настоящей заявки, рядовой специалист в относящейся к делу области техники, будет способен предполагать эти и подобные реализации или конфигурации настоящих принципов.
Было описано некоторое количество реализаций. Тем не менее, должно быть понятно, что могут быть произведены различные модификации. Например, элементы разных реализаций могут быть комбинированы, дополнены, модифицированы или удалены для создания других реализаций. Дополнительно, рядовой специалист должен понимать, что другие конструкции и последовательности операций могут быть использованы вместо раскрытых, и получающиеся в результате реализации будут выполнять по меньшей мере по существу такую же функцию(ии), по меньшей мере по существу таким же образом, для достижения по меньшей мере по существу такого же результата(ов), как раскрытые реализации. В частности, хотя иллюстративные варианты осуществления были описаны в материалах настоящей заявки со ссылкой на прилагаемые чертежи, должно быть понятно, что настоящие принципы не ограничены такими отдельно взятыми вариантами осуществления, и что различные изменения и модификации могут быть осуществлены в них рядовым специалистом в относящейся к делу области техники, не выходя из объема и сущности настоящих принципов. Соответственно, эти и другие реализации предполагаются этой заявкой и находятся в пределах объема последующей формулы изобретения.