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

Авторы патента:

ДЕНУАЛЬ, Франк (FR)

УЭДРАОГО, Наель (FR)

ТАКЕ, Джонатан (FR)

H04N21/845 - Передача изображений, например телевидение (измерения, испытания G01; системы для оригиналов рукописей например, пишущие телеграфные аппараты, которые рассматриваются в подклассе G08; накопление информации, основанное на относительном перемещении носителя записи и преобразователя G11B; кодирование; декодирование или преобразование кодов вообще H03M; радиовещание или регистрация использования радиосети H04H)

Владельцы патента RU 2711591:

КЭНОН КАБУСИКИ КАЙСЯ (JP)

Изобретение относится к технике адаптивной потоковой передачи мультимедийного контента виртуальной реальности по сети Интернет с использованием протокола http. Техническим результатом является оптимизирование передачи мультимедийных данных виртуальной реальности, поскольку передаются только необходимые мультимедийные данные, качество которых соответствует характеристикам запрашивающих клиентов, повышение качества, поскольку изображения высокого разрешения можно обрабатывать, и сохранение масштабируемости на стороне сервера, поскольку управление осуществляется клиентами. Предложена потоковая передача мультимедийных данных, представляющих проекцию захвата широкого вида сцены, причем потоковые мультимедийные данные позволяют рендеризовать широкий вид на 3D геометрической поверхности дисплея или для рендеризации широкого вида на поверхности дисплея согласно разным точкам обзора, причем рендеризация содержит проекцию рендеризации мультимедийных данных. Приняв файл описания, включающий в себя информацию о мультимедийных данных, которая содержит описательную информацию, относящуюся к захвату широкого вида для создания мультимедийных данных, причем сообщения запроса для запрашивания потоки мультимедийных данных на основании файла описания отправляются на сервер. В ответ на сообщения запроса принимаются мультимедийные данные, соответствующие запрошенным потокам мультимедийных данных. 6 н. и 16 з.п. ф-лы, 5 ил.

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

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

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

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

Для улучшения ощущений пользователя и, в частности, для обеспечения ощущения погружения, видеоизображения и даже аудио могут быть всенаправленными (или мультинаправленными или многонаправленными). Применительно к видеоизображениям, также известным как 360° панорамное видео, пользователь ощущает себя находящимся в отображаемой сцене.

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

Такое всенаправленное видео можно рендеризовать посредством наголовных дисплеев или посредством проекции на искривленный экран, окружающий пользователей. Оно также может отображаться на традиционных 2D экранах с навигационным меню в пользовательском интерфейсе для панорамирования во всенаправленное видео. Оно часто именуется виртуальной реальностью (VR), поскольку пользователь ощущает себя в виртуальном мире. При добавлении виртуальных объектов к всенаправленному видео, оно именуется дополненной реальностью (AR).

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

Как показано, эти мультимедиа имеет видеоконтент, полученный от системы 100 камер и передаваемый на наголовный дисплей (HMD) 105 через сервер 110, клиент 115 и сеть 120.

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

Изображения, полученные из системы 100 камер, обрабатываются (этап 130) на сервере 110 для создания потока видео 360°, также именуемого потоком всенаправленного видео или потоком мультимедийных данных виртуальной реальности. Поток мультимедийных данных виртуальной реальности может быть потоком панорамных изображений наподобие потока 190 панорамного изображения на фиг. 1c, т.е. потока изображений 360°, или потоком стандартных потоков видео, например, потоком потоков видео, полученных из каждой камеры камеры 100.

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

