Сигнализация трехмерной видеоинформации в коммуникационных сетях

Сигнализация трехмерной видеоинформации в коммуникационных сетях

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1 схематически иллюстрирует сетевую среду 100, в соответствии с различными вариантами осуществления. Сетевая среда 100 включает в себя пользовательское устройство (UE) 104, которое также может упоминаться как абонентский терминал или устройство мобильной связи, подключенное к беспроводной сети с радиодоступом (RAN) 108. RAN 108 может включать в себя усовершенствованную базовую станцию (eNB) 112, выполненную с возможностью устанавливать связь с НЕ 104 посредством беспроводного (OTA) интерфейса. 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 могут иметь ряд компонентов, которые выполнены с возможностью облегчить доступ, хранение, передачу и отображение 3-D видеоконтента. Например, UE 104 может включать в себя модуль 120 управления контентом, медиаплеер 124, имеющий потоковое приложение 126, и дисплей 128. Потоковое приложение 126 может иметь достаточную функциональность для приема 3-D видеоконтента и ассоциированной информации; для декодирования, распаковки и в ином случае имеет возможность восстановить 3-D видеоизображение; и осуществить визуализацию 3-D видео на дисплее 128. В различных вариантах осуществления, потоковое приложение 126 может относиться к контексту потоковой технологии. Например, в вариантах осуществления, в которых контент передается в потоковом режиме с помощью услуги потоковой передачи с коммутацией пакетов (PSS), потоковое приложение 126 может упоминаться как PSS приложение. Модуль 120 управления контентом может управлять процессом установления связи или иным образом доводить параметры потоковой передачи, включающие в себя, например, функциональные параметры устройства, обеспечивающие прием данных для обеспечения работы медиаплеера 124.

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

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

В некоторых вариантах осуществления модуль 132 доставки контента может доставлять через eNB 112, в одном примере, 3-D видеоконтент в UE 104 в соответствии со стандартом 3GPP потоковой передачи информации. Например, 3-D видеоконтент может быть передан в соответствии с 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 может быть выполнено с возможностью принимать 3-D видеоконтент по любому из многочисленных транспортных протоколов, например транспортный протокол реального времени (RTP), протокол передачи гипертекста (HTTP) и т.д.

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

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

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

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

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

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

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

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

Фиг. 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 может послать информацию о функциональных возможностях устройства, например, которые поддерживают форматы 3-D видео и кодеков, в сообщении 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-D видео и кодеков. Затем, SDF 312 может послать сообщение SIP NOTIFY с информацией обнаружения службы в IM CN подсистему 308, которая ретранслирует SIP NOTIFY сообщение обратно в UE 304. UE 304 может затем ответить посредством посылки сообщения OK SIP 200 в IM CN подсистему 308, которая затем передается в SDF 312.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компонент: Streaming

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

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

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

ПРИМЕР <StreaxnmgJFramePackmgJFormatsRTP>

<rdf: Bag>

<rdf: li>3</rdf: li>

<rdf: li>4</rdf: li>

</rdf: Bag>

</StreammgFramePackingFormatsRTP>

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

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

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

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

Компонент: Streaming

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

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

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

ПРИМЕР <StreaxnmgJFramePackmgJFormatsHTTP>

<rdf: Bag>

<rdf: li>3</rdf: li>

<rdf: li>4</rdf: li>

</rdf: Bag>

</StreamingFramePackingFormatsHTTP>

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

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

Компонент: ThreeGPFileFormat

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

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

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

ПРИМЕР

<TbereeGPFramePackingFormats>

<rdf: Bag>

<rdf: li>3</rdf: li>

<rdf: li>4</rdf: li>

</rdf: Bag>

</ThereeGPFramePackingFormats>

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

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

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

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

Для Наборов адаптации или Представления, которые содержат видеокомпонент, который соответствует стандарту ISO/IEC Информационные технологии - Кодирование аудиовизуальных объ