СИГНАЛИЗАЦИЯ ТРЁХМЕРНОЙ ВИДЕОИНФОРМАЦИИ В КОММУНИКАЦИОННЫХ СЕТЯХ Российский патент 2018 года по МПК H04H60/85 H04N13/00 

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

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

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

Трехмерное (3D) видео предлагает высококачественное восприятие мультимедийной информации с эффектом присутствия, что только в последнее время реализуется в бытовой электронной технике и на мобильных платформах с помощью достижений в области технологии отображения информации, обработки сигналов, технологии передачи сигналов и схемного решения. В настоящее время; данная услуга начинает предоставляться пользователям по месту их проживания по различным каналам, которые включают в себя Blu-Ray Disc™, кабельные и спутниковые каналы и т.д., а также применяется к мобильным сетям посредством использования 3D смартфонов и т.д. Разрабатываются концепты, которые относятся к доставке контента через беспроводные сети.

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

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

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

Фиг. 2A и 2B иллюстрируют адаптацию потокового контента и/или ассоциированного описания сеанса и метаданных файлов в соответствии с различными вариантами осуществления.

Фиг. 3 иллюстрирует установку потокового сеанса в соответствии с вариантом осуществления.

Фиг. 4 показывает форматы упаковки совместимости кадров в соответствии с различными вариантами осуществления.

Фиг. 5 иллюстрирует способ сигнализации 3D видео посредством устройства в соответствии с различными вариантами осуществления.

Фиг. 6 иллюстрирует способ сигнализации 3D видеоконтента в соответствии с различными вариантами осуществления.

Фиг. 7 схематически изображает примерную систему в соответствии с различными вариантами осуществления.

Описание вариантов осуществления

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

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

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

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

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

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

Были продемонстрированы значительные улучшения возможности технологии сжатия видеоинформации с введением стандарта H.264/MPEG-4 Усовершенствованное кодирование видеосигнала (AVC). С разработкой данного стандарта, объединенная команда по видеокодированию ITU-T экспертной группы по видеокодированию (VCEG) и Международная организация по стандартизации (ISO)/Международная электротехническая комиссия (IEC) экспертной группы по движущемуся изображению (MPEG) также стандартизировали расширение AVC, известное, как кодирование многоракурсных изображений (MVC). MVC обеспечивает компактное представление многоракурсных видеоизображений, таких как групповые синхронизированные видеокамеры.

В стереоскопических 3D видеоприложениях, отображаются два изображения. Одно для левого глаза и одно для правого глаза. Существуют различные способы форматирования изображений стереоскопического 3D видеоконтента. В одном варианте осуществления кодирование стереоспаренного 3D видеоизображения может быть частным случаем MVC, где изображение для просмотра левым глазом и изображение для просмотра правым глазом воспроизводятся с помощью MVC. Другие форматы кодирования воспроизведения 3D видеоконтента также возможны. Различные устройства могут иметь разные возможности в отношении декодирования и визуализации этих различных форматов. Варианты осуществления, описанные здесь, обеспечивают различные параметры обмена возможностями устройства, которые могут облегчить доставку и просмотр 3D видеоконтента в коммуникационной сети, такой как, беспроводная сеть, например, сеть наземного радиодоступа в усовершенствованном варианте (EUTRAN).

Фиг. 1 схематически иллюстрирует сетевую среду 100, в соответствии с различными вариантами осуществления. Сетевая среда 100 включает в себя пользовательское устройство (UE) 104, которое также может упоминаться как абонентский терминал или устройство мобильной связи, подключенное к беспроводной сети с радиодоступом (RAN) 108. RAN 108 может включать в себя усовершенствованную базовую станцию (eNB) 112, выполненную с возможностью устанавливать связь с UE 104 посредством беспроводного (ОТА) интерфейса. RAN 108 может быть частью проекта партнерства третьего поколения (3GPP) долгосрочного развития (LTE) развитой сети и может называться как EUTRAN. В других вариантах осуществления могут быть использованы другие технологии сетевого радиодоступа.

UE 104 может осуществлять связь с удаленным медиасервером 116 через RAN 108. В то время как eNB 112 показан, устанавливающий прямую связь с медиасервером, очевидно, что коммуникации могут осуществляться через ряд промежуточных сетевых компонентов, например, коммутаторы, маршрутизаторы, шлюзы и т.п., в различных вариантах осуществления. Например, в некоторых вариантах осуществления RAN 108 может быть соединена с сетью базовых услуг (CSN), что коммуникативно соединяет RAN 108 с более крупной сетью, например, с глобальной сетью, в которой медиасервер 116 может рассматриваться как часть.

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

UE 104 и медиасервер 116 могут иметь ряд компонентов, которые выполнены с возможностью облегчить доступ, хранение, передачу и отображение 3D видеоконтента. Например, UE 104 может включать в себя модуль 120 управления контентом, медиаплеер 124, имеющий потоковое приложение 126, и дисплей 128. Потоковое приложение 126 может иметь достаточную функциональность для приема 3D видеоконтента и ассоциированной информации; для декодирования, распаковки и в ином случае имеет возможность восстановить 3D видеоизображение; и осуществить визуализацию 3D видео на дисплее 128. В различных вариантах осуществления потоковое приложение 126 может относиться к контексту потоковой технологии. Например, в вариантах осуществления, в которых контент передается в потоковом режиме с помощью услуги потоковой передачи с коммутацией пакетов (PSS), потоковое приложение 126 может упоминаться как PSS приложение. Модуль 120 управления контентом может управлять процессом установления связи или иным образом доводить параметры потоковой передачи, включающие в себя, например, функциональные параметры устройства, обеспечивающие прием данных для обеспечения работы медиаплеера 124.

