ВЫСОКОУРОВНЕВАЯ ПЕРЕДАЧА СЛУЖЕБНЫХ СИГНАЛОВ ДЛЯ ВИДЕОДАННЫХ ТИПА "РЫБИЙ ГЛАЗ" Российский патент 2022 года по МПК H04N21/845 H04N13/178 H04N19/70 H04N21/81 

[1] Эта заявка притязает на приоритет предварительной заявки США № 62/511189, поданной 25 мая 2017 года, содержимое которой полностью содержится в данном документе по ссылке.

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

[2] Данное раскрытие сущности относится к хранению и транспортировке кодированных видеоданных.

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

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

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

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

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

[6] В одном примере, способ включает в себя обработку файла, включающего в себя видеоданные типа "рыбий глаз", причем файл включает в себя синтаксическую структуру, включающую в себя множество синтаксических элементов, которые указывают атрибуты видеоданных типа "рыбий глаз", при этом множество синтаксических элементов включают в себя: первый синтаксический элемент, который явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, и один или более синтаксических элементов, которые неявно указывают то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; определение, на основе первого синтаксического элемента, того, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и рендеринг, на основе определения, видеоданных типа "рыбий глаз" как моноскопических или стереоскопических.

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

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

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

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

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

[11] Фиг. 1A и 1B являются блок–схемами, иллюстрирующими примерные устройства для захвата всенаправленного контента изображений, в соответствии с одной или более примерных технологий, описанных в этом раскрытии сущности.

[12] Фиг. 2 является примером изображения, которое включает в себя несколько изображений типа "рыбий глаз".

[13] Фиг. 3–8 являются концептуальными схемами, которые иллюстрируют различные привнесенные параметры и поля обзора всенаправленных изображений, в соответствии с одной или более примерных технологий, описанных в этом раскрытии сущности.

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

[15] Фиг. 10 является концептуальной схемой, иллюстрирующей элементы примерного мультимедийного контента.

[16] Фиг. 11 является блок–схемой, иллюстрирующей элементы примерного видеофайла, который может соответствовать сегменту представления.

[17] Фиг. 12 является блок–схемой последовательности операций способа, иллюстрирующей примерную технологию для обработки файла, который включает в себя видеоданные типа "рыбий глаз", в соответствии с одной или более технологий этого раскрытия сущности.

[18] Фиг. 13 является блок–схемой последовательности операций способа, иллюстрирующей примерную технологию для формирования файла, который включает в себя видеоданные типа "рыбий глаз", в соответствии с одной или более технологий этого раскрытия сущности.

Подробное описание изобретения

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

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

[21] Всенаправленное видео может быть стереоскопическим или моноскопическим. Когда видео является стереоскопическим, различное изображение показывается для каждого глаза таким образом, что зритель может воспринимать глубину. В связи с этим, стереоскопическое видео типично захватывается с использованием двух камер, обращенных в каждом направлении. Когда видео является моноскопическим, идентичное изображение показывается для обоих глаз.

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

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

[24] В некоторых примерах, всенаправленный контент изображений может захватываться с помощью устройства камеры, которое включает в себя две линзы типа "рыбий глаз". Если две линзы типа "рыбий глаз" позиционируются на противоположных сторонах устройства камеры, чтобы захватывать противоположные части сферы контента изображений, контент изображений может быть моноскопическим и покрывать полную сферу видео с углом обзора в 360 градусов. Аналогично, если две линзы типа "рыбий глаз" позиционируются на идентичной стороне устройства камеры, чтобы захватывать идентичную часть сферы контента изображений, контент изображений может быть стереоскопическим и покрывать половину сферы видео с углом обзора в 360 градусов. Изображения, сформированные посредством камер, представляют собой круглые изображения (например, один кадр с изображением включает в себя два круглых изображения).

[25] Фиг. 1A и 1B являются блок–схемами, иллюстрирующими примерные устройства для захвата всенаправленного контента изображений, в соответствии с одной или более примерных технологий, описанных в этом раскрытии сущности. Как проиллюстрировано на фиг. 1A, вычислительное устройство 10A представляет собой устройство видеозахвата, которое включает в себя линзу 12A типа "рыбий глаз" и линзу 12B типа "рыбий глаз", расположенные на противоположных сторонах вычислительного устройства 10A, чтобы захватывать моноскопический контент изображений, который покрывает всю сферу (например, полный видеоконтент с углом обзора в 360 градусов). Как проиллюстрировано на фиг. 1B, вычислительное устройство 10B представляет собой устройство видеозахвата, которое включает в себя линзу 12C типа "рыбий глаз" и линзу 12D типа "рыбий глаз", расположенные на идентичной стороне вычислительного устройства 10B, в стереоскопический контент изображений, который покрывает приблизительно половину сферы.

[26] Как описано выше, устройство камеры включает в себя множество линз типа "рыбий глаз". Некоторые примерные устройства камеры включают в себя две линзы типа "рыбий глаз", но примерные технологии не ограничены двумя линзами типа "рыбий глаз". Одно примерное устройство камеры может включать в себя 16 линз (например, массив с 16 камерами для съемки трехмерного VR–контента). Другое примерное устройство камеры может включать в себя восемь линз, каждая из которых имеет угол обзора в 195 градусов (например, каждая линза захватывает 195 градусов из 360 градусов контента изображений). Другие примерные устройства камеры включают в себя три или четыре линзы. Некоторые примеры могут включать в себя линзу с углом обзора в 360 градусов, которая захватывает 360 градусов контента изображений.

[27] Примерные технологии, описанные в этом раскрытии сущности, в общем, описываются относительно двух линз типа "рыбий глаз", захватывающих всенаправленное изображение/видео. Тем не менее, примерные технологии не ограничены в этом отношении. Примерные технологии могут быть применимыми к примерным устройствам камеры, которые включают в себя множество линз (например, две или более), даже если линзы не представляют собой линзы типа "рыбий глаз", и множество линз типа "рыбий глаз". Например, примерные технологии описывают способы сшивать захваченные изображения, и технологии могут быть применимыми к примерам, в которых предусмотрено множество захваченных изображений из множества линз (которые могут представлять собой линзы типа "рыбий глаз", в качестве примера). Хотя примерные технологии описываются относительно двух линз типа "рыбий глаз", примерные технологии не ограничены в этом отношении и являются применимыми к различным типам камеры, используемым для захвата всенаправленных изображений/видео.

[28] Технологии этого раскрытия сущности могут применяться к видеофайлам, соответствующим видеоданным, инкапсулированным согласно любому базовому формату мультимедийных файлов ISO (например, ISOBMFF, ISO/IEC 14496–12) и другим форматам файлов, извлекаемым из ISOBMFF, включающим в себя MPEG–4–формат файлов (ISO/IEC 14496–15), формат файлов по стандарту Партнерского проекта третьего поколения (3GPP) (3GPP TS 26.244) и форматы файлов для AVC– и HEVC–семейств видеокодеков (ISO/IEC 14496–15) либо другие аналогичные форматы видеофайлов.

[29] ISOBMFF используется в качестве базиса для многих форматов инкапсуляции кодека, таких как AVC–формат файлов, а также для многих форматов мультимедийных контейнеров, таких как MPEG–4–формат файлов, 3GPP–формат файлов (3GP) и DVB–формат файлов. В дополнение к непрерывному мультимедиа, такому как аудио и видео, статическое мультимедиа, такое как изображения, а также метаданные могут сохраняться в файле, соответствующем ISOBMFF. Файлы, структурированные согласно ISOBMFF, могут использоваться для множества целей, включающих в себя локальное воспроизведение мультимедийных файлов, прогрессивную загрузку удаленного файла, сегменты для динамической адаптивной потоковой передачи по HTTP (DASH), контейнеры для контента, который должен передаваться в потоковом режиме, и инструкции по его пакетированию, и запись принимаемых мультимедийных потоков в реальном времени.

[30] Поле представляет собой элементарную синтаксическую структуру в ISOBMFF, включающую в себя четырехсимвольный кодированный тип поля, число байтов поля и рабочие данные. ISOBMFF–файл состоит из последовательности полей, и поля могут содержать другие поля. Кинополе (moov) содержит метаданные для непрерывных мультимедийных потоков, присутствующих в файле, при этом каждый из них представляется в файле в качестве дорожки. Метаданные для дорожки включаются в поле дорожек (trak), тогда как мультимедийный контент дорожки включается либо в поле мультимедийных данных (mdat), либо непосредственно в отдельный файл. Мультимедийный контент для дорожек состоит из последовательности выборок, таких как единицы аудио– или видеодоступа.

[31] При рендеринге видеоданных типа "рыбий глаз", для видеодекодера может быть желательным определять то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. Например, способ, которым видеодекодер отображает и/или сшивает круглые изображения, включенные в изображение видеоданных типа "рыбий глаз", непосредственно зависит от того, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими.

[32] В некоторых примерах, видеодекодер может определять то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, на основе одного или более синтаксических элементов, включенных в файл, которые неявно указывают то, являются видеоданные типа "рыбий глаз", описанные посредством файла, моноскопическими или стереоскопическими. Например, видеокодер может включать синтаксические элементы в файл, которые описывают привнесенные параметры (например, физические/географические атрибуты, такие как угол относительно вертикальной оси, угол наклона в продольном направлении, угол наклона в поперечном направлении и одно или более пространственных смещений) каждой из камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз", и видеодекодер может обрабатывать привнесенные параметры, чтобы вычислять то, являются видеоданные, описанные посредством файла, моноскопическими или стереоскопическими. В качестве одного примера, если обработка привнесенных параметров приводит к индикатору того, что камеры обращены в идентичном направлении и имеют пространственное смещение, видеодекодер может определять то, что видеоданные являются стереоскопическими. В качестве другого примера, если обработка привнесенных параметров указывает то, что камеры обращены в противоположных направлениях, видеодекодер может определять то, что видеоданные являются моноскопическими. Тем не менее, в некоторых примерах, для видеодекодера может быть желательным иметь возможность определять то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, без необходимости выполнять такие дополнительные ресурсоемкие вычисления. Дополнительно, в некоторых примерах, обработка привнесенных параметров может не давать в результате корректную (например, намеченную) классификацию видеоданных как моноскопических или стереоскопических. В качестве одного примера, значения привнесенных параметров могут становиться поврежденными во время кодирования/перехода/декодирования. В качестве другого примера, привнесенные параметры могут не предоставляться точно в кодере.