Хотя, рассматривая широкий вид сцены, например, вид на 360° в горизонтальном и вертикальном измерении, как показано позицией 180 на фиг. 1b, панорамное изображение широкого вида соответствует проекции (обозначенной как проекция захвата) этого широкого вида, захваченного одним датчиком изображения или набором датчиков изображения, на 2D изображение. Соответственно, схема проекции захвата связана с каждым панорамным изображением, например, для сохранения надлежащих пропорций в записанной сцене. В частности, используемая схема проекции захвата может не отражать реальности и, напротив, может быть художественным представлением широкого вида (например, как с фотографическим эффектом ʺмаленькой планетыʺ, которая основана на стереографической проекции https://en.wikipedia.orf/wiki/Stereographic_projection).

Следует отметить, что вид на 360° может быть реальным видом на 360°, соответствующим виду на 360° в горизонтальной плоскости и виду на 360° в вертикальной плоскости, или псевдовидом на 360°, соответствующим, например, виду на 360° в горизонтальной плоскости и, виду на 210° или менее в вертикальной плоскости. Например, панорама 180° в горизонтальном измерении также может рассматриваться как широкий вид, при условии, что поле зрения больше или равно полю зрения человеческого глаза, для создания ощущения погруженности. Термины "вид на 360°" или "видео 360°" обычно используются, когда записанная сцена соответствует либо последовательности реального мира, либо синтетической последовательности.

В целях иллюстрации, изображения, полученные от камеры 100 объединяются для создания потока мультимедийных данных виртуальной реальности, который содержит набор последовательных панорамных изображений, как показано панорамным представлением 135 (или потоком 190 панорамного изображения на фиг. 1c).

После создания потока мультимедийных данных виртуальной реальности, он кодируется на этапе 140 в битовый поток видео и затем упаковывается (или инкапсулируется) на этапе 141 в файле или в файлах сегментов, подлежащих передаче клиенту 115 по сети 120, например, через интернет, с использованием протокола http (протокола передачи гипертекста). В целях иллюстрации, упаковка может содержать инкапсуляцию битового потока видео в ISOBMFF. Результирующее файл или файлы сегментов может быть файлом mp4 или сегментами mp4. В ходе упаковки, аудиопоток может добавляться в битовый поток видео, а также в дорожки метаданных, обеспечивающие информацию о потоках видео или аудио.

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

После приема, упакованный мультимедийный файл или сегменты мультимедиа виртуальной реальности разлагаются на этапе 142 для извлечения потока данных, который декодируется на этапе 145. В случае приема файла или сегментов ISOBMFF на этапе 142, разложение обычно обрабатывается устройством чтения mp4 или блоком разложения mp4, который, из описательных метаданных, может извлекать битовый поток видео или битовый подпоток видео. Согласно проиллюстрированному примеру, панорамное представление 135' декодированных панорамных изображений соответствует панорамному представлению 135.

Затем декодированный поток мультимедийных данных виртуальной реальности обрабатывается для рендеризации видео (этап 150). Следует отметить, что рендеризация видео зависит от нескольких параметров, в том числе, точки зрения пользователя, точки наблюдения и проекции(й), используемой(ых) для создания панорамных изображений. Как показано представлением 155 рендеризация, рендеризация видео содержит этап повторной проекции декодированных панорамных изображений. Изображения, полученные из такой повторной проекции (обозначенной проекцией рендеризации) отображаются в HMD 105.

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

При этом следует отметить, что существует несколько стандартов потока мультимедийных данных виртуальной реальности (например ISO/IEC 23000-19), и что проекции, используемые для создания панорамных изображений обычно являются следующими (из открытого списка):

- сферы,

- сплющенной сферы,

- куба,

- цилиндра,

- пирамида, и

- ни одного из вышеперечисленных.

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

Следует отметить, что проекция рендеризации зависит от точки обзора, которая соответствует направлению наблюдения широкого вида сцены на поверхности, на которую сцена проецируется, как показано на фиг. 1d. Совместно с точкой(ами) отсчета, точка обзора задает систему отсчета или опорный вид. Его можно задавать значением рысканья, значением тангажа и значением крена (как указано на фиг. 1e), соответствующими параметрами поворота системы отсчета в виде абсолютной системы отсчета (соответствующей, например, точке обзора по умолчанию). Обычно, для систем HMD, угол рысканья соответствует повороту головы слева направо или справа налево, угол тангажа соответствует повороту сверху вниз или снизу вверх, и крен соответствует повороту (наклону) головы вокруг оси направления наблюдения.

В случае сферической проекции или сплющенной сферической проекции, центральная точка 2D панорамной проекции обычно соответствует проекции в главной ориентации точки обзора, заданной как ориентация возвышения (например, по оси z в правосторонней системе координат (x, y, z)) к точке отсчета (например, центру 181 сферы 180 на фиг. 1b). Точка обзора также позволяет определять полюсы сферы.

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

Также следует отметить, что панорамные изображения могут быть выполнена из областей панорамы, как показано позицией 191 на фиг. 1c, где каждая область соответствует конкретной проекции. Каждая область является набором пикселей. Ее форма может быть прямоугольной или нет. Некоторые проекции могут генерировать разрывной картой пикселей. Например, кубическая проекция может делиться на 6 областей проекции, каждая из которых соответствует одной грани куба.

Фиг. 2, содержащая фиг. 2a, 2b и 2c, демонстрирует пример панорамного представления, содержащего несколько областей, на основании кубической проекции, причем каждая область связана с проекцией поверхности.

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

Панорамное представление 200 содержит 6 областей панорамы, обозначенные ① - ⑥. Как указано,

- позиция ① соответствует проекции вида спереди на переднюю грань куба,

- позиция ② соответствует проекции вида сверху на верхнюю грань куба,

- позиция ③ соответствует проекции вида снизу на нижнюю грань куба,

- позиция ④ соответствует проекции вида слева на левую грань куба,

- позиция ⑤ соответствует проекции вида справа на правую грань куба, и

- позиция ⑥ соответствует проекции вида сзади на заднюю грань куба.

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

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

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

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

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

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

Настоящее изобретение предложено для решения одного или более из вышеупомянутых проблем.

В этом контексте, обеспечено решение для адаптивной потоковой передачи мультимедийного контента виртуальной реальности, например, по сети IP, например, интернете, с использованием протокола http.

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

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

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

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

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

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

Согласно варианту осуществления, описательная информация обеспечивается, по меньшей мере, частично в, по меньшей мере, одном описателе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно варианту осуществления, файл описания является описанием представления мультимедиа динамической адаптивной потоковой передачи по протоколу http.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг. 1, содержащая фиг. 1a, 1b, 1c, 1d и 1e, демонстрирует пример потока данных для захвата, передачи и рендеризации всенаправленного видео от сервера клиенту, а также примеры широкого вида, точки обзора, потока панорамного изображения и панорамного изображения, имеющего области панорамы.

Фиг. 2, содержащая фиг. 2a, 2b, и 2c, демонстрирует пример панорамного представления, содержащего несколько областей, на основании кубической проекции, причем каждая область связана с проекцией поверхности и панорамным представлением, причем одна область дополнительно разделена на подобласти или участки;

фиг. 3 демонстрирует блок-схему, иллюстрирующую пример общего принципа адаптивной потоковой передачи мультимедиа по HTTP;

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

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

Согласно конкретным вариантам осуществления, манифест потоковой передачи или список воспроизведения потоковой передачи, например, описание представления мультимедиа (MPD) динамической адаптивной потоковой передачи по протоколу HTTP (DASH) используется для сигнализации (т.е. обеспечения) характеристик мультимедийных данных, представляющих широкий вид сцены, например, мультимедийные данные виртуальной реальности, например, панорамные изображения или наборы сшиваемых изображений. Эти характеристики, которые могут содержать, например, тип проекции, используемой для создания панорамных изображений, возможность осуществления доступа к частям панорамных изображений, и качество и указание направления наблюдения, которые помогают сначала сообщать клиентам потоковой передачи, что мультимедиа не являются классическими мультимедиа или видео, но обеспечивают некоторые возможности навигации, и затем выбирать данные, подлежащие извлечению, могут сигнализироваться во вновь добавленных структурных элементах или описателях в случае DASH. Первый точка позволяет клиенту устанавливать и/или выбирать надлежащий пользовательский интерфейс для взаимодействия с контентом.

Эти новые описатели можно вставлять в манифест потоковой передачи или список воспроизведения потоковой передачи при подготовке контента для потоковой передачи на стороне сервера. В случае DASH, новые описатели вставляются в файл MPD сервером DASH или модулем упаковки DASH для указания (или сигнализации) клиенту DASH, что обеспечено представление мультимедийных данных виртуальной реальности широкого вида сцены, и, например, для характеризации панорамных изображений, содержащихся в мультимедийных данных виртуальной реальности. Соответственно, эти новые описатели могут содержать тип панорамной проекции, а также характеристики и параметры, используемые с этим типом панорамной проекции для получения панорамных изображений. Обычно они содержат точку обзора и параметры для определения положения областей панорамы, при наличии, внутри панорамного изображения. Эти новые описатели, именуемые в дальнейшем описателями VR, могут быть структурированными элементами наподобие элементов XML и/или атрибутами или могут быть описаны посредством JSON (обозначения объектов JavaScript) или даже в простом текстовом формате при условии, что ключевые слова или комментарии предназначены для переноса этих описателей.

Напомним, что DASH позволяет создавать связь между компактным описанием контента(ов) представления мультимедиа и адресами HTTP (обычно URL). Такая связь описана в файле, именуемом файлом манифеста или файлом описания. В контексте DASH, этот файл манифеста представляет собой файл, также именуемый файлом MPD (для описания представления мультимедиа).

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

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

Фиг. 3 демонстрирует блок-схему, иллюстрирующую пример общего принципа потоковой передачи мультимедиа по HTTP. В предпочтительном варианте осуществления, протокол DASH рассматривается как протокол потоковой передачи по HTTP.

Кроме того, фиг. 4 демонстрирует, совместно с фиг. 3, общую организацию файла MPD.

Как показано, сервер 300 мультимедиа содержит разные представления мультимедиа. Проиллюстрирован упрощенный пример представления 301 мультимедиа. В данном случае оно содержит мультимедийные данные виртуальной реальности, например, временную последовательность панорамных изображений. Это представление мультимедиа разделено, во времени и в пространстве, на малые независимый сегменты 302, 302a и 303 (или позиция 403 на фиг. 4). Эти сегменты допускают независимую адресацию и загрузку. Адреса загрузки мультимедийного контента являются адресами HTTP (или URL). Существует один адрес HTTP, связанный с каждым сегментом мультимедийного контента виртуальной реальности. Они устанавливаются сервером 300 мультимедиа для каждого из этих сегментов.

Файл 304 манифеста (или файл описания) отражает организацию представления мультимедиа, имеющуюся на сервере мультимедиа в отношении адресов HTTP, версии контента в отношении разрешения, кодека, битовой скорости, типа мультимедиа и т.д. Это может быть документ XML или даже простой текстовый файл наподобие потоковой передачи HTTP в реальном времени. Например, DASH MPD и манифест потоковой передачи для плавной потоковой передачи используют XML. Он описывает контент сегментов мультимедиа, например, тип мультимедиа (аудио, видео, аудио-видео, текст, метаданные и т.д.), как показано, например, с помощью адаптационных наборов 401 на фиг. 4, формат кодирования, продолжительность времени сегмента. Кроме того, он связывает URL с каждым описанным сегментом мультимедийного контента.

Файл 304 манифеста отправляется клиенту 310. Считывая принятый файл 305 манифеста, клиент может узнавать связь между сегментами разных мультимедийных контентов и адресами HTTP, указывающими сегменты. Он также может определять альтернативные версии видео (например, представления 402 на фиг. 4), например, или связывать метаданные с мультимедийным потоком. Кроме того, файл 305 манифеста сообщает информацию о контенте (в этом примере мультимедийных данных виртуальной реальности) представления мультимедиа. Например, информация может включать в себя разрешение и/или битовую скорость. Вся информация, обеспеченная в манифесте потоковой передачи, или список воспроизведения потоковой передачи, обрабатываются модулем 311 адаптационной логики, который может определять, какие сегменты следует запрашивать у сервера потоковой передачи.

Таким образом, клиент 310 может выдавать запросы 306 HTTP для загрузки нужных ему сегментов, причем эти сегменты описаны в принятом файле 305 манифеста.

В ответ, сервер 300 отправляет запрошенные сегменты в ответе 307 HTTP. Эти сегменты могут декодироваться клиентом 310 и отображаться (этапы 308 и 309).

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

- генерации мультимедийного контента,

- инкапсуляции мультимедийного потока в формате файла,

- генерации манифеста потоковой передачи или списка воспроизведения файл,

- передачи представления мультимедиа, и

- передачи мультимедийного контента, чаще всего в виде сегментов контента.

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

В таблицах 1a и 1b приложения приведены два разных примера использования новых описателей VR в описании представления мультимедиа (MPD) для сигнализации одной и той же проекции, связанной с панорамными изображениями мультимедийных данных виртуальной реальности. Та же информация может размещаться в других типах манифеста потоковой передачи, требующих только адаптации к синтаксису или языку, используемому для этого манифеста (XML, JSON, простого текста и т.д.).

Как показано в таблице 1a, сигнализация представления мультимедийных данных виртуальной реальности в MPD может осуществляться, например, с использованием либо универсального описателя DASH SupplementalProperty, либо универсального описателя DASH EssentialProperty с атрибутом @schemeIdURI, который устанавливается, например, на новое значение ʺurn:mpeg:dash:VR:2016ʺ. Это значение обеспечено здесь лишь в порядке примера. Задача состоит в том, чтобы иметь зарезервированное уникальное значение (обычно URN в DASH MPD) в @schemeIdUri, чтобы однозначно идентифицировать описатель как описатель для виртуальной реальности или всенаправленного мультимедиа, обеспечивающих информацию о панораме. Альтернативные варианты осуществления состоят в задании, вместо использования универсальных описателей DASH, явный описатель в качестве зарезервированного элемента для переноса VR и/или всенаправленной информации, например, элемента <ProjectionInfo>, наследующего в схеме MPD за DescriptorType, который можно поместить непосредственно на уровне MPD, если манифест обеспечивает только контент VR или в некоторых адаптационных наборах, уровне представлений или подпредставлений, если манифест обеспечивает контент как VR, так и не-VR, этот явный описатель является потомком адаптационных наборов, представлением, или подпредставлением, описывающим контент VR. Пример, приведенный в таблице 1a, является примером расширения универсального описателя DASH < SupplementalProperty >, причем, с одной стороны, новое значение schemeIdUri для его указания является описателем VR и, с другой стороны, новый элемент именуемый ʺpanoramaʺ для переноса идентификатора проекции, информация типа проекции (на цилиндре в примере) и информация вертикального поля зрения, выраженная как два значения угла между точкой отсчета и, соответственно, верхней поверхностью цилиндра (+60° в примере) и нижней поверхностью цилиндра (-60° в примере), таким образом, обеспечивая поле зрения 120° в вертикальном измерении. Таблица 7a является альтернативой таблицы 1a, предпочитающей новые атрибуты для ID проекции, типа проекции и информации поле зрения. Таблица 7b является другой альтернативой, где атрибут @value используется вместо создания новых атрибутов. Следует отметить, что эти варианты будут применяться таким же образом, если используется описатель EssentialProperty или явный описатель. Наконец, таблица 7c является тем же примером, как в таблице 7b, за исключением того, что поле зрения значение выражается как два значения угла 180° и 120°, соответственно обеспечивающие горизонтальное поле зрения и вертикальное поле зрения (угол, наблюдаемый из точки отсчета).

Согласно некоторым вариантам осуществления, где несколько альтернативных панорам описаны в MPD, существующий атрибут @value описателей SupplementalProperty и/или EssentialProperty может использоваться для обозначения одной из нескольких альтернативных панорам, адресованных текущим представлением или адаптационным набором (или, возможно, подпредставлением).

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

Для обеспечения обратной совместимости для клиентов, которые не могут интерпретировать описатели VR, использование описателя SupplementalProperty для сигнализации описателей VR может быть более адаптировано, чем использование описателя EssentialProperty. Действительно, когда панорама, область панорамы или подобласть панорамы объявлена в манифесте, например, область панорамы, соответствующая одной грани проекции на куб, автор контента может позволять клиентам потоковой передачи без VR выбирать, загружать и воспроизводить эту панораму, область панорамы или подобласть панорамы в качестве классического 2D видео. Напротив, когда проекция захвата не позволяет клиенту без VR воспроизводить любую из панорамы, области панорамы, или области панорамы, описатели VR помещаются в описатель EssentialProperty таким образом, что описатели плюс связанный контент (родительский адаптационный набор, представление или подпредставление) игнорируется и может безопасно удаляться из MPD.

Описатель SupplementalProperty или описатель EssentialProperty сигнализирующий представление мультимедийных данных виртуальной реальности может именоваться VR SupplementalProperty или VR EssentialProperty.

Согласно конкретным вариантам осуществления, сигнализация типа проекции, используемой в панорамном изображении может осуществляться с новым элементом/атрибутом. Например, он может сигнализироваться с элементом/атрибутом ʺprojection_type='cube'ʺ или ʺprojection_type='cubical'ʺ для сигнализации использования кубической проекции или, как показано в таблице 1a приложения, с ʺtype='cylindrical'ʺ или type=ʺcylinderʺ для сигнализации использования цилиндрической проекции, проекции на цилиндр. Он также может сигнализироваться с использованием существующего атрибута @value, например, ʺvalue='pyramid'ʺ или ʺvalue='pyramidal'ʺ для сигнализации использования пирамидальной проекции или возможно, как показано в описании представления мультимедиа таблицы 1b, с использованием нового особого значения атрибута @chemeIdURI, например, одного зарезервированного или конкретного URN для каждого типа проекции, например, ʺurn:mpeg:dash:VR:cylinder:2016ʺ (для сигнализации использования цилиндрической проекции), который также используется для сигнализации представления мультимедийных данных VR (а не универсального ʺurn:mpeg:dash:VR:2016ʺ, который не указывает фактический тип проекции в ходе эксплуатации). Наличие такого конкретного URN в описателе VR может помогать клиенту потоковой передачи в время разложения MPD для более быстрого определения, способны ли они воспроизводить панораму, область панорамы или даже подобласть панорамы.

Согласно конкретным вариантам осуществления, существующий атрибут @value универсальных описателей DASH может использоваться для выражения параметров, которые специфичны для сигнализируемого типа проекции в качестве списка значений с разделителем в виде запятой (например, ʺvalue=ʺ60, -60ʺʺ в таблице 1a), или в качестве новых атрибутов, специфичных для особого schemeIdUri для описателя VR (например, ʺtop_pitch=ʺ60ʺ bottom_pitch=ʺ-60ʺ) в таблице 1b). В этом примере, конкретные атрибуты являются значениями угла тангажа (выраженными в градусах), соответствующими проекции верхней поверхности и проекции нижней поверхности цилиндрической проекции. Дополнительные атрибуты также могут обеспечиваться для обеспечения параметров, например, при углах min_yaw (максимальный угол влево) и max_yaw (максимальный угол вправо), а также при минимальном и максимальном значениях угла крена, например в градусах. Заметим, что возможно использование других единиц для углов, но что требуется дополнительный атрибут для обеспечения единицы угла, (например, angle_unit=ʺradianʺ). Этот тип параметров также может быть полезен для других видов проекции, например, squished_sphere.