Медиасервер 116 может включать в себя модуль 132 доставки контента, имеющий потоковое приложение 134, модуль 136 управления контентом и модуль 140 хранения контента. Модуль 132 доставки контента может кодировать, упаковывать или иным образом монтировать 3D видеоконтент, сохраненный в модуль 140 хранения контента, для передачи одному или нескольким UE, например UE 104. Модуль 136 управления контентом может управлять процессом установления связи или иным образом доводить параметры потоковой передачи, включающие в себя, например, функциональные параметры устройства и управлять работой модуля 132 доставки контента для обеспечения доставки 3D контента.

В некоторых вариантах осуществления один или более компонентов, которые показаны как часть медиасервера 116, могут быть расположены отдельно от медиасервера 116 и быть коммуникационно соединенными с медиасервером по линии связи. Например, в некоторых вариантах осуществления и модуль 140 хранения контента может быть расположен удаленно от модуля 132 доставки контента и модуля 136 управления контентом.

В некоторых вариантах осуществления модуль 132 доставки контента может доставлять через eNB 112, в одном примере 3D видеоконтент в UE 104 в соответствии со стандартом 3GPP потоковой передачи информации. Например, 3D видеоконтент может быть передан в соответствии с PSS стандартом, например 3GPP TS 26.234 V.11.0.0 (16 марта 2012), стандартом динамической адаптивной потоковой передачи по HTTP (DASH), например 3GPP TS 26.247 V.11.0.0 (16 марта 2012 г.), стандартом мультимедийной широковещательной и многоадресной передачи (MBMS), например TS 26.346 V.11.1.0 (29 июня 2012 года), и/или в соответствии со стандартом, основанным на IMS PSS и MBMS услугах (IMS_PSS_MBMS), например TS 26.237 V.11.0.0 (29 июня 2012 года). Потоковое приложение 126 может быть выполнено с возможностью принимать 3D видеоконтент по любому из многочисленных транспортных протоколов, например транспортный протокол реального времени (RTP), протокол передачи гипертекста (HTTP) и т.д.

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

Модуль 120 управления контентом и модуль 136 управления контентом могут управлять процессом осуществления связи или иным образом передавать информацию о параметрах 3D видеоконтента потокового сеанса. Данный обмен информацией может осуществляться посредством сигнализации на уровне сеансов через RAN 108. В некоторых вариантах осуществления сигнализация на уровне сеансов может включать в себя передачи, относящиеся к информации о функциональной способности устройства, которая включает в себя информацию о функциональной возможности медиаплеера 124 осуществлять декодирование и визуализацию стереоскопической 3D видеоинформации. В различных вариантах осуществления информация о возможностях устройства может дополнительно включать в себя информацию о емкости буфера перед декодером, начальной буферизации, возможности декодера, параметрах дисплея (размер экрана, разрешение, глубина цвета и т.д.), о потоковом способе (транспортный протокол реального времени (RTSP), HTTP и т.д.) поддержки адаптации, о поддержке качества восприятия (QoE), о поддержке создания ответов протокола управления передачей в реальном времени (RTCP), поддержка быстрой коммутации контента, о поддерживаемых RTF профилях, атрибутах протокола описания сеанса (SDP) и т.д.

Во время установки потокового сеанса модуль 136 управления контентом может использовать информацию о функциональных возможностях устройства для управления модулем 132 доставки контента таким образом, чтобы обеспечить UE 104 соответствующим типом мультимедийного контента. Например, медиасервер 116 может определить, какие варианты из нескольких доступных вариантов видеопотока желательны на основе реальных возможностей UE 104 для определения наиболее подходящих потоков для того терминала. Это может обеспечить улучшенную доставку 3D видеоконтента и ассоциированного описания сеанса и метаданных файлов, например SDP файл или описание медиапрезентаций файла (MPD) в UE 104.

Модуль 132 доставки контента может получить доступ к контенту в модуле 140 хранения контента и адаптировать контент и/или ассоциированное описание сеанса и метаданные файлов, например SDP/MPD файлов, в соответствии с оговоренными параметрами сеанса до доставки контента/ассоциированных файлов. Контент, когда доставлен в UE 104, может быть декодирован медиаплеером 124 и визуализирован на дисплее 128.

Процесс адаптации контента и/или ассоциированного описания сеанса и метаданных файлов показан в соответствии с некоторыми конкретными примерами со ссылкой на фиг. 2A и 2B, в то время как процесс установки потокового сеанса показан в соответствии с конкретным примером со ссылкой на фиг. 3.

Фиг. 2A иллюстрирует вариант осуществления потоковой передачи, основанный на DASH, с адаптацией форматов 3D видео в соответствии с некоторыми вариантами осуществления. В частности, фиг. 2A иллюстрирует HTTP сервер 204, устанавливающий связь с DASH абонентом 208, и реализующий вариант осуществления потоковой передачи по запросу, в котором управление потоковой передачи поддерживается абонентом, а не сервером, где абонент загружает контент с сервера посредством последовательных HTTP транзакций запрос-ответ после проверки MPD. В DASH потоковой передаче, MPD метаданные файла предоставляют информацию о структуре и разных версиях представлений медиаконтента, хранящихся в HTTP сервере 204 (в том числе различные скорости передачи, скорости передачи кадров, разрешения, типы кодеков и т.д.). Основываясь на этой информации MPD метаданных, которая описывает отношения сегментов и как они формируют медиапрезентацию, DASH абонент 208 может запросить медиасегменты с помощью HTTP GET или посредством частичных GET способов. HTTP сервер 204 и DASH абонент 208 могут быть аналогичны, и по существу, взаимозаменяемы медиасервером 116 и UE 104, соответственно.