[33] В соответствии с одной или более технологий этого раскрытия сущности, видеокодер может включать первый синтаксический элемент в файл, который явно указывает то, являются видеоданные типа "рыбий глаз", описанные посредством файла, моноскопическими или стереоскопическими. Файл может включать в себя первый синтаксический элемент в дополнение к синтаксическим элементам, что привнесенные параметры видеоданных типа "рыбий глаз". В связи с этим, файл может включать в себя как явный индикатор (т.е. первый синтаксический элемент), так и неявный индикатор (т.е. синтаксические элементы, что привнесенные параметры) того, являются видеоданные типа "рыбий глаз", описанные посредством файла, моноскопическими или стереоскопическими. Таким образом, видеодекодер может точно определять то, являются видеоданные моноскопическими или стереоскопическими (например, без необходимости выполнять дополнительные вычисления на основе привнесенных параметров).

[34] ISOBMFF указывает следующие типы дорожек: мультимедийная дорожка, которая содержит элементарный мультимедийный поток, дорожка с подсказками, которая или включает в себя инструкции по передаче мультимедиа или представляет поток принимаемых пакетов, и дорожка синхронизированных по времени метаданных, которая содержит метаданные с временной синхронизацией.

[35] Хотя первоначально спроектирован для хранения, ISOBMFF оказался очень ценным для потоковой передачи, например, для прогрессивной загрузки или DASH. Для целей потоковой передачи, могут использоваться кинофрагменты, заданные в ISOBMFF.

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

[37] ISOBMFF обеспечивает указание конкретных для выборки метаданных с помощью различных механизмов. Конкретные поля в поле таблиц выборок (stbl) стандартизированы, с тем чтобы реагировать на общие потребности. Например, поле выборок синхроимпульсов (stss) используется для того, чтобы перечислять выборки с произвольным доступом дорожки. Механизм группировки выборок предоставляет преобразование выборок согласно четырехсимвольному типу группировки в группы выборок, совместно использующих идентичное свойство, указываемое в качестве записи описания групп выборок в файле. Несколько типов группировки указаны в ISOBMFF.

[38] Виртуальная реальность (VR) представляет собой способность виртуально присутствовать в нематериальном мире, созданном посредством рендеринга естественного и/или синтетического изображения и звука, коррелированных посредством перемещений погруженного пользователя, позволяющего взаимодействовать с этим миром. В силу недавнего прогресса в устройствах рендеринга, таких как наголовные дисплеи (HMD) и создание VR–видео (зачастую также называемого "видео с углом обзора в 360 градусов"), может предлагаться значимое фактическое качество услуг. VR–приложения включают в себя игры, тренировки, обучение, спортивное видео, онлайновые покупки, развлечения для взрослых и т.д.

[39] Типичная VR–система может включать в себя один или более следующих компонентов, которые могут выполнять один или более следующих этапов:

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

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

3) Видео в преобразованном прямоугольном формате кодируется/сжимается с использованием видеокодека, например, H.265/HEVC или H.264/AVC.

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

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

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

[40] Формат всенаправленных мультимедийных приложений (OMAF) разрабатывается посредством MPEG, чтобы задавать формат мультимедийных приложений, который обеспечивает всенаправленные мультимедийные приложения, с акцентированием внимания на VR–приложениях с видео с углом обзора в 360° и ассоциированным аудио. OMAF указывает пакетирование в разрезе проекций и областей, которое может использоваться для преобразования сферического видео или видео с углом обзора в 360° в двумерное прямоугольное видео, далее указывает то, как сохранять всенаправленное мультимедиа и ассоциированные метаданные с использованием базового формата мультимедийных файлов ISO (ISOBMFF), и то, как инкапсулировать, передавать в служебных сигналах и передавать в потоковом режиме всенаправленное мультимедиа с использованием динамической адаптивной потоковой передачи по HTTP (DASH), и, в завершение указывает то, какие видео– и аудиокодеки, а также конфигурации кодирования мультимедиа могут использоваться для сжатия и воспроизведения всенаправленного мультимедийного сигнала.

[41] Пакетирование в разрезе проекций и областей представляет собой процессы, используемые на стороне формирования контента, чтобы формировать двумерные видеоизображения из сферического сигнала для проецируемого всенаправленного видео. Проекция обычно сочетается со сшиванием, которое может формировать сферический сигнал из нескольких захваченных изображений камеры для каждого видеоизображения. Проекция может представлять собой фундаментальный этап обработки в VR–видео. Типичные типы проекции включают в себя равнопрямоугольную и кубическую карту. Проект международного стандарта (DIS) OMAF поддерживает только тип равнопрямоугольной проекции. Пакетирование в разрезе областей представляет собой необязательный этап после проекции (из порта вида стороны формирования контента). Пакетирование в разрезе областей обеспечивает обработки (изменение размеров, повторное позиционирование, вращение и зеркалирование) любой прямоугольной области пакетированного изображения перед кодированием.

[42] Фиг. 2 является примером изображения, которое включает в себя несколько изображений типа "рыбий глаз". OMAF DIS поддерживает видеоформат по технологии VR/с углом обзора в 360 градусов типа "рыбий глаз", при этом вместо применения проекции и необязательно пакетирования в разрезе областей, чтобы формировать двумерное видео перед кодированием, для каждой единицы доступа, круглые изображения из захватывающих камер непосредственно встраиваются в двумерное изображение. Например, как показано на фиг. 2, первое изображение 202 типа "рыбий глаз" и второе изображение 204 типа "рыбий глаз" встраиваются в двумерное изображение 200.

[43] Такое видео типа "рыбий глаз" затем может кодироваться, и поток битов может инкапсулироваться в ISOBMFF–файле и дополнительно может инкапсулироваться в качестве DASH–представления. Помимо этого, свойство видео типа "рыбий глаз", включающее в себя параметры, указывающие характеристики видео типа "рыбий глаз", может передаваться в служебных сигналах и использоваться для корректного рендеринга видео с углом обзора в 360 градусов на стороне клиента. Одно преимущество подхода на основе видео по технологии VR/с углом обзора в 360 градусов типа "рыбий глаз" состоит в том, что он поддерживает недорогой формируемый пользователями VR–контент посредством мобильных терминалов.

[44] В OMAF DIS, использование всенаправленной видеосхемы типа "рыбий глаз" для ограниченного типа записи видеовыборки resv указывает то, что декодированные изображения представляют собой видеоизображения типа "рыбий глаз". Использование всенаправленной видеосхемы типа "рыбий глаз" указывается посредством scheme_type, равного fodv (всенаправленное видео типа "рыбий глаз"), в SchemeTypeBox. Формат видео типа "рыбий глаз" указывается с помощью FisheyeOmnidirectionalVideoBox, содержащегося в SchemeInformationBox, который включен в RestrictedSchemeInfoBox, который включен в запись выборки. В текущем проекте OMAF DIS (Information technology – Coded representation of immersive media (MPEG–I) – Part 2: Omnidirectional media format, ISO/IEC FDIS, 14496–15:2014(E), ISO/IEC JTC 1/SC 29/WG 11, w16824, 13.01.2014, далее "текущий проект OMAF DIS"), один и только один FisheyeOmnidirectionalVideoBox должен присутствовать в SchemeInformationBox, когда тип схемы представляет собой fodv. Когда FisheyeOmnidirectionalVideoBox присутствует в SchemeInformationBox, StereoVideoBox и RegionWisePackingBox не должны присутствовать в идентичном SchemeInformationBox. FisheyeOmnidirectionalVideoBox, как указано в параграфе 6 OMAF DIS, содержит синтаксическую структуру FisheyeOmnidirectionalVideoInfo(), которая содержит параметры свойства видео типа "рыбий глаз".

[45] Синтаксис синтаксической структуры FisheyeOmnidirectionalVideoInfo() в текущем проекте OMAF DIS является следующим.

aligned(8) class FisheyeOmnidirectionalVideoInfo() {

bit(24) reserved=0;

unsigned int(8) num_circular_images;

for(i=0; i<num_circular_images; i++) {

unsigned int(32) image_center_x;

unsigned int(32) image_center_y;

unsigned int(32) full_radius;

unsigned int(32) picture_radius;

unsigned int(32) scene_radius;

unsigned int(32) image_rotation;

bit(30) reserved=0;

unsigned int(2) image_flip;

unsigned int(32) image_scale_axis_angle;

unsigned int(32) image_scale_x;

unsigned int(32) image_scale_y;

unsigned int(32) field_of_view;

bit(16) reserved=0;

unsigned int (16) num_angle_for_displaying_fov;

for(j=0; j<num_angle_for_displaying_fov; j++) {

unsigned int(32) displayed_fov;

unsigned int(32) overlapped_fov;

}

signed int(32) camera_center_yaw;

signed int(32) camera_center_pitch;

signed int(32) camera_center_roll;

unsigned int(32) camera_center_offset_x;

unsigned int(32) camera_center_offset_y;

unsigned int(32) camera_center_offset_z;

bit(16) reserved=0;

unsigned int(16) num_polynomial_coefficeients;

for(j=0; j<num_polynomial_coefficients; j++) {

unsigned int(32) polynomial_coefficient_K;

}

bit(16) reserved=0;

unsigned int (16) num_local_fov_region;

for(j=0; j<num_local_fov_region; j++) {

unsigned int(32) start_radius;

unsigned int(32) end_radius;

signed int(32) start_angle;

signed int(32) end_angle;

unsigned int(32) radius_delta;

signed int(32) angle_delta;

for(rad=start_radius; rad<=end_radius; rad+=radius_delta) {

for(ang=start_angle; ang<=ang_radius; ang+=angle_delta) {

unsigned int(32) local_fov_weight;

}

}

}

bit(16) reserved=0;

unsigned int(16) num_polynomial_coefficients_lsc;

for(j=0; j<num_polynomial_coefficients_lsc; j++) {

unsigned int (32) polynomial_coefficient_K_lsc_R;

unsigned int (32) polynomial_coefficient_K_lsc_G;

unsigned int (32) polynomial_coefficient_K_lsc_B;

}

}

bit(24) reserved=0;

unsigned int(8) num_deadzones;

for(i=0; i<num_deadzones; i++) {

unsigned int(16) deadzone_left_horizontal_offset;

unsigned int(16) deadzone_top_vertical_offset;

unsigned int(16) deadzone_width;

unsigned int(16) deadzone_height;

}

}