Ориентация точки обзора для проекции (т.е. опорной точки обзора) может задаваться значением рысканья, значением тангажа и, в необязательном порядке, значением крена, которое может выражаться, например, в градусах поворота. В целях иллюстрации, эти значения могут сигнализироваться с использованием нового(ых) элемент(ов)/атрибут(ов), например, ʺref_vp='180,0'ʺ для соответствующего задания фактических значений рысканья и тангажа в одиночном атрибуте или в отдельных атрибутах, например, ʺvp_yaw='180'ʺ для сигнализации только значения рысканья. Если один или несколько атрибутов исключены, пропущенное(ые) значение(я) можно заменять соответствующим(и) значением(ями) по умолчанию точки обзора (например ʺ0,0,0ʺ).

Сигнализация типа проекции позволяет клиенту DASH выбирать Representation, AdaptationSet или SubRepresentation как функцию типов проекции, которыми он может обрабатывать. Сигнализация абсолютной ориентации позволяет клиенту DASH выбирать Representation, AdaptationSet или SubRepresentation согласно точке обзора, запрошенной пользователем. Например, когда пользователь перемещает голову или осуществляет навигацию в панораме посредством особого пользовательского интерфейса, адаптационная логика клиента (позиция 311 на фиг. 3) может идентифицировать наиболее подходящую версию контента из MPD (позиция 305 на фиг. 3).