В DASH набор форматов 3D видео и информация, соответствующая контенту, может быть передана DASH абоненту 208 в MPD. В зависимости от профиля функциональных возможностей DASH абонента 208, и его поддерживаемых форматов 3D, HTTP сервер 204 может предложить различный отформатированный контент, например, HTTP - сервер 204 может исключить 3D форматы, которые не поддерживаются DASH абонентом 208 в MPD, и использовать только те, которые поддерживаются DASH абонентом 208. В этом контексте HTTP сервер 204 может предоставить контент, оптимизированный для различных форматов 3D видео, для DASH абонента 208. При этом, HTTP сервер 204 может использовать функциональные возможности устройства, обеспечивающие обменную сигнализацию от DASH абонента 208, описывающая различные поддерживаемые форматы 3D видео. DASH абонент 208 может затем запросить соответствующие версии 3D видеоконтента, поддерживаемые DASH абонентом 208. Кроме того, при извлечении MPD с HTTP, DASH абонент 208 может включить в состав GET запроса 3D видеокодек и информацию о формате, включающую в себя любые временные изменения в форматах 3D видео, основанных на разнице профиля (ProfDiff). В качестве примера, информация об отличии может быть выполнена с возможностью временно изменять один или несколько параметров MPD для представления сеанса контента. Например, информация об отличии может быть выполнена с возможностью изменять MPD до тех пор, пока представление сеанса контента не закончится или последующая информация об отличии (в соответствии с первым переданной информацией об отличии) не будет доведена до сведения HTTP сервера 204. Таким образом, HTTP сервер 204 может доставлять оптимизированный MPD в адрес DASH абонента 208.

Фиг. 2B иллюстрирует вариант осуществления потоковой передачи, основанный на RTSP, с адаптацией форматов 3D видео в соответствии с некоторыми вариантами осуществления. В частности, фиг. 2B иллюстрирует сервер 212 и абонента 216, реализующие способ потоковой передачи, основанный на предложении, в котором управление потоковой передачей и сеансом поддерживается сервером 212, а не абонентом 216. Сервер 212 и абонент 216 могут быть могут быть аналогичны, и по существу, взаимозаменяемы медиасервером 116 и UE 104, соответственно.

Примеры потоковой передачи, основанной на предложении, включают в себя PSS и TMS_PSS_MBMS услуги, основанные на RTSP и протоколе инициации сеанса (SIP), соответственно. В этом контексте сервер 212 принимает набор поддерживаемых 3D видеокодеков и форматов от абонента 216 и адаптирует контент на основе этой информации, например, сервер 212 выбирает наиболее подходящую версию контента среди сохраненных версий контента или динамически преобразует контент на основе поддерживаемых 3D видеоформатов, и передает контент абоненту 216. Метаданные сеанса, переносимые в SDP, могут нести информацию о формате 3D видео для потокового контента.

Фиг. 3 иллюстрирует процесс обнаружения службы с подпиской/уведомлением IMS_PSS_MBMS услуги в соответствии с некоторыми вариантами осуществления. В частности, фиг. 3 иллюстрирует процесс взаимодействия между UE 304, IP-мультимедиа (IM) базовой сети (CN) подсистемы 308 и функцией обнаружения службы (SDF) 312. UE 304 может быть аналогичным и, по существу, взаимозаменяемым UE 104. IM CN подсистема 308 и SDF 312 могут быть частью домена основной сети, который взаимодействует с доменом доступа сети, например, RAN 108.

В IMS PSS MBMS службе UE 304 может послать информацию о функциональных возможностях устройства, например, которые поддерживают форматы 3D видео и кодеков, в сообщении SIP SUBSCRIBE в IM CN подсистему 308 во время обнаружения службы. IM CN подсистема 308 может затем переслать сообщение в SDF 312. SDF 312 определяет информацию надлежащего обнаружения службы, например, в соответствии с возможностями UE 304, как описано в профиле пользователя (обнаружение персонализированной службы). SDF 312 затем может отправить сообщение OK SIP 200 в IM CN подсистему 308, которое ретранслируется на UE 304 для подтверждения инициализации сеанса, на основании отправленной информации о возможностях устройства, которая также включает в себя информацию о поддерживаемых форматах 3видео и кодеков. Затем, SDF 312 может послать сообщение SIP NOTIFY с информацией обнаружения службы в IM CN подсистему 308, которая ретранслирует SIP NOTIFY сообщение обратно в UE 304. UE 304 может затем ответить посредством посылки сообщения OK SIP 200 в IM CN подсистему 308, которая затем передается в SDF 312.

Такая структура позволяет использовать оптимизированную технологию обнаружения служб, поддерживаемая форматы 3D видео в PSS и MBMS службах пользователя, основанных на IMS. Позднее, во время сеанса IMS, UE 304 может также использовать SIP сигнализацию для указания обновления, которая включает в себя любые временные корректировки набора форматов, поддерживаемые 3D видео и кодеков, основанных на ProfDiff (например, если текущая ориентация устройства отличается от ориентации устройства по умолчанию). Это может осуществлено посредством обновления подписки через дополнительное SIP SUBSCRIBE сообщение, которое включает в себя информацию об обновлении информации о формате 3D видео.

Обратимся снова к фиг. 1, в некоторых вариантах осуществления медиасервер 116 может быть соединен с сервером 144 профиля устройства, который имеет информацию о профиле UE 104. Информация о профиле может включать в себя некоторую или всю информацию о возможностях устройства. В таких вариантах осуществления медиасервер 116 может принимать идентификационную информацию от UE 104, и затем извлекать информацию о профиле из сервера 144 профиля устройства. Это может он выполняется как часть сигнализации на уровне сеансов.

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

Потоковое приложение 134 может кодировать 3D видеоконтент для передачи в сетевой среде 100 в соответствии с многочисленными различными типами потоков, с каждым типом потока, имеющий ассоциированный тип кадров. Типы кадров могут включать в себя упаковку кадров, одновременную передачу или 2D плюс вспомогательные типы кадров.

Упаковка кадра может включать в себя форматы упаковки совместимости кадров и формат упаковки с высоким разрешением на ракурс (FRPV). В форматах упаковки совместимости кадров, потоковое приложение 134 может пространственно упаковать составные кадры стереопары в один кадр и кодировать один кадр. Выходные кадры, производимые потоковым приложением 126, содержат составные кадры стереопары. Пространственное разрешение исходных кадров каждого изображения и упакованного одного кадра может быть то же самое. В этом случае потоковое приложение 134 может снизить разрешение двух составных кадров перед операцией упаковки. Форматы упаковки совместимости кадров могут использовать вертикальное перемежение, горизонтальное перемежение, примыкающий формат, формат сверху вниз или шахматный формат, как показано на фигурах с 4а-е, соответственно, и снижение разрешения может быть выполнено соответствующим образом.