[46] Семантика синтаксической структуры FisheyeOmnidirectionalVideoInfo() в текущем проекте OMAF DIS является следующей.

[47] num_circular_images указывает число круглых изображений в кодированном изображении каждой выборки, к которой применяется это поле. Типично, значение равно 2, но другие ненулевые значения также являются возможными.

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

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

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

[51] picture_radius является значением 16,16 с фиксированной запятой, которое указывает радиус, в выборках сигнала яркости, от центра круглого изображения до ближайшего края границы изображения. Круглое изображение типа "рыбий глаз" может быть обрезано посредством изображения камеры. Следовательно, это значение указывает радиус окружности, при котором пикселы являются применимыми.

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

[53] image_rotation является значением 16,16 с фиксированной запятой, которое указывает величину вращения, в градусах, круглого изображения. Изображение может вращаться посредством изображений +/–90 градусов или +/–180 градусов, или любого другого значения.

[54] image_flip указывает то, является или нет (и каким образом является) изображение перевернутым, и в силу этого должна применяться операция обратного переворачивания. Значение 0 указывает то, что изображение не является перевернутым. Значение 1 указывает то, что изображение является вертикально перевернутым. Значение 2 указывает то, что изображение является горизонтально перевернутым. Значение 3 указывает то, что изображение является вертикально и горизонтально перевернутое.

[55] image_scale_axis_angle, image_scale_x и image_scale_y являются тремя значениями 16,16 с фиксированной запятой, которые указывают то, масштабировано или нет (и каким образом масштабировано) изображение вдоль оси. Ось задается посредством одного угла, как указано посредством значения image_scale_axis_angle в градусах. Угол в 0 градусов означает то, горизонтальный вектор является идеально горизонтальным, и вертикальный вектор является идеально вертикальным. Значения image_scale_x и image_scale_y указывают коэффициенты масштабирования в направлениях, которые являются параллельными и ортогональными, соответственно, оси.

[56] field_of_view является значением 16,16 с фиксированной запятой, которое указывает поле обзора линзы типа "рыбий глаз" в градусах. Типичное значение для полусферической линзы типа "рыбий глаз" составляет 180,0 градусов.

[57] num_angle_for_displaying_fov указывает число углов. Согласно значению num_angle_for_displaying_fov, несколько значений displayed_fov и overlapped_fov задаются с равными интервалами, которые начинаются в 12 часов и проходят по часовой стрелке.

[58] displayed_fov указывает отображаемое поле обзора и соответствующую площадь изображения для каждого снятого камерой изображения типа "рыбий глаз"; overlapped_fov указывает область, которая включает в себя перекрывающиеся области, которые обычно используются для смешивания, с точки зрения поля обзора между несколькими круглыми изображениями. Значения displayed_fov и overlapped_fov меньше или равны значению field_of_view.

[59] Примечание: Значение field_of_view определяется посредством физического свойства каждой линзы типа "рыбий глаз", в то время как значения displayed_fov и overlapped_fov определяются посредством конфигурации нескольких линз типа "рыбий глаз". Например, когда значение num_circular_images равно 2, и две линзы расположены симметрично, значение displayed_fov и overlapped_fov может задаваться равным 180 и 190, соответственно, по умолчанию. Тем не менее, значение может изменяться в зависимости от конфигурации линзы и характеристик контента. Например, если качество сшивания со значениями displayed_fov (левая камера=170 и правая камера=190) и значениями overlapped_fov (левая камера=185 и правая камера=190) лучше качества со значениями по умолчанию (180 и 190), либо если физическая конфигурация камер является асимметричной, то могут приниматься неравные значения displayed_fov и overlapped_fov. Помимо этого, когда дело доходит до нескольких (N>2) изображений типа "рыбий глаз", одно значение displayed_fov не может указывать точную площадь каждого изображения типа "рыбий глаз". Как показано на фиг. 6, displayed_fov (602) варьируется согласно направлению. Чтобы обрабатывать несколько (N>2) изображений типа "рыбий глаз", вводится num_angle_for_displaying_fov. Например, если это значение равно 12, то изображение типа "рыбий глаз" разделяется на 12 секторов, при этом каждый угол сектора составляет 30 градусов.

[60] camera_center_yaw указывает угол относительно вертикальной оси, в единицах 2^–16 градусов, точки, в которой центральный пиксел круглого изображения в кодированном изображении каждой выборки проецируется в сферическую поверхность. Он представляет собой первый из 3 углов, которые указывают привнесенные параметры камеры относительно глобальных осей координат; camera_center_yaw должен составлять в диапазоне от –180*2¹⁶ до 180*2¹⁶–1, включительно.

[61] camera_center_pitch указывает угол наклона в продольном направлении, в единицах 2^–16 градусов, точки, в которой центральный пиксел круглого изображения в кодированном изображении каждой выборки проецируется в сферическую поверхность; camera_center_pitch должен составлять в диапазоне от –90*2¹⁶ до 90*2¹⁶, включительно.

[62] camera_center_roll указывает угол наклона в поперечном направлении, в единицах 2^–16 градусов, точки, в которой центральный пиксел круглого изображения в кодированном изображении каждой выборки проецируется в сферическую поверхность; camera_center_roll должен составлять в диапазоне от –180*2¹⁶ до 180*2¹⁶–1, включительно.

[63] camera_center_offset_x, camera_center_offset_y и camera_center_offset_z являются значениями 8,24 с фиксированной запятой, которые указывают значения смещения XYZ от начала координат единичной сферы, на которую проецируются пикселы в круглом изображении в кодированном изображении; camera_center_offset_x, camera_center_offset_y и camera_center_offset_z должны составлять в диапазоне от –1,0 до 1,0, включительно.

[64] num_polynomial_coefficients является целым числом, которое указывает число присутствующих коэффициентов полинома. Список коэффициентов полинома polynomial_coefficient_K являются значениями 8,24 с фиксированной запятой, которые представляют коэффициенты в полиноме, которые указывают преобразование из пространства типа "рыбий глаз" в неискаженное плоское изображение.

[65] num_local_fov_region указывает число локальных областей подгонки, имеющих различное поле обзора.

[66] start_radius, end_radius, start_angle и end_angle указывают область для локальной подгонки/искривления, чтобы изменять фактическое поле обзора для отображения локально; start_radius и end_radius являются значениями 16,16 с фиксированной запятой, которые указывают минимальные и максимальные значения радиуса; start_angle и end_angle указывают минимальные и максимальные значения угла, которые начинаются в 12 часов и увеличиваются по часовой стрелке в единицах 2^–16 градусов; start_angle и end_angle должны составлять в диапазоне от –180*2¹⁶ до 180*2¹⁶–1, включительно.

[67] radius_delta является значением 16,16 с фиксированной запятой, которое указывает дельта–значение радиуса для представления различного поля обзора для каждого радиуса.

[68] angle_delta указывает дельта–значение угла, в единицах 2^–16 градусов, для представления различного поля обзора для каждого угла.

[69] local_fov_weight является форматом с фиксированной запятой 8,24, который указывает весовое значение для поля обзора позиции, указываемой посредством start_radius, end_radius, start_angle, end_angle, индекса i угла и индекса j радиуса. Положительное значение local_fov_weight указывает расширение поля обзора, в то время как отрицательное значение указывает сжатие поля обзора.

[70] num_polynomial_coefficeients_lsc должен быть порядком полиномиальной аппроксимации кривой затенения линзы.

[71] polynomial_coefficient_K_lsc_R, polynomial_coefficient_K_lsc_G и polynomial_coefficient_K_lsc_B являются форматами 8,24 с фиксированной запятой, которые указывают LSC–параметры, чтобы компенсировать артефакт затенения, который уменьшает цвет вдоль радиального направления. Компенсирующий весовой коэффициент (w), который должен умножаться на исходный цвет, аппроксимируется в качестве функции кривой радиуса от центра изображения с использованием полиномиального выражения. Он формулируется как , где p указывает значение коэффициента, равное polynomial_coefficient_K_lsc_R, polynomial_coefficient_K_lsc_G или polynomial_coefficient_K_lsc_B, и r указывает значение радиуса после нормализации посредством full_radius. N равен значению num_polynomial_coefficeients_lsc.

[72] num_deadzones является целым числом, которое указывает число мертвых зон в кодированном изображении каждой выборки, к которой применяется это поле.

[73] deadzone_left_horizontal_offset, deadzone_top_vertical_offset, deadzone_width и deadzone_height являются целочисленными значениями, которые указывают позицию и размер прямоугольной области мертвой зоны, в которой пикселы не являются применимыми; deadzone_left_horizontal_offset и deadzone_top_vertical_offset указывают горизонтальные и вертикальные координаты, соответственно, в выборках сигнала яркости, верхнего левого угла мертвой зоны в кодированном изображении; deadzone_width и deadzone_height указывают ширину и высоту, соответственно, в выборках сигнала яркости, мертвой зоны. Чтобы сокращать число битов для представления видео, все пикселы в мертвой зоне должны задаваться равными идентичному пиксельному значению, например, все являются черными.

