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

Группа изобретений относится к сигнализации трехмерной видеоинформации в коммуникационных сетях. Технический результат заключается в улучшении доставки 3-D видеоконтента в терминал пользователя за счет проверки совместимости форматов 3-D видеоконтента с терминалом пользователя. Для этого предложены средства, выполненные с возможностью получать запрос о возможностях пользовательского устройства обрабатывать 3-D видеоконтент и список форматов, поддерживаемых устройством, релевантных для передачи 3-D видео по транспортному протоколу на пользовательском устройстве, в котором транспортный протокол является транспортным протоколом реального времени (RTP) или протоколом передачи гипертекста (HTTP), при этом список форматов включает индикацию вертикального перемежения, горизонтального перемежения, примыкающего типа формата упаковки совместимости кадров, типа сверху-вниз формата упаковки совместимости кадров, типа шахматного поля формата упаковки совместимости кадров или временного перемежения формата упаковки с высоким разрешением на ракурс. 5 н. и 22 з.п. ф-лы, 8 ил.

 

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

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

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

Трехмерное (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 Информационные технологии - Кодирование аудиовизуальных объектов - часть 10: Усовершенствованное кодирование видеосигнала (ISO/IEC 14496-10: 2012), универсальный индикатор ресурсов для FramePacking@schemeldUri может быть 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 сигнализации 3-D видео посредством использования функциональных возможностей устройства в соответствии с некоторыми вариантами осуществления. Способ 500 может быть выполнен с помощью компонентов UE, например UE 104. В некоторых вариантах осуществления, UE может включать в себя и/или иметь доступ к одному или более машиночитаемым носителям, имеющим инструкции, сохраненные на нем, которые, когда выполняются, вызывают UE или компоненты выполнить способ 500.

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

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

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

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

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

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

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

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

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

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

Описанные здесь компоненты, например 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 может включать в себя любую подходящую энергонезависимую память, такую как флэш-память, например, и/или может включать в себя любое подходящее энергонезависимое запоминающее устройство (a), например, один или несколько драйверов жестких дисков (HDD (s)), один или несколько драйверов компакт-дисков (CD) и/или одни или более драйверов универсального цифрового диска (DVD), например.

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

Логика 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.

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

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

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

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

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

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

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

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

4. Один или более компьютерно-считываемых носителей информации по п.1, в которых транспортный протокол содержит RTP.

5. Один или более компьютерно-считываемых носителей информации по п. 1, в которых транспортный протокол содержит HTTP.

6. Один или более компьютерно-считываемых носителей информации по п.1, в которых описание сеанса или метаданные файла является протоколом (SDP) описания сеанса файла транспортного протокола реального времени (RTSP) или описанием медиапрезентаций (MPD) файла динамической адаптивной потоковой передачи по транспортному протоколу гипертекста (DASH).

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

8. Один или более компьютерно-считываемых носителей информации, содержащих инструкции, которые при выполнении побуждают компьютер:
получить из сервера профиля устройства атрибут формата упаковки кадра потокового видео, который включает в себя список форматов упаковки кадров, поддерживаемые абонентским терминалом, релевантные для стереоскопического 3-D видео, которые могут быть включены в состав файла формата проекта партнерства третьего поколения (3GPP) и обработаны с помощью приложения услуги потоковой передачи с коммутацией пакетов (PSS) на пользовательском устройстве; и передать контент на пользовательское устройство на основании атрибута формата упаковки кадра потокового видео, в котором список по меньшей мере одного формата упаковки кадров включает в себя индикацию вертикального перемежения формата упаковки совместимости кадров, горизонтального перемежения формата упаковки совместимости кадров, примыкающего типа формата упаковки совместимости кадров, типа сверху-вниз формата упаковки совместимости кадров, в виде шахматного поля формата упаковки совместимости кадров или временного перемежения формата упаковки с высоким разрешением на ракурс.

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

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

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

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

13. Устройство по п. 12, в котором информация о возможностях устройства имеет атрибут формата 3-D, который включает в себя тип формата, поддерживаемый схемой медиаплеера.

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

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

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

17. Устройство по п. 12, в котором модуль управления контентом переназначен для передачи информации о возможностях устройства в сообщении SUBSCRIBE протокола инициации сеанса (SIP) в мультимедийную подсистему базовой сети протокола сети интернет во время выполнения процедуры обнаружения службы.

18. Устройство по п. 17, в котором после выполнения процедуры обнаружения службы модуль управления контентом использует SIP сигнализацию для обновления набора поддерживаемых 3-D видеокодеков и форматов.

19. Устройство по п. 12, в котором медиаплеер дополнительно выполнен с возможностью:
принимать поток, включающий в себя запрашиваемый стереоскопический 3-D видеоконтент, в котором медиаплеер дополнительно выполнен с возможностью принимать поток в соответствии с протоколом (DASH) динамической адаптивной потоковой передачи по транспортному протоколу гипертекста, протоколом (PSS) потоковой передачи с коммутацией пакетов или интернет протоколу мультимедийной подсистемы (IMS) на основе PSS и мультимедийного широковещательного/многоадресного протокола (MBMS) услуг.

20. Устройство по п. 19, в котором медиаплеер дополнительно выполнен с возможностью принимать файл протокола (SDP) описания сеанса или метаданные файла описания (MPD) медиапрезентаций, ассоциированные с потоком.

21. Мобильное устройство, содержащее устройство по п. 12.

22. Мобильное устройство по п. 21, дополнительно содержащее:
автостереоскопический дисплей, предназначенный для визуализации 3-D видеоконтента под управлением медиаплеера.

23. Один или более компьютерно-считываемых носителей информации, содержащих инструкции, которые при выполнении побуждают компьютер:
получать из сервера профиля устройства запрос на информацию о возможности пользовательского устройства обрабатывать 3-D видеоконтент; и обеспечивать атрибут формата упаковки кадра потокового видео, который включает в себя список форматов упаковки кадров, поддерживаемые пользовательским устройством, релевантные для потоковой передачи стереоскопического 3-D видео по транспортному протоколу, поддерживаемого приложением услуги потоковой передачи с коммутацией пакетов (PSS) на пользовательском устройстве, в котором, транспортный протокол является транспортным протоколом реального времени (RTP) или протоколом передачи гипертекста (HTTP), в
котором, список форматов упаковки кадров включает в себя индикацию вертикального перемежения формата упаковки совместимости кадров, горизонтального перемежения формата упаковки совместимости кадров, примыкающего типа формата упаковки совместимости кадров, типа сверху-вниз формата упаковки совместимости кадров, типа шахматного поля формата упаковки совместимости кадров или временного перемежения формата упаковки с высоким разрешением на ракурс.

24. Один или более компьютерно-считываемых носителей информации по п. 23, в которых транспортный протокол содержит RTP.

25. Один или более компьютерно-считываемых носителей информации по п. 23, в которых транспортный протокол содержит HTTP.

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

27. Один или более компьютерно-считываемых носителей информации по п. 26, в которых список из одного или более целых чисел включает в себя форматы упаковки кадров, который включает в себя 1, соответствующее вертикальному перемежению формата упаковки совместимости кадров, 2, соответствующее горизонтальному перемежению формата упаковки совместимости кадров, 3, соответствующее примыкающему типу формата упаковки совместимости кадров, 4, соответствующее типу сверху-вниз формата упаковки совместимости кадров, 0, соответствующее типу шахматного поля формата упаковки совместимости кадров, или 5, соответствующее временному перемежению формата упаковки с высоким разрешением на ракурс.