Согласно конкретным вариантам осуществления, описатель панорамы может использовать идентификатор проекции с использованием, например, атрибута @projection_id, как показано в таблице 1b. Это позволяет связывать все параметры (например, точку обзора и конкретные параметры) проекции с этим идентификатором и сообщать клиенту об альтернативных версиях областей панорамы или подобластей панорамы с использованием одной и той же проекции. Соответственно, это позволяет избегать повторения типа проекции захвата, в манифесте обеспечивается только ссылка на проекцию и соответствующее панорамное представление.

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

В необязательном порядке, описатель панорамы также может быть связан с идентификатором панорамы с использованием атрибута @panorama_id для различения разных версий панорам, если в MPD описано несколько панорам. В частности, два представления, которые совместно используют одно и то же значение идентификатора панорамы указывает, что эти представления альтернативны друг другу. Опять же в необязательном порядке, описатель панорамы также может быть связан с индексом панорамного изображения с использованием @panorama_image_id, если несколько панорамных изображений используется внутри одной и той же панорамы. Последнее применяется, в частности, когда среда погружения обеспечивается вдоль данного пути навигации в широком виде. Несколько панорамных изображений генерируется в нескольких местах на пути.

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

Согласно вариантам осуществления, описание областей панорамы осуществляется с использованием элемента PanoramaRegion, содержащегося в элементе Panorama либо VR SupplementalProperty, либо VR EssentialProperty. Альтернативный вариант осуществления состоит в объявлении этого описателя для PanoramaRegion в качестве конкретного описателя, т.е. в качестве конкретного элемента MPD, предназначенного для переноса описательной информации об области панорамы, например, <PanoramaRegion>, наследующего в схеме MPD за DescriptorType и объявленного на уровнях адаптационного набора, представления или подпредставления.

Согласно вариантам осуществления, все области панорамы описаны в AdaptationSet, Representation или SubRepresentation, содержащих описание соответствующего панорамного изображения. Альтернативно, области панорамы описаны в пустых AdaptationSet, Representation или SubRepresentation, описывающих панорамное изображение, но не содержащих никаких сегментов мультимедиа этого панорамного изображения. Целью таких AdaptationSet, Representation или SubRepresentation является объявление полного списка имеющихся областей таким образом, что другие AdaptationSet, Representation или SubRepresentation фактически содержащие сегменты мультимедиа могут ссылаться на него для получения информации о имеющихся областей панорамы.

Опять же, согласно вариантам осуществления, в отсутствие AdaptationSet, Representation или SubRepresentation, описывающих полное панорамное изображение в MPD, области панорамы все же можно описывать в каждом AdaptationSet, Representation или SubRepresentation видеоизображений, содержащих одну (или более) областей панорамы, как показано в таблице 4a приложения.

Опять же, согласно вариантам осуществления, описатели VR и области панорамы описатели описаны в AdaptationSet, Representation или SubRepresentation, описывающих дорожку метаданных, например метаданные с использованием формата всенаправленного мультимедиа-приложения (OMAF). Это требует, чтобы этап 141 упаковки контента на фиг. 1a отражал связь, объявленную между дорожкой OMAF и одной или более дорожек видео в манифесте MPD. Как показано в таблице 8 приложения, это может осуществляться путем объявления атрибутов associationId и associationType в представлениях, описывающих дорожку OMAF в MPD, соответственно, указывающую представление одной или более дорожек видео в MPD. Атрибут associationType может принимать значение 'cdsc' для указания, что представление метаданных дорожки OMAF в MPD обеспечивает дополнительный контент описания для одного или более представлений видео, объявленных в MPD.

В ходе этапа 141 упаковки мультимедиа, сервер предпочтительно проверяет информацию формата файла для мультимедийный файла для определения, присутствует ли некоторая информация постдекодерного требования, например, путем проверки, относятся ли выборочные записи дорожки видео для упаковки для потоковой передачи к типу 'resv'. Если да, модуль упаковки мультимедиа разлагет блок информации схемы, который может обеспечивать информацию в типах проекции захвата, используемых для построения панорамы. Если такая информация присутствует (при наличии одной дорожки OMAF), модуль упаковки мультимедиа использует эту информацию для установления значения описателя VR в AdaptationSet, Representation или SubRepresentation, описывающем панораму. Опять же, извлечение этой информации и ее раскрытие в манифесте потоковой передачи позволяют клиентам потоковой передачи, посредством их адаптационной логики, быстро идентифицировать, является ли AdaptationSet, Representation или SubRepresentation видео кандидатом для загрузки и воспроизведения. В случае дорожки OMAF метаданных, она является менее прямым, поскольку клиент должен следовать associationId представления OMAF для нахождения Representation, обеспечивающего описание панорамных изображений.

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

В случае стереоскопических представлений, схема множественных видов DASH может использоваться непосредственно для сигнализации роли каждого вида, где описатель Role применяемый к элементу ContentComponent типа видео или к элементу AdaptationSet, если каждый вид содержится в отдельном панорамном изображении (т.е. в отдельном AdaptationSet). Ее также может быть расширить, позволяя применять описатель Role к PanoramaRegion для поддержки случая, когда представления левого глаза и правого глаза находятся в двух частях одного и того же изображения/видеоконтента. Альтернативно, PanoramaRegion может содержать новый(е) необязательный(е) атрибут(ы) для задания стереоинформации (например, "stereo='left'ʺ, ʺstereo='none'ʺ [по умолчанию])

Таблицы 2a, 2b, 2c и 2d приложения иллюстрируют четыре описателя AdaptationSet с использованием описателей VR.

Согласно примеру, приведенному в таблице 2a, пространственное положение области в видео, описанном на уровне адаптационного набора сигнализируется, в описателе области панорамы, с использованием четырех параметров, выраженных в пикселях в образце видео панорамного изображения. Эти параметры содержат координаты (x, y) верхнего левого угла области (в панораме видео) и ширину и высоту области (или, альтернативно, координаты x, y нижнего правого угла области). Эти параметры можно описать в новом атрибуте @position элемента PanoramaRegion с использованием списка с разделителем в виде запятой целочисленных значений, как показано в таблице 2a (например, ʺposition='0,200,200,200'ʺ). Согласно вариантам осуществления, если пространственное положение области не обеспечено, это означает, что видео адаптационного набора, в котором объявлена область, полностью покрыто областью.

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

Каждый описатель области панорамы связан с типом области, который зависит от типа проекции опорного панорамного изображения. Он задается конкретными значениями идентификаторов области (например, ʺпереднийʺ, ʺверхнийʺ, ʺправыйʺ, и т.д.), как показано в таблице 2a, или заранее заданным индексом области с использованием численных значений, например, списка значений, предложенного в OMAF.

Согласно вариантам осуществления, описатель PanoramaRegion может быть объявлен как элемент описателя панорамы (как показано в таблице 2a). Альтернативно, PanoramaRegion может быть объявлен непосредственно либо в VR SupplementalProperty, либо в VR EssentialProperty, либо в любом явном описателе. В таком случае, опорное панорамное изображение идентифицируется атрибутом, принадлежащим PanoramaRegion.

Как показано в таблице 2b, описатель области панорамы может быть связан с опорной панорамной проекцией с использованием его идентификатора (например ʺprojection_id='1'ʺ) или, альтернативно, с использованием идентификатора панорамы (если существуют более одной панорамы в MPD) и идентификатора панорамного изображения (если существуют более одного изображения для этой панорамы) (например ʺpanorama_id='1', panorama_image_id='0'ʺ). Альтернативно, если описатель PanoramaRegion объявлен дочерним элементом панорамы, идентификатор проекции не требуется. Тогда область панорамы ссылается на ее панораму внедрения, например, как показано в таблице 2a.

Согласно вариантам осуществления, если используется описатель PanoramaRegion, но представление AdaptationSet панорамы отсутствует, тип панорамной проекции может непосредственно идентифицироваться атрибутом, принадлежащим PanoramaRegion, как показано в таблице 2c. Это не требуется, если используется схема, выделенная проекции, как показано в таблице 2d.

Аналогично, если описатели PanoramaRegion используются в различных AdaptationSet, Representation или SubRepresentations, но отсутствует AdaptationSet, Representation или SubRepresentation, описывающий панораму, projection_id все еще используется для указания, что области панорамы относятся тому же панорамному изображению, как показано, например, в таблицах 2c и 2d. Это позволяет связывать эти области панорамы как относящиеся к одной и той же панораме (даже если ее нет). Вся описательная информация, порождаемая новыми описателями, показанными в таблицах 2a, 2b и 2c, также может переноситься в новых атрибутах выбранного описателя (либо универсального описателя DASH, либо явного описателя), или в существующем атрибуте ʺvalueʺ как список сцепленных значений. Например, таблица 9a обеспечивает такую же информацию, как в таблице 2a, но с новым атрибутом ʺregion_listʺ для областей панорамы. Альтернатива будет использовать описатели DASH в количестве, равном количеству областей, помещая описательную информацию областей в атрибут ʺvalueʺ, таким образом, что описатели не могут считаться эквивалентными, таким образом, принуждая проигрыватель обрабатывать их все (а не только один в наборе). Таблица 9b обеспечивает такой пример.

Стандарт DASH позволяет выражать пространственные соотношения компонентов мультимедийного контента в MPD на уровне адаптационного набора или подпредставления. Он предусматривает использование описатели SupplementalProperty или EssentialProperty, где @schemeIdURI равен ʺurn:mpeg:dash:srd:2014ʺ. Атрибут @value состоит из списка значений с разделителем в виде запятой для параметров SRD (описания пространственного соотношения), содержащих нижеследующие параметры:

- source_id обеспечивает идентификатор источника мультимедийного контента. Параметры (object_x, object_y, object_width, object_height), используемые в разных SRD, совместно использующих одно и то же значение, именуемое ʺsource_id valueʺ в течение периода, можно сравнивать для определения, что два представления в пространстве связаны друг с другом;

- object_x: обеспечивает горизонтальную позицию, в базовом пространстве, заданном этим описателем SRD, верхнего левого угла видео, описанного в нескольких AdaptationSet или SubRepresentation с использованием этого описателя;

- object_y: обеспечивает вертикальную позицию, в базовом пространстве, заданном этим описателем SRD, верхнего левого угла видео, описанного в нескольких AdaptationSet или SubRepresentation с использованием этого описателя;

- object_width: обеспечивает ширину, в базовом пространстве, заданном этим описателем SRD, видео, описанного в нескольких AdaptationSet или SubRepresentation с использованием этого описателя;

- object_height: обеспечивает высоту, в базовом пространстве, заданном этим описателем SRD, видео, описанного в нескольких AdaptationSet или SubRepresentation с использованием этого описателя;

-total_width: обеспечивает максимальную протяженность вдоль оси x видео, описанного в нескольких AdaptationSet или SubRepresentation, имеющих SRD с одним и тем же значением source_id. В его отсутствие, это значение устанавливается равным значению total_width аннотации SRD, имеющей одно и то же значение source_id. Для данного значения source_id, следует указать, по меньшей мере, одно значение total_width;

- total_height: обеспечивает максимальную протяженность вдоль оси y видео, описанного в нескольких AdaptationSet или SubRepresentation, имеющих SRD с одним и тем же значением source_id. В его отсутствие, это значение устанавливается равным значению total_height аннотации SRD, имеющей одно и то же значение source_id. Для данного значения source_id, следует указать, по меньшей мере, одно значение total_height;

- spatial_set_id: обеспечивает идентификатор для группы AdaptationSet или SubRepresentation, имеющих одно и то же значение source_id. Параметр spatial_set_id можно использовать для указания, что группа AdaptationSet или SubRepresentation образуют группу неперекрывающихся или смежных видеоизображений без зазоров или являются частью одного и того же слоя масштабируемости;

параметры object_x и object_y (соответственно object_width и object_height) выражают 2D позиции (соответственно 2D размеры) связанных AdaptationSet или SubRepresentation в системе координат, связанной с источником, идентифицированным параметром source_id. Эта система координат может использовать произвольное начало отсчета. Согласно конкретным вариантам осуществления, ось x ориентирована слева направо, и y ось - сверху вниз. Все SRD, совместно использующие одно и то же значение source_id имеют одинаковые начало отсчета и ориентации осей.

Значения total_width и total_height задают базовое пространство в этой системе координат. Значения параметров object_x, object_y, object_width и object_height связаны со значениями параметров total_width и total_height. Позиции (object_x, object_y) и размеры (object_width, object_height) SRD, совместно использующего одно и то же значение source_id, можно сравнивать с учетом размера базового пространства, т.е. после деления значений object_x и object_width на значение total_width и деления значений object_y и object_height на значение total_height их соответствующих описателей.

В таблице 3 приложения приведен пример описателя SRD, где видео состоит из 4 плиток (AS1 - AS4) в базовом пространстве с произвольными единицами. В целях иллюстрации показано только описание MPD для плиток AS1 и AS2.

Первый адаптационный набор соответствует плитке AS1. Он состоит из одного представления видео с разрешением 1920×1080 пикселей. Описатель SRD (использующий описатель SupplementalProperty) указывает, что это видео является плиткой, где source_id равен 1, и что она располагается в верхнем левом углу базового пространства (координаты object_x=0 и object_y=0). Размер видео представляет половину базового пространства в каждом направлении (object_width и object_height покрывают 100 на 200 произвольных единиц для total_width и total_height базового пространства). Из описателя SRD можно вывести, что все базовое пространство действительно представляет видео 4k2k (3840×2160 пикселей).

Из описателя SRD можно вывести, что второй адаптационный набор соответствует плитке AS2. Этот описатель SRD вводится с использованием, здесь, описателя EssentialProperty, указывающего, что плитка относится к тому же базовому пространству, что и первый адаптационный набор (тот же source_id=1), и что она располагается посередине на оси x (значение 100 на 200) и на основании оси y (значение 0).

Различие между SupplementalProperty и EssentialProperty описатели состоит в том, как родительский элемент (AdaptationSet, Representation или SubRepresentation) обрабатывается клиентом, который не понимает значения атрибута schemeIdURI, в случае SRD: ʺurn:mpeg:dash:srd:2014ʺ. Действительно, в случае описателя EssentialProperty, если клиент не понимает schemeIdUri, он должен игнорировать его, а также родительский элемент, который содержит описатель. В случае SupplementalProperty, предполагается, что клиент будет игнорировать только сам описатель, но все же сможет использовать родительский элемент.

Соответственно, когда в MPD используются описатели SRD, рекомендуется опираться на, по меньшей мере, один описатель SupplementalProperty для обратной совместимости с клиентами, которые не понимают описание пространственного соотношения.

Таблица 4 в приложении демонстрирует, как описатель панорамы и описатель области панорамы можно объединять с описанием пространственного соотношения (SRD) в MPD. Как показано, панорамное изображение (например, <SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,0,0,2120,1080,2120,1080"/>) или, альтернативно, область панорамы (например, <SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="2,0,0,1920,1080,1920,1080"/>) можно делить в областях, представляющих интерес (ROI). Соответственно, описатель SRD используется для указания ROI в панорамном изображении (например, <SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,200,0,1920,1080,2120,1080"/>) или, альтернативно, в области панорамы (например, <EssentialProperty schemeIdUri="urn:mpeg:dash:srd:2014" value=ʺ2,0,0,960,540,1920,1080"/>). Следует отметить, что описатель VR не влияет на описатель SRD или не изменяет его. Оба описателя ортогональны и хорошо объединяются для обеспечения пространственного доступа в области панорамы или подобласти панорамы. Таблица 11 является альтернативным описанием областей панорамы по сравнению с кубической проекцией с нормализованными координатами. ID проекции является неявно source_id SRD. Информация типа проекции обеспечивается посредством описателя VR.

Таблица 5a и 5b в приложении обеспечивают альтернативные примеры использования описателя VR с SRD.

Как показано в таблице 5a, вложенное использование SRD представлено аналогично представленному в таблице 4. Однако оно не содержит никакого объявления областей внутри панорамы. В этом примере, projection_id не используется, source_id описателя SRD можно использовать вместо связывания областей панорамы с панорамой. В таком варианте осуществления, панорама идентифицируется посредством значений параметров SRD, когда object_width=total_width и object_height=total_height, как для классического SRD. В этом варианте осуществления, описатель VR и классический описатель SRD объединяются для обеспечения пространственного доступа к областям панорамы (или участкам или пространственным частям) и также для связывания панорамы с ее областями панорамы.

В альтернативных вариантах осуществления, проиллюстрированных в таблице 5b, схема SRD расширяется с использованием нового значения @shemeIdUri, равного, например, ʺurn:mpeg:dash:srd:2016ʺ, для поддержки контента VR. В этом варианте осуществления, эту новую схему можно использовать таким образом, что описатель SRD манипулирует как описанием пространственного соотношения, так и описанием VR или всенаправленным мультимедиа. Атрибут @value сохраняет те же форматирование/параметры, что и в схеме SRD 2014, и используется для извлечения областей, представляющих интерес, панорамы (которые могут соответствовать или не соответствовать областям панорамы или подобластям панорамы). Тот же атрибут типа проекции, который описан для панорамы, добавляется в эту новую схему SRD, например, в качестве нового атрибута. Когда этот атрибут присутствует в MPD, это говорит о том, что SRD относится к панорамному изображению, в противном случае SRD относится к классическому 2D видео. Согласно вариантам осуществления, атрибут @projection_id не добавляется: идентификатор SRD (первый параметр @value) используется вместо того, чтобы идентифицировать панораму. Область также сигнализируется с использованием схемы SRD 2016, но с использованием, например, нового атрибута @region_id, для указания соответствующей области проекции.

Таблица 6 в приложении демонстрирует, как использовать вложенный идентификатор SRD (например, 0.1 и 0.2) для расширения новой схемы SRD для создания возможности прямого объявления областей внутри панорамы, и как его можно использовать с абсолютными координатами в панораме (например < SupplementalProperty schemeIdUri= "urn:mpeg:dash:srd:2016" value="0.1,320,0,320,270,1920,1080"/>) для описания, например, подобласти или с координатами относительно области панорамы (например < SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0.2,0,0,320,270,640,540"/>).

Другое возможное расширение описателя SRD для виртуальной реальности служит для описания непосредственно в SRD ID проекции и/или типа проекции и/или позиции, где для находить область панорамы, как показано в примере таблицы 10a. В зависимости от типа проекции, позицию следует рассматривать как пиксели или нормализованные пиксели (проекция на куб или пирамиду или без использования) или как углы yaw_start, yaw_end, pitch_start, pitch_end для squished_sphere, цилиндр, как показано в примере таблицы 10b. В необязательном порядке, в зависимости от типа проекции, идентификационная информация областям может обеспечиваться как последнее значение: ʺallʺ для панорамы, ʺfrontʺ или ʺtopʺ или ʺbottomʺ для грани куба.

Другая альтернатива для описания PanoramaRegion в отношении доступа в зависимости от вида пользователя или от навигации пользователя относится к использованию, вместо пространственных координат (например, атрибута ʺpositionʺ таблицы 4 приложения) с или без SRD, значения диапазона, выраженных как значения углов рысканья, тангажа и, в необязательном порядке, крена, как показано в таблице 10c приложения и описывающие точку обзора, как на фиг. 1d (относительно точки отсчета в широком виде, имеющем углы yaw=0, pitch=0 и roll=0). Текущую точку обзора можно задавать, по меньшей мере 2 углами: углами рысканья и тангажа и, в необязательном порядке, углом крена, задающими позицию центральной точки серой области на фиг. 1d, атрибутами ширины и высоты представления, задающими ширину и высоту серой области на фиг. 1d. Это позволяет клиенту избегать, отображения углов, обусловленных движением головы, в пространственные координаты для использования для извлечения надлежащей области панорамы. Вместо этого, клиент может вычислять накопленные углы от опорной точки обзора, где он начал отображать мультимедиа, и непосредственно согласовывать значения углов обеспеченных этим описателем, с использованием значений угла рысканья, тангажа и, в необязательном порядке, крена. Эти описатели могут устанавливаться блоком 141 упаковки мультимедиа путем разложения значений дорожки OMAF при подготовке мультимедиа для потоковой передачи.

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

- центральному процессору (CPU) 501, например, микропроцессору;

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

- постоянной памяти (ROM) 503 для хранения компьютерных программ для реализации вариантов осуществления изобретения;

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

- пользовательскому интерфейсу (UI) 505 для приема вводов от пользователя или для отображения информации пользователю;

- жесткому диску (HD) 506;

- модулю 507 I/O для приема/отправки данных от/на внешние устройства, например, источник видеосигнала или дисплей.

Исполнимый код может храниться либо в постоянной памяти 503, либо на жестком диске 506, либо на сменном цифровом носителе, например, диске. Согласно варианту, исполнимый код программ может приниматься по сети связи, через сетевой интерфейс 504, для сохранения в одном из средства хранения устройства 500 связи, например, жестком диске 506, до выполнения.

Центральный процессор 501 выполнен с возможностью управления и предписания выполнения инструкций или участков программного кода программы или программ согласно вариантам осуществления изобретения, причем инструкции хранятся в одном из вышеупомянутых средств хранения. После включения питания, CPU 501 способен выполнять инструкции из главной RAM-памяти 502, связанной с программным приложением, после загрузки этих инструкций, например, из ROM 503 программ или жесткого диска (HD) 506. Такое программное приложение, при выполнении на CPU 501, обуславливает осуществление этапов блок-схем операций, показанных на предыдущих фигурах.

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

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

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

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

ПРИЛОЖЕНИЕ

<?xml version="1.0" encoding="UTF-8"?>
<MPD […]>
	<Period […]>
		<AdaptationSet […]>
			<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
				<Panorama projection_id="0" type="cylindrical" value="60,-60">
					[…]
				</Panorama>
			</ SupplementalProperty >
		[…]
		</AdaptationSet>
		[…]
	</Period>
</MPD>

Таблица 1a

<?xml version="1.0" encoding="UTF-8"?>
<MPD […]>
	<Period […]>
		<AdaptationSet […]>
			<SupplementalProperty schemeIdUri="urn:mpeg:dash:cylinder:VR:2016">
				<Panorama projection_id="0" top_pitch="60" bottom_pitch="-60">
					[…]
				</Panorama>
			</ SupplementalProperty >
		[…]
		</AdaptationSet>
		[…]
	</Period>
</MPD>

Таблица 1b

<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<Panorama projection_id="0" type="cylindrical" […]>
			<PanoramaRegion region_id="top" position="0,0,200,200"/>
			<PanoramaRegion region_id="bottom" position="0,200,200,200"/>
		</Panorama>
	</ SupplementalProperty >
	[…]
</AdaptationSet>

Таблица 2a

<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<Panorama projection_id="0" type="cylindrical" […]/>
			<PanoramaRegion region_id="top" projection_id="0"/>
		</Panorama>
	</ SupplementalProperty >
	[…]
</AdaptationSet>

Таблица 2b

<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<PanoramaRegion region_id="top" projection_id="0" type="cylindrical"/>
		</Panorama>
	</ SupplementalProperty >
	[…]
</AdaptationSet>

Таблица 2c

<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<PanoramaRegion region_id="top" projection_id="0"/>
		</Panorama>
	</ SupplementalProperty >
	[…]
</AdaptationSet>

Таблица 2d

<?xml version="1.0" encoding="UTF-8"?>
	<MPD …]>
		<Period … >	<!-- 4 плитки -->
			<!-- плитка AS1 -->
			<AdaptationSet […]>
				<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1, 0, 0, 100, 100, 200, 200"/>
				<Representation id="1" bandwidth="5000000" width="1920" height="1080">
					<BaseURL>tile1.mp4</BaseURL>
				</Representation>
			</AdaptationSet>
			<!-- плитка AS2 -->
			<AdaptationSet […]>
				<EssentialProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1, 100, 0, 100, 100"/>
				<Representation id="2" bandwidth="5000000" width="1920" height="1080">
					<BaseURL>tile2.mp4</BaseURL>
				</Representation>
			</AdaptationSet>
			<!-- плитка AS3 --> …
			<!-- плитка AS4 --> …
		</Period>
	</MPD>

Таблица 3

[…]
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<Panorama projection_id="0" type="cylindrical" […]>
			<PanoramaRegion region_id="top" position="0,0,200,200"/>
			<PanoramaRegion region_id="bottom" position="0,200,200,200"/>
			<PanoramaRegion region_id="side" position="200,0,1920,1080"/>
		</Panorama>
	</ SupplementalProperty >
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,0,0,2120,1080,2120,1080"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<EssentialProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<PanoramaRegion projection_id="0" region_id="side"/>
	</EssentialProperty>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,200,0,1920,1080,2120,1080"/>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="2,0,0,1920,1080,1920,1080"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<EssentialProperty schemeIdUri="urn:mpeg:dash:VR:2016">
		<PanoramaRegion projection_id="0" region_id="side"/>
	</EssenetialProperty>
	<EssentialProperty schemeIdUri="urn:mpeg:dash:srd:2014" value=ʺ2,0,0,960,540,1920,1080"/>
	[…]
</AdaptationSet>
[…]

Таблица 4

[…]
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="cube" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="0,0,0,1920,1080,1920,1080" />
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" region_id="front"/>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="0,0,0,640,540,1920,1080" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,0,0,640,540,640,540" />
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" region_id="front"/>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="1,320,0,320,270,640,540"/>
	[…]
</AdaptationSet>
[…]

Таблица 5a

[…]
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0,0,0,1920,1080,1920,1080" type="cube"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0,0,0,640,540,1920,1080" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="1,0,0,640,540,640,540" region_id="front"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value=ʺ1,320,0,320,270,640,540ʺ/>
	[…]
</AdaptationSet>
[…]

Таблица 5b

[…]
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0,0,0,1920,1080,1920,1080" type="cube"/>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0.1,0,0,640,540,1920,1080" region_id="front"/>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0.2,0,540,640,540,1920,1080" region_id="bottom"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0.1,320,0,320,270,1920,1080"/>
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2016" value="0.2,0,0,320,270,640,540"/>
	[…]
</AdaptationSet>
[…]

Таблица 6

<?xml version="1.0" encoding="UTF-8"?>
<MPD […]>
	<Period […]>
		<AdaptationSet […]>
			<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" projection_id="0" type="cylindrical" value="60,-60" />
				<Representation …> … </Representation>
		</AdaptationSet>
		[…]
	</Period>
</MPD>

Таблица 7a

<?xml version="1.0" encoding="UTF-8"?>
<MPD […]>
	<Period […]>
		<AdaptationSet […]>
			<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="0, cylindrical, 60, -60" />
				<Representation …> … </Representation>
		</AdaptationSet>
		[…]
	</Period>
</MPD>

Таблица 7b

<?xml version="1.0" encoding="UTF-8"?>
<MPD […]>
	<Period […]>
		<AdaptationSet […]>
			<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="0, cylindrical, 180, 120" />
				<Representation …> … </Representation>
		</AdaptationSet>
		[…]
	</Period>
</MPD>

Таблица 7c

<MPD…>
…
<AdaptationSet mimeType=ʺvideo/mp4ʺ… >
	<Representation id=ʺ1ʺ … > … </Representation>
</AdaptationSet>
<AdaptationSet mimeType=ʺregistered mimeType for OMAFʺ… >
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="0, cube" />
	<Representation id=ʺ2ʺ associationId=ʺ1ʺ associationType=ʺcdscʺ… >
		…
	</Representation>
</AdaptationSet>
	[…]
</MPD>

Таблица 8

<MPD …>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" projection_id="0" type="cylindrical" region_list="top, 0, 0, 200, 200; bottom, 0, 200, 200, 200" />
	[…]
</AdaptationSet>
	[…]
</MPD>

Таблица 9a

<MPD>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" projection_id="0" type="cylindrical" value="top, 0, 0, 200, 200ʺ />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" projection_id="0" type="cylindrical" value="bottom, 0, 200, 200, 200" />
	[…]
</AdaptationSet>
</MPD>

Таблица 9b

<MPD>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:srd-VR:2016" value=ʺ0, cube, 0, 0, 200, 200, 200, 200, allʺ />
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:srd-VR:2016" value=ʺ0, cube, 20, 20, 100, 100, topʺ />
	[…]
</AdaptationSet>
</MPD>

Таблица 10a

<MPD>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:srd-VR:2016" value=ʺ0, cylinder, -180, 180, 90, -90, 360, 120ʺ />
	[…]
</AdaptationSet>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:srd-VR:2016" value=ʺ0, cylinder, -90, 90, 45, -45, ʺ />
	[…]
</AdaptationSet>
</MPD>

Таблица 10b

<MPD>
<AdaptationSet […]>
	<SupplementalProperty schemeIdUri="urn:mpeg:srd:2016" value=ʺ0, yaw, pitch, rollʺ />
<Representation width=ʺ1920ʺ height=ʺ1080ʺ…> … </Representation>
	[…]
</AdaptationSet>
</MPD>

Таблица 10c

<MPD…>
<AdaptationSet […]>
	<!-- полная панорама с указанием типа проекции -->
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="cube" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="0, 0, 0, 5, 4, 5, 4" />
	<Represention […] >
		…
	</Representation>
</AdaptationSet>
<AdaptationSet […]>
	<!-- область панорамы (верхняя) -->
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="cube" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="0, 0, 0, 2, 1" />
	<Represention […] >
		…
	</Representation>
</AdaptationSet>
<AdaptationSet […]>
	<!-- область панорамы (передняя) -->
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016" value="cube" />
	<SupplementalProperty schemeIdUri="urn:mpeg:dash:srd:2014" value="0, 1, 1, 2, 2 "/>
	[…]
</AdaptationSet>
…
</MPD>

Таблица 11

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

принимают от сервера описание представления мультимедиа, согласующееся со стандартом MPEG-DASH (динамической адаптивной потоковой передачи по протоколу HTTP) и включающее в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

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

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

2. Способ по п. 1, в котором по меньшей мере один указатель включен в атрибут '@schemeIdUri'.

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

4. Способ по п. 3, в котором тип, представленный информацией типа проекции, включает в себя по меньшей мере одну из кубической проекции, цилиндрической проекции и пирамидальной проекции.

5. Способ по п. 4, в котором информация типа проекции включена в элемент EssentialProperty с некоторым конкретным атрибутом '@schemeIdUri'.

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

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

отправляют клиенту описание представления мультимедиа, согласующееся со стандартом MPEG-DASH и включающее в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

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

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

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

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

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

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

аппаратный процессор; и

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

приема от сервера описания представления мультимедиа, согласующегося со стандартом MPEG-DASH и включающего в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

отправки на сервер по меньшей мере одного сообщения запроса для запрашивания по меньшей мере одного сегмента мультимедийных данных с использованием по меньшей мере одного из унифицированных идентификаторов ресурсов описания представления мультимедиа; и

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

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

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

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

аппаратный процессор; и

отправки клиенту описания представления мультимедиа, согласующегося со стандартом MPEG-DASH и включающего в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

приема от клиента по меньшей мере одного сообщения запроса для запрашивания по меньшей мере одного сегмента мультимедийных данных на основании по меньшей мере одного из унифицированных идентификаторов ресурсов описания представления мультимедиа; и

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

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

16. Серверное устройство по п. 15, в котором тип, представленный информацией типа проекции, включает в себя по меньшей мере одну из кубической проекции, цилиндрической проекции и пирамидальной проекции.

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

прием от сервера описания представления мультимедиа, согласующегося со стандартом MPEG-DASH и включающего в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

отправку на сервер по меньшей мере одного сообщения запроса для запрашивания по меньшей мере одного сегмента мультимедийных данных с использованием по меньшей мере одного из унифицированных идентификаторов ресурсов описания представления мультимедиа; и

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

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

19. Носитель по п. 18, в котором тип, представленный информацией типа проекции, включает в себя по меньшей мере одну из кубической проекции, цилиндрической проекции и пирамидальной проекции.

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

отправку клиенту описания представления мультимедиа, согласующегося со стандартом MPEG-DASH и включающего в себя (i) унифицированный идентификатор ресурса каждого из одного или более сегментов мультимедийных данных, (ii) мультимедийную информацию, описывающую каждый из одного или более сегментов мультимедийных данных, и (iii) по меньшей мере один указатель, сигнализирующий согласование мультимедийных данных, как описано мультимедийной информацией, с форматом всенаправленного мультимедиа,

прием от клиента по меньшей мере одного сообщения запроса для запрашивания по меньшей мере одного сегмента мультимедийных данных на основании по меньшей мере одного из унифицированных идентификаторов ресурсов описания представления мультимедиа; и

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

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

22. Носитель по п. 21, в котором тип, представленный информацией типа проекции, включает в себя по меньшей мере одну из кубической проекции, цилиндрической проекции и пирамидальной проекции.

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

Способ формирования восстановленного блока // 2711306

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

Устройство декодирования видеоданных // 2711182

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

Устройство декодирования видеоданных // 2711176

Устройство и способ улучшения обмена данными изображения на основе нелинейности восприятия яркости между разными возможностями отображения // 2711102

Изобретение относится к вычислительной технике. Технический результат − визуализация изображения на устройствах отображения конечных пользователей с меньшим количеством визуально заметных ошибок.

Способ формирования восстановленного блока // 2710996

Способ формирования восстановленного блока // 2710995

Способ декодирования видеосигнала // 2710989

Изобретение относится к вычислительной технике. Технический результат заключается в повышении эффективности преобразования.

Способ и система для прогнозирования изменения котировок для игры на биржах // 2710981

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

Внутреннее предсказание с низкой сложностью для кодирования видеосигнала // 2710947

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