[74] Фиг. 3–8 является концептуальными схемами, которые иллюстрируют различные аспекты вышеуказанного синтаксиса и семантики. Фиг. 3 иллюстрирует синтаксис image_center_x и image_center_y в качестве центра 302, синтаксис full_radius в качестве полного радиуса 304, picture_radius в качестве радиуса 306 кадра для кадра 300, scene_radius в качестве радиуса 308 сцены (например, области без преград относительно корпуса камеры 510). Фиг. 4 иллюстрирует displayed_fov (т.е. отображаемое поле обзора (FOV)) для двух изображений типа "рыбий глаз". FOV 402 представляет поле обзора в 170 градусов, и FOV 404 представляет поле обзора в 190 градусов. Фиг. 5 иллюстрирует displayed_fov (т.е. отображаемое поле обзора (FOV)) и overlapped_fov для нескольких (например, N>2) изображений типа "рыбий глаз". FOV 502 представляет первое поле обзора, и FOV 504 представляет второе поле обзора. Фиг. 6 является иллюстрацией синтаксиса camera_center_offset_x (o_x), camera_center_offset_y (o_y) и camera_center_offset_z (o_z). Фиг. 7 является концептуальной схемой, иллюстрирующей параметры относительно локального поля обзора. Фиг. 8 является концептуальной схемой, иллюстрирующей пример локального поля обзора.

[75] Передача в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS может представлять один или более недостатков.

[76] В качестве одного примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, когда имеются два круглых изображения в каждом видеоизображении типа "рыбий глаз" (например, если num_circular_images в синтаксической структуре FisheyeOmnidirectionalVideoInfo() равен 2), в зависимости от значений привнесенных параметров камеры (например, camera_center_yaw, camera_center_pitch, camera_center_roll, camera_center_offset_x, camera_center_offset_y и camera_center_offset_z), видео типа "рыбий глаз" может быть моноскопическим или стереоскопическим. В частности, когда две камеры, захватывающие два круглых изображения, находятся на идентичной стороне, видео типа "рыбий глаз" является стереоскопическим с покрытием приблизительно половины (т.е. 180 градусов по горизонтали) сферы, а когда две камеры находятся на противоположных сторонах, видео типа "рыбий глаз" является моноскопическим, но покрывает полную (т.е. 360 градусов по горизонтали) сферу. Например, когда два набора значений привнесенных параметров камеры являются следующими, видео типа "рыбий глаз" является моноскопическим:

1–ый набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

2–ой набор:

camera_center_yaw=180 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

[77] Вышеуказанные значения параметров могут соответствовать значениям привнесенных параметров камеры вычислительного устройства 10B по фиг. 1B. В качестве другого примера, когда два набора значений привнесенных параметров камеры являются следующими, видео типа "рыбий глаз" является стереоскопическим:

1–ый набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

2–ой набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=64 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

[78] Вышеуказанные значения параметров могут соответствовать значениям привнесенных параметров камеры вычислительного устройства 10A по фиг. 1A. Следует отметить, что расстояние стереосмещения X в 64 мм является эквивалентным 2,5 дюймам, что составляет среднее расстояние между человеческими глазами.

[79] Другими словами, информация относительно того, является видео типа "рыбий глаз" моноскопическим или стереоскопическим, маскируется (т.е. неявно, но не явно кодируется). Тем не менее, для целей высокоуровневой системы, таких как выбор контента, может быть желательным то, что эта информация является легкодоступной как на уровне формата файлов, так и на DASH–уровне (например, таким образом, что объект, который выполняет функцию выбора контента, не должен синтаксически анализировать большое количество информации в синтаксической структуре FisheyeOmnidirectionalVideoInfo(), чтобы определять то, являются соответствующие видеоданные моноскопическими или стереоскопическими).

[80] В качестве другого примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, когда имеются два круглых изображения в каждом видеоизображении типа "рыбий глаз" (например, если num_circular_images в синтаксической структуре FisheyeOmnidirectionalVideoInfo() равен 2), и видео типа "рыбий глаз" является стереоскопическим, клиентское устройство может определять то, какое из двух круглых изображений представляет собой вид для просмотра левым глазом, а какое представляет собой вид для просмотра правым глазом, из привнесенных параметров камеры. Тем не менее, для клиентского устройства может быть нежелательной необходимость быть определять то, какое изображение представляет собой вид для просмотра левым глазом, а какое представляет собой вид для просмотра правым глазом, из привнесенных параметров камеры.

[81] В качестве другого примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, когда имеются четыре камеры типа "рыбий глаз", по две на каждой стороне, для захвата видео типа "рыбий глаз", видео типа "рыбий глаз" должно быть стереоскопическим с покрытием всей сферы. В этом случае, имеются четыре круглых изображения в каждом видеоизображении типа "рыбий глаз" (например, num_circular_images в синтаксической структуре FisheyeOmnidirectionalVideoInfo() равен 4). В таких случаях (когда имеется более двух круглых изображений в каждом видеоизображении типа "рыбий глаз"), клиентское устройство может определять спаривание определенных двух круглых изображений, принадлежащих идентичному виду, из привнесенных параметров камеры. Тем не менее, для клиентского устройства может быть нежелательной необходимость определять спаривание определенных двух круглых изображений, принадлежащих идентичному виду, из привнесенных параметров камеры.

[82] В качестве другого примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, для проецируемого всенаправленного видео, информация покрытия (например, какая область на сфере покрывается видео) либо явно передается в служебных сигналах с использованием CoverageInformationBox, либо, когда не присутствует, логически выводится посредством клиентского устройств в качестве полной сферы. Хотя клиентское устройство может определять покрытие из привнесенных параметров камеры, снова может быть желательной явная передача в служебных сигналах этой информации, которая должна быть легкодоступной.

[83] В качестве другого примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, использование пакетирования в разрезе областей разрешается для проецируемого всенаправленного видео, но запрещается для видео типа "рыбий глаз". Тем не менее, некоторые преимущества пакетирования в разрезе областей, применимого к проецируемому всенаправленному видео, также могут быть применимыми к видео типа "рыбий глаз".

[84] В качестве другого примерного недостатка передачи в служебных сигналах видео типа "рыбий глаз" в текущем проекте OMAF DIS, перенос проецируемого всенаправленного видео в дорожках субизображений указывается в OMAF DIS посредством использования группировки композиционных дорожек. Тем не менее, перенос всенаправленного видео типа "рыбий глаз" в дорожках субизображений не поддерживается.

[85] Это раскрытие сущности представляет решения вышеуказанных проблем. Некоторые из этих технологий могут применяться независимо, и некоторые из них могут применяться в комбинации.

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

[87] В качестве одного примера, один или более начальных 24 битов в синтаксической структуре FisheyeOmnidirectionalVideoInfo() могут использоваться для того, чтобы формировать поле (например, однобитовый флаг), чтобы передавать в служебных сигналах индикатор относительно моноскопического или стереоскопического. Поле, равное первому конкретному значению (например, 0), может указывать то, что видео типа "рыбий глаз" является моноскопическим, и поле, равное второму конкретному значению (например, 1), может указывать то, что видео типа "рыбий глаз" является стереоскопическим. Например, при формировании файла, включающего в себя видеоданные типа "рыбий глаз", устройство подготовки контента (например, устройство 20 подготовки контента по фиг. 9 и, в конкретном примере, модуль 30 инкапсуляции устройства 20 подготовки контента), может кодировать поле (например, FisheyeOmnidirectionalVideoBox) в файле, причем поле включает в себя синтаксическую структуру (например, FisheyeOmnidirectionalVideoInfo), которая содержит параметры для видеоданных типа "рыбий глаз", и синтаксическую структуру, включающую в себя явный индикатор относительно того, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. Клиентское устройство (например, клиентское устройство 40 по фиг. 9 и, в конкретном примере, модуль 52 извлечения клиентского устройства 40) может аналогично обрабатывать файл, чтобы получать явный индикатор относительно моноскопического или стереоскопического.

[88] В качестве другого примера, новое поле, содержащее поле, например, однобитовый флаг, несколько зарезервированных битов и возможно некоторую другую информацию, может добавляться в FisheyeOmnidirectionalVideoBox, чтобы передавать в служебных сигналах индикатор относительно моноскопического или стереоскопического. Поле, равное первому конкретному значению (например, 0), может указывать то, что видео типа "рыбий глаз" является моноскопическим, и поле, равное второму конкретному значению (например, 1), может указывать то, что видео типа "рыбий глаз" является стереоскопическим. Например, при формировании файла, включающего в себя видеоданные типа "рыбий глаз", устройство подготовки контента (например, устройство 20 подготовки контента по фиг. 9) может кодировать первое поле (например, FisheyeOmnidirectionalVideoBox) в файле, причем первое поле включает в себя второе поле, которое включает в себя поле, которое явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. Клиентское устройство (например, клиентское устройство 40 по фиг. 9) может аналогично обрабатывать файл, чтобы получать явный индикатор относительно моноскопического или стереоскопического.

[89] В качестве другого примера, поле (например, однобитовый флаг) может непосредственно добавляться в FisheyeOmnidirectionalVideoBox, чтобы передавать в служебных сигналах этот индикатор. Например, при формировании файла, включающего в себя видеоданные типа "рыбий глаз", устройство подготовки контента (например, устройство 20 подготовки контента по фиг. 9) может кодировать поле (например, FisheyeOmnidirectionalVideoBox) в файле, причем поле включает в себя поле, которое явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. Клиентское устройство (например, клиентское устройство 40 по фиг. 9) может аналогично обрабатывать файл, чтобы получать явный индикатор относительно моноскопического или стереоскопического.

[90] В соответствии с одной или более технологий этого раскрытия сущности, файл, включающий в себя видеоданные типа "рыбий глаз" в качестве множества круглых изображений, может включать в себя, для каждого соответствующего круглого изображения из множества круглых изображений, явный индикатор относительно соответствующих идентификационных данных вида (идентификатора вида). Другими словами, для каждого круглого изображения видеоданных типа "рыбий глаз", может добавляться поле, которое указывает идентификатор вида каждого круглого изображения. Когда имеются только два значения идентификаторов видов в 0 и 1, то вид с идентификатором вида, равным 0, может представлять собой вид для просмотра левым глазом, и вид с идентификатором вида, равным 1, может представлять собой вид для просмотра правым глазом. Например, если множество круглых изображений включают в себя только два круглых изображения, круглое изображение из множества круглых изображений, имеющих первые предварительно определенные идентификационные данные видео, представляет собой вид для просмотра левым глазом, и круглое изображение из множества круглых изображений, имеющих вторые предварительно определенные идентификационные данные видео, представляет собой вид для просмотра правым глазом. Таким образом, клиентское устройство может избегать необходимости логически выводить то, какое круглое изображение представляет собой вид для просмотра левым глазом, а какое представляет собой вид для просмотра правым глазом, из других параметров.

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

[92] Чтобы обеспечивать возможность простого доступа к идентификаторам видов без необходимости синтаксического анализа всех параметров видео типа "рыбий глаз" для круглых изображений, контур может добавляться после поля num_circular_images и перед существующим контуром. Например, обработка файла может включать в себя синтаксический анализ, в первом контуре, явных индикаторов относительно идентификационных данных видов; и синтаксический анализ, во втором контуре, который находится после первого контура, других параметров круглых изображений. Например, идентификаторы видов и другие параметры могут синтаксически анализироваться следующим образом:

aligned(8) class FisheyeOmnidirectionalVideoInfo() {

bit(24) reserved=0;

unsigned int(8) num_circular_images;

for(i=0; i<num_circular_images; i++) {

unsigned int(8) view_id;

bit(24) reserved=0;

}

for(i=0; i<num_circular_images; i++) {

unsigned int(32) image_center_x;

unsigned int(32) image_center_y;

...

}

}

[93] view_id указывает идентификатор вида для вида, которому принадлежит круглое изображение. Когда имеются только два значения view_id в 0 и 1 для всех круглых изображений, круглые изображения с view_id, равным 0, могут принадлежать виду для просмотра левым глазом, и круглые изображения с view_id, равным 1, могут принадлежать виду для просмотра правым глазом. В некоторых примерах, синтаксический элемент(ы), который указывает идентификатор вида (т.е. синтаксический элемент, который указывает то, какое круглое изображение представляет собой вид для просмотра левым глазом, а какое представляет собой вид для просмотра правым глазом), может быть идентичным синтаксическому элементу, который явно указывает то, являются видеоданные типа "рыбий глаз" стереоскопическими или моноскопическими.

[94] В соответствии с одной или более технологий этого раскрытия сущности, файл, включающий в себя видеоданные типа "рыбий глаз", может включать в себя первое поле, которое включает в себя синтаксическую структуру, которая содержит параметры для видеоданных типа "рыбий глаз", и необязательно может включать в себя второе поле, которое указывает информацию покрытия для видеоданных типа "рыбий глаз". Например, передача в служебных сигналах информации покрытия для всенаправленного видео типа "рыбий глаз" может добавляться в FisheyeOmnidirectionalVideoBox. Например, CoverageInformationBox, как задано в OMAF DIS, может иметь возможность необязательно содержаться в FisheyeOmnidirectionalVideoBox, и когда он не присутствует в FisheyeOmnidirectionalVideoBox, полное сферическое покрытие может логически выводиться для видео типа "рыбий глаз". Когда CoverageInformationBox присутствует в FisheyeOmnidirectionalVideoBox, сферическая область, представленная посредством видеоизображений типа "рыбий глаз", может представлять собой область, указываемую посредством двух окружностей наклона относительно вертикальной оси и двух окружностей наклона в продольном направлении. Таким образом, клиентское устройство может избегать необходимости логически выводить информацию покрытия из других параметров.

[95] В соответствии с одной или более технологий этого раскрытия сущности, файл, включающий в себя видеоданные типа "рыбий глаз", может включать в себя первое поле, которое включает в себя информацию схемы, первое поле может включать в себя второе поле, которое включает в себя синтаксическую структуру, которая содержит параметры для видеоданных типа "рыбий глаз", и первое поле необязательно может включать в себя третье поле, которое указывает то, пакетированы или нет изображения видеоданных типа "рыбий глаз" в разрезе областей. Например, RegionWisePackingBox может быть необязательно включен в SchemeInformationBox для всенаправленного видео типа "рыбий глаз" (например, когда FisheyeOmnidirectionalVideoBox присутствует в SchemeInformationBox, RegionWisePackingBox может присутствовать в идентичном SchemeInformationBox). В этом случае, присутствие RegionWisePackingBox указывает то, что видеоизображения типа "рыбий глаз" пакетированы в разрезе областей и требуют распаковки до рендеринга. Таким образом, одно или более преимуществ пакетирования в разрезе областей могут получаться для видео типа "рыбий глаз".

[96] В соответствии с одной или более технологий этого раскрытия сущности, группировка для композиции субизображений может использоваться для всенаправленного видео типа "рыбий глаз", и указание относительно применения группировки для композиции субизображений может добавляться во всенаправленное видео типа "рыбий глаз". Это указание может применяться, когда любая из дорожек, преобразованных в группу композиционных дорожек субизображений, имеет тип записи выборки, равный resv, и scheme_type, равный fodv, в SchemeTypeBox, включенном в запись выборки. В этом случае, каждое композиционное изображение представляет собой пакетированное изображение, которое имеет формат типа "рыбий глаз", указываемый посредством любого FisheyeOmnidirectionalVideoBox, и формат пакетирования в разрезе областей, указываемый посредством любого RegionWisePackingBox, включенного в записи выборок дорожек, преобразованных в группу композиционных дорожек субизображений. Помимо этого, может применяться следующее:

[97] 1) Каждая дорожка, преобразованная в эту группировку, должна иметь тип записи выборки, равный resv; scheme_type должен быть равен fodv в SchemeTypeBox, включенном в запись выборки.

[98] 2) Контент всех экземпляров FisheyeOmnidirectionalVideoBox, включенных в записи выборок дорожек, преобразованных в идентичную группу композиционных дорожек субизображений, должен быть идентичным.

[99] 3) Контент всех экземпляров RegionWisePackingBox, включенных в записи выборок дорожек, преобразованных в идентичную группу композиционных дорожек субизображений, должен быть идентичным.

[100] В потоковой HTTP–передаче, часто используемые операции включают в себя HEAD, GET и частичный GET. Операция HEAD извлекает заголовок файла, ассоциированного с данным универсальным указателем ресурса (URL–адресом) или универсальным именем ресурса (URN), без извлечения рабочих данных, ассоциированных с URL–адресом или URN. Операция GET извлекает целый файл, ассоциированный с данным URL–адресом или URN. Операция частичного GET принимает байтовый диапазон в качестве входного параметра и извлекает непрерывное число байтов файла, при этом число байтов соответствует принимаемому байтовому диапазону. Таким образом, кинофрагменты могут предоставляться для потоковой HTTP–передачи, поскольку операция частичного GET может получать один или более отдельных кинофрагментов. В кинофрагменте, может быть предусмотрено несколько фрагментов дорожек для различных дорожек. В потоковой HTTP–передаче, мультимедийное представление может представлять собой структурированную совокупность данных, которая является доступной для клиента. Клиент может запрашивать и загружать информацию в виде мультимедийных данных, чтобы представлять услугу потоковой передачи пользователю.

[101] В примере потоковой передачи 3GPP–данных с использованием потоковой HTTP–передачи, может быть предусмотрено несколько представлений для видео– и/или аудиоданных мультимедийного контента. Как пояснено ниже, различные представления могут соответствовать различным характеристикам кодирования (например, различным профилям или уровням стандарта кодирования видео), различным стандартам кодирования или расширениям стандартов кодирования (к примеру, многовидовым и/или масштабируемым расширениям) или различным скоростям передачи битов. Манифест таких представлений может задаваться в структуре данных описания мультимедийного представления (MPD). Мультимедийное представление может соответствовать структурированной совокупности данных, которая является доступной для клиентского устройства с поддержкой потоковой HTTP–передачи. Клиентское устройство с поддержкой потоковой HTTP–передачи может запрашивать и загружать информацию в виде мультимедийных данных, чтобы представлять услугу потоковой передачи пользователю клиентского устройства. Мультимедийное представление может описываться в структуре MPD–данных, которая может включать в себя обновления MPD.

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

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

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

[105] Различные представления могут выбираться для практически одновременного извлечения для различных типов мультимедийных данных. Например, клиентское устройство может выбирать аудиопредставление, видеопредставление и синхронизированное по времени текстовое представление, из которых можно извлекать сегменты. В некоторых примерах, клиентское устройство может выбирать конкретные адаптивные наборы для выполнения адаптации полосы пропускания. Иными словами, клиентское устройство может выбирать адаптивный набор, включающий в себя видеопредставления, адаптивный набор, включающий в себя аудиопредставления, и/или адаптивный набор, включающий в себя синхронизированный по времени текст. Альтернативно, клиентское устройство может выбирать адаптивные наборы для определенных типов мультимедиа (например, видео) и непосредственно выбирать представления для других типов мультимедиа (например, аудио и/или синхронизированного по времени текста).

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

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

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

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

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

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

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

[113] Множество стандартов кодирования видео, таких как ITU–T H.264/AVC и стандарт высокоэффективного кодирования видео (HEVC), задают синтаксис, семантику и процесс декодирования для безошибочных потоков битов, любой из которых соответствует определенному профилю или уровню. Стандарты кодирования видео типично не указывают кодер, но кодер имеет задачу гарантирования того, что сформированные потоки битов являются совместимыми со стандартом для декодера. В контексте стандартов кодирования видео, "профиль" соответствует поднабору алгоритмов, признаков или инструментальных средств и ограничений, которые применяются к ним. Как задано посредством стандарта H.264, например, "профиль" представляет собой поднабор полного синтаксиса потока битов, который указывается посредством стандарта H.264. "Уровень" соответствует ограничениям по потреблению ресурсов декодера, таких как, например, запоминающее устройство декодера и вычисление, которые связаны с разрешением изображений, скорость передачи битов и скорость блочной обработки. Профиль может передаваться в служебных сигналах со значением profile_idc (индикатора профиля), тогда как уровень может передаваться в служебных сигналах со значением level_idc (индикатора уровня).

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

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

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

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

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

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

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

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

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

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

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