В некоторых вариантах осуществления потоковое приложение 134 может указать формат упаковки кадра, который был использован, путем включения в состав битового потока одного или более сообщений о дополнительной расширенной информации (SEI) о порядке упаковки кадра, как указано в Н. 264/AVC стандарте. Потоковое приложение 126 может декодировать кадр, распаковать два составных кадра из выходных кадров декодера, увеличить разрешение кадров, осуществив обратный процесс, выполненный на стороне кодера, при котором было снижено разрешение, и визуализировать составные кадры на дисплее 128.

Формат упаковки FRPV может включать в себя временное перемежение. При временном перемежении, 3D видео может быть закодировано при удвоенной частоте кадров исходного видео каждым родительским и последующими изображениями, составляющие стереопару (левый и правый ракурс). Визуализация стереоскопического видео с временным перемежением обычно может быть проведена при высокой частоте кадров, где активные (затворные) очки используются для сочетания неправильного ракурса в каждом глазу. Это может быть достигнуто путем точной синхронизации между очками и экраном.

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

В вариантах осуществления с использованием типа 2D плюс вспомогательных кадров 2D видеоконтент может быть послан потоковым приложением 134 совместно со вспомогательной информацией, которая может быть использована потоковым приложением 126 для визуализации 3D видео на дисплее 128. Эта вспомогательная информация может быть, например, информацией о таблице глубине/параллакса, которая является 2D таблицей с каждым пикселем, определяющим глубину/параллакс одного или нескольких пикселей в соответствующем 2D видеокадре.

В некоторых вариантах осуществления могут быть использованы другие типы кадров. Например, в некоторых вариантах осуществления потоковое приложение 134 может кодировать стереоскопические ракурсы в поток основного ракурса и поток вспомогательного ракурса, который может быть передан в том же или в различных потоках. В некоторых вариантах осуществления это может упоминаться как стереоскопическое видео, основанное на MVC. Поток вспомогательного ракурса может включать в себя кадры межкадрового предсказания, которые обеспечивают пространственную/временную информацию предсказания. Поток основного ракурса может быть достаточным для одного изображения, например, 2D декодер визуализирует изображение основного ракурса как 2D видео, в то время как поток вспомогательного ракурса может обеспечить 3D декодеры, например потоковое приложение 126, достаточной информацией для визуализации 3D видео. Если медиасервер 116 обладает информацией о функциональных возможностях UEs, то отправка потока информации вспомогательного ракурса в устройство, которое не поддерживает 3D видео или не обладает достаточной скоростью битового потока для поддержки 3D видео, не осуществляется.

В различных вариантах осуществления информация о функциональных возможностях устройства передается из модуля 120 управления контентом и/или сервера 144 профиля устройства в модуль 136 управления контентом, которая может включать в себя атрибут формата 3D, который включает в себя список одного или нескольких форматов, релевантных для потоковой передачи стереоскопического 3D видео по соответствующим протоколам передачи, например RTF или HTTP, поддерживаемые потоковым приложением 126. В некоторых вариантах осуществления атрибут формата 3D может быть форматом упаковки потокового кадра для RTP или HTTP, имеющий целое численное значение "1" для вертикального перемежения, "2" для горизонтального перемежения, "3" для примыкающего, "4" для сверху-вниз, "0" для шахматного поля или "5" для временного перемежения. В некоторых вариантах осуществления те же самые атрибуты формата 3D могут быть использованы для указания форматов упаковки кадров, поддерживаемые в конкретном файле или контейнерном формате. В некоторых вариантах осуществления атрибут формата 3D может включать в себя более обобщенное значение, например "FP", для упаковки кадра.

В некоторых вариантах осуществления атрибут формата 3D может быть другим форматом потоковой передачи, имеющий значение "SC" для одновременной передачи или "2DA" для 2D видеоплюс вспомогательной информации.

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

В некоторых вариантах осуществления в дополнение к обеспечению атрибута типа кадра модуль 120 управления контентом и/или сервер 144 профиля устройства может обеспечить один или более атрибутов типа компонента. Атрибуты типа компонента могут обеспечить дополнительные сведения о конкретных типах видеокомпонентов, которые являются составными элементами стереоскопического 3D видео, поддерживаемые и/или предпочитаемые потоковым приложением 126.

Атрибуты типа компонента могут иметь значение "С" для указания потока центрального ракурса, "CD" для указания потока центрального ракурса и карты глубины, "CP" для указания потока центрального ракурса и карты параллакса, "D" для указания карты глубины, "Р" для указания карты параллакса, "L" для указания потока для левого ракурса, "LD" для указания потока левого ракурса и карты глубины, "LIL" для индикации видеокадров, которые включают в себя чередующиеся строки развертки от левого и правого ракурсов, "LP" для индикации потока левого ракурса и карты параллакса, "R" для указания потока правого ракурса, "Seq" для указания последовательных кадров (например, видеопоток, который включает в себя чередующиеся кадры из потоков изображения левого и правого ракурсов - дополнительная сигнализация, например AVC SEI сообщения, могут быть необходимы, чтобы сигнализировать о том, какие кадры содержат изображения левого и правого ракурсов), "SbS" для указания смежной компоновки и "ТаВ" для индикации схемы сверху вниз.

Каждый атрибут типа формата может быть ассоциирован с соответствующим набором атрибутов типа компонента. Например, если тип формата является SC, то ассоциированный тип компонента может быть L или R для указания левого и правого ракурса, соответственно.

Функциональная возможность устройства осуществить обменную сигнализацию в соответствии со спецификацией PSS 3GPP TS 24.234, позволяет серверам предоставлять широкому спектру устройств контент, подходящий для конкретного устройства. В целях улучшения доставки стереоскопического 3D видеоконтента в абонентский терминал настоящее изобретения описывает новый набор атрибутов, которые могут быть включены в состав словаря PSS для обмена сигнализацией о возможностях устройства. Эти предлагаемые атрибуты могут описывать возможности абонентского терминала относительно декодирования и визуализации 3D видео, в том числе какой формат упаковки кадров 3D видео поддерживает абонент. Это может, например, позволять серверу и сети обеспечить оптимизированную RTSP SDP или DASH MPD абонентскому терминалу, а также выполнять соответствующую перекодировку и преобразование 3D формата, чтобы соответствовать возможностям абонентского устройства передаваемого 3D видеоконтента.

Способность устройства обеспечивать обменную сигнализацию, поддерживаемую 3D видеокодеков и форматов, может быть обеспечена в 3GPP TS 26.234 использованием трех новых атрибутов в PSS словаре: (1) для компонента Streaming применяется два атрибута, указывающие на список поддерживаемых форматов упаковки кадров, имеющие отношение к потоковой передачи стереоскопического 3D видео по RTP и HTTP, соответственно, и (2) для ThreeGPFileFormat компонента применяется один атрибут, указывающий список поддерживаемых форматов упаковки кадров, имеющие отношение к стереоскопическому 3D-видео, которые могут быть включены в состав 3GPP формата файла (3GPP) файл, который является мультимедийным контейнерным форматом, обычно используемым для мультимедийных услуг на 3GPP основе. Подробное описание определений атрибутов представлено ниже в соответствии с некоторыми вариантами осуществления.

Имя атрибута: StreamingFramePackingFormatsRTP

Определение атрибута: список поддерживаемых форматов упаковки кадров, релевантных для потокового стереоскопического 3D видео по RTP, поддерживаемых приложением PSS. Форматы упаковки кадров в пределах объема для стереоскопического 3D видео включают в себя:

Форматы упаковки совместимых кадров: 1 = Вертикальное перемежение, 2 = горизонтальное перемежение, 3 = примыкающее, 4 = сверху-вниз, 0 = шахматного поля

Форматы упаковки с высоким разрешением на ракурс: 5 = Временное перемежение

Компонент: Streaming

Тип: Литерал (Bag)

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

Правило резолюции: Присоединение

ПРИМЕР

Имя атрибута: StreamingFramePackingFormatsHTTP

Определение атрибута: список поддерживаемых форматов упаковки кадров, релевантных для потокового стереоскопического 3D видео по HTTP, поддерживаемых приложением PSS. Форматы упаковки кадров в пределах объема для стереоскопического 3D видео включают в себя:

Форматы упаковки совместимых кадров: 1 = Вертикальное перемежение, 2 = горизонтальное перемежение, 3 = примыкающее, 4 = сверху-вниз, 0 = шахматное поле

Форматы упаковки с высоким разрешением на ракурс: 5 = Временное перемежение

Компонент: Streaming

Тип: Литерал (Bag)

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

Правило резолюции: присоединение

ПРИМЕР

Имя атрибута: ThreeGPFrameFormats

Определение атрибута: список поддерживаемых форматов упаковки кадров, релевантных для потокового стереоскопического 3D видео, которые могут быть включены в состав 3GP файла и обрабатываемые PSS приложением.

Компонент: ThreeGPFileFormat

Тип: Литерал (Bag)

Допустимые значения: список целочисленных значений, соответствующие поддерживаемым форматам упаковки кадров. Значения 3 или 4 соответствуют форматам упаковки кадров «примыкающее» и «сверху-вниз», соответственно.

Правило резолюции: присоединение

ПРИМЕР:

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

Элемент FramePacking может включать в себя атрибут an@schemeIdUri, который включает в себя универсальный индикатор ресурса (UPI) для определения применяемой конфигурации упаковки кадров. В некоторых вариантах осуществления FramePacking элемент может дополнительно включать в себя атрибут an@value для обеспечения значения для элемента дескриптора.

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

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

Для Наборов адаптации или Представления, которые содержат видеокомпонент, который соответствует стандарту ISO/IEC Информационные технологии - Кодирование аудиовизуальных объектов - часть 10: Усовершенствованное кодирование видеосигнала (ISO/IEC 14496-10: 2012), универсальный индикатор ресурсов для FramePacking@ schemeIdUri может быть urn:mpeg:dash:14496:10:frame_packing_arrangement_type:2011, который может быть определен для указания компоновки упаковки кадров, как это определено в таблице D-8 ISO/IEC 14496-10: 2012 ("Definition frame_packing_arrangement_type"), который должен содержаться в элементе FramePacking. @value, может быть столбцом "Value", как указано в таблице D - 8 в ISO/IEC 14496-10: 2012 и может быть истолковано в соответствии с колонкой "Interpretation" в той же таблице.

Фиг. 5 иллюстрирует способ 500 сигнализации 3D видео посредством использования функциональных возможностей устройства в соответствии с некоторыми вариантами осуществления. Способ 500 может быть выполнен с помощью компонентов UE, например, UE 104. В некоторых вариантах осуществления UE может включать в себя и/или иметь доступ к одному или более машиночитаемых носителей, имеющие инструкции, сохраненные на нем, которые, когда выполняются, вызывают UE или компоненты выполнить способ 500.

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

На этапе 508 UE может предоставить информацию о возможностях устройства на медиасервер 116 или сервер 144 профиля устройства, которая включает в себя информацию о возможности осуществить декодирование и визуализацию стереоскопического 3D видео на UE. Как описано выше, информация о функциональных возможностях устройства может включать в себя один или более атрибутов типа формата, которые представляют список типов кадров, поддерживаемые потоковым приложением UE. В некоторых вариантах осуществления информация о функциональных возможностях устройства может быть обеспечена до или после запроса на этапе 512.

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

На этапе 512 UE может запросить 3D видеоконтент. В некоторых вариантах осуществления запрос может быть сделан в соответствии с действующими потоковыми/транспортными протоколами, например, HTTP, RTP, RTSP, DASH, MBMS, PSS, IMS PSS MBMS и т.д. Запрос может быть направлен на медиасервер и может включать в себя унифицированный указатель ресурсов (URL) или некоторый другой индикатор запрошенного контента или его части. В некоторых вариантах осуществления временная корректировка информации о возможностях устройства (например, с помощью сигнализации ProfDiff) может быть также предоставлена вместе с запросом на этапе 508. Соответственно, UE может дополнить информацию о профиле, полученную из сервера профиля устройства дополнительными атрибутами, или игнорировать атрибуты уже определенные в его профиле возможностей устройства, основываясь на ProfDiff сигнализации. В одном примере такая временная корректировка может быть вызвана информацией о предпочтениях пользователя, например, если пользователь в течение определенного сеанса хотел принять только двумерный (2D) видеоконтент, даже при том, что терминал способен осуществить визуализацию 3D видео.

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

Фиг. 6 иллюстрирует способ 600 сигнализации 3D видеоконтента в соответствии с некоторыми вариантами осуществления. Способ 600 может быть выполнен с помощью компонентов медиасервера, например, медиасервера 116. В некоторых вариантах осуществления медиасервер может включать в себя и/или иметь доступ к одному или более машиночитаемым носителям, имеющие инструкции, сохраненные на нем, которые, когда выполняются, вызывают медиасервер или его компоненты выполнить способ 600.

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

На этапе 608 медиасервер может принять запрос на 3D видеоконтент. В некоторых вариантах осуществления запрос может быть осуществлен в соответствии с действующим потоковым/транспортным протоколом, например, HTTP, RTF, RTSP, DASH, MBMS, PSS, IMS_PSS_MBMS и т.д. Запрос может быть послан UE и может включать в себя универсальный локатор ресурса (URL) или некоторый другой индикатор запрошенного контента или его части. В некоторых вариантах осуществления запрос, принятый на этапе 608, может осуществляться одновременно с определением информации о возможностях устройства на этапе 604, перед определением или после определения. В некоторых вариантах осуществления информация о временной корректировке информации о возможностях устройства (например, с помощью сигнализации ProfDiff) также могут быть принята вместе с запросом на этапе 608. Соответственно, медиасервер может дополнительно принимать информацию о профиле, полученную из сервера профиля устройства, с дополнительными атрибутами или может игнорировать атрибуты уже определенные в профиле возможностей устройства, на основании ProfDiff сигнализации.

На этапе 612 медиасервер может генерировать описание сеанса и/или метаданные файлов для установки сеанса потоковой передачи, например, файл SDP или описание медиапрезентаций (MPD) на основании информации о возможностях устройства относительно стереоскопического 3D декодирования видео и возможности визуализации медиаплеером на UE.

На этапе 616 медиасервер может кодировать 3D видеоконтент в формате, указанный в информации о функциональных возможностях устройства в соответствии с поддерживаемым UE. 3D видеоконтент может затем передаваться на мобильное устройство.

Описанные здесь компоненты, например UE 104, медиасервер 116 и/или сервер 144 профиля устройства, могут быть реализованы в системе, которая использует любые подходящие аппаратные средства и/или программное обеспечение. Фиг. 7 иллюстрирует для одного из вариантов осуществления пример системы 700, включающей в себя процессор(ы) 704, логическую систему 708 управления, соединенную по меньшей мере с одним процессором (ми) 704, системную память 712, соединенную с логической системой 708 управления, энергонезависимую память (NVM)/запоминающее устройство 716, соединенную с логической системой 708 управления, сетевой интерфейс 720, соединенный с логической системой 708 управления и устройства 732 ввода/вывода (I/O), соединенные с логической системой 708 управления.

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

Логическая система 708 управления для одного варианта осуществления может включать в себя любые подходящие контроллеры интерфейса для обеспечения любого подходящего интерфейса по меньшей мере для одного из процессора(ов) 704 и/или для любого подходящего устройства или компонента для обеспечения взаимодействия с логической системой 708 управления.

Логическая система 708 управления для одного варианта осуществления может включать в себя один или более контроллер(ов) памяти для обеспечения интерфейса к системной памяти 712. Системная память 712 может быть использована для загрузки и хранения данных и/или инструкций, например логики 724 программы. Системная память 712 для одного варианта осуществления может включать в себя любую подходящую энергозависимую память, такую как динамическую оперативную память (DRAM), например.

NVM/запоминающее устройство 716 может включать в себя один или более материальный машиночитаемый носитель, используемый для хранения данных и/или инструкции, например логику 724 программы. NVM/запоминающее устройство 716 может включать в себя любую подходящую энергонезависимую память, такую как флэш-память, например, и/или может включать в себя любое подходящее энергонезависимое запоминающее устройство (а), например, один или несколько драйверов жестких дисков (HDD (s)), один или несколько драйверов компакт-дисков (CD) и/или одни или более драйверов универсального цифрового диска (DVD), например.

NVM/запоминающее устройство 716 может включать в себя физическую часть устройства для хранения ресурсов, на которой установлена система 700 или может быть доступна, но не обязательно быть частью устройства. Например, NVM/запоминающее устройство 716 может быть доступно по сети через сетевой интерфейс 720 и/или посредством устройств 732 ввода/вывода (I/O).

Логика 724 программы, при выполнении по меньшей мере одним из процессоров 704, может вызвать систему выполнить действия, описанные в данном документе по отношению к UE 104, медиасерверу 116 и/или серверу 144 профиля устройства. Логика 724 программы может быть установлена дополнительно/альтернативно на других компонентах системы, например, логической системе 708 управления и может включать в себя любое сочетание аппаратных средств, программного обеспечения или микропрограммного компонента.

Сетевой интерфейс 720 может иметь трансивер 722 для обеспечения интерфейса радиосвязи для системы 700 для осуществления связи по одной или более сети (ей) и/или с любым другим подходящим устройством. В различных вариантах осуществления трансивер 722 может быть интегрирован с другими компонентами системы 700, например, трансивер 722 может включать в себя процессор процессора(ов) 704, память системной памяти 712 и NVM/запоминающее устройство 716. Сетевой интерфейс 720 может включать в себя любое подходящее аппаратное оборудование и/или программное обеспечение. Сетевой интерфейс 720 может включать в себя множество антенн для обеспечения радио интерфейса многоканального входа, многоканального выхода. Сетевой интерфейс 720 для одного варианта осуществления может включать в себя, например, проводной сетевой адаптер, адаптер беспроводной сети, телефонный модем и/или беспроводной модем.

В одном варианте осуществления по меньшей мере один процессор 704 может использоваться вместе с логической схемой для одного или нескольких контроллеров логической системы 708 управления. Для одного варианта осуществления по меньшей мере один процессор 704 может быть использован вместе с логической схемой для одного или нескольких контроллеров логической системы 708 управления для формирования системы в пакете (SiP). В одном варианте осуществления по меньшей мере один процессор(ы) 704 может быть интегрирован на одном кристалле с логической схемой для одного или нескольких контроллера(ов) логической системы 708 управления. В одном варианте осуществления по меньшей мере один процессор(ы) 704 может быть интегрирован на одном кристалле с логической схемой для одного или нескольких контроллеров логической системы 708 управления для формирования системы на кристалле (SoC).

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

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

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

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

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

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

Группа изобретений относится к сигнализации 3D информации в сетях связи. Технический результат – улучшение доставки 3D видеоконтента. Для этого предложены носители для адаптации описания медиапрезентации для пользовательского устройства (UE), при этом носители побуждают устройство: получить профиль Партнерство (3GP) третьего поколения - Динамическая адаптивная потоковая передача по транспортному протоколу (DASH) гипертекста, 3GP-DASH профиль указывает одно или более ограничений, связанных со стереоскопическим трехмерным (3D) видеоконтентом, поддерживаемым в UE; идентифицировать первую медиапрезентацию, которая соответствует полученному 3GP-DASH профилю; получить описание (MPD) медиапрезентации, которое содержит информацию, связанную с идентифицированной первой медиапрезентацией, и информацию, связанную со второй медиапрезентацией, которая не соответствует полученному 3GP-DASH профилю; модифицировать, на основе полученного 3GP-DASH профиля, MPD так, чтобы оно не содержало информации, связанной со второй медиапрезентацией, которая не соответствует полученному 3GP-DASH профилю; передать модифицированное MPD на UE. 5 н. и 23 з.п. ф-лы, 8 ил.

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

получить профиль Партнерство (3GP) третьего поколения - Динамическая адаптивная потоковая передача по транспортному протоколу (DASH) гипертекста, связанный с пользовательским устройством (UE) сети беспроводной связи, 3GP-DASH профиль указывает одно или более ограничений, связанных со стереоскопическим трехмерным (3-D) видеоконтентом, поддерживаемым в UE;

идентифицировать первую медиапрезентацию, которая соответствует полученному 3GP-DASH профилю и которая доступна для передачи на UE;

получить описание (MPD) медиапрезентации, которое содержит информацию, связанную с идентифицированной первой медиапрезентацией, и информацию, связанную со второй медиапрезентацией, которая не соответствует полученному 3GP-DASH профилю;

модифицировать, на основе полученного 3GP-DASH профиля, MPD так, чтобы оно не содержало информации, связанной со второй медиапрезентацией, которая не соответствует полученному 3GP-DASH профилю; передать модифицированное MPD на UE.

2. Один или более носителей информации по п. 1, в которых 3GP-DASH профиль представляет собой профиль многоракурсного стереоскопического 3D видео для указания того, что UE поддерживает многоракурсный стереоскопический 3D видеоконтент, содержащий основной ракурс и неосновной ракурс, которые чередуются по времени.

3. Один или более носителей информации по п. 1, в которых 3GP-DASH профиль представляет собой профиль стереоскопического 3D видео с упакованными кадрами для указания того, что UE поддерживает стереоскопический 3D видеоконтент с упакованными кадрами, содержащий основной ракурс и неосновной ракурс, которые упакованы в одном кадре.

4. Один или более носителей информации по п. 3, в которых инструкции, при их исполнении, дополнительно побуждают устройство поместить элемент упаковки кадра в модифицированное MPD для указания типа формата упаковки кадров, используемого для DASH доставки медиапрезентаций.

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

6. Один или более носителей информации по п. 1, в которых модифицированное MPD содержит один или более атрибутов, связанных с отдельными DASH представлениями первой медиапрезентации, при этом отдельные DASH представления содержат DASH представления, связанные с различными временными периодами первой медиапрезентации.

7. Один или более носителей информации по п. 6, в которых модифицированное MPD содержит атрибуты, связанные с DASH представлениями первой медиапрезентации, которые соответствуют 3GP-DASH профилю, и не содержит атрибутов, связанных с одним или более представлениями первой медиапрезентации, которые не соответствуют 3GP-DASH профилю.

8. Один или более носителей информации по любому из пп. 1 - 7, в которых инструкции, при исполнении, побуждают устройство:

получить GET запрос или частичный GET запрос транспортного протокола (HTTP) гипертекста, переданный UE, для DASH представления, связанного с первой медиапрезентацией; и

направить на UE, в ответ на GET запрос или частичный GET запрос HTTP, DASH презентацию.

9. Один или более носителей информации по п. 8, в которых DASH представление направляют на UE с помощью мультимедийной широковещательной/многоадресной услуги (MBMS).

10. Один или более носителей информации по любому из пп. 1-7, в которых 3GP-DASH профиль получают от сервера профиля устройства.

11. Устройство, используемое пользовательским устройством (UE) для адаптации описания медиапрезентации для пользовательского устройства, содержащее:

модуль управления контентом с целью:

передать с помощью сети беспроводной связи технологии «Долгосрочное развитие» (LTE) идентификатор профиля Партнерство третьего поколения (3GP) - Динамическая адаптивная потоковая передача по

транспортному протоколу (DASH) гипертекста, связанного с UE, 3GP-DASH профиль указывает одно или более ограничений, связанных со стереоскопическим трехмерным (3-D) видеоконтентом, поддерживаемым в UE;

принять описание (MPD) медиапрезентации, которое содержит информацию, связанную с первой медиапрезентацией, которая соответствует 3GP-DASH профилю и не содержит информацию, связанную с одной или более другими медиапрезентациями, которые не соответствуют 3GP-DASH профилю; и

передать GET запрос или частичный GET запрос транспортного протокола (HTTP) гипертекста для DASH представления, связанного с первой медиапрезентацией; и

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

12. Устройство по п. 11, в котором 3GP-DASH профиль представляет собой профиль многоракурсного стереоскопического 3D видео для указания того, что UE поддерживает многоракурсный стереоскопический 3D видеоконтент, содержащий основной ракурс и неосновной ракурс, которые чередуются по времени.

13. Устройство по п. 11, в котором 3GP-DASH профиль представляет собой профиль стереоскопического 3D видео с упакованными кадрами для указания того, что UE поддерживает стереоскопический 3D видеоконтент с упакованными кадрами, содержащий основной ракурс и неосновной ракурс, которые упакованы в одном кадре.

14. Устройство по п. 13, в котором MPD содержит элемент упаковки кадров для указания типа формата упаковки кадров, используемого для первой медиапрезентации.

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

16. Устройство по п. 11, в котором MPD содержит один или более атрибутов, связанных с отдельными DASH представлениями первой медиапрезентации, при этом отдельные представления содержат представления, связанные с различными временными периодами медиапрезентации.

17. Устройство по п. 11, в котором в UE должны принять DASH представление с помощью мультимедийной широковещательной/многоадресной услуги (MBMS).

18. Устройство, содержащее устройство по любому из пп. 11-17, и дополнительно содержащее автостереоскопический дисплей, соединенный с медиаплеером для показа воспроизводимого DASH представления.

19. Медиасервер для адаптации описания медиапрезентации для пользовательского устройства, содержащий:

схему управления контентом с целью:

получить профиль Партнерство третьего поколения (3GP) - Динамическая адаптивная потоковая передача по транспортному протоколу (DASH) гипертекста, связанный с пользовательским устройством (UE), при этом 3GP-DASH профиль представляет собой профиль многоракурсного стереоскопического трехмерного (3D) видео для указания того, что UE поддерживает многоракурсный стереоскопический 3D видеоконтент, содержащий основной ракурс и неосновной ракурс, которые чередуются по времени, или профиль стереоскопического 3D видео с упакованными кадрами для указания того, что UE поддерживает стереоскопический 3D видеоконтент с упакованными кадрами, содержащий основной ракурс и неосновной ракурс, которые упакованы в одном кадре;

генерировать, на основе полученного 3GP-DASH профиля, описание (MPD) медиапрезентации, которое содержит один или более атрибутов, связанных с первым DASH представлением медиапрезентации, которая соответствует 3GP-DASH профилю, и которое не содержит атрибутов, связанных со вторым DASH представлением медиапрезентации, которая не соответствует 3GP-DASH профилю; и

передать сгенерированное MPD на UE; и

схему доставки контента, соединенную со схемой управления контентом и приспособленную для доставки на UE 3D видеоконтента, связанного с первым DASH представлением.

20. Медиасервер по п. 19, в котором MPD содержит элемент упаковки кадров для указания типа формата упаковки кадров, используемого для первого DASH представления.

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

22. Медиасервер по любому из пп. 19-21, в котором в схеме управления контентом должны принимать от UE идентификатор и в котором в схеме управления контентом должны получать 3GP-DASH профиль от сервера профиля устройства на основе упомянутого идентификатора.

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

передать на UE с помощью сети беспроводной связи технологии «Долгосрочное развитие» (LTE) идентификатор профиля Партнерство третьего поколения (3GP) - Динамическая адаптивная потоковая передача по транспортному протоколу (DASH) гипертекста, связанного с UE, при этом 3GP-DASH профиль указывает одно или более ограничений, связанных со стереоскопическим трехмерным (3-D) видеоконтентом, поддерживаемым в UE;

принять описание (MPD) медиапрезентации, которое содержит один или более атрибутов, связанных с первым DASH представлением медиапрезентации, которое соответствует 3GP-DASH профилю и MPD не содержит один или более атрибутов, связанных со вторым отдельным DASH представлением медиапрезентации, которое не соответствуют 3GP-DASH профилю;

передать GET запрос или частичный GET запрос транспортного протокола (HTTP) гипертекста для DASH представления, связанного с первой медиапрезентацией;

получить DASH представление; и

воспроизвести полученное DASH представление.

24. Один или более носителей информации по п. 23, в которых 3GP-DASH профиль представляет собой профиль многоракурсного стереоскопического 3D видео для указания того, что UE поддерживает многоракурсный стереоскопический 3D видеоконтент, содержащий основной ракурс и неосновной ракурс, которые чередуются по времени.

25. Один или более носителей информации по п. 23, в которых 3GP-DASH профиль представляет собой профиль стереоскопического 3D видео с упакованными кадрами для указания того, что UE поддерживает стереоскопический 3D видеоконтент с упакованными кадрами, содержащий основной ракурс и неосновной ракурс, которые упакованы в одном кадре.

26. Один или более носителей информации по п. 25, в которых MPD содержит элемент упаковки кадров для указания типа формата упаковки кадров, используемого для медиапрезентации.

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

28. Один или более носителей информации по любому из пп. 23-27, в которых MPD не содержит информации, связанной с одной или более медиапрезентациями, которые не соответствуют 3GP-DASH профилю.