СПОСОБ, УСТРОЙСТВО И КОМПЬЮТЕРНАЯ ПРОГРАММА ДЛЯ АДАПТИВНОЙ ПОТОКОВОЙ ПЕРЕДАЧИ МУЛЬТИМЕДИЙНОГО КОНТЕНТА ВИРТУАЛЬНОЙ РЕАЛЬНОСТИ
METHOD, APPARATUS AND COMPUTER PROGRAM FOR ADAPTIVE STREAMING OF VIRTUAL REALITY MULTIMEDIA CONTENT

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение относится к области техники потоковой передачи видео и, в частности, к способу, устройству и компьютерной программе для адаптивной потоковой передачи мультимедийного контента виртуальной реальности, например, по сети 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, угол рысканья соответствует повороту головы слева направо или справа налево, угол тангажа соответствует повороту сверху вниз или снизу вверх, и крен соответствует повороту (наклону) головы вокруг оси направления наблюдения.
z
x
y
z
В случае сферической проекции или сплющенной сферической проекции, центральная точка 2D панорамной проекции обычно соответствует проекции в главной ориентации точки обзора, заданной как ориентация возвышения (например, по оси  в правосторонней системе координат (, , )) к точке отсчета (например, центру 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 геометрической поверхности дисплея или рендеризовать, по меньшей мере, часть широкого вида на поверхности дисплея согласно, по меньшей мере, двум разным точкам обзора, причем рендеризация содержит, по меньшей мере, одну проекцию рендеризации мультимедийных данных, представляющих проекцию захвата, по меньшей мере, части широкого вида, причем способ осуществляется на сервере и содержит:
передачу, клиенту, файла описания, включающего в себя информацию о мультимедийных данных, представляющих проекцию захвата широкого вида, причем информация содержит описательную информацию, относящуюся к захвату широкого вида для создания мультимедийных данных;
прием, от клиента, по меньшей мере, одного сообщения запроса для запрашивания, по меньшей мере, одного потока мультимедийных данных на основании файла описания; и
передачу, клиенту, в ответ на, по меньшей мере, одно сообщение запроса, мультимедийных данных, соответствующих, по меньшей мере, одному запрошенному потоку мультимедийных данных.
Таким образом, способ изобретения позволяет оптимизировать передачу мультимедийных данных виртуальной реальности, поскольку передаются только необходимые данные, в частности, мультимедийные данные, качество которых соответствует характеристикам запрашивающих клиентов, повышать качество, поскольку изображения высокого разрешения можно обрабатывать, и сохранять масштабируемость на стороне сервера, поскольку управление данными, подлежащими передаче, осуществляется клиентами. Кроме того, согласно способу изобретения, клиентам требуется меньше ресурсов.
Согласно варианту осуществления, описательная информация, относящаяся к захвату широкого вида для создания мультимедийных данных, относится к проекции захвата.
Согласно варианту осуществления, описательная информация обеспечивается, по меньшей мере, частично в, по меньшей мере, одном описателе.
Согласно варианту осуществления, мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является панорамным изображением, причем панорамное изображение содержит одиночную область панорамы или множество областей панорамы, или является набором разных областей панорамы.
Согласно варианту осуществления, описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном конкретном описателе, причем один конкретный описатель связан с одним панорамном изображением или с одной областью панорамы.
Согласно варианту осуществления, проекция захвата является геометрической проекцией, имеющей, по меньшей мере, один заранее определенный тип, и области панорамы определяются как функция, по меньшей мере, одного заранее определенного типа геометрической проекции.
Согласно варианту осуществления, описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном описателе или одном конкретном описателе, который связан с информацией сигнализации, сигнализирующей, могут ли мультимедийные данные, соответствующие описательной информации в этом описателе или конкретном описателе, отвергаться клиентом, разрешая при этом рендеризацию принятых мультимедийных данных.
Согласно варианту осуществления, описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным.
Согласно варианту осуществления, проекция захвата имеет, по меньшей мере, один заранее определенный тип, и файл описания содержит, по меньшей мере, один заранее определенный тип проекции захвата.
Согласно варианту осуществления, по меньшей мере, один заранее определенный тип проекции захвата является, по меньшей мере, одним из сферического, сплющенного сферического, кубического, цилиндрического и пирамидального типов геометрической проекции.
Согласно варианту осуществления, файл описания дополнительно содержит параметры проекции захвата, причем параметры проекции захвата содержат параметры точки обзора.
Согласно варианту осуществления, идентификатор связан с, по меньшей мере, одним заданным описателем или конкретным описателем таким образом, что параметры, связанные с идентифицированным заданным описателем или конкретным описателем, могут использоваться для описания разных частей мультимедийных данных.
Согласно варианту осуществления, мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, одну область, причем, по меньшей мере, одна область задается как атрибут описателя.
Согласно варианту осуществления, по меньшей мере, один элемент списка, содержащего идентификационную информацию, тип проекции, точку обзора, идентификатор проекции, и область является атрибутом или элементом описателя или конкретного описателя, причем, по меньшей мере, один элемент является частью описательной информации.
Согласно варианту осуществления, проекция захвата имеет, по меньшей мере, один заранее определенный тип, и значения атрибута или элемента описателя или конкретного описателя заранее определены для, по меньшей мере, одного заранее определенного типа проекции захвата.
Согласно варианту осуществления, файл описания дополнительно содержит, по меньшей мере, одно описание пространственного соотношения, причем, по меньшей мере, одно описание пространственного соотношения задает область, представляющую интерес, в, по меньшей мере, части панорамного изображения или задает области панорамных изображений.
Согласно варианту осуществления, описательная информация относительно первой проекции захвата первой области панорамного изображения используется для рендеризации второй области панорамного изображения, как функции, по меньшей мере, одного описания пространственного соотношения.
Согласно варианту осуществления, описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным как функцию описания пространственного соотношения.
Согласно варианту осуществления, мультимедийные данные, представляющие проекцию захвата широкого вида, содержат наборы сшиваемых изображений, и описательная информация не содержит никакого конкретного типа проекции захвата.
Согласно варианту осуществления, мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, две разные области, соответствующие двум изображениям одного и того же стереоскопического вида.
Согласно варианту осуществления, мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является всенаправленным панорамным изображением.
Согласно варианту осуществления, файл описания является описанием представления мультимедиа динамической адаптивной потоковой передачи по протоколу http.
Согласно третьей задаче изобретения, предусмотрено устройство для клиента для приема мультимедийных данных, представляющих проекцию захвата широкого вида сцены, от сервера, причем принятые мультимедийные данные позволяют рендеризовать, по меньшей мере, часть широкого вида на 3D геометрической поверхности дисплея или рендеризовать, по меньшей мере, часть широкого вида на поверхности дисплея согласно, по меньшей мере, двум разным точкам обзора, причем рендеризация содержит, по меньшей мере, одну проекцию рендеризации мультимедийных данных, представляющих проекцию захвата, по меньшей мере, части широкого вида, причем устройство содержит микропроцессор, выполненный с возможностью осуществления этапов:
приема, от сервера, файла описания, включающего в себя информацию о мультимедийных данных, представляющих проекцию захвата широкого вида, причем информация содержит описательную информацию, относящуюся к захвату широкого вида для создания мультимедийных данных;
отправки, на сервер, по меньшей мере, одного сообщения запроса для запрашивания, по меньшей мере, одного потока мультимедийных данных на основании файла описания; и
приема, от сервера, в ответ на, по меньшей мере, одно сообщение запроса, мультимедийных данных, соответствующих, по меньшей мере, одному запрошенному потоку мультимедийных данных.
Таким образом, устройство изобретения позволяет оптимизировать передачу мультимедийных данных виртуальной реальности, поскольку передаются только необходимые данные, в частности, мультимедийные данные, качество которых соответствует характеристикам запрашивающих клиентов, повышать качество, поскольку изображения высокого разрешения можно обрабатывать, и сохранять масштабируемость на стороне сервера, поскольку управление данными, подлежащими передаче, осуществляется клиентами. Кроме того, согласно устройству изобретения, клиентам требуется меньше ресурсов.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, относящаяся к захвату широкого вида для создания мультимедийных данных, относится к проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация обеспечивается, по меньшей мере, частично в, по меньшей мере, одном описателе.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является панорамным изображением, причем панорамное изображение содержит одиночную область панорамы или множество областей панорамы, или является набором разных областей панорамы.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном конкретном описателе, причем один конкретный описатель связан с одним панорамном изображением или с одной областью панорамы.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата является геометрической проекцией, имеющей, по меньшей мере, один заранее определенный тип и таким образом, что области панорамы определяются как функция, по меньшей мере, одного заранее определенного типа геометрической проекции.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном описателе или одном конкретном описателе, который связан с информацией сигнализации, сигнализирующей, могут ли мультимедийные данные, соответствующие описательной информации в этом описателе или конкретном описателе, отвергаться клиентом, разрешая при этом рендеризацию принятых мультимедийных данных.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата имеет, по меньшей мере, один заранее определенный тип, и таким образом, что файл описания содержит, по меньшей мере, один заранее определенный тип проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что, по меньшей мере, один заранее определенный тип проекции захвата является, по меньшей мере, одним из сферического, сплющенного сферического, кубического, цилиндрического и пирамидального типов геометрической проекции.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания дополнительно содержит параметры проекции захвата, причем параметры проекции захвата содержат параметры точки обзора.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что идентификатор связан с, по меньшей мере, одним заданным описателем или конкретным описателем таким образом, что параметры, связанные с идентифицированным заданным описателем или конкретным описателем, могут использоваться для описания разных частей мультимедийных данных.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, одну область, причем, по меньшей мере, одна область задается как атрибут описателя.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что, по меньшей мере, один элемент списка, содержащего идентификационную информацию, тип проекции, точку обзора, идентификатор проекции, и область является атрибутом или элементом описателя или конкретного описателя, причем, по меньшей мере, один элемент является частью описательной информации.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата имеет, по меньшей мере, один заранее определенный тип, и таким образом, что значения атрибута или элемента описателя или конкретного описателя заранее определены для, по меньшей мере, одного заранее определенного типа проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания дополнительно содержит, по меньшей мере, одно описание пространственного соотношения, причем, по меньшей мере, одно описание пространственного соотношения задает область, представляющую интерес, в, по меньшей мере, части панорамного изображения или задает области панорамных изображений.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация относительно первой проекции захвата первой области панорамного изображения используется для рендеризации второй области панорамного изображения, как функции, по меньшей мере, одного описания пространственного соотношения.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным как функцию описания пространственного соотношения.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат наборы сшиваемых изображений, и таким образом, что описательная информация не содержит никакого конкретного типа проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, две разные области, соответствующие двум изображениям одного и того же стереоскопического вида.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является всенаправленным панорамным изображением.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания является описанием представления мультимедиа динамической адаптивной потоковой передачи по протоколу http.
Согласно четвертой задаче изобретения, предусмотрено устройство для сервера для потоковой передачи мультимедийных данных, представляющих проекцию захвата широкого вида сцены, от сервера клиенту, причем потоковые мультимедийные данные позволяют клиенту рендеризовать, по меньшей мере, часть широкого вида на 3D геометрической поверхности дисплея или рендеризовать, по меньшей мере, часть широкого вида на поверхности дисплея согласно, по меньшей мере, двум разным точкам обзора, причем рендеризация содержит, по меньшей мере, одну проекцию рендеризации мультимедийных данных, представляющих проекцию захвата, по меньшей мере, части широкого вида, причем устройство содержит микропроцессор, выполненный с возможностью осуществления этапов:
передачу, клиенту, файла описания, включающего в себя информацию о мультимедийных данных, представляющих проекцию захвата широкого вида, причем информация содержит описательную информацию, относящуюся к захвату широкого вида для создания мультимедийных данных;
прием, от клиента, по меньшей мере, одного сообщения запроса для запрашивания, по меньшей мере, одного потока мультимедийных данных на основании файла описания; и
передачу, клиенту, в ответ на, по меньшей мере, одно сообщение запроса, мультимедийных данных, соответствующих, по меньшей мере, одному запрошенному потоку мультимедийных данных.
Таким образом, устройство изобретения позволяет оптимизировать передачу мультимедийных данных виртуальной реальности, поскольку передаются только необходимые данные, в частности, мультимедийные данные, качество которых соответствует характеристикам запрашивающих клиентов, повышать качество, поскольку изображения высокого разрешения можно обрабатывать, и сохранять масштабируемость на стороне сервера, поскольку управление данными, подлежащими передаче, осуществляется клиентами. Кроме того, согласно устройству изобретения, клиентам требуется меньше ресурсов.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, относящаяся к захвату широкого вида для создания мультимедийных данных, относится к проекции захвата.
Согласно варианту осуществления, описательная информация обеспечивается, по меньшей мере, частично в, по меньшей мере, одном описателе.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является панорамным изображением, причем панорамное изображение содержит одиночную область панорамы или множество областей панорамы, или является набором разных областей панорамы.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном конкретном описателе, причем один конкретный описатель связан с одним панорамном изображением или с одной областью панорамы.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата является геометрической проекцией, имеющей, по меньшей мере, один заранее определенный тип и таким образом, что области панорамы определяются как функция, по меньшей мере, одного заранее определенного типа геометрической проекции.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация, по меньшей мере, частично обеспечивается в, по меньшей мере, одном описателе или одном конкретном описателе, который связан с информацией сигнализации, сигнализирующей, могут ли мультимедийные данные, соответствующие описательной информации в этом описателе или конкретном описателе, отвергаться клиентом, разрешая при этом рендеризацию принятых мультимедийных данных.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата имеет, по меньшей мере, один заранее определенный тип, и таким образом, что файл описания содержит, по меньшей мере, один заранее определенный тип проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что, по меньшей мере, один заранее определенный тип проекции захвата является, по меньшей мере, одним из сферического, сплющенного сферического, кубического, цилиндрического и пирамидального типов геометрической проекции.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания дополнительно содержит параметры проекции захвата, причем параметры проекции захвата содержат параметры точки обзора.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что идентификатор связан с, по меньшей мере, одним заданным описателем или конкретным описателем таким образом, что параметры, связанные с идентифицированным заданным описателем или конкретным описателем, могут использоваться для описания разных частей мультимедийных данных.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, одну область, причем, по меньшей мере, одна область задается как атрибут описателя.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что, по меньшей мере, один элемент списка, содержащего идентификационную информацию, тип проекции, точку обзора, идентификатор проекции, и область является атрибутом или элементом описателя или конкретного описателя, причем, по меньшей мере, один элемент является частью описательной информации.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что проекция захвата имеет, по меньшей мере, один заранее определенный тип, и таким образом, что значения атрибута или элемента описателя или конкретного описателя заранее определены для, по меньшей мере, одного заранее определенного типа проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания дополнительно содержит, по меньшей мере, одно описание пространственного соотношения, причем, по меньшей мере, одно описание пространственного соотношения задает область, представляющую интерес, в, по меньшей мере, части панорамного изображения или задает области панорамных изображений.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация относительно первой проекции захвата первой области панорамного изображения используется для рендеризации второй области панорамного изображения, как функции, по меньшей мере, одного описания пространственного соотношения.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что описательная информация содержит информацию для идентификации ресурсов, относящихся к мультимедийным данным как функцию описания пространственного соотношения.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат наборы сшиваемых изображений, и таким образом, что описательная информация не содержит никакого конкретного типа проекции захвата.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений содержит, по меньшей мере, две разные области, соответствующие двум изображениям одного и того же стереоскопического вида.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что мультимедийные данные, представляющие проекцию захвата широкого вида, содержат изображения, причем, по меньшей мере, одно из изображений является всенаправленным панорамным изображением.
Согласно варианту осуществления, микропроцессор дополнительно сконфигурирован таким образом, что файл описания является описанием представления мультимедиа динамической адаптивной потоковой передачи по протоколу http.
Поскольку настоящее изобретение можно реализовать программными средствами, настоящее изобретение может быть воплощено в виде компьютерно-считываемого кода для подачи на программируемое устройство на любой подходящей среде переноса, и, в частности, подходящей материальной среде переноса или подходящей переходной среде переноса. Материальная среда переноса может содержать среду хранения, например, флоппи-диск, CD-ROM, жесткий диск, устройство для магнитной ленты или твердотельное запоминающее устройство и пр. Переходная среда переноса может включать в себя сигнал, например, электрический сигнал, электронный сигнал, оптический сигнал, акустический сигнал, магнитный сигнал или электромагнитный сигнал, например, микроволновой или RF сигнал.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Специалисты в данной области техники поймут дополнительные преимущества настоящего изобретения, ознакомившись с чертежами и подробным описанием. Предполагается, что сюда могут быть включены любые дополнительные преимущества.
Варианты осуществления изобретения будут описано ниже, исключительно в порядке примера и со ссылкой на нижеследующие чертежи, в которых:
фиг. 1, содержащая фиг. 1a, 1b, 1c, 1d и 1e, демонстрирует пример потока данных для захвата, передачи и рендеризации всенаправленного видео от сервера клиенту, а также примеры широкого вида, точки обзора, потока панорамного изображения и панорамного изображения, имеющего области панорамы.
Фиг. 2, содержащая фиг. 2a, 2b, и 2c, демонстрирует пример панорамного представления, содержащего несколько областей, на основании кубической проекции, причем каждая область связана с проекцией поверхности и панорамным представлением, причем одна область дополнительно разделена на подобласти или участки;
фиг. 3 демонстрирует блок-схему, иллюстрирующую пример общего принципа адаптивной потоковой передачи мультимедиа по HTTP;
фиг. 4 - блок-схема, демонстрирующая главные компоненты манифеста потоковой передачи описания представления мультимедиа DASH; и
фиг. 5 - блок-схема вычислительного устройства для реализации одного или более вариантов осуществления изобретения.
ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ
Согласно конкретным вариантам осуществления, манифест потоковой передачи или список воспроизведения потоковой передачи, например, описание представления мультимедиа (MPD) динамической адаптивной потоковой передачи по протоколу HTTP (DASH) используется для сигнализации (т.е. обеспечения) характеристик мультимедийных данных, представляющих широкий вид сцены, например, мультимедийные данные виртуальной реальности, например, панорамные изображения или наборы сшиваемых изображений. Эти характеристики, которые могут содержать, например, тип проекции, используемой для создания панорамных изображений, возможность осуществления доступа к частям панорамных изображений, и качество и указание направления наблюдения, которые помогают сначала сообщать клиентам потоковой передачи, что мультимедиа не являются классическими мультимедиа или видео, но обеспечивают некоторые возможности навигации, и затем выбирать данные, подлежащие извлечению, могут сигнализироваться во вновь добавленных структурных элементах или описателях в случае DASH. Первый точка позволяет клиенту устанавливать и/или выбирать надлежащий пользовательский интерфейс для взаимодействия с контентом.
Напомним, что 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, простого текста и т.д.).
SupplementalProperty
EssentialProperty
@schemeIdURI
urn:mpeg:dash:VR:2016
schemeIdUri
ProjectionInfo
DescriptorType
SupplementalProperty
schemeIdUri
panorama
@value
EssentialProperty
Как показано в таблице 1a, сигнализация представления мультимедийных данных виртуальной реальности в MPD может осуществляться, например, с использованием либо универсального описателя DASH, либо универсального описателя DASH с атрибутом , который устанавливается, например, на новое значение ʺʺ. Это значение обеспечено здесь лишь в порядке примера. Задача состоит в том, чтобы иметь зарезервированное уникальное значение (обычно URN в DASH MPD) в @, чтобы однозначно идентифицировать описатель как описатель для виртуальной реальности или всенаправленного мультимедиа, обеспечивающих информацию о панораме. Альтернативные варианты осуществления состоят в задании, вместо использования универсальных описателей DASH, явный описатель в качестве зарезервированного элемента для переноса VR и/или всенаправленной информации, например, элемента <>, наследующего в схеме MPD за , который можно поместить непосредственно на уровне MPD, если манифест обеспечивает только контент VR или в некоторых адаптационных наборах, уровне представлений или подпредставлений, если манифест обеспечивает контент как VR, так и не-VR, этот явный описатель является потомком адаптационных наборов, представлением, или подпредставлением, описывающим контент VR. Пример, приведенный в таблице 1a, является примером расширения универсального описателя DASH < >, причем, с одной стороны, новое значение  для его указания является описателем VR и, с другой стороны, новый элемент именуемый ʺʺ для переноса идентификатора проекции, информация типа проекции (на цилиндре в примере) и информация вертикального поля зрения, выраженная как два значения угла между точкой отсчета и, соответственно, верхней поверхностью цилиндра (+60° в примере) и нижней поверхностью цилиндра (-60° в примере), таким образом, обеспечивая поле зрения 120° в вертикальном измерении. Таблица 7a является альтернативой таблицы 1a, предпочитающей новые атрибуты для ID проекции, типа проекции и информации поле зрения. Таблица 7b является другой альтернативой, где атрибут используется вместо создания новых атрибутов. Следует отметить, что эти варианты будут применяться таким же образом, если используется описатель или явный описатель. Наконец, таблица 7c является тем же примером, как в таблице 7b, за исключением того, что поле зрения значение выражается как два значения угла 180° и 120°, соответственно обеспечивающие горизонтальное поле зрения и вертикальное поле зрения (угол, наблюдаемый из точки отсчета).
@value
SupplementalProperty
EssentialProperty
Согласно некоторым вариантам осуществления, где несколько альтернативных панорам описаны в MPD, существующий атрибут  описателей  и/или  может использоваться для обозначения одной из нескольких альтернативных панорам, адресованных текущим представлением или адаптационным набором (или, возможно, подпредставлением).
Эта сигнализация используется, предпочтительно, как описатель на уровне адаптационного набора для указания, что адаптационный набор содержит мультимедийные данные, относящийся к данным панорамы, например, панорамному(ым) изображению(ям) или видео. Согласно альтернативным вариантам осуществления, этот описатель может быть установлен на уровне представления или подпредставления. Когда панорама дополнительно делится на области панорамы, как показано на фиг. 1c, для обеспечения доступа к участкам, пространственным областям или подобластям в области панорамы, описатели VR могут быть установлены в представлении или подпредставлении, описывающем область панорамы в отношении размера, полосы и соответствующих сегментов для загрузки.
SupplementalProperty
EssentialProperty
EssentialProperty
Для обеспечения обратной совместимости для клиентов, которые не могут интерпретировать описатели VR, использование описателя  для сигнализации описателей VR может быть более адаптировано, чем использование описателя. Действительно, когда панорама, область панорамы или подобласть панорамы объявлена в манифесте, например, область панорамы, соответствующая одной грани проекции на куб, автор контента может позволять клиентам потоковой передачи без VR выбирать, загружать и воспроизводить эту панораму, область панорамы или подобласть панорамы в качестве классического 2D видео. Напротив, когда проекция захвата не позволяет клиенту без VR воспроизводить любую из панорамы, области панорамы, или области панорамы, описатели VR помещаются в описатель таким образом, что описатели плюс связанный контент (родительский адаптационный набор, представление или подпредставление) игнорируется и может безопасно удаляться из MPD.
SupplementalProperty
EssentialProperty
VR SupplementalProperty
VR EssentialProperty
Описатель  или описатель сигнализирующий представление мультимедийных данных виртуальной реальности может именоваться  или .
projection_type='cube'
projection_type='cubical'
type='cylindrical'
@value
chemeIdURI
urn:mpeg:dash:VR:cylinder:2016
urn:mpeg:dash:VR:2016
Согласно конкретным вариантам осуществления, сигнализация типа проекции, используемой в панорамном изображении может осуществляться с новым элементом/атрибутом. Например, он может сигнализироваться с элементом/атрибутом ʺʺ или ʺʺ для сигнализации использования кубической проекции или, как показано в таблице 1a приложения, с ʺʺ или type=ʺcylinderʺ для сигнализации использования цилиндрической проекции, проекции на цилиндр. Он также может сигнализироваться с использованием существующего атрибута , например, ʺvalue='pyramid'ʺ или ʺvalue='pyramidal'ʺ для сигнализации использования пирамидальной проекции или возможно, как показано в описании представления мультимедиа таблицы 1b, с использованием нового особого значения атрибута @, например, одного зарезервированного или конкретного URN для каждого типа проекции, например, ʺʺ (для сигнализации использования цилиндрической проекции), который также используется для сигнализации представления мультимедийных данных VR (а не универсального ʺʺ, который не указывает фактический тип проекции в ходе эксплуатации). Наличие такого конкретного URN в описателе VR может помогать клиенту потоковой передачи в время разложения MPD для более быстрого определения, способны ли они воспроизводить панораму, область панорамы или даже подобласть панорамы.
@value
value=ʺ60, -60ʺ
schemeIdUri
min_yaw
max_yaw
angle_unit=ʺradianʺ
Согласно конкретным вариантам осуществления, существующий атрибут  универсальных описателей DASH может использоваться для выражения параметров, которые специфичны для сигнализируемого типа проекции в качестве списка значений с разделителем в виде запятой (например, ʺʺ в таблице 1a), или в качестве новых атрибутов, специфичных для особого  для описателя VR (например, ʺtop_pitch=ʺ60ʺ bottom_pitch=ʺ-60ʺ) в таблице 1b). В этом примере, конкретные атрибуты являются значениями угла тангажа (выраженными в градусах), соответствующими проекции верхней поверхности и проекции нижней поверхности цилиндрической проекции. Дополнительные атрибуты также могут обеспечиваться для обеспечения параметров, например, при углах  (максимальный угол влево) и  (максимальный угол вправо), а также при минимальном и максимальном значениях угла крена, например в градусах. Заметим, что возможно использование других единиц для углов, но что требуется дополнительный атрибут для обеспечения единицы угла, (например, ). Этот тип параметров также может быть полезен для других видов проекции, например, squished_sphere.
ref_vp='180,0'
vp_yaw='180'
0,0,0
Ориентация точки обзора для проекции (т.е. опорной точки обзора) может задаваться значением рысканья, значением тангажа и, в необязательном порядке, значением крена, которое может выражаться, например, в градусах поворота. В целях иллюстрации, эти значения могут сигнализироваться с использованием нового(ых) элемент(ов)/атрибут(ов), например, ʺʺ для соответствующего задания фактических значений рысканья и тангажа в одиночном атрибуте или в отдельных атрибутах, например, ʺʺ для сигнализации только значения рысканья. Если один или несколько атрибутов исключены, пропущенное(ые) значение(я) можно заменять соответствующим(и) значением(ями) по умолчанию точки обзора (например ʺʺ).
Representation
AdaptationSet
SubRepresentation
Representation
AdaptationSet
SubRepresentation
Сигнализация типа проекции позволяет клиенту DASH выбирать ,  или  как функцию типов проекции, которыми он может обрабатывать. Сигнализация абсолютной ориентации позволяет клиенту DASH выбирать ,  или  согласно точке обзора, запрошенной пользователем. Например, когда пользователь перемещает голову или осуществляет навигацию в панораме посредством особого пользовательского интерфейса, адаптационная логика клиента (позиция 311 на фиг. 3) может идентифицировать наиболее подходящую версию контента из MPD (позиция 305 на фиг. 3).
@projection_id
Согласно конкретным вариантам осуществления, описатель панорамы может использовать идентификатор проекции с использованием, например, атрибута , как показано в таблице 1b. Это позволяет связывать все параметры (например, точку обзора и конкретные параметры) проекции с этим идентификатором и сообщать клиенту об альтернативных версиях областей панорамы или подобластей панорамы с использованием одной и той же проекции. Соответственно, это позволяет избегать повторения типа проекции захвата, в манифесте обеспечивается только ссылка на проекцию и соответствующее панорамное представление.
AdaptationSet
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
Таким образом, если один и тот же идентификатор проекции используется в, по меньшей мере, двух адаптационных наборов, все параметры, относящиеся к проекции, связанные с идентификаторами проекции, могут объявляться только один раз в одном  и исключаться в другом  (или в другом  или ), где они предполагаются одинаковыми. Если параметры дублируются в нескольких ,  или  с использованием одной и той же проекции и/или точки обзора, рекомендуется использовать одни и те же значения для параметров проекции и/или параметров точки обзора во всех этих ,  или  таким образом, что клиент может однозначно связывать их как части одной и той же панорамы.
@panorama_id
@panorama_image_id
В необязательном порядке, описатель панорамы также может быть связан с идентификатором панорамы с использованием атрибута  для различения разных версий панорам, если в MPD описано несколько панорам. В частности, два представления, которые совместно используют одно и то же значение идентификатора панорамы указывает, что эти представления альтернативны друг другу. Опять же в необязательном порядке, описатель панорамы также может быть связан с индексом панорамного изображения с использованием , если несколько панорамных изображений используется внутри одной и той же панорамы. Последнее применяется, в частности, когда среда погружения обеспечивается вдоль данного пути навигации в широком виде. Несколько панорамных изображений генерируется в нескольких местах на пути.
Как описано выше, данное панорамное изображение может содержать несколько областей, специфичных для типа проекции. Соответственно, следует обеспечивать информацию о каждой области панорамы. Это можно осуществлять с использованием нового описателя области панорамы.
PanoramaRegion
Panorama
VR SupplementalProperty
VR EssentialProperty
PanoramaRegion
PanoramaRegion
DescriptorType
Согласно вариантам осуществления, описание областей панорамы осуществляется с использованием элемента, содержащегося в элементе  либо , либо . Альтернативный вариант осуществления состоит в объявлении этого описателя для  в качестве конкретного описателя, т.е. в качестве конкретного элемента MPD, предназначенного для переноса описательной информации об области панорамы, например, <>, наследующего в схеме MPD за  и объявленного на уровнях адаптационного набора, представления или подпредставления.
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
Согласно вариантам осуществления, все области панорамы описаны в ,  или , содержащих описание соответствующего панорамного изображения. Альтернативно, области панорамы описаны в пустых ,  или , описывающих панорамное изображение, но не содержащих никаких сегментов мультимедиа этого панорамного изображения. Целью таких ,  или  является объявление полного списка имеющихся областей таким образом, что другие ,  или  фактически содержащие сегменты мультимедиа могут ссылаться на него для получения информации о имеющихся областей панорамы.
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
Опять же, согласно вариантам осуществления, в отсутствие ,  или , описывающих полное панорамное изображение в MPD, области панорамы все же можно описывать в каждом ,  или  видеоизображений, содержащих одну (или более) областей панорамы, как показано в таблице 4a приложения.
AdaptationSet
Representation
SubRepresentation
associationId
associationType
associationType
Опять же, согласно вариантам осуществления, описатели VR и области панорамы описатели описаны в ,  или , описывающих дорожку метаданных, например метаданные с использованием формата всенаправленного мультимедиа-приложения (OMAF). Это требует, чтобы этап 141 упаковки контента на фиг. 1a отражал связь, объявленную между дорожкой OMAF и одной или более дорожек видео в манифесте MPD. Как показано в таблице 8 приложения, это может осуществляться путем объявления атрибутов  и  в представлениях, описывающих дорожку OMAF в MPD, соответственно, указывающую представление одной или более дорожек видео в MPD. Атрибут  может принимать значение 'cdsc' для указания, что представление метаданных дорожки OMAF в MPD обеспечивает дополнительный контент описания для одного или более представлений видео, объявленных в MPD.
AdaptationSet
Representation
SubRepresentation
AdaptationSet
Representation
SubRepresentation
associationId
Representation
В ходе этапа 141 упаковки мультимедиа, сервер предпочтительно проверяет информацию формата файла для мультимедийный файла для определения, присутствует ли некоторая информация постдекодерного требования, например, путем проверки, относятся ли выборочные записи дорожки видео для упаковки для потоковой передачи к типу 'resv'. Если да, модуль упаковки мультимедиа разлагет блок информации схемы, который может обеспечивать информацию в типах проекции захвата, используемых для построения панорамы. Если такая информация присутствует (при наличии одной дорожки OMAF), модуль упаковки мультимедиа использует эту информацию для установления значения описателя VR в ,  или , описывающем панораму. Опять же, извлечение этой информации и ее раскрытие в манифесте потоковой передачи позволяют клиентам потоковой передачи, посредством их адаптационной логики, быстро идентифицировать, является ли ,  или  видео кандидатом для загрузки и воспроизведения. В случае дорожки OMAF метаданных, она является менее прямым, поскольку клиент должен следовать  представления OMAF для нахождения , обеспечивающего описание панорамных изображений.
Согласно вариантам осуществления, описатель области панорамы сигнализируется на том же уровне, что и описание панорамы (адаптационный набор, представление или подпредставление). Альтернативно, описатель области панорамы сигнализируется на том же уровне, что и описание области панорамы (адаптационный набор, представление или подпредставление). Первое решение представляет преимущество разрешения клиенту определять размер каждой области и количество областей в ходе разложения одиночного элемента (т.е. нет необходимости разлагать каждое описание области панорамы). Второе решение требует меньше операций разложения MPD, если некоторые области панорамы не используются клиентом.
Role
ContentComponent
AdaptationSet
AdaptationSet
PanoramaRegion
PanoramaRegion
stereo='left'
stereo='none'
В случае стереоскопических представлений, схема множественных видов DASH может использоваться непосредственно для сигнализации роли каждого вида, где описатель  применяемый к элементу  типа видео или к элементу, если каждый вид содержится в отдельном панорамном изображении (т.е. в отдельном ). Ее также может быть расширить, позволяя применять описатель Role к  для поддержки случая, когда представления левого глаза и правого глаза находятся в двух частях одного и того же изображения/видеоконтента. Альтернативно,  может содержать новый(е) необязательный(е) атрибут(ы) для задания стереоинформации (например, "ʺ, ʺʺ [по умолчанию])
Таблицы 2a, 2b, 2cи2d приложения иллюстрируют четыре описателя AdaptationSet с использованием описателей VR.
position
PanoramaRegion
position='0,200,200,200'
Согласно примеру, приведенному в таблице 2a, пространственное положение области в видео, описанном на уровне адаптационного набора сигнализируется, в описателе области панорамы, с использованием четырех параметров, выраженных в пикселях в образце видео панорамного изображения. Эти параметры содержат координаты (x, y) верхнего левого угла области (в панораме видео) и ширину и высоту области (или, альтернативно, координаты x, y нижнего правого угла области). Эти параметры можно описать в новом атрибуте @ элемента с использованием списка с разделителем в виде запятой целочисленных значений, как показано в таблице 2a (например, ʺʺ). Согласно вариантам осуществления, если пространственное положение области не обеспечено, это означает, что видео адаптационного набора, в котором объявлена область, полностью покрыто областью.
В необязательном порядке, пятый параметр может использоваться для указания индекса панорамного изображения, если конкретное панорамное изображение подлежит адресации (если панорама содержит множественные панорамные изображения, и не обеспечено ни одного пятого параметра, это означает, что рассмотрены все панорамные изображения).
Каждый описатель области панорамы связан с типом области, который зависит от типа проекции опорного панорамного изображения. Он задается конкретными значениями идентификаторов области (например, ʺпереднийʺ, ʺверхнийʺ, ʺправыйʺ, и т.д.), как показано в таблице 2a, или заранее заданным индексом области с использованием численных значений, например, списка значений, предложенного в OMAF.
PanoramaRegion
PanoramaRegion
VR SupplementalProperty
VR EssentialProperty
PanoramaRegion
Согласно вариантам осуществления, описатель  может быть объявлен как элемент описателя панорамы (как показано в таблице 2a). Альтернативно,  может быть объявлен непосредственно либо в , либо в , либо в любом явном описателе. В таком случае, опорное панорамное изображение идентифицируется атрибутом, принадлежащим .
projection_id='1'
PanoramaRegion
Как показано в таблице 2b, описатель области панорамы может быть связан с опорной панорамной проекцией с использованием его идентификатора (например ʺʺ) или, альтернативно, с использованием идентификатора панорамы (если существуют более одной панорамы в MPD) и идентификатора панорамного изображения (если существуют более одного изображения для этой панорамы) (например ʺpanorama_id='1', panorama_image_id='0'ʺ). Альтернативно, если описатель  объявлен дочерним элементом панорамы, идентификатор проекции не требуется. Тогда область панорамы ссылается на ее панораму внедрения, например, как показано в таблице 2a.
PanoramaRegion
PanoramaRegion
Согласно вариантам осуществления, если используется описатель , но представление AdaptationSet панорамы отсутствует, тип панорамной проекции может непосредственно идентифицироваться атрибутом, принадлежащим , как показано в таблице 2c. Это не требуется, если используется схема, выделенная проекции, как показано в таблице 2d.
PanoramaRegion
AdaptationSet
Representation
SubRepresentations
AdaptationSet, Representation или SubR
presentation
projection_id
value
region_list
value
Аналогично, если описатели  используются в различных ,  или , но отсутствует e, описывающий панораму,  все еще используется для указания, что области панорамы относятся тому же панорамному изображению, как показано, например, в таблицах 2c и 2d. Это позволяет связывать эти области панорамы как относящиеся к одной и той же панораме (даже если ее нет). Вся описательная информация, порождаемая новыми описателями, показанными в таблицах 2a, 2b и 2c, также может переноситься в новых атрибутах выбранного описателя (либо универсального описателя DASH, либо явного описателя), или в существующем атрибуте ʺʺ как список сцепленных значений. Например, таблица 9a обеспечивает такую же информацию, как в таблице 2a, но с новым атрибутом ʺʺ для областей панорамы. Альтернатива будет использовать описатели DASH в количестве, равном количеству областей, помещая описательную информацию областей в атрибут ʺʺ, таким образом, что описатели не могут считаться эквивалентными, таким образом, принуждая проигрыватель обрабатывать их все (а не только один в наборе). Таблица 9b обеспечивает такой пример.
SupplementalProperty
EssentialProperty
@schemeIdURI
urn:mpeg:dash:srd:2014
@value
Стандарт DASH позволяет выражать пространственные соотношения компонентов мультимедийного контента в MPD на уровне адаптационного набора или подпредставления. Он предусматривает использование описатели  или , где  равен ʺʺ. Атрибут  состоит из списка значений с разделителем в виде запятой для параметров SRD (описания пространственного соотношения), содержащих нижеследующие параметры:
source_id
object_x, object_y, object_width, object_height
-  обеспечивает идентификатор источника мультимедийного контента. Параметры (), используемые в разных SRD, совместно использующих одно и то же значение, именуемое ʺsource_id valueʺ в течение периода, можно сравнивать для определения, что два представления в пространстве связаны друг с другом;
object_x
AdaptationSet
SubRepresentation
- : обеспечивает горизонтальную позицию, в базовом пространстве, заданном этим описателем SRD, верхнего левого угла видео, описанного в нескольких  или  с использованием этого описателя;
object_y
AdaptationSet
SubRepresentation
- : обеспечивает вертикальную позицию, в базовом пространстве, заданном этим описателем SRD, верхнего левого угла видео, описанного в нескольких  или  с использованием этого описателя;
object_width
AdaptationSet
SubRepresentation
- : обеспечивает ширину, в базовом пространстве, заданном этим описателем SRD, видео, описанного в нескольких  или  с использованием этого описателя;
object_height
AdaptationSet
SubRepresentation
- : обеспечивает высоту, в базовом пространстве, заданном этим описателем SRD, видео, описанного в нескольких  или  с использованием этого описателя;
total_width
AdaptationSet
SubRepresentation
source_id
total_width
source_id
source_id
total_width
-: обеспечивает максимальную протяженность вдоль оси x видео, описанного в нескольких  или , имеющих SRD с одним и тем же значением. В его отсутствие, это значение устанавливается равным значению аннотации SRD, имеющей одно и то же значение. Для данного значения, следует указать, по меньшей мере, одно значение;
total_height
AdaptationSet
SubRepresentation
source_id
total_height
source_id
source_id
total_height
- : обеспечивает максимальную протяженность вдоль оси y видео, описанного в нескольких  или , имеющих SRD с одним и тем же значением. В его отсутствие, это значение устанавливается равным значению аннотации SRD, имеющей одно и то же значение. Для данного значения, следует указать, по меньшей мере, одно значение;
spatial_set_id
AdaptationSet
SubRepresentation
source_id
spatial_set_id
AdaptationSet
SubRepresentation
- : обеспечивает идентификатор для группы  или , имеющих одно и то же значение. Параметр  можно использовать для указания, что группа  или  образуют группу неперекрывающихся или смежных видеоизображений без зазоров или являются частью одного и того же слоя масштабируемости;
object_x
object_y
object_width
object_height
AdaptationSet
SubRepresentation
source_id
source_id
параметры  и  (соответственно  и ) выражают 2D позиции (соответственно 2D размеры) связанных  или  в системе координат, связанной с источником, идентифицированным параметром. Эта система координат может использовать произвольное начало отсчета. Согласно конкретным вариантам осуществления, ось x ориентирована слева направо, и y ось - сверху вниз. Все SRD, совместно использующие одно и то же значение имеют одинаковые начало отсчета и ориентации осей.
total_width
total_height
object_x
object_y
object_width
object_height
total_width
total_height
object_x
object_y
object_width
object_height
source_id
object_x
object_width
total_width
object_y
object_height
total_height
Значения и  задают базовое пространство в этой системе координат. Значения параметров , ,  и  связаны со значениями параметров и . Позиции (, ) и размеры (, ) SRD, совместно использующего одно и то же значение, можно сравнивать с учетом размера базового пространства, т.е. после деления значений  и  на значение и деления значений  и  на значение их соответствующих описателей.
В таблице 3 приложения приведен пример описателя SRD, где видео состоит из 4 плиток (AS1 - AS4) в базовом пространстве с произвольными единицами. В целях иллюстрации показано только описание MPD для плиток AS1 и AS2.
SupplementalProperty
source_id
object_x
object_y
object_width
object_height
total_width
total_height
Первый адаптационный набор соответствует плитке AS1. Он состоит из одного представления видео с разрешением 1920×1080 пикселей. Описатель SRD (использующий описатель ) указывает, что это видео является плиткой, где  равен 1, и что она располагается в верхнем левом углу базового пространства (координаты =0 и =0). Размер видео представляет половину базового пространства в каждом направлении ( и  покрывают 100 на 200 произвольных единиц для  и  базового пространства). Из описателя SRD можно вывести, что все базовое пространство действительно представляет видео 4k2k (3840×2160 пикселей).
EssentialProperty
source_id
Из описателя SRD можно вывести, что второй адаптационный набор соответствует плитке AS2. Этот описатель SRD вводится с использованием, здесь, описателя, указывающего, что плитка относится к тому же базовому пространству, что и первый адаптационный набор (тот же =1), и что она располагается посередине на оси x (значение 100 на 200) и на основании оси y (значение 0).
SupplementalProperty
EssentialProperty
AdaptationSet
Representation
SubRepresentation
schemeIdURI
ʺurn:mpeg:dash:srd:2014ʺ
EssentialProperty
schemeIdUri
SupplementalProperty
Различие между  и  описатели состоит в том, как родительский элемент (,  или ) обрабатывается клиентом, который не понимает значения атрибута, в случае SRD: . Действительно, в случае описателя, если клиент не понимает , он должен игнорировать его, а также родительский элемент, который содержит описатель. В случае , предполагается, что клиент будет игнорировать только сам описатель, но все же сможет использовать родительский элемент.
SupplementalProperty
Соответственно, когда в MPD используются описатели SRD, рекомендуется опираться на, по меньшей мере, один описатель  для обратной совместимости с клиентами, которые не понимают описание пространственного соотношения.
<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"/>
<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"/>
source_id
Таблица 4 в приложении демонстрирует, как описатель панорамы и описатель области панорамы можно объединять с описанием пространственного соотношения (SRD) в MPD. Как показано, панорамное изображение (например, ) или, альтернативно, область панорамы (например, ) можно делить в областях, представляющих интерес (ROI). Соответственно, описатель SRD используется для указания ROI в панорамном изображении (например, ) или, альтернативно, в области панорамы (например, ). Следует отметить, что описатель VR не влияет на описатель SRD или не изменяет его. Оба описателя ортогональны и хорошо объединяются для обеспечения пространственного доступа в области панорамы или подобласти панорамы. Таблица 11 является альтернативным описанием областей панорамы по сравнению с кубической проекцией с нормализованными координатами. ID проекции является неявно  SRD. Информация типа проекции обеспечивается посредством описателя VR.
Таблица 5aи5b в приложении обеспечивают альтернативные примеры использования описателя VR с SRD.
projection_id
source_id
object_width
total_width
object_height
total_height
Как показано в таблице 5a, вложенное использование SRD представлено аналогично представленному в таблице 4. Однако оно не содержит никакого объявления областей внутри панорамы. В этом примере,  не используется,  описателя SRD можно использовать вместо связывания областей панорамы с панорамой. В таком варианте осуществления, панорама идентифицируется посредством значений параметров SRD, когда = и =, как для классического SRD. В этом варианте осуществления, описатель VR и классический описатель SRD объединяются для обеспечения пространственного доступа к областям панорамы (или участкам или пространственным частям) и также для связывания панорамы с ее областями панорамы.
@shemeIdUri
urn:mpeg:dash:srd:2016
@value
@projection_id
@value
@region_id
В альтернативных вариантах осуществления, проиллюстрированных в таблице 5b, схема SRD расширяется с использованием нового значения , равного, например, ʺʺ, для поддержки контента VR. В этом варианте осуществления, эту новую схему можно использовать таким образом, что описатель SRD манипулирует как описанием пространственного соотношения, так и описанием VR или всенаправленным мультимедиа. Атрибут  сохраняет те же форматирование/параметры, что и в схеме SRD 2014, и используется для извлечения областей, представляющих интерес, панорамы (которые могут соответствовать или не соответствовать областям панорамы или подобластям панорамы). Тот же атрибут типа проекции, который описан для панорамы, добавляется в эту новую схему SRD, например, в качестве нового атрибута. Когда этот атрибут присутствует в MPD, это говорит о том, что SRD относится к панорамному изображению, в противном случае SRD относится к классическому 2D видео. Согласно вариантам осуществления, атрибут  не добавляется: идентификатор SRD (первый параметр ) используется вместо того, чтобы идентифицировать панораму. Область также сигнализируется с использованием схемы SRD 2016, но с использованием, например, нового атрибута, для указания соответствующей области проекции.
< 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"/>
Таблица 6 в приложении демонстрирует, как использовать вложенный идентификатор SRD (например, 0.1 и 0.2) для расширения новой схемы SRD для создания возможности прямого объявления областей внутри панорамы, и как его можно использовать с абсолютными координатами в панораме (например ) для описания, например, подобласти или с координатами относительно области панорамы (например ).
yaw_start
yaw_end
pitch_start
pitch_end
squished_sphere
all
front
top
bottom
Другое возможное расширение описателя SRD для виртуальной реальности служит для описания непосредственно в SRD ID проекции и/или типа проекции и/или позиции, где для находить область панорамы, как показано в примере таблицы 10a. В зависимости от типа проекции, позицию следует рассматривать как пиксели или нормализованные пиксели (проекция на куб или пирамиду или без использования) или как углы , , ,  для , цилиндр, как показано в примере таблицы 10b. В необязательном порядке, в зависимости от типа проекции, идентификационная информация областям может обеспечиваться как последнее значение: ʺʺ для панорамы, ʺʺ или ʺʺ или ʺʺ для грани куба.
PanoramaRegion
position
yaw
pitch
roll
рысканья
тангажа
крена
Другая альтернатива для описания  в отношении доступа в зависимости от вида пользователя или от навигации пользователя относится к использованию, вместо пространственных координат (например, атрибута ʺʺ таблицы 4 приложения) с или без SRD, значения диапазона, выраженных как значения углов рысканья, тангажа и, в необязательном порядке, крена, как показано в таблице 10c приложения и описывающие точку обзора, как на фиг. 1d (относительно точки отсчета в широком виде, имеющем углы=0, =0 и =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>
</<i> SupplementalProperty</i> >
[…]
</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>
</<i> SupplementalProperty</i> >
[…]
</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>
</<i> SupplementalProperty</i> >
[…]
</AdaptationSet>
Таблица 2a
<AdaptationSet […]>
<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
<Panorama projection_id="0" type="cylindrical" […]/>
<PanoramaRegion region_id="top" projection_id="0"/>
</Panorama>
</<i> SupplementalProperty</i> >
[…]
</AdaptationSet>
Таблица 2b
<AdaptationSet […]>
<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
<PanoramaRegion region_id="top" projection_id="0" type="cylindrical"/>
</Panorama>
</<i> SupplementalProperty</i> >
[…]
</AdaptationSet>
Таблица 2c
<AdaptationSet […]>
<SupplementalProperty schemeIdUri="urn:mpeg:dash:VR:2016">
<PanoramaRegion region_id="top" projection_id="0"/>
</Panorama>
</<i> SupplementalProperty</i> >
[…]
</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>
</<i> SupplementalProperty</i> >
<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