[125] Модуль 70 обработки запросов выполнен с возможностью принимать сетевые запросы из клиентских устройств, таких как клиентское устройство 40, на предмет данных носителя 62 хранения данных. Например, модуль 70 обработки запросов может реализовывать версию 1.1 протокола передачи гипертекста (HTTP), как описано в документе RFC 2616 "Hypertext Transfer Protocol – HTTP/1.1" авторов R. Fielding и др., Network Working Group, IETF, июнь 1999 года. Иными словами, модуль 70 обработки запросов может быть выполнен с возможностью принимать HTTP GET– или частичные GET–запросы и предоставлять данные мультимедийного контента 64 в ответ на запросы. Запросы могут указывать сегмент одного из представлений 68, например, с использованием URL–адреса сегмента. В некоторых примерах, запросы также могут указывать один или более байтовых диапазонов сегмента, за счет этого включая в себя частичные GET–запросы. Модуль 70 обработки запросов дополнительно может быть выполнен с возможностью обслуживать HTTP HEAD–запросы, чтобы предоставлять данные заголовка сегмента одного из представлений 68. В любом случае, модуль 70 обработки запросов может быть выполнен с возможностью обрабатывать запросы, чтобы предоставлять запрашиваемые данные в запрашивающее устройство, к примеру, в клиентское устройство 40.

[126] Дополнительно или альтернативно, модуль 70 обработки запросов может быть выполнен с возможностью доставлять мультимедийные данные через протокол широковещательной или многоадресной передачи, такой как eMBMS. Устройство 20 подготовки контента может создавать DASH–сегменты и/или субсегменты практически идентично тому, что описано, но серверное устройство 60 может доставлять эти сегменты или субсегменты с использованием eMBMS либо другого сетевого транспортного протокола широковещательной или многоадресной передачи. Например, модуль 70 обработки запросов может быть выполнен с возможностью принимать запрос на присоединение к группе многоадресной передачи из клиентского устройства 40. Иными словами, серверное устройство 60 может оповещать адрес по Интернет–протоколу (IP), ассоциированный с группой многоадресной передачи, в клиентские устройства, включающие в себя клиентское устройство 40, ассоциированное с конкретным мультимедийным контентом (например, широковещательной передачей передаваемого вживую события). Клиентское устройство 40, в свою очередь, может отправлять запрос на то, чтобы присоединяться к группе многоадресной передачи. Этот запрос может распространяться по сети 74, например, через маршрутизаторы, составляющие сеть 74, так что маршрутизаторам инструктируется направлять трафик, предназначенный для IP–адреса, ассоциированного с группой многоадресной передачи, в подписанные клиентские устройства, такие как клиентское устройство 40.

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

[128] В частности, модуль 52 извлечения может извлекать конфигурационные данные (не показаны) клиентского устройства 40, чтобы определять характеристики декодирования видеодекодера 48 и характеристики рендеринга видеовывода 44. Конфигурационные данные также могут включать в себя любое из настройки языка, выбранной пользователем клиентского устройства 40, одной или более перспектив камеры, соответствующих настройкам глубины, заданным пользователем клиентского устройства 40, и/или настройки рейтинга, выбранной пользователем клиентского устройства 40. Модуль 52 извлечения может содержать, например, веб–обозреватель или мультимедийный клиент, выполненный с возможностью отправлять HTTP GET– и частичные GET–запросы. Модуль 52 извлечения может соответствовать программным инструкциям, выполняемым посредством одного или более процессоров или модулей обработки (не показаны) клиентского устройства 40. В некоторых примерах, вся или части функциональности, описанной относительно модуля 52 извлечения, может реализовываться в аппаратных средствах или комбинации аппаратных средств, программного обеспечения и/или микропрограммного обеспечения, при этом требуемые аппаратные средства могут предоставляться, чтобы выполнять инструкции для программного обеспечения или микропрограммного обеспечения.

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

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

[131] Дополнительно или альтернативно, модуль 52 извлечения может быть выполнен с возможностью принимать данные в соответствии с сетевым протоколом широковещательной или многоадресной передачи, таким как eMBMS или многоадресная IP–передача. В таких примерах, модуль 52 извлечения может отправлять запрос, чтобы присоединяться к сетевой группе многоадресной передачи, ассоциированной с конкретным мультимедийным контентом. После присоединения к группе многоадресной передачи, модуль 52 извлечения может принимать данные группы многоадресной передачи без дополнительных запросов, выданных в серверное устройство 60 или устройство 20 подготовки контента. Модуль 52 извлечения может отправлять запрос, чтобы выходить из группы многоадресной передачи, когда данные группы многоадресной передачи более не требуются, например, чтобы прекращать воспроизведение или переключать каналы на другую группу многоадресной передачи.

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

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

[134] Клиентское устройство 40, серверное устройство 60 и/или устройство 20 подготовки контента могут быть выполнены с возможностью работать в соответствии с технологиями этого раскрытия сущности. В целях примера, это раскрытие сущности описывает эти технологии относительно клиентского устройства 40 и серверного устройства 60. Тем не менее, следует понимать, что устройство 20 подготовки контента может быть выполнено с возможностью осуществлять эти технологии, вместо (или в дополнение к) серверного устройства 60.

[135] Модуль 30 инкапсуляции может формировать NAL–единицы, содержащие заголовок, который идентифицирует программу, которой принадлежит NAL–единица, а также рабочие данные, например, аудиоданные, видеоданные или данные, которые описывают транспортный или программный поток, которому соответствует NAL–единица. Например, в H.264/AVC, NAL–единица включает в себя 1–байтовый заголовок и рабочие данные варьирующегося размера. NAL–единица, включающая в себя видеоданные в своих рабочих данных, может содержать различные уровни детализации видеоданных. Например, NAL–единица может содержать блок видеоданных, множество блоков, серию последовательных макроблоков видеоданных или полное изображение видеоданных. Модуль 30 инкапсуляции может принимать кодированные видеоданные из видеокодера 28 в форме PES–пакетов элементарных потоков. Модуль 30 инкапсуляции может ассоциировать каждый элементарный поток с соответствующей программой.

[136] Модуль 30 инкапсуляции также может ассемблировать единицы доступа из множества NAL–единиц. В общем, единица доступа может содержать одну или более NAL–единиц для представления кадра видеоданных, также аудиоданных, соответствующих кадру, когда такие аудиоданные доступны. Единица доступа, в общем, включает в себя все NAL–единицы для одного момента времени вывода, например, все аудио– и видеоданные для одного момента времени. Например, если каждый вид имеет частоту кадров в 20 кадров в секунду (кадр/с), то каждый момент времени может соответствовать временному интервалу в 0,05 секунд. В течение этого временного интервала, конкретные кадры для всех видов идентичной единицы доступа (идентичного момента времени) могут подготавливаться посредством рендеринга одновременно. В одном примере, единица доступа может содержать кодированное изображение в один момент времени, которое может представляться в качестве первичного кодированного изображения.

[137] Соответственно, единица доступа может содержать все аудио– и видеокадры общего временного момента, например, все виды, соответствующие времени X. Это раскрытие сущности также упоминает кодированное изображение конкретного вида в качестве "компонента вида". Иными словами, компонент вида может содержать кодированное изображение (или кадр) для конкретного вида в конкретное время. Соответственно, единица доступа может задаваться как включающая в себя все компоненты видов общего временного момента. Порядок декодирования единиц доступа необязательно должен быть идентичным порядку вывода или отображения.

[138] Мультимедийное представление может включать в себя описание мультимедийного представления (MPD), которое может содержать описания различных альтернативных представлений (например, услуг передачи видео с различным качеством), и описание может включать в себя, например, информацию кодека, значение профиля и значение уровня. MPD представляет собой один пример файла манифеста, такого как файл 66 манифеста. Клиентское устройство 40 может извлекать MPD мультимедийного представления, чтобы определять то, как осуществлять доступ к кинофрагментам различных представлений. Кинофрагменты могут быть расположены в полях кинофрагментов (полях moof) видеофайлов.

[139] Файл 66 манифеста (который может содержать, например, MPD) может оповещать доступность сегментов представлений 68. Иными словами, MPD может включать в себя информацию, указывающую физическое время, в которое первый сегмент одного из представлений 68 становится доступным, а также информацию, указывающую длительность сегментов в представлениях 68. Таким образом, модуль 52 извлечения клиентского устройства 40 может определять то, когда каждый сегмент доступен, на основе начального времени, а также длительности сегментов, предшествующих конкретному сегменту.

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

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

[142] Таким образом, клиентское устройство 40 представляет пример устройства для извлечения мультимедийных данных, причем устройство включает в себя устройство для извлечения файлов видеоданных типа "рыбий глаз", как описано выше и/или как заявлено в формуле изобретения ниже. Например, клиентское устройство 40 может извлекать файлы видеоданных типа "рыбий глаз" и/или подготавливать посредством рендеринга видео типа "рыбий глаз" на основе определения того, является видео типа "рыбий глаз" моноскопическим или стереоскопическим, и это определение может быть основано на синтаксическом элементе, который явно указывает то, является видео типа "рыбий глаз" моноскопическим или стереоскопическим.

[143] Аналогично, устройство 20 подготовки контента представляет устройство для формирования файлов видеоданных типа "рыбий глаз", как описано выше и/или как заявлено в формуле изобретения ниже. Например, устройство 20 подготовки контента может включать в себя в видеоданных типа "рыбий глаз", синтаксический элемент, который явно указывает то, является видео типа "рыбий глаз" моноскопическим или стереоскопическим.

[144] Фиг. 10 является концептуальной схемой, иллюстрирующей элементы примерного мультимедийного контента 120. Мультимедийный контент 120 может соответствовать мультимедийному контенту 64 (фиг. 9) или другому мультимедийному контенту, сохраненному на носителе 62 хранения данных. В примере по фиг. 10, мультимедийный контент 120 включает в себя описание 122 мультимедийного представления (MPD) и множество представлений 124A–124N (представлений 124). Представление 124A включает в себя необязательные данные 126 заголовка и сегменты 128A–128N (сегменты 128), тогда как представление 124N включает в себя необязательные данные 130 заголовка и сегменты 132A–132N (сегменты 132). Буква N используется для того, чтобы обозначать последний кинофрагмент в каждом из представлений 124 для удобства. В некоторых примерах, могут быть предусмотрены различные числа кинофрагментов между представлениями 124.

[145] MPD 122 может содержать структуру данных, отдельную от представлений 124. MPD 122 может соответствовать файлу 66 манифеста по фиг. 9. В общем, MPD 122 может включать в себя данные, которые, в общем, описывают характеристики представлений 124, такие как характеристики кодирования и рендеринга, адаптивные наборы, профиль, которому соответствует MPD 122, информация типов текста, информация ракурсов камеры, рейтинговая информация, информация режимов трюков (например, информация, указывающая представления, которые включают в себя временные подпоследовательности), и/или информация для извлечения удаленных периодов (например, для вставки адресных рекламных объявлений в мультимедийный контент во время воспроизведения).

[146] Данные 126 заголовка, когда присутствуют, могут описывать характеристики сегментов 128, например, временные местоположения точек произвольного доступа (RAP, также называемых в качестве точек доступа к потоку (SAP)), то, какие из сегментов 128 включают в себя точки произвольного доступа, байтовые смещения в точках произвольного доступа в сегментах 128, универсальные указатели ресурса (URL–адреса) сегментов 128 либо другие аспекты сегментов 128. Данные 130 заголовка, когда присутствуют, могут описывать аналогичные характеристики для сегментов 132. Дополнительно или альтернативно, такие характеристики могут быть полностью включены в MPD 122.

[147] Сегменты 128, 132 включают в себя одну или более кодированных видеовыборок, каждая из которых может включать в себя кадры или серии последовательных макроблоков видеоданных. Каждая из кодированных видеовыборок сегментов 128 может иметь аналогичные характеристики, например, высоту, ширину и требования по полосе пропускания. Такие характеристики могут описываться посредством данных MPD 122, хотя такие данные не проиллюстрированы в примере по фиг. 10. MPD 122 может включать в себя характеристики, как описано посредством технических требований 3GPP, с добавлением любой из передаваемой в служебных сигналах информации, описанной в этом раскрытии сущности.

[148] Каждый из сегментов 128, 132 может быть ассоциирован с уникальным универсальным указателем ресурса (URL–адресом). Таким образом, каждый из сегментов 128, 132 может быть независимо извлекаемым с использованием сетевого протокола потоковой передачи, такого как DASH. Таким образом, устройство назначения, к примеру, клиентское устройство 40, может использовать HTTP GET–запрос, чтобы извлекать сегменты 128 или 132. В некоторых примерах, клиентское устройство 40 может использовать частичные HTTP GET–запросы, чтобы извлекать конкретные байтовые диапазоны сегментов 128 или 132.

[149] Фиг. 11 является блок–схемой, иллюстрирующей элементы примерного видеофайла 150, который может соответствовать сегменту представления, к примеру, одному из сегментов 114, 124 по фиг. 10. Каждый из сегментов 128, 132 может включать в себя данные, которые фактически соответствуют компоновке данных, проиллюстрированных в примере по фиг. 11. Можно сказать, что видеофайл 150 инкапсулирует сегмент. Как описано выше, видеофайлы в соответствии с базовым форматом мультимедийных файлов ISO и его расширениями сохраняют данные в последовательности объектов, называемых в качестве "полей". В примере по фиг. 11, видеофайл 150 включает в себя поле 152 типов файлов (FTYP), кинополе 154 (MOOV), поля 162 индексов сегментов (SIDX), поля 164 кинофрагментов (MOOF) и поле 166 произвольного доступа к кинофрагментам (MFRA). Хотя фиг. 11 представляет пример видеофайла, следует понимать, что другие мультимедийные файлы могут включать в себя другие типы мультимедийных данных (например, аудиоданные, синхронизированные по времени текстовые данные и т.п.), которые структурированы аналогично данным видеофайла 150, в соответствии с базовым форматом мультимедийных файлов ISO и его расширениями.

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

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

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

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

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

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

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

[157] Кроме того, в соответствии с технологиями этого раскрытия сущности, видеофайл 150 может включать FisheyeOmnidirectionalVideoBox в SchemeInformationBox, который может быть включен в поле 154 MOOV. В некоторых примерах, FisheyeOmnidirectionalVieoBox может быть включен в поле 158 TRAK, если различные дорожки видеофайла 150 могут включать в себя моноскопические или стереоскопические видеоданные типа "рыбий глаз". В некоторых примерах, FisheyeOmnidirectionalVieoBox может быть включен в поле 157 FOV.

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

[159] Поля 162 SIDX представляют собой необязательные элементы видеофайла 150. Иными словами, видеофайлы, соответствующие 3GPP–формату файлов или другим таким форматам файлов, не обязательно включают в себя поля 162 SIDX. В соответствии с примером 3GPP–формата файлов, поле SIDX может использоваться для того, чтобы идентифицировать субсегмент сегмента (например, сегмента, содержащегося в видеофайле 150). 3GPP–формат файлов задает субсегмент в качестве "автономного набора из одного или более последовательных полей кинофрагментов с соответствующим полем(ями) мультимедийных данных, и поле мультимедийных данных, содержащее данные, к которым обращаются посредством поля кинофрагментов, должно идти после этого поля кинофрагментов и предшествовать следующему полю кинофрагментов, содержащему информацию относительно идентичной дорожки". 3GPP–формат файлов также указывает то, что поле SIDX "содержит последовательность ссылок на субсегменты для (суб)сегмента, задокументированного посредством поля. Субсегменты, к которым обращаются, являются смежными по времени представления. Аналогично, байты, на которые ссылаются посредством поля индексов сегментов, всегда являются смежными в сегменте. Размер, к которому обращаются, обеспечивает подсчет числа байтов в материале, к которому обращаются".

[160] Поля 162 SIDX, в общем, предоставляют информацию, представляющую один или более субсегментов сегмента, включенного в видеофайл 150. Например, эта информация может включать в себя времена воспроизведения, в которые субсегменты начинаются и/или завершаются, байтовые смещения для субсегментов, то, включают или нет субсегменты в себя (например, начинаются) точку доступа к потоку (SAP), тип для SAP (например, то, представляет собой SAP изображение на основе мгновенного обновления декодера (IDR), изображение на основе чистого произвольного доступа (CRA), изображение на основе доступа к нерабочей ссылке (BLA) и т.п.), позицию SAP (с точки зрения времени воспроизведения и/или байтового смещения) в субсегменте и т.п.

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

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

[163] В некоторых примерах, кинофрагменты 164 могут включать в себя одну или более точек доступа к потоку (SAP), таких как IDR–изображения. Аналогично, поле 166 MFRA может предоставлять индикаторы относительно местоположений в видеофайле 150 SAP. Соответственно, временная подпоследовательность видеофайла 150 может формироваться из SAP видеофайла 150. Временная подпоследовательность также может включать в себя другие изображения, такие как P–кадры и/или B–кадры, которые зависят от SAP. Кадры и/или серии последовательных макроблоков временной подпоследовательности могут размещаться в сегментах таким образом, что кадры/серии последовательных макроблоков временной подпоследовательности, которые зависят от других кадров/серий последовательных макроблоков подпоследовательности, могут надлежащим образом декодироваться. Например, в иерархической компоновке данных, данные, используемые для прогнозирования для других данных, также могут быть включены во временную подпоследовательность.

[164] Фиг. 12 является блок–схемой последовательности операций способа, иллюстрирующей примерную технологию для обработки файла, который включает в себя видеоданные типа "рыбий глаз", в соответствии с одной или более технологий этого раскрытия сущности. Технологии по фиг. 12 описываются как выполняемые посредством клиентского устройства 40 по фиг. 9, хотя устройства, имеющие конфигурации, отличные от клиентского устройства 40, могут выполнять технологию по фиг. 12.

[165] Клиентское устройство 40 может принимать файл, включающий в себя видеоданные типа "рыбий глаз" и синтаксическую структуру, которая включает в себя множество синтаксических элементов, указывающих атрибуты видеоданных типа "рыбий глаз" (1202). Как пояснено выше, множество синтаксических элементов могут включать в себя первый синтаксический элемент, который явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, и один или более синтаксических элементов, которые неявно указывают то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. Один или более синтаксических элементов, которые неявно указывают то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, могут представлять собой синтаксические элементы, которые явно указывают привнесенные параметры камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз". В некоторых примерах, один или более синтаксических элементов могут быть или могут быть аналогичными синтаксическим элементам, включенным в синтаксическую структуру FisheyeOmnidirectionalVideoInfo() в текущем проекте OMAF DIS. В некоторых примерах, первый синтаксический элемент может быть включен в набор начальных битов синтаксической структуры (например, в начальные 24 бита синтаксической структуры FisheyeOmnidirectionalVideoInfo()).

[166] Клиентское устройство 40 может определять, на основе первого синтаксического элемента, то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими (1204). Значение первого синтаксического элемента может явно указывать то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими. В качестве одного примера, в котором первый синтаксический элемент имеет первое значение, клиентское устройство 40 может определять то, что видеоданные типа "рыбий глаз" являются моноскопическими (т.е. то, что круглые изображения, включенные в изображения видеоданных типа "рыбий глаз", имеют совмещенные оптические оси и обращены в противоположных направлениях). В качестве другого примера, в котором первый синтаксический элемент имеет второе значение, клиентское устройство 40 может определять то, что видеоданные типа "рыбий глаз" являются стереоскопическими (т.е. то, что круглые изображения, включенные в изображения видеоданных типа "рыбий глаз", имеют параллельные оптические оси и обращены в идентичном направлении).

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

[168] Клиентское устройство 40 может подготавливать посредством рендеринга видеоданные типа "рыбий глаз" на основе определения. Например, в ответ на определение того, что видеоданные типа "рыбий глаз" являются моноскопическими, клиентское устройство 40 может подготавливать посредством рендеринга данные типа "рыбий глаз" как моноскопические (1206). Например, клиентское устройство 40 может определять порт вида (т.е. часть сферы, на которую в данный момент "смотрит" пользователь), идентифицировать часть круглых изображений видеоданных типа "рыбий глаз", которые соответствуют порту вида, и отображать идентичную часть круглых изображений для каждого из глаз зрителя. Аналогично, в ответ на определение того, что видеоданные типа "рыбий глаз" являются стереоскопическими, клиентское устройство 40 может подготавливать посредством рендеринга данные типа "рыбий глаз" как стереоскопические (1208). Например, клиентское устройство 40 может определять порт вида (т.е. часть сферы, на которую в данный момент "смотрит" пользователь), идентифицировать соответствующую часть каждого из круглых изображений видеоданных типа "рыбий глаз", которые соответствуют порту вида, и отображать соответствующие части круглых изображений для глаз зрителя.

[169] Фиг. 13 является блок–схемой последовательности операций способа, иллюстрирующей примерную технологию для формирования файла, который включает в себя видеоданные типа "рыбий глаз", в соответствии с одной или более технологий этого раскрытия сущности. Технологии по фиг. 13 описываются как выполняемые посредством устройства 20 подготовки контента по фиг. 9, хотя устройства, имеющие конфигурации, отличные от устройства 20 подготовки контента, могут выполнять технологию по фиг. 13.

[170] Устройство 20 подготовки контента может получать видеоданные типа "рыбий глаз" и привнесенные параметры камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз" (1302). Например, устройство 20 подготовки контента может получать изображения видеоданных типа "рыбий глаз", которые кодируются с использованием видеокодека, такого как HEVC. Каждое изображение видеоданных типа "рыбий глаз" может включать в себя множество круглых изображений, которые соответствуют изображению, захваченному посредством различной камеры с линзой типа "рыбий глаз" (например, изображение может включать в себя первое круглое изображение, захваченное через линзу 12A типа "рыбий глаз" по фиг. 1A, и второе круглое изображение, захваченное через линзу 12B типа "рыбий глаз" по фиг. 1A). Привнесенные параметры могут указывать различные атрибуты камер. Например, привнесенные параметры могут указывать угол относительно вертикальной оси, угол наклона в продольном направлении, угол наклона в поперечном направлении и одно или более пространственных смещений каждой из камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз".

[171] Устройство 20 подготовки контента может определять, на основе привнесенных параметров, то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими (1304). В качестве одного примера, когда два набора значений привнесенных параметров камеры являются следующими, устройство 20 подготовки контента может определять то, что видео типа "рыбий глаз" является стереоскопическим:

1–ый набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

2–ой набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=64 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

[172] В качестве другого примера, когда два набора значений привнесенных параметров камеры являются следующими, устройство 20 подготовки контента может определять то, что видео типа "рыбий глаз" является моноскопическим:

1–ый набор:

camera_center_yaw=0 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

2–ой набор:

camera_center_yaw=180 градусов (+/–5 градусов)

camera_center_pitch=0 градусов (+/–5 градусов)

camera_center_roll=0 градусов (+/–5 градусов)

camera_center_offset_x=0 мм (+/–3 мм)

camera_center_offset_y=0 мм (+/–3 мм)

camera_center_offset_z=0 мм (+/–3 мм)

[173] Устройство 20 подготовки контента может кодировать, в файле, видеоданные типа "рыбий глаз" и синтаксическую структуру, включающую в себя множество синтаксических элементов, которые указывают атрибуты видеоданных типа "рыбий глаз" (1306). Множество синтаксических элементов включают в себя: первый синтаксический элемент, который явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, и один или более синтаксических элементов, которые явно указывают привнесенные параметры камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз".

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

[175] В качестве примера, а не ограничения, эти машиночитаемые носители хранения данных могут содержать RAM, ROM, EEPROM, CD–ROM или другое устройство хранения данных на оптических дисках, устройство хранения данных на магнитных дисках или другие магнитные устройства хранения, флэш–память либо любой другой носитель, который может использоваться для того, чтобы сохранять требуемый программный код в форме инструкций или структур данных, и к которому можно осуществлять доступ посредством компьютера. Кроме того, любое соединение корректно называть машиночитаемым носителем. Например, если инструкции передаются из веб–узла, сервера или другого удаленного источника с помощью коаксиального кабеля, оптоволоконного кабеля, "витой пары", цифровой абонентской линии (DSL), или беспроводных технологий, таких как инфракрасные, радиопередающие и микроволновые среды, то коаксиальный кабель, оптоволоконный кабель, "витая пара", DSL или беспроводные технологии, такие как инфракрасные, радиопередающие и микроволновые среды, включаются в определение носителя. Тем не менее, следует понимать, что машиночитаемые носители хранения данных и носители хранения данных не включают в себя соединения, несущие, сигналы или другие энергозависимые носители, а вместо этого направлены на энергонезависимые материальные носители хранения данных. Диск (disk) и диск (disc) при использовании в данном документе включают в себя компакт–диск (CD), лазерный диск, оптический диск, универсальный цифровой диск (DVD), гибкий диск и Blu–Ray–диск, при этом диски (disk) обычно воспроизводят данные магнитно, тогда как диски (disc) обычно воспроизводят данные оптически с помощью лазеров. Комбинации вышеперечисленного также следует включать в число машиночитаемых носителей.

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

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

[178] Выше описаны различные примеры. Эти и другие примеры находятся в пределах объема прилагаемой формулы изобретения.

Изобретение относится к хранению и транспортировке кодированных видеоданных. Техническим результатом является более эффективно передавать и принимать цифровую видеоинформацию. Предложен способ обработки файла, включающего в себя видеоданные типа "рыбий глаз". При рендеринге видеоданных типа "рыбий глаз", для видеодекодера может быть желательным определять то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, при этом множество синтаксических элементов включают в себя: первый синтаксический элемент, который явно указывает то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими, и один или более синтаксических элементов, которые неявно указывают то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; определение, на основе первого синтаксического элемента, того, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и рендеринг, на основе определения, видеоданных типа "рыбий глаз" как моноскопических или стереоскопических. 4 н. и 38 з.п. ф-лы, 14 ил.

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

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

определяют, на основе первого синтаксического элемента, то, являются видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и

выводят, на основе определения, видеоданные типа "рыбий глаз" для рендеринга как моноскопические или стереоскопические.

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

3. Способ по п. 2, в котором набор начальных битов имеет длину в 24 бита.

4. Способ по п. 1, в котором файл включает в себя поле, которое включает в себя синтаксическую структуру.

5. Способ по п. 4, в котором поле представляет собой первое поле, которое включено во второе поле, причем способ дополнительно содержит этап, на котором:

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

6. Способ по п. 5, дополнительно содержащий этапы, на которых:

в ответ на определение того, что первое поле включает в себя третье поле, распаковывают изображения видеоданных до рендеринга изображений видеоданных; или

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

7. Способ по п. 5, в котором первое поле представляет собой SchemeInformationBox, второе поле представляет собой FisheyeOmnidirectionalVideoBox и третье поле представляет собой RegionWisePackingBox.

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

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

10. Способ по п. 1, в котором синтаксическая структура является внешней для данных слоя кодирования видео (VCL), инкапсулированных посредством файла.

11. Способ по п. 1, в котором определение того, являются видеоданные моноскопическими или стереоскопическими, содержит этап, на котором:

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

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

получают видеоданные типа "рыбий глаз" и привнесенные параметры камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз";

определяют, на основе привнесенных параметров, то, являются ли видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и

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

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

14. Способ по п. 13, в котором набор начальных битов имеет длину в 24 бита.

15. Способ по п. 12, в котором файл включает в себя поле, которое включает в себя синтаксическую структуру.

16. Способ по п. 15, в котором поле представляет собой первое поле, которое включено во второе поле, причем способ дополнительно содержит этап, на котором:

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

17. Способ по п. 16, в котором первое поле представляет собой SchemeInformationBox, второе поле представляет собой FisheyeOmnidirectionalVideoBox и третье поле представляет собой RegionWisePackingBox.

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

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

20. Способ по п. 12, в котором видеоданные кодируются в слое кодирования видео (VCL), при этом синтаксическая структура является внешней для VCL.

21. Устройство для обработки видеоданных, при этом устройство содержит:

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

один или более процессоров, выполненных с возможностью:

определять, на основе первого синтаксического элемента, то, являются ли видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и

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

22. Устройство по п. 21, в котором первый синтаксический элемент включен в набор начальных битов синтаксической структуры.

23. Устройство по п. 22, в котором набор начальных битов имеет длину в 24 бита.

24. Устройство по п. 21, в котором файл включает в себя поле, которое включает в себя синтаксическую структуру.

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

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

26. Устройство по п. 25, в котором:

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

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

27. Устройство по п. 25, в котором первое поле представляет собой SchemeInformationBox, второе поле представляет собой FisheyeOmnidirectionalVideoBox и третье поле представляет собой RegionWisePackingBox.

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

29. Устройство по п. 21, в котором синтаксическая структура является внешней для данных слоя кодирования видео (VCL), инкапсулированных посредством файла.

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

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

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

запоминающее устройство, выполненное с возможностью сохранять видеоданные типа "рыбий глаз"; и

один или более процессоров, выполненных с возможностью:

получать привнесенные параметры камер, используемых для того, чтобы захватывать видеоданные типа "рыбий глаз";

определять, на основе привнесенных параметров, то, являются ли видеоданные типа "рыбий глаз" моноскопическими или стереоскопическими; и

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

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

33. Устройство по п. 32, в котором набор начальных битов имеет длину в 24 бита.

34. Устройство по п. 31, в котором файл включает в себя поле, которое включает в себя синтаксическую структуру.

35. Устройство по п. 34, в котором поле представляет собой первое поле, которое включено во второе поле, один или более процессоров дополнительно выполнены с возможностью:

кодировать, в первом поле, третье поле, которое указывает то, пакетированы или нет изображения видеоданных типа "рыбий глаз".

36. Устройство по п. 35, в котором первое поле представляет собой SchemeInformationBox, второе поле представляет собой FisheyeOmnidirectionalVideoBox и третье поле представляет собой RegionWisePackingBox.

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

38. Устройство по п. 31, в котором видеоданные кодируются в слое кодирования видео (VCL), при этом синтаксическая структура является внешней для VCL.

39. Способ по п. 1, в котором видеоданные являются видеоданными типа "рыбий глаз".

40. Способ по п. 12, в котором видеоданные являются видеоданными типа "рыбий глаз".

41. Устройство по п. 21, в котором видеоданные являются видеоданными типа "рыбий глаз".

42. Устройство по п. 31, в котором видеоданные являются видеоданными типа "рыбий глаз".