Descripción

SEÑALIZACIÓN DE ALTO NIVEL PARA DATOS DE VIDEO DE OJO DE PEZ
[0001] Esta solicitud reivindica el beneficio de la Solicitud Provisoria de los Estados

Unidos No. 62/511.189, presentada el 25 de mayo de 2017, cuyo contenido completo
se incorpora en la presente como referencia.
CAMPO TÉCNICO
[0002] Esta divulgación se refiere al almacenamiento y transporte de datos de video
codificados.
ANTECEDENTES
[0003] Se pueden incorporar capacidades de video digitales en una amplia gama de
dispositivos, incluyendo televisores digitales, sistemas de transmisión directa digitales,
sistemas de transmisión inalámbricos, asistentes digitales personales (PDA),
ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de registro
digital, reproductores de medios digitales, dispositivos de videojuegos, consolas de
videojuegos, teléfonos celulares de radio o por satélite, dispositivos de teleconferencia
de video, y similares. Los dispositivos de video digitales implementan técnicas de
compresión de video, tales como las descritas en los estándares definidos por MPEG-
2, MPEG-4, ITU-T H.263 o ITU-T H.264/MPEG-4, Part 10, Advanced Video Coding
(AVC), ITU-T H.265 (AVC), UIT-T H.265 (también denominada Codificación de Video
de Alta Eficiencia (HEVC)), y las extensiones de tales estándares, para transmitir y
recibir información de video digital de manera más eficiente.
[0004] Las técnicas de compresión de video realizan predicción espacial y/o temporal
para reducir o eliminar la redundancia inherente en las secuencias de video. Para la
codificación de video con base en bloques, un cuadro o porción de video se puede
dividir en macrobloques. Cada macrobloque se puede dividir aún más. Los
macrobloques en un cuadro o porción intra-codificado (I) se codifican utilizando
predicción espacial con respecto a los macrobloques vecinos. Los macrobloques en un
cuadro o porción inter-codificado (P o B) pueden utilizar predicción espacial con
respecto a los macrobloques vecinos en el mismo cuadro o porción o predicción
temporal con respecto a otros cuadros de referencia.
[0005] Después de que los datos de video han sido codificados, los datos de video se
pueden empacar para transmisión o almacenamiento. Los datos de video pueden
ensamblarse en un archivo de video conforme a cualquiera de una variedad de
estándares, tal como los formatos de archivo multimedia de base de la Organización
1
Internacional de Normalización (ISO) y sus extensiones, tal como AVC.
SÍNTESIS
[0006] En un ejemplo, un método incluye procesar un archivo que incluye datos de
video de ojo de pez, donde el archivo incluye una estructura de sintaxis que incluye
una pluralidad de elementos de sintaxis que especifican atributos de los datos de video
de ojo de pez, donde la pluralidad de elementos de sintaxis incluye: un primer
elemento de sintaxis que indica explícitamente si los datos de video de ojo de pez son
monoscópicos o estereoscópicos, y uno o más elementos de sintaxis que indican
implícitamente si los datos de video de ojo de pez son monoscópicos o
estereoscópicos; determinar, con base en el primer elemento de sintaxis, si los datos
de video de ojo de pez son monoscópicos o estereoscópicos; y renderizar, con base
en la determinación, los datos de video de ojo de pez como monoscópicos o
estereoscópicos.
[0007] En otro ejemplo, un dispositivo incluye una memoria configurada para
almacenar al menos una porción de un archivo que incluye datos de video de ojo de
pez, donde el archivo incluye una estructura de sintaxis que incluye una pluralidad de
elementos de sintaxis que especifican atributos de los datos de video de ojo de pez,
donde la pluralidad de sintaxis elementos incluye: un primer elemento de sintaxis que
indica explícitamente si los datos de video de ojo de pez son monoscópicos o
estereoscópicos, y uno o más elementos de sintaxis que indican implícitamente si los
datos de video de ojo de pez son monoscópicos o estereoscópicos; y uno o más
procesadores configurados para: determinar, con base en el primer elemento de
sintaxis, si los datos de video de ojo de pez son monoscópicos o estereoscópicos; y
renderizar, con base en la determinación, los datos de video de ojo de pez como
monoscópicos o estereoscópicos.
[0008] En otro ejemplo, un método incluye obtener datos de video de ojo de pez y
parámetros extrínsecos de cámaras utilizadas para capturar los datos de video de ojo
de pez; determinar, con base en los parámetros extrínsecos, si los datos de video de
ojo de pez son monoscópicos o estereoscópicos; y codificar, en un archivo, los datos
de video de ojo de pez y una estructura de sintaxis que incluye una pluralidad de
elementos de sintaxis que especifican atributos de los datos de video de ojo de pez,
donde la pluralidad de elementos de sintaxis incluye: un primer elemento de sintaxis
que indica explícitamente si los datos de video de ojo de pez son monoscópicos o
estereoscópicos, y uno o más elementos de sintaxis que indican explícitamente los
parámetros extrínsecos de las cámaras utilizadas para capturar los datos de video de
2
ojo de pez.
[0009] En otro ejemplo, un dispositivo incluye una memoria configurada para
almacenar datos de video de ojo de pez; y uno o más procesadores configurados para:
obtener parámetros extrínsecos de las cámaras utilizadas para capturar los datos de
video de ojo de pez; determinar, con base en los parámetros extrínsecos, si los datos
de video de ojo de pez son monoscópicos o estereoscópicos; y codificar, en un
archivo, los datos de video de ojo de pez y una estructura de sintaxis que incluye una
pluralidad de elementos de sintaxis que especifican atributos de los datos de video de
ojo de pez, donde la pluralidad de elementos de sintaxis incluye: un primer elemento
de sintaxis que indica explícitamente si los datos de video de ojo de pez son
explícitamente los parámetros extrínsecos de las cámaras utilizadas para capturar los
datos de video de ojo de pez.
[0010] Los detalles de uno o más ejemplos se exponen en las figuras adjuntas y la
descripción siguiente. Otras características, objetivos y ventajas serán evidentes a
partir de la descripción, figuras y reivindicaciones.
BREVE DESCRIPCIÓN DE LAS FIGURAS
[0011] Las FIGS. 1A y 1B son diagramas de bloques que ilustran dispositivos de
ejemplo para la captura de contenido de imagen omnidireccional, de acuerdo con una
o más técnicas de ejemplo descritas en esta divulgación.
[0012] La FIG. 2 es un ejemplo de una imagen que incluye varias imágenes de ojo de
pez.
[0013] Las FIGS. 3-8 son diagramas conceptuales que ilustran diversos parámetros
extrínsecos y campos de vista de imágenes omnidireccionales, de acuerdo con una o
más técnicas de ejemplo descritas en esta divulgación.
[0014] La FIG. 9 es un diagrama de bloques que ilustra un sistema de ejemplo que
implementa técnicas para la transmisión de datos de medios sobre una red.
[0015] La FIG. 10 es un diagrama conceptual que ilustra elementos de contenido
multimedia de ejemplo.
[0016] La FIG. 11 es un diagrama de bloque que ilustra elementos de un archivo de
video de ejemplo, que puede corresponder a un segmento de una renderización.
[0017] La FIG. 12 es un diagrama de flujo que ilustra una técnica de ejemplo para
procesar un archivo que incluye datos de video de ojo de pez, de acuerdo con una o
más técnicas de la presente divulgación.
3
generar un archivo que incluye datos de video de ojo de pez, de acuerdo con una o
más técnicas de la presente divulgación.
DESCRIPCIÓN DETALLADA
[0019] Las técnicas de ejemplo descritas en esta divulgación están relacionadas con
el procesamiento de archivos que representan datos de video o imagen
omnidireccional. Cuando el contenido de medios omnidireccional se consume con
ciertos dispositivos (por ejemplo, un casco de realidad virtual y auriculares), sólo se
representan las partes de los medios que corresponden a la orientación de
visualización del usuario, como si el usuario estuviera en el lugar donde y cuando se
capturaron los medios (por ejemplo, donde estaban las cámaras). Una de las formas
más populares de aplicaciones de medios omnidireccionales es el video
omnidireccional, también conocido como video de 360 grados. El video
omnidireccional es típicamente capturado por múltiples cámaras que cubren hasta 360
grados de la escena.
[0020] En general, el video omnidireccional se forma a partir de una secuencia de
imágenes omnidireccionales. Por consiguiente, las técnicas de ejemplo descritas en
esta divulgación se describen con respecto a la generación de contenido de imagen
omnidireccional. Entonces, para el contenido de video omnidireccional, estas
imágenes omnidireccionales se pueden visualizar de forma secuencial. En algunos
ejemplos, un usuario puede desear tomar sólo una imagen omnidireccional (por
ejemplo, tal como una instantánea de la totalidad de los 360 grados circundantes del
usuario), y las técnicas descritas en esta divulgación son aplicables a estos casos de
ejemplo también.
[0021] El video omnidireccional puede ser estereoscópico o monoscópico. Cuando el
video es estereoscópico, una imagen diferente se muestra a cada ojo de tal modo que
el espectador puede percibir la profundidad. Como tal, el video estereoscópico es
típicamente capturado utilizando dos cámaras que enfrenta cada dirección. Cuando el
video es monoscópico, la misma imagen se muestra en los dos ojos.
[0022] Los datos de video pueden ser considerados como datos de video de ojo de
pez cuando se capturan utilizando una o más lentes de ojo de pez (o generada a
aparecer como si son capturados utilizando una o más lentes de ojo de pez). Una lente
de ojo de pez puede ser una lente ultra gran angular que produce una fuerte distorsión
visual destinada a crear una imagen amplia panorámica o hemisférica.
[0023] Las técnicas pueden ser aplicables a contenido de video capturado, realidad
virtual, y en general a visualización de video e imagen. Las técnicas se pueden utilizar
4
en dispositivos móviles, pero las técnicas no deben considerarse limitado a las
aplicaciones móviles. En general, las técnicas pueden ser para aplicaciones de
realidad virtual, aplicaciones de juegos de video, u otras aplicaciones donde se desee
un entorno de video/imagen esférico de 360 grados.
[0024] En algunos ejemplos, el contenido de imagen omnidireccional puede
capturarse con un dispositivo de cámara que incluye dos lentes de ojo de pez. Cuando
las dos lentes de ojo de pez están posicionadas en lados opuestos del dispositivo de
cámara para capturar porciones opuestas de la esfera de contenido de la imagen, el
contenido de la imagen puede ser monoscópico y cubrir la esfera completa del video
de 360 grados. Asimismo, cuando las dos lentes de ojo de pez están posicionadas en
el mismo lado del dispositivo de cámara para capturar la misma porción de la esfera
de contenido de la imagen, el contenido de la imagen puede ser estereoscópico y
cubrir la mitad de la esfera de video de 360 grados. Las imágenes generadas por las
cámaras son imágenes circulares (por ejemplo, un cuadro de imagen incluye dos
imágenes circulares).
[0025] Las FIGS. 1A y 1B son diagramas de bloques que ilustran dispositivos de
ejemplo para la captura de contenido de imagen omnidireccional de acuerdo con una o
más técnicas de ejemplo descritas en esta divulgación. Como se ilustra en la FIG. 1A,
el dispositivo informático 10A es un dispositivo de captura de video que incluye lente
de ojo de pez 12A y lente de ojo de pez 12B situadas en lados opuestos del dispositivo
informático 10A para capturar contenido de imagen monoscópica que cubre toda la
esfera (por ejemplo, contenido de video completo de 360 grados). Como se ilustra en
la FIG. 1B, el dispositivo informático 10B es un dispositivo de captura de video que
incluye lente ojo de pez 12C y lente de ojo de pez 12D situado en el mismo lado del
dispositivo informático 10B al contenido de imagen estereoscópica que cubre
aproximadamente la mitad de la esfera.
[0026] Como se describió anteriormente, un dispositivo de cámara incluye una
pluralidad de lentes de ojo de pez. Algunos dispositivos de cámara de ejemplo
incluyen dos lentes de ojo de pez, pero las técnicas de ejemplo no se limitan a dos
lentes de ojo de pez. Un dispositivo de cámara de ejemplo puede incluir 16 lentes (por
ejemplo, disposición de 16 cámaras para filmar contenido 3D VR). Otro dispositivo de
cámara de ejemplo puede incluir ocho lentes, cada uno con de ángulo de vista de 195
grados (por ejemplo, cada lente captura 195 grados de los 360 grados de contenido de
la imagen). Otros dispositivos de cámaras de ejemplo incluyen tres o cuatro lentes.
Algunos ejemplos pueden incluir una lente de 360 grados que captura 360 grados de
5
contenido de imagen.
[0027] Las técnicas de ejemplo descritas en esta divulgación se describen
generalmente con respecto a dos lentes de ojo de pez que capturan imagen/video
omnidireccional. Sin embargo, las técnicas de ejemplo no están limitadas por estas.
Las técnicas de ejemplo pueden ser aplicables a dispositivos de cámaras de ejemplo
que incluyen una pluralidad de lentes (por ejemplo, dos o más), incluso si las lentes no
son lentes de ojo de pez, y una pluralidad de lentes de ojo de pez. Por ejemplo, las
técnicas de ejemplo describen formas combinar imágenes capturadas, y las técnicas
pueden ser aplicables a ejemplos donde hay una pluralidad de imágenes capturadas
de una pluralidad de lentes (que pueden ser lentes de ojo de pez, como un ejemplo).
Aunque las técnicas de ejemplo se describen con respecto a dos lentes de ojo de pez,
las técnicas de ejemplo no están limitadas a estas, y son aplicables a los diversos
tipos de cámara utilizados para capturar imágenes/videos onmidireccionales.
[0028] Las técnicas de la presente divulgación se pueden aplicar a archivos de video
conforme a los datos de video encapsulados de acuerdo con cualquiera de formato de
archivo multimedia de base ISO (por ejemplo, ISOBMFF, ISO/IEC 14496-12), y otros
formatos de archivo derivados de ISOBMFF, incluyendo formato de archivo MPEG-4
(ISO/IEC 14496-15), formato de archivo de Proyecto de Asociación de Tercera
Generación (3GPP) (3GPP TS 26.244) y formatos de archivo para familias AVC y
HEVC de códecs de video (ISO/IEC 14496-15), u otro formatos de archivo de video
similares.
[0029] El ISOBMFF se utiliza como base para muchos formatos de encapsulamiento
de códec, tal como el formato de archivo de AVC, así como para muchos formatos
contenedores multimedia, tal como el formato de archivo MPEG-4, el formato de
archivo 3GPP (3GP), y el formato de archivo DVB. Además de los medios continuos,
tal como audio y video, medios estáticos, tal como imágenes, así como metadatos, se
pueden almacenar en un archivo conforme a ISOBMFF. Los archivos estructurados
conforme a ISOBMFF se pueden utilizar para muchos propósitos, incluyendo la
reproducción de archivos de medios locales, descarga progresiva de un archivo
remoto, segmentos para Streaming Dinámico Adaptativo a través de HTTP (DASH),
contenedores para contenido a transmitir por streaming y sus instrucciones de
paquetización, y registro de flujos de medios en tiempo real recibidos.
[0030] Una caja es la estructura de sintaxis elemental en el ISOBMFF, incluyendo un
tipo de caja codificado de cuatro caracteres, el número de bytes de la caja, y la carga
útil. Un archivo ISOBMFF consiste en una secuencia de cajas, y las cajas pueden
6
contener otras cajas. Una caja de películas (“moov”) contiene los metadatos para los
flujos de medios continuos presentes en el archivo, cada uno representado en el
archivo como una pista. Los metadatos de una pista están encerrados en una caja de
Pista (“Trak”), mientras que el contenido de medios de una pista está encerrado en
una caja de Datos de Medios (“mdat”) o directamente en un archivo separado. El
contenido de los medios para las pistas consiste en una secuencia de muestras, tal
como unidades de acceso de audio o video.
[0031] Durante la renderización de los datos de video de ojo de pez, puede ser
deseable para un decodificador de video determinar si los datos de video de ojo de
pez son monoscópicos o estereoscópicos. Por ejemplo, la manera en que el
decodificador de video exhibe y/o combina las imágenes circulares incluidas en una
imagen de datos de video de ojo de pez es directamente dependiente de si los datos
de video de ojo de pez son monoscópicos o estereoscópicos.
[0032] En algunos ejemplos, un decodificador de video puede determinar si los datos
de video de ojo de pez son monoscópicos o estereoscópicos con base en uno o más
elementos de sintaxis incluidos en un archivo que indican implícitamente si los datos
de video de ojo de pez descritos por el archivo son monoscópicos o estereoscópicos.
Por ejemplo, un codificador de video puede incluir elementos de sintaxis en el archivo
que describen parámetros extrínsecos (por ejemplo, atributos físicos/de localización
tales como el ángulo de guiñada, un ángulo de paso, un ángulo de balanceo, y uno o
más desplazamientos espaciales) de cada una de las cámaras utilizadas para capturar
los datos de video de ojo de pez, y el decodificador de video puede procesar los
parámetros extrínsecos para calcular si los datos de video descritos por el archivo son
monoscópicos o estereoscópicos. Como un ejemplo, si el procesamiento de los
parámetros extrínsecos conduce a una indicación de que las cámaras están
orientadas en la misma dirección y tienen un desplazamiento espacial, el decodificador
de video puede determinar que los datos de video son estereoscópicos. Como otro
ejemplo, si el procesamiento de los parámetros extrínsecos indica que las cámaras
están orientadas en direcciones opuestas, el decodificador de video puede determinar
que los datos de video son monoscópicos. Sin embargo, en algunos ejemplos, puede
ser deseable que el decodificador de video sea capaz de determinar si los datos de
video de ojo de pez son monoscópicos o estereoscópicos sin tener que realizar tales
cálculos adicionales, de uso intensivo de recursos. Además, en algunos ejemplos, el
procesamiento de los parámetros extrínsecos puede no producir la correcta (por
ejemplo, pretendida) clasificación de los datos de video como monoscópicos o
7
estereoscópicos. Como un ejemplo, los valores de los parámetros extrínsecos pueden
corromperse durante la codificación/tránsito/decodificación. Como otro ejemplo, los
parámetros extrínsecos pueden no haber sido provistos con exactitud en el
codificador.
[0033] De acuerdo con una o más técnicas de la presente divulgación, un codificador
de video puede incluir un primer elemento de sintaxis en un archivo que indica
explícitamente si los datos de video de ojo de pez descritos por el archivo son
monoscópicos o estereoscópicos. El archivo puede incluir el primer elemento de
sintaxis, además de los elementos de sintaxis de los parámetros extrínsecos de los
datos de video de ojo de pez. Como tal, el archivo puede incluir tanto una indicación
explícita (es decir, el primer elemento de sintaxis) y una indicación implícita (es decir,
los elementos de sintaxis de los parámetros extrínsecos) de si los datos de video de
ojo de pez descritos por el archivo son monoscópicos o estereoscópicos. De esta
manera, un decodificador de video puede determinar con exactitud si los datos de
video son monoscópicos o estereoscópicos (por ejemplo, sin tener que realizar
cálculos adicionales basados en los parámetros extrínsecos).
[0034] ISOBMFF especifica los siguientes tipos de pistas: una pista de medios, que
contiene un flujo de medios elemental, una pista de indicación, que incluye
instrucciones para la transmisión de medios o representa un flujo de paquetes
recibidos, y una pista de metadatos temporizados, que comprende metadatos
sincronizados en el tiempo.
[0035] Aunque está originalmente diseñado para almacenamiento, ISOBMFF ha
demostrado ser muy valioso para la transmisión, por ejemplo, para la descarga
progresiva o DASH. Para fines de transmisión, se pueden utilizar los fragmentos de
película definidos en ISOBMFF.
[0036] Los metadatos para cada pista incluyen una lista de entradas de descripción de
muestra, donde cada una proporciona el formato de codificación o de encapsulamiento
utilizado en la pista y los datos de inicialización necesarios para el procesamiento de
dicho formato. Cada muestra se asocia con una de las entradas de descripción de
muestra de la pista.
[0037] ISOBMFF permite la especificación de metadatos de muestra específica con
diversos mecanismos. Se han normalizado cajas específicas dentro de la caja Tabla
de Muestra (“Stbl”) para responder a las necesidades comunes. Por ejemplo, una caja
Muestra Sinc (“stss”) se utiliza para enumerar las muestras de acceso aleatorio de la
pista. El mecanismo de agrupación de muestras permite el mapeo de muestras de
8
acuerdo con un tipo de agrupación de cuatro caracteres en grupos de muestras que
comparten la misma propiedad especificada que una entrada de descripción de grupo
de muestra en el archivo. Varios tipos de agrupación se han especificado en
ISOBMFF.
[0038] La realidad virtual (VR) es la capacidad estar virtualmente presente en un
mundo no físico creado por la renderización de imágenes naturales y/o sintéticas y el
sonido correlacionado por los movimientos del usuario inmerso que permite interactuar
con ese mundo. Con los recientes avances en los dispositivos de renderización, tal
como cascos de realidad virtual (HMD), y creación de video VR (a menudo también
denominado video de 360 grados), se puede ofrecer una calidad importante de
experiencia. Las aplicaciones de VR incluyen juegos, capacitación, educación, videos
de los deportes, compras en línea, entretenimiento para adultos, y etc.
[0039] Un sistema VR típico puede incluir uno o más de los siguientes componentes,
que pueden realizar una o más de las siguientes etapas:
1) Un conjunto de cámara, que por lo general se compone de varias
cámaras individuales que apuntan a diferentes direcciones y lo ideal
sería que cubran colectivamente todas las vistas alrededor del conjunto
de cámara.
2) Combinación de imágenes, donde las imágenes de video tomadas por
las múltiples cámaras individuales se sincronizan en el dominio del
tiempo y se combinan en el dominio espacial, como un video esférico,
pero asignado a un formato rectangular, tal como mapeo equi-
rectangular (tal como un mapamundi) o cubo.
3) El video en el formato rectangular asignado está codificado/comprimido
utilizando un códec de video, por ejemplo, H.265/HEVC o H.264/AVC.
4) El flujo de bits de video comprimido se puede almacenar y/o encapsular
en un formato de medios y transmitir (posiblemente sólo el subconjunto
que cubre sólo el área que está siendo vista por un usuario) a través de
una red a un receptor.
5) El receptor recibe el flujo de bits de video o porción del mismo,
posiblemente encapsulado en un formato, y envía la señal de video
decodificada o porción del mismo a un dispositivo de renderización.
6) El dispositivo de renderización puede ser, por ejemplo, un HMD, que
puede realizar un seguimiento del movimiento de la cabeza, e incluso
del movimiento del ojo y renderizar la parte correspondiente del video
9
de tal manera de entregar al usuario una experiencia de inmersión.
[0040] El Formato de Aplicación de Medio Omnidireccional (OMAF) está siendo
desarrollado por MPEG para definir un formato de aplicación multimedia que permite a
las aplicaciones de medios omnidireccionales enfocarse en aplicaciones de VR con
360° de video y audio asociado. OMAF especifica proyección y empaque por regiones
que se puede utilizar para la conversión de un video esférico o de 360° en un video
rectangular de dos dimensiones, seguido por la forma de almacenamiento de los
medios omnidireccionales y los metadatos asociados con el formato de archivo
multimedia de base ISO (ISOBMFF) y la forma de encapsulamiento de la señal, y
transmisión de medios omnidireccionales utilizando streaming dinámico adaptativo a
través de HTTP (DASH), y finalmente qué códecs de video y audio, así como
configuraciones de codificación medios se pueden utilizar para la compresión y
reproducción de la señal de los medios omnidireccionales.
[0041] La proyección y empaque por regiones son los procesos utilizados en el lado
de la producción de contenido para generar imágenes de video 2D a partir de la señal
de esfera para video omnidireccional proyectado. La proyección por lo general va de la
mano de combinación, lo que puede generar la señal de esfera de las imágenes
capturadas de múltiples cámaras para cada imagen de video. La proyección puede ser
una etapa paso fundamental de procesamiento en video VR. Los tipos de proyección
típicos incluyen equirectangular y de cubo. El Proyecto de Estándar Internacional
OMAF (DIS) sólo es compatible con el tipo de proyección equirectangular. El empaque
por regiones es una etapa opcional después de la proyección (de la ventana de
observación del lado de la producción de contenido). El empaque por regiones permite
manipular (cambio de tamaño, cambio de posición, rotación y simetría) de cualquier
región rectangular de la imagen empacada antes de la codificación.
[0042] La FIG. 2 es un ejemplo de una imagen que incluye varias imágenes de ojo de
pez. El OMAF DIS soporta un formato de video de ojo de pez VR/360, donde en lugar
de aplicar una proyección y, opcionalmente, un empaque por regiones para generar el
video 2D antes de la codificación, para cada unidad de acceso las imágenes circulares
de las cámaras de captura están incrustadas directamente en una imagen 2D. Por
ejemplo, como se muestra en la FIG. 2, la primera imagen de ojo de pez 202 y
segunda imagen de ojo de pez 204 están incrustadas en la imagen 2D 200.
[0043] Tal video ojo de pez puede entonces ser codificado y el flujo de bits puede ser
encapsulado en un archivo ISOBMFF y se puede encapsular adicionalmente como
una representación DASH. Además, la propiedad del video de ojo de pez, incluyendo
10
parámetros que indican las características del video de ojo de pez, puede señalarse y
se utiliza para renderizar correctamente el video 360 en el lado del cliente. Una ventaja
del enfoque de video de ojo de pez VR/360 es que soporta contenido VR de bajo costo
generado por usuario por terminales móviles.
[0044] En OMAF DIS, el uso del sistema de video omnidireccional de ojo de pez para
el tipo de entrada de la muestra de video restringido 'resv' indica que las imágenes
decodificadas son imágenes de video de ojo de pez. El uso del sistema de video
omnidireccional de ojo de pez se indica mediante scheme_type igual a 'fodv' (video de
ojo de pez omnidireccional) dentro de la SchemeTypeBox. El formato de video de ojo
de pez se indica con la FisheyeOmnidirectionalVideoBox contenida dentro de la
SchemeInformationBox, que se incluye en la RestrictedSchemeInfoBox que se incluye
en la entrada de la muestra. En el proyecto actual de OMAF DIS (Information
technology — Coded representation of immersive media (MPEG-I) — Part 2:
Omnidirectional media format, ISO/IEC FDIS 14496-15:2014(E), ISO/IEC JTC 1/SC
29/WG 11, w16824, 2014-01-13, en adelante “proyecto actual de OMAF DIS”), una y
sólo una FisheyeOmnidirectionalVideoBox está presente en la SchemeInformationBox
cuando el tipo de esquema es 'fodv'. Cuando FisheyeOmnidirectionalVideoBox está
presente en la SchemeInformationBox, StereoVideoBox y RegionWisePackingBox no
deben estar presentes en la misma SchemeInformationBox. La
FisheyeOmnidirectionalVideoBox, como se especifica en la cláusula 6 de OMAF DIS,
contiene la estructura de sintaxis FisheyeOmnidirectionalVideoInfo () que contiene los
parámetros de propiedades de video de ojo de pez.
[0045] La sintaxis de la estructura de sintaxis FisheyeOmnidirectionalVideoInfo () en el
proyecto actual de OMAF DIS es de la siguiente manera.
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
bit(24) reserved = 0;
unsigned int(8) num_circular_images;
for(i=0; i< num_circular_images; i++) {
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
unsigned int(32) full_radius;
unsigned int(32) picture_radius;
unsigned int(32) scene_radius;
unsigned int(32) image_rotation;
11
unsigned int(2) image_flip;
unsigned int(32) image_scale_axis_angle;
unsigned int(32) image_scale_x;
unsigned int(32) image_scale_y;
unsigned int(32) field_of_view;
unsigned int (16) num_angle_for_displaying_fov;
for(j=0; j< num_angle_for_displaying_fov; j++) {
unsigned int(32) displayed_fov;
unsigned int(32) overlapped_fov;
}
signed int(32) camera_center_yaw;
signed int(32) camera_center_pitch;
signed int(32) camera_center_roll;
unsigned int(32) camera_center_offset_x;
unsigned int(32) camera_center_offset_y;
unsigned int(32) camera_center_offset_z;
unsigned int(16) num_polynomial_coefficeients;
for(j=0; j< num_polynomial_coefficients; j++) {
unsigned int(32) polynomial_coefficient_K;
}
unsigned int (16) num_local_fov_region;
for(j=0; j<num_local_fov_region; j++) {
unsigned int(32) start_radius;
unsigned int(32) end_radius;
signed int(32) start_angle;
signed int(32) end_angle;
unsigned int(32) radius_delta;
signed int(32) angle_delta;
for(rad=start_radius; rad<= end_radius; rad+=radius_delta) {
for(ang=start_angle; ang<= ang_radius;
ang+=angle_delta) {
unsigned int(32) local_fov_weight;
12
}
}
}
unsigned int(16) num_polynomial_coefficients_lsc;
for(j=0; j< num_polynomial_coefficients_lsc; j++) {
unsigned int (32) polynomial_coefficient_K_lsc_R;
unsigned int (32) polynomial_coefficient_K_lsc_G;
unsigned int (32) polynomial_coefficient_K_lsc_B;
}
}
unsigned int(8) num_deadzones;
for(i=0; i< num_deadzones; i++) {
unsigned int(16) deadzone_left_horizontal_offset;
unsigned int(16) deadzone_top_vertical_offset;
unsigned int(16) deadzone_width;
unsigned int(16) deadzone_height;
}
}
[0046] La semántica de la estructura de sintaxis FisheyeOmnidirectionalVideoInfo () en
el actual proyecto de OMAF DIS es de la siguiente manera.
[0047] num_circular_images especifica el número de imágenes circulares en la
imagen codificada de cada muestra a la que aplica esta imagen. Típicamente, el valor
es igual a 2, pero otros valores distintos de cero son también posibles.
[0048] image_center_x es un valor de punto fijo 16.16 que especifica la coordenada
horizontal, en muestras de luminancia, del centro de la imagen circular en la imagen
codificada de cada muestra a la que aplica esta imagen.
[0049] image_center_y es un valor de punto fijo 16.16 que especifica la coordenada
vertical, en muestras de luminancia, del centro de la imagen circular en la imagen
codificada de cada muestra a la que aplica esta imagen.
[0050] full_radius es un valor de punto fijo 16.16 que especifica el radio, en muestras
de luminancia, del centro de la imagen circular al borde de la imagen redonda
completa.
[0051] picture_radius es un valor de punto fijo 16.16 que especifica el radio, en
13
muestras de luminancia, del centro de la imagen circular al borde más cercano al
borde de la imagen. La imagen de ojo de pez circular puede ser recortada por la
imagen de la cámara. Por lo tanto, este valor indica el radio de un círculo donde los
píxeles son utilizables.
[0052] scene_radius es un valor de punto fijo 16.16 que especifica el radio, en
muestras de luminancia, del centro de la imagen circular hacia el borde más cercano
del área de la imagen donde se garantiza que no hay obstrucciones desde el propio
cuerpo de la cámara y que dentro de la zona cerrada no hay distorsión de la lente
demasiado grande para combinación.
[0053] image_rotation es un valor de punto fijo 16.16 que especifica la cantidad de
rotación, en grados, de la imagen circular. La imagen puede ser girada por imágenes
+/- 90 grados, o +/- 180 grados, o cualquier otro valor.
[0054] image_flip especifica si, y cómo, la imagen se ha volteado y por lo tanto una
operación de volteo inversa debe ser aplicada. El valor 0 indica que la imagen no se
ha volteado. El valor 1 indica que la imagen se ha girado verticalmente. El valor 2
indica que la imagen se ha volteado horizontalmente. El valor 3 indica que la imagen
se ha volteado tanto vertical como horizontalmente.
[0055] image_scale_axis_angle, image_scale_x e image_scale_y son tres valores de
punto fijo 16.16 que especifican si, y cómo, la imagen se ha reducido a lo largo de un
eje. El eje se define por un solo ángulo, como se indica por el valor de
image_scale_axis_angle, en grados. Un ángulo de 0 grados significa que un vector
horizontal es perfectamente horizontal y que un vector vertical es perfectamente
vertical. Los valores de image_scale_x e image_scale_y indican las relaciones de
escala en las direcciones que son paralelas y ortogonales, respectivamente, al eje.
[0056] field_of_view es un valor de punto fijo 16.16 que especifica el campo de vista
de la lente de ojo de pez, en grados. Un valor típico para una lente ojo de pez
hemisférica es 180,0 grados.
[0057] num_angle_for_displaying_fov especifica el número de ángulos. De acuerdo
con el valor de num_angle_for_displaying_fov, múltiples valores de displayed_fov y
overlapped_fov se definen con intervalos iguales, que comienzan a las 12:00 y se
desplazan en sentido horario.
[0058] displayed_fov especifica el campo de vista exhibido y la correspondiente área
de imagen de cada imagen de la cámara de ojo de pez. overlapped_fov especifica la
región que incluye las regiones solapadas, que se utilizan por lo general para la
mezcla, en términos de campo de vista entre varias imágenes circulares. Los valores
14
de displayed_fov y overlapped_fov son más pequeños o igual que el valor de
field_of_view.
[0059] NOTA: El valor de field_of_view está determinado por la propiedad física de
cada lente de ojo de pez, mientras que los valores de displayed_fov y overlapped_fov
se determinan por la configuración de múltiples lentes de ojo de pez. Por ejemplo,
cuando el valor de num_circular_images es igual a 2, y dos lentes están situadas
simétricamente, el valor de displayed_fov y overlapped_fov se puede establecer como
180 y 190 respectivamente, de forma predeterminada. Sin embargo, el valor puede
cambiarse dependiendo de la configuración de la lente y las características de los
contenidos. Por ejemplo, si la calidad de la combinación con los valores displayed_fov
(cámara izquierda = 170 y cámara derecha = 190) y los valores overlapped_fov
(cámara izquierda = 185 y cámara derecha = 190) es mejor que la calidad con los
valores por defecto (180 y 190) o si la configuración física de las cámaras es
asimétrica, entonces se pueden tomar los valores desiguales displayed_fov y
overlapped_fov. Además, cuando se trata de múltiples (N> 2) imágenes de ojo de pez,
un solo valor displayed_fov no puede especificar el área exacta de cada imagen de ojo
de pez. Como se muestra en la FIG. 6, displayed_fov (602) varía en función de la
dirección. Con el fin de manipular las imágenes de ojo de pez múltiples (N> 2), se
introduce num_angle_for_displaying_fov. Por ejemplo, si este valor es igual a 12,
entonces la imagen de ojo de pez se divide en 12 sectores donde cada ángulo de
sector es de 30 grados.
[0060] camera_center_yaw especifica el ángulo de guiñada, en unidades de 2-16
grados, del punto en que el píxel central de la imagen circular en la imagen codificada
de cada muestra se proyecta a una superficie esférica. Este es el primero de los 3
ángulos que especifican los parámetros extrínsecos de la cámara con respecto a los
ejes de coordenadas globales. camera_center_yaw estará en el rango de −180 * 216 a
180 * 216 – 1, inclusive.
[0061] camera_center_pitch especifica el ángulo de inclinación, en unidades de 2-16
de cada muestra se proyecta a una superficie esférica. camera_center_pitch estará en
el rango de −90 * 216 a 90 * 216, inclusive.
[0062] camera_center_roll especifica el ángulo de balanceo, en unidades de 2-16
de cada muestra se proyecta a una superficie esférica. camera_center_roll estará en el
rango de −180 * 216 a 180 * 216 – 1, inclusive.
15
[0063] camera_center_offset_x, camera_center_offset_y y camera_center_offset_z
son valores de punto fijo 8.24 que indican los valores de desplazamiento XYZ desde el
origen de la unidad de esfera en la que se proyectan los píxeles de la imagen circular
en la imagen codificada. camera_center_offset_x, camera_center_offset_y y
camera_center_offset_z están en el intervalo de -1,0 a 1,0, inclusive.
[0064] num_polynomial_coefficients es un número entero que especifica el número de
coeficientes polinómicos presentes. La lista de coeficientes polinómicos
polynomial_coefficient_K son valores de punto fijo 8.24 que representan los
coeficientes en el polinomio que especifican la transformación del espacio de ojo de
pez a la imagen plana no distorsionada.
[0065] num_local_fov_region especifica el número de regiones de ajuste locales que
tienen diferentes campos de vista.
[0066] start_radius, end_radius, start_angle, y end_angle especifican la región para el
ajuste/pandeo local para cambiar el campo de vista real para visualización local.
start_radius y end_radius son valores de punto fijo 16.16 que especifican los valores
de radio máximos y mínimos. start_angle y end_angle especifican los valores de
ángulo mínimos y máximos que comienzo a las 12:00 y aumentan en sentido horario,
en unidades de 2-16 grados. start_angle, y end_angle están en el rango de −180 * 216 a
180 * 216 − 1, inclusive.
[0067] radius_delta es un valor de punto fijo 16.16 que especifica el valor de radio
delta para representar un campo de vista diferente para cada radio.
[0068] angle_delta especifica el valor del ángulo delta, en unidades de 2-16 grados,
para representar un campo de vista diferente para cada ángulo.
[0069] local_fov_weight es un formato de punto fijo 8.24 que especifica el valor de
ponderación para el campo de vista de la posición especificada por start_radius,
end_radius, start_angle, end_angle, el índice de ángulo i y el índice de radio j. El valor
positivo de local_fov_weight especifica la expansión del campo de vista, mientras que
el valor negativo especifica la contracción del campo de vista.
[0070] num_polynomial_coefficeients_lsc es el orden de la aproximación polinómica
de la curva de sombreado de lente.
[0071] polynomial_coefficient_K_lsc_R, polynomial_coefficient_K_lsc_G y
polynomial_coefficient_K_lsc_B son formatos de punto fijo 8.24 que especifican los
parámetros de LSC para compensar el artefacto sombreado que reduce el color a lo
largo de la dirección radial. El peso de compensación (w) que se multiplica al color
original es aproximado como una función curva del radio del centro de la imagen
16
utilizando una expresión polinómica. Se formula como , donde p
indica el valor del coeficiente igual a polynomial_coefficient_K_lsc_R,

polynomial_coefficient_K_lsc_G o polynomial_coefficient_K_lsc_B, y r indica el valor
del radio después de la normalización por full_radius. N es igual al valor de
num_polynomial_coefficeients_lsc.
[0072] num_deadzones es un número entero que especifica el número de zonas
muertas en la imagen codificada de cada muestra a la que aplica esta caja.
[0073] deadzone_left_horizontal_offset, deadzone_top_vertical_offset,
deadzone_width, y deadzone_height son valores enteros que especifican la posición y
el tamaño del área rectangular de la zona muerta donde los píxeles no son utilizables.
deadzone_left_horizontal_offset y deadzone_top_vertical_offset especifican las
coordenadas horizontales y verticales, respectivamente, en muestras de luminancia,
de la esquina superior izquierda de la zona muerta en la imagen codificada.
deadzone_width y deadzone_height especifican el ancho y la altura, respectivamente,
en muestras de luminancia, de la zona muerta. Para guardar los bits para representar
el video, todos los píxeles dentro de una zona muerta deben ajustarse al mismo valor
de píxel, por ejemplo, todo negro.
[0074] Las FIGS. 3-8 son diagramas conceptuales que ilustran diversos aspectos de la
sintaxis y la semántica anteriores. La FIG. 3 ilustra la sintaxis image_center_x e
image_center_y como centro 302, la sintaxis full_radius como radio completo 304,
picture_radius como radio de cuadro 306 del cuadro 300, scene_radius como radio de
escena 308 (por ejemplo, el área sin obstrucciones del cuerpo de la cámara 510). La
FIG. 4 ilustra displayed_fov (es decir, campo de vista (FOV) mostrado) para dos
imágenes de ojo de pez. FOV 402 representa un campo de vista de 170 grados y FOV
404 representa un campo de vista de 190 grados. La FIG. 5 ilustra displayed_fov (es
decir, campo de vista (FOV) mostrado)) y overlapped_fov para múltiples (por ejemplo,
N> 2) imágenes de ojo de pez. FOV 502 representa un primer campo de vista y FOV
504 representa un segundo campo de vista. La FIG. 6 es una ilustración de sintaxis
camera_center_offset_x (ox), camera_center_offset_y (oy), y camera_center_offset_z
(oz). La FIG. 7 es un diagrama conceptual que ilustra parámetros respecto del campo
de vista local. La FIG. 8 es un diagrama conceptual que ilustra un ejemplo de un
campo de vista local.
[0075] La señalización de video de ojo de pez en el proyecto actual de OMAF DIS
puede presentar una o más desventajas.
[0076] Como un ejemplo de desventaja de la señalización de video de ojo de pez en el
17
proyecto actual de OMAF DIS, cuando hay dos imágenes circulares en cada imagen
de video de ojo de pez (por ejemplo, donde num_circular_images en la estructura de
sintaxis FisheyeOmnidirectionalVideoInfo () es igual a 2), dependiendo de los valores
de los parámetros extrínsecos de la cámara (por ejemplo, camera_center_yaw,
camera_center_pitch, camera_center_roll, camera_center_offset_x,
camera_center_offset_y, y camera_center_offset_z), el video de ojo de pez puede ser
monoscópico o estereoscópico. En particular, cuando las dos cámaras que capturan
las dos imágenes circulares están en el mismo lado, el video de ojo de pez cubre de
manera estereoscópica aproximadamente la mitad (es decir, 180 grados
horizontalmente) de la esfera, y cuando las dos cámaras están en lados opuestos, el
video de ojo de pez es monoscópico pero cubre aproximadamente la totalidad (es
decir, 360 grados horizontalmente) de la esfera. Por ejemplo, cuando los dos
conjuntos de valores de los parámetros extrínsecos de cámara son los siguientes, el
video de ojo de pez es monoscópico:
1er conjunto:
camera_center_yaw = 0 grados (+/- 5 grados)
camera center_pitch = 0 grados (+/- 5 grados)
camera center roll = 0 grados (+/- 5 grados)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
2do conjunto:
[0077] Los valores de los parámetros anteriores pueden corresponder a valores de
parámetros extrínsecos de cámara del dispositivo informático 10B de la FIG. 1B. Como
otro ejemplo, cuando los dos conjuntos de valores de los parámetros extrínsecos de
cámara son los siguientes, el video de ojo de pez es estereoscópico:
1er conjunto:
18
2do conjunto:
camera_center_pitch = 0 grados (+/- 5 grados)
[0078] Los valores de los parámetros anteriores pueden corresponder a valores de los
parámetros extrínsecos de cámara del dispositivo informático 10A de la FIG. 1A.
Téngase en cuenta que la distancia X de desplazamiento estéreo de 64 mm es
equivalente a 2,5 pulgadas, que es la distancia promedio entre los ojos humanos.
[0079] En otras palabras, la información sobre si el video de ojo de pez es
monoscópico o estereoscópico está oculta (es decir, codificado de manera implícita
pero no explícita). Sin embargo, para los propósitos del sistema de alto nivel como
selección de contenidos, puede ser deseable que esta información sea de fácil acceso
tanto en nivel de formato de archivo como en nivel DASH (por ejemplo, de manera tal
que la entidad que realice la función de selección de contenidos no tenga que analizar
demasiada información en la estructura de sintaxis FisheyeOmnidirectionalVideoInfo ()
para determinar si los datos de video correspondientes son monoscópicos o
estereoscópicos).
[0080] Como otro ejemplo de desventaja de la señalización de video de ojo de pez en
el proyecto actual de OMAF DIS, cuando hay dos imágenes circulares en cada imagen
de video de ojo de pez (por ejemplo, donde num_circular_images en la estructura de
sintaxis FisheyeOmnidirectionalVideoInfo () es igual a 2), y el video de ojo de pez es
estereoscópico, un dispositivo de cliente puede determinar cuál de las dos imágenes
circulares es la vista del ojo izquierdo y cuál es la vista del ojo derecho de los
parámetros extrínsecos de cámara. Sin embargo, puede que no sea deseable que el
dispositivo de cliente tenga que determinar qué imagen es la vista del ojo izquierdo y
qué imagen es la vista del ojo derecho de los parámetros extrínsecos de cámara.
el proyecto actual de OMAF DIS, cuando hay cuatro cámaras de ojo de pez, dos en
19
cada lado, para capturar el video de ojo de pez, el video de ojo de pez es
estereoscópico y cubre toda la esfera. En este caso, hay cuatro imágenes circulares
en cada imagen de video de ojo de pez (por ejemplo, num_circular_images en la
estructura de sintaxis FisheyeOmnidirectionalVideoInfo () es igual a 4). En tales casos
(cuando hay más de dos imágenes circulares en cada imagen de video de ojo de pez),
un dispositivo de cliente puede determinar el emparejamiento de ciertas dos imágenes
circulares que pertenecen a la misma vista desde los parámetros extrínsecos de
cámara. Sin embargo, puede que no sea deseable que el dispositivo de cliente tenga
que determinar el emparejamiento de ciertas dos imágenes circulares que pertenecen
a la misma vista desde los parámetros extrínsecos de cámara.
el proyecto actual de OMAF DIS, para video omnidireccional proyectado, la
información de cobertura (por ejemplo, qué área de la esfera está cubierta por el
video), se señaliza explícitamente utilizando la CoverageInformationBox o, cuando no
está presente, se infiere por el dispositivo de cliente que es la esfera completa.
Aunque el dispositivo de cliente puede determinar la cobertura de los parámetros
extrínsecos de cámara, nuevamente, puede ser deseable que la señalización explícita
que esta información sea de fácil acceso.
el proyecto actual de OMAF DIS, se permite el uso de empaque por regiones para
video omnidireccional proyectado, pero no se permite para video de ojo de pez. Sin
embargo, algunos beneficios de empaque por regiones aplicables a video
omnidireccional proyectado también pueden ser aplicables a video de ojo de pez.
el proyecto actual de OMAF DIS, el transporte de video omnidireccional proyectado en
pistas de sub-imagen se especifica en OMAF DIS mediante el uso de la agrupación de
pista de composición. Sin embargo, el transporte de video de ojo de pez
omnidireccional en pistas de sub-imagen no es soportado.
[0085] Esta divulgación presenta soluciones a los problemas anteriores. Algunas de
estas técnicas se pueden aplicar de forma independiente y algunas se pueden aplicar
en combinación.
[0086] De acuerdo con una o más técnicas de la presente divulgación, un archivo que
incluye datos de video de ojo de pez puede incluir una indicación explícita de si los
datos de video de ojo de pez son monoscópicos o estereoscópicos. En otras palabras,
una indicación de si el video de ojo de pez es monoscópico o estereoscópico puede
20
ser señalada explícitamente. De esta manera, un dispositivo de cliente puede evitar
tener que inferir si los datos de video de ojo de pez son monoscópicos o
estereoscópicos a partir de otros parámetros.
[0087] Como un ejemplo, uno o más de los 24 bits iniciales en la estructura de sintaxis
FisheyeOmnidirectionalVideoInfo () pueden utilizarse para formar un campo (por
ejemplo, una bandera de un bit) para señalar la indicación de monoscópico o
estereoscópico. El campo que es igual a un primer valor particular (por ejemplo, 0)
puede indicar que el video de ojo de pez es monoscópico, y el campo igual a un
segundo valor particular (por ejemplo, 1) puede indicar que el video de ojo de pez es
estereoscópico. Por ejemplo, cuando se genera un archivo que incluye datos de video
de ojo de pez, un dispositivo de preparación de contenidos (por ejemplo, dispositivo de
preparación de contenidos 20 de la FIG. 9, y en un ejemplo particular, la unidad de
encapsulamiento 30 del dispositivo de preparación de contenidos 20) puede codificar
una caja (por ejemplo, una FisheyeOmnidirectionalVideoBox) dentro del archivo, la
caja incluye una estructura de sintaxis (por ejemplo, FisheyeOmnidirectionalVideoInfo
()) que contiene parámetros para los datos de video de ojo de pez, y la estructura de
sintaxis incluyendo una indicación explícita de si los datos de video de ojo de pez son
monoscópicos o estereoscópicos. Un dispositivo de cliente (por ejemplo, dispositivo de
cliente 40 de la FIG. 9, y en un ejemplo particular, la unidad de recuperación 52 del
dispositivo de cliente 40) puede procesar de manera similar el archivo para obtener la
indicación explícita de monoscópico o estereoscópico.
[0088] Como otro ejemplo, una nueva caja que contiene un campo, por ejemplo, una
bandera de un bit, algunos bits reservados y, posiblemente, alguna otra información,
se puede añadir en la FisheyeOmnidirectionalVideoBox a la señal de indicación de
monoscópico o estereoscópico. El campo que es igual a un primer valor particular (por
ejemplo, 0) puede indicar que el video de ojo de pez es monoscópico, y el campo igual
a un segundo valor particular (por ejemplo, 1) puede indicar que el video de ojo de pez
es estereoscópico. Por ejemplo, cuando se genera un archivo que incluye datos de
video de ojo de pez, un dispositivo de preparación de contenidos (por ejemplo,
dispositivo de preparación de contenidos 20 de la FIG. 9) puede codificar una primera
caja (por ejemplo, una FisheyeOmnidirectionalVideoBox) dentro del archivo, donde la
primera caja incluye una segunda caja que incluye un campo que indica explícitamente
si los datos de video de ojo de pez son monoscópicos o estereoscópicos. Un
dispositivo de cliente (por ejemplo, dispositivo de cliente 40 de la FIG. 9) puede
procesar el archivo de manera similar para obtener la indicación explícita de
21
monoscópico o estereoscópico.
[0089] Como otro ejemplo, un campo (por ejemplo, una bandera de un bit) se puede
añadir directamente en la FisheyeOmnidirectionalVideoBox para señalar esta
indicación. Por ejemplo, cuando se genera un archivo que incluye datos de video de
ojo de pez, un dispositivo de preparación de contenidos (por ejemplo, dispositivo de
preparación de contenidos 20 de la FIG. 9) puede codificar una caja (por ejemplo, una
FisheyeOmnidirectionalVideoBox) dentro del archivo, donde la caja incluye un campo
que indica explícitamente si los datos de video de ojo de pez son monoscópicos o
estereoscópicos. Un dispositivo de cliente (por ejemplo, dispositivo de cliente 40 de la
FIG. 9) puede procesar de manera similar el archivo para obtener la indicación
explícita de monoscópico o estereoscópico.
incluye datos de video de ojo de pez como una pluralidad de imágenes circulares
puede incluir, para cada imagen circular respectiva de la pluralidad de imágenes
circulares, una indicación explícita de una identificación de vista respectiva (ID de
vista). En otras palabras, para cada imagen circular de datos de video de ojo de pez,
se puede añadir un campo que indica la ID de vista de cada imagen circular. Cuando
sólo hay dos valores de ID de vista de 0 y 1, entonces la vista con ID de vista igual a 0
puede ser la vista izquierda, y la vista con ID de vista igual a 1 puede ser la vista
derecha. Por ejemplo, cuando la pluralidad de imágenes circulares incluye sólo dos
imágenes circulares, una imagen circular de la pluralidad de imágenes circulares que
tiene una primera identificación de video predeterminado es una vista izquierda y una
imagen circular de la pluralidad de imágenes circulares que tienen una segunda
identificación de video predeterminado es una vista derecha. De esta manera, un
dispositivo de cliente puede evitar tener que inferir qué imagen circular es la vista
izquierda y cuál es la vista derecha a partir de otros parámetros.
[0091] La ID de vista señalada también puede utilizarse para indicar la relación de
emparejamiento de cualquiera de dos imágenes circulares que pertenecen a la misma
vista (por ejemplo, dado que ambas pueden tener el mismo valor de la ID de vista
señalada).
[0092] Para permitir que se pueda acceder fácilmente a las ID de vista sin la
necesidad de analizar todos los parámetros de video de ojo de pez de las imágenes
circulares, se puede añadir un bucle después del campo num_circular_images y antes
del bucle existente. Por ejemplo, el procesamiento del archivo puede incluir analizar,
en un primer bucle, las indicaciones explícitas de las identificaciones de vista; y
22
analizar, en un segundo bucle que es posterior al primer bucle, otros parámetros de
las imágenes circulares. Por ejemplo, las ID de vista y los otros parámetros pueden
analizarse de la siguiente manera:
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
unsigned int(8) num_circular_images;
unsigned int(8) view_id;
}
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
…
}
}
[0093] view_idindica el identificador de vista de la vista a la que pertenece la imagen
circular. Cuando sólo hay dos valores de view_id 0 y 1 para todas las imágenes
circulares, las imágenes circulares con view_id igual a 0 pueden pertenecer a la vista
izquierda, y las imágenes circulares con view_id igual a 1 pueden pertenecer a la vista
derecha. En algunos ejemplos, el elemento de sintaxis que indica el identificador de
vista (es decir, el elemento de sintaxis que indica qué imagen circular es la vista
izquierda y cuál es la vista derecha) puede ser el mismo que el elemento de sintaxis
que indica explícitamente si los datos de video de ojo de pez son estereoscópicos o
monoscópicos.
incluye datos de video de ojo de pez puede incluir una primera caja que incluye una
estructura de sintaxis que contiene parámetros para los datos de video de ojo de pez,
y puede incluir opcionalmente una segunda caja que indica la información de cobertura
para los datos de video de ojo de pez. Por ejemplo, la señalización de la información
de cobertura para el video omnidireccional de ojo de pez se puede añadir a la
FisheyeOmnidirectionalVideoBox. Por ejemplo, puede permitirse que la
CoverageInformationBox como se define en OMAF DIS esté opcionalmente contenida
en la FisheyeOmnidirectionalVideoBox, y cuando no está presente en la
FisheyeOmnidirectionalVideoBox, puede deducirse la cobertura de esfera completa
23
por el video de ojo de pez. Cuando CoverageInformationBox está presente en la
FisheyeOmnidirectionalVideoBox, la región esférica representada por las imágenes de
video de ojo de pez puede ser una región especificada por dos círculos de guiñada y
dos círculos de ángulo. De esta manera, un dispositivo de cliente puede evitar tener
que inferir la información de cobertura a partir de otros parámetros.
incluye datos de video de ojo de pez puede incluir una primera caja que incluye
información de esquema, la primera caja puede incluir una segunda caja que incluye
una estructura de sintaxis que contiene parámetros para los datos de video de ojo de
pez, y la primera caja puede incluir opcionalmente una tercera caja que indica si las
imágenes de los datos de video de ojo de pez se empaquetan por regiones. Por
ejemplo, la RegionWisePackingBox puede incluirse opcionalmente en la
SchemeInformationBox para video omnidireccional de ojo de pez (por ejemplo, cuando
FisheyeOmnidirectionalVideoBox está presente en la SchemeInformationBox,
RegionWisePackingBox puede estar presente en la misma SchemeInformationBox).
En este caso, la presencia de la RegionWisePackingBox indica que las imágenes de
video de ojo de pez se empaquetan por regiones y requieren desempaque antes de su
renderización. De esta manera, uno o más beneficios de empaque por regiones se
pueden lograr para el video de ojo de pez.
[0096] De acuerdo con una o más técnicas de esta divulgación, se puede utilizar
agrupación de composición de sub-imagen para para video omnidireccional de ojo de
pez, y una especificación de la aplicación de agrupación de composición de sub-
imagen se puede añadir al video de ojo de pez omnidireccional. Esa especificación
puede aplicarse cuando alguna de las pistas asignadas al grupo de pista de
composición sub-imagen tiene un tipo de entrada de la muestra igual a 'resv' y
scheme_type igual a 'fodv' en la SchemeTypeBox incluida en la entrada de la muestra.
En este caso, cada imagen compuesta es una imagen empacada que tiene el formato
de ojo de pez indicado por cualquiera de FisheyeOmnidirectionalVideoBox y el formato
de empaque por regiones indicado por cualquiera RegionWisePackingBox que se
incluye en las entradas de ejemplo de las pistas asignadas al grupo de pista de
composición de sub-imagen. Además, puede aplicarse lo siguiente:
[0097] 1) Cada pista asignada a esta agrupación tendrá un tipo de entrada de la
muestra igual a 'resv'. El scheme_type será igual a 'fodv' en la SchemeTypeBox
incluida en la entrada de la muestra.
[0098] 2) El contenido de todas las instancias de la
24
FisheyeOmnidirectionalVideoBox incluidas en las entradas de ejemplo de las pistas
asignadas al mismo grupo de pista de composición de sub-imagen será idéntico.
[0099] 3) El contenido de todas las instancias de la RegionWisePackingBox
incluidas en las entradas de ejemplo de las pistas asignadas al mismo grupo de pista
de composición de sub-imagen será idéntico.
[00100] En el flujo HTTP, las operaciones de uso frecuente incluyen HEAD, GET y
GET parcial. La operación HEAD recupera una cabecera de un archivo asociado con
un localizador de recursos uniformes (URL) o un nombre de recursos uniformes (URN)
dado, sin recuperar una carga útil asociada a la dirección URL o URN. La operación
GET recupera un archivo completo asociado a un URL o URN dado. La operación
GET parcial recibe un intervalo de bytes como parámetro de entrada y recupera un
número continuo de bytes de un archivo, donde el número de bytes corresponde al
rango de bytes recibido. Por lo tanto, se pueden proporcionar fragmentos de películas
al flujo HTTP, dado que una operación GET parcial puede obtener uno o más
fragmentos de películas individuales. En un fragmento de película, puede haber varios
fragmentos de pista de diferentes pistas. En el flujo HTTP, una presentación de
medios puede ser una colección estructurada de datos accesibles para el cliente. El
cliente puede solicitar y descargar información de datos de medios para presentar un
servicio de streaming a un usuario.
[00101] En el ejemplo de streaming de datos 3GPP utilizando el flujo HTTP, puede
haber múltiples representaciones de datos de audio y/o video de contenido multimedia.
Como se explica a continuación, las diferentes representaciones pueden corresponder
a diferentes características de codificación (por ejemplo, diferentes perfiles o niveles
de un estándar de codificación de video), diferentes estándares de codificación o
extensiones de estándares de codificación (tal como extensiones de multiples vistas
y/o escalables), o diferentes velocidades de bits. El manifiesto de tales
representaciones se puede definir en una estructura de datos de Descripción de
Presentación de Medios (MPD). Una presentación de medios puede corresponder a
una colección estructurada de datos accesible a un dispositivo de cliente flujo HTTP.
El dispositivo de cliente de flujo HTTP puede solicitar y descargar información de datos
de medios para presentar un servicio de streaming a un usuario del dispositivo de
cliente. Una presentación de medios puede describirse en la estructura de datos MPD,
que puede incluir actualizaciones de MPD.
[00102] Una presentación de medios puede contener una secuencia de uno o más
Períodos. Cada período puede extenderse hasta el comienzo del próximo período, o
25
hasta el final de la presentación de medios, en el caso del último período. Cada
período puede contener una o más representaciones para el mismo contenido de
medios. Una representación puede ser una de un número de versiones codificadas
alternativas de audio, video, texto temporizado, u otros de tales datos. Las
representaciones pueden diferir por tipos de codificación, por ejemplo, por la velocidad
de bits, resolución, y/o códec para los datos de video y velocidad de bits, idioma, y/o
códec para datos de audio. El término representación puede utilizarse para referirse a
una sección de datos de audio o de video codificados correspondientes a un período
particular del contenido multimedia y codificados de una manera particular.
[00103] Las representaciones de un período particular pueden asignarse a un grupo
indicado por un atributo en la MPD indicativo de un conjunto de adaptación al que
pertenecen las representaciones. Las representaciones en el mismo conjunto de
adaptación generalmente se consideran alternativas entre sí, dado que un dispositivo
de cliente de forma dinámica y sin problemas puede cambiar entre estas
representaciones, por ejemplo, para llevar a cabo la adaptación del ancho de banda.
Por ejemplo, cada representación de datos de video para un período particular puede
asignarse al mismo conjunto de adaptación, de manera que cualquiera de las
representaciones se puede seleccionar para la decodificación para presentar datos de
medios, tales como datos de video o datos de audio, de los contenidos multimedia
para el período correspondiente. El contenido de medios dentro de un período puede
ser representado por una representación de grupo 0, si está presente, o la
combinación de al menos una representación de cada grupo distinto de cero, en
algunos ejemplos. Los datos de tiempo para cada representación de un período
pueden expresarse en relación con el tiempo de inicio del período.
[00104] Una representación puede incluir uno o más segmentos. Cada representación
puede incluir un segmento de inicialización, o cada segmento de una representación
puede ser de auto-inicialización. Cuando está presente, el segmento de inicialización
puede contener información de inicialización para el acceso a la representación. En
general, el segmento de inicialización no contiene datos de medios. Un segmento
puede ser referenciado de forma única por un identificador, tal como un localizador de
recursos uniformes (URL), nombre de recursos uniformes (URN), o identificador de
recursos uniformes (URI). La MPD puede proporcionar los identificadores para cada
segmento. En algunos ejemplos, la MPD también puede proporcionar intervalos de
bytes en la forma de un atributo de rango, que puede corresponder a los datos para un
segmento dentro de un archivo accesible por URL, URN, o URI.
26
[00105] Se pueden seleccionar diferentes representaciones para la recuperación
sustancialmente simultánea de diferentes tipos de datos de medios. Por ejemplo, un
dispositivo de cliente puede seleccionar una representación de audio, una
representación de video, y una representación de texto temporizado de la que se
recuperan segmentos. En algunos ejemplos, el dispositivo de cliente puede
seleccionar conjuntos de adaptación particulares para llevar a cabo la adaptación del
ancho de banda. Es decir, el dispositivo de cliente puede seleccionar un conjunto de
adaptación que incluye representaciones de video, un conjunto de adaptación que
incluye representaciones de audio, y/o un conjunto de adaptación que incluye texto
temporizado. Alternativamente, el dispositivo de cliente puede seleccionar conjuntos
de adaptación para ciertos tipos de medios (por ejemplo, video), y seleccionar
directamente representaciones para otros tipos de medios (por ejemplo, audio y/o
texto temporizado).
[00106] La FIG. 9 es un diagrama de bloques que ilustra un ejemplo de sistema 10
que implementa técnicas para streaming de datos de medios sobre una red. En este
ejemplo, el sistema 10 incluye un dispositivo de preparación de contenidos 20,
dispositivo de servidor 60, y dispositivo de cliente 40. El dispositivo de cliente 40 y el
dispositivo de servidor 60 están acoplados comunicativamente por la red 74, que
puede comprender Internet. En algunos ejemplos, el dispositivo de preparación de
contenidos 20 y el dispositivo de servidor 60 también se pueden acoplar por la red 74
u otra red, o pueden estar directamente acoplados comunicativamente. En algunos
ejemplos, el dispositivo de preparación de contenidos 20 y el dispositivo de servidor 60
pueden comprender el mismo dispositivo.
[00107] El dispositivo de preparación de contenidos 20, en el ejemplo de la FIG. 9,
comprende fuente de audio 22 y fuente de video 24. La fuente de audio 22 puede
comprender, por ejemplo, un micrófono que produce señales eléctricas representativas
de los datos de audio capturados para ser codificados por el codificador de audio 26.
Alternativamente, la fuente de audio 22 puede comprender un medio de
almacenamiento que almacena datos de audio previamente registrados, un generador
de datos de audio tal como un sintetizador automatizado, o cualquier otra fuente de
datos de audio. La fuente de video 24 puede comprender una cámara de video que
produce datos de video para ser codificados por el codificador de video 28, un medio
de almacenamiento codificado con datos de video previamente registrados, una
unidad de generación de datos de video tal como una fuente de gráficos de ordenador,
o cualquier otra fuente de datos de video. El dispositivo de preparación de contenidos
27
20 no está necesariamente acoplado de forma comunicativa al dispositivo de servidor
60 en todos los ejemplos, pero puede almacenar contenido multimedia en un medio
separado que es leído por el dispositivo de servidor 60.
[00108] Los datos de audio y video sin procesar pueden comprender datos analógicos
o digitales. Los datos analógicos pueden ser digitalizados antes de ser codificados por
el codificador de audio 26 y/o el codificador de video 28. La fuente de audio 22 puede
obtener datos de audio de un participante que habla mientras que el participante que
habla está hablando, y la fuente de video 24 puede obtener simultáneamente datos de
video del participante que habla. En otros ejemplos, la fuente de audio 22 puede
comprender un medio de almacenamiento legible por ordenador que comprende datos
de audio almacenados, y la fuente de video 24 puede comprender un medio de
almacenamiento legible por ordenador que comprende datos de video almacenados.
De esta manera, las técnicas descritas en la presente divulgación se pueden aplicar a
datos de audio y video en vivo, en streaming, en tiempo real o a datos de audio y video
archivados, pre-registrados.
[00109] Las tramas de audio que corresponden a los cuadros de video son
generalmente tramas de audio que contienen datos de audio que fueron capturados (o
generados) por la fuente de audio 22 simultáneamente con los datos de video
capturados (o generados) por la fuente de video 24 que está contenida dentro de los
cuadros de video. Por ejemplo, mientras que un participante que habla generalmente
produce datos de audio hablando, la fuente de audio 22 capta los datos de audio, y la
fuente de video 24 capta los datos de video del participante que habla al mismo
tiempo, es decir, mientras que la fuente de audio 22 captura los datos de audio. Por lo
tanto, una trama de audio puede corresponder temporalmente a uno o más cuadros de
video particulares. En consecuencia, una trama de audio correspondiente a un cuadro
de video generalmente corresponde a una situación en la que datos de audio y datos
de video fueron capturados al mismo tiempo y para la que una trama de audio y un
cuadro de video comprenden, respectivamente, los datos de audio y los datos de video
que fueron capturados al mismo tiempo.
[00110] En algunos ejemplos, el codificador de audio 26 puede codificar una marca de
tiempo en cada trama de audio codificada que representa un momento en que se
registran los datos de audio para la trama de audio codificada, y de manera similar, el
codificador de video 28 puede codificar una marca de tiempo en cada cuadro de video
codificado que representa un momento en que se registran los datos de video para el
cuadro de video codificado. En tales ejemplos, una trama de audio correspondiente a
28
un cuadro de video puede comprender una trama de audio que comprende una marca
de tiempo y un cuadro de video que comprende la misma marca de tiempo. El
dispositivo de preparación de contenidos 20 puede incluir un reloj interno a partir del
que el codificador de audio 26 y/o codificador de video 28 pueden generar las marcas
de tiempo, o que la fuente de audio 22 y la fuente de video 24 pueden utilizar para
asociar los datos de audio y video, respectivamente, con una marca de tiempo.
[00111] En algunos ejemplos, la fuente de audio 22 puede enviar datos al codificador
de audio 26 correspondiente a un momento en que se registran los datos de audio, y
la fuente de video 24 puede enviar datos al codificador de video 28 correspondientes a
un momento en que se registran los datos de video. En algunos ejemplos, el
codificador de audio 26 puede codificar un identificador de secuencia en datos de
audio codificados para indicar un ordenamiento temporal relativo de los datos de audio
codificados, pero sin indicar necesariamente un tiempo absoluto en el cual se
registraron los datos de audio, y de manera similar, el codificador de video 28 también
puede utilizar identificadores de secuencia para indicar un ordenamiento temporal
relativo de los datos de video codificados. Del mismo modo, en algunos ejemplos, un
identificador de secuencia se puede asignar o de otra manera correlacionar con una
marca de tiempo.
[00112] El codificador de audio 26 generalmente produce un flujo de datos de audio
codificados, mientras que el codificador de video 28 produce un flujo de datos de video
codificados. Cada flujo individual de datos (ya sea de audio o video) puede ser referido
como un flujo elemental. Un flujo elemental es un único componente codificado
digitalmente, (posiblemente comprimido) de una representación. Por ejemplo, la parte
de video o audio codificado de la representación puede ser un flujo elemental. Un flujo
elemental puede ser convertido en un flujo elemental empaquetado (PES) antes de ser
encapsulado dentro de un archivo de video. Dentro de la misma representación, un ID
de flujo puede utilizarse para distinguir los paquetes PES que pertenecen a un flujo
elemental del otro. La unidad básica de datos de un flujo elemental es un paquete de
flujo elemental en paquetes (PES). Por lo tanto, los datos de video codificados
generalmente corresponden a flujos de video elementales. De manera similar, los
datos de audio corresponden a una o más flujos elementales respectivos.
[00113] Muchos de los estándares de codificación de video, tales como ITU-T
H.264/AVC y el estándar de Codificación de Video de Alta Eficiencia (HEVC), definen
la sintaxis, semántica y proceso de decodificación de flujos de bits sin errores,
cualquiera de los cuales se ajustan a un determinado perfil o nivel. Los estándares de
29
codificación de video típicamente no especifican el codificador, pero el codificador
tiene la tarea de garantizar que los flujos de bits generados sean compatibles con el
estándar para un decodificador. En el contexto de los estándares de codificación de
video, un “perfil” corresponde a un subconjunto de algoritmos, funciones o
herramientas y las restricciones que se aplican a estos. Como se define por el
estándar H.264, por ejemplo, un “perfil” es un subconjunto de toda la sintaxis de flujo
de bits que se especifica por el estándar H.264. Un “nivel” corresponde a las
limitaciones del consumo de recursos del decodificador, tal como, por ejemplo, la
memoria y computación del decodificador, que están relacionados con la resolución de
imágenes, velocidad de bits, y velocidad de transformación de bloque. Un perfil puede
señalarse con un valor profile_idc (indicador de perfil), mientras que un nivel puede
señalarse con un valor level_idc (indicador de nivel).
[00114] El estándar H.264, por ejemplo, reconoce que, dentro de los límites impuestos
por la sintaxis de un perfil dado, todavía es posible requerir una gran variación en el
rendimiento de los codificadores y decodificadores, dependiendo de los valores
tomados por los elementos de sintaxis en el flujo de bits, tal como el tamaño
especificado de las imágenes decodificadas. El estándar H.264 reconoce, además,
que, en muchas aplicaciones, no es ni práctico ni económico implementar un
decodificador capaz de hacer frente a todos los usos hipotéticos de la sintaxis dentro
de un perfil particular. De acuerdo con ello, el estándar H.264 define un “nivel” como
un conjunto especificado de restricciones impuestas en los valores de los elementos
de sintaxis en el flujo de bits. Estas limitaciones pueden ser simples límites sobre los
valores. Alternativamente, estas limitaciones pueden tomar la forma de restricciones
sobre las combinaciones aritméticas de valores (por ejemplo, ancho de imagen
multiplicado por altura de imagen multiplicado por el número de imágenes
decodificadas por segundo). El estándar H.264 proporciona, además, que las
implementaciones individuales pueden soportar un nivel diferente para cada perfil
soportado.
[00115] Un decodificador conforme a un perfil normalmente soporta todas las
características definidas en el perfil. Por ejemplo, como una característica de
codificación, la codificación de imagen B no se admite en el perfil de la línea de base
de H.264/AVC, pero se admite en otros perfiles de H.264/AVC. Un decodificador
conforme a un nivel debe ser capaz de decodificar cualquier flujo de bits que no
requiera recursos más allá de las limitaciones definidas en el nivel. Las definiciones de
perfiles y niveles pueden ser útiles para interpretabilidad. Por ejemplo, durante la
30
transmisión de video, un par de definiciones de perfil y nivel puede ser negociado y
acordado para una sesión de transmisión de conjunto. Más específicamente, en
H.264/AVC, un nivel puede definir limitaciones en el número de macrobloques que
necesitan ser procesados, tamaño de búfer de imagen decodificada (DPB), tamaño de
búfer de imagen codificada (CPB), rango de vector de movimiento vertical, número
máximo de vectores de movimiento por dos MB consecutivos, y si un bloque B puede
tener particiones de submacrobloques menores que 8x8 píxeles. De esta manera, un
decodificador puede determinar si el decodificador es capaz de decodificar
correctamente el flujo de bits.
[00116] En el ejemplo de la FIG. 9, la unidad de encapsulamiento 30 del dispositivo de
preparación de contenidos 20 recibe flujos elementales que comprenden datos de
video codificados del codificador de video 28 y flujos elementales que comprenden
datos de audio codificados del codificador de audio 26. En algunos ejemplos, el
codificador de video 28 y el codificador de audio 26 pueden incluir cada uno
empaquetadores para formar paquetes PES de datos codificados. En otros ejemplos,
el codificador de video 28 y el codificador de audio 26 pueden estar en interfaz con
empaquetadores respectivos para la formación de paquetes PES de datos codificados.
En aún otros ejemplos, la unidad de encapsulamiento 30 puede incluir
empaquetadores para la formación de paquetes PES de datos de audio y video
codificados.
[00117] El codificador de video 28 puede codificar datos de video de contenido
multimedia en una variedad de maneras, para producir diferentes representaciones del
contenido multimedia en diferentes velocidades de bits y con diferentes características,
tal como píxeles de resolución, velocidad de cuadros, conformidad con varios
estándares de codificación, conformidad con varios perfiles y/o niveles de perfiles para
diferentes estándares de codificación, representaciones que tienen uno o múltiples
vistas (por ejemplo, para reproducción en dos dimensiones o tres dimensiones), u
otras tales características. Una representación, de acuerdo con lo utilizado en esta
divulgación, puede comprender uno de los datos de audio, datos de video, datos de
texto (por ejemplo, para subtítulos), u otros de tales datos. La representación puede
incluir un flujo elemental, tal como un flujo elemental de audio o un flujo elemental de
video. Cada paquete PES puede incluir un stream_id que identifica el flujo elemental al
que pertenece el paquete PES. La unidad de encapsulamiento 30 es responsable del
montaje de flujos elementales en archivos de video (por ejemplo, segmentos) de
diversas representaciones.
31
[00118] La unidad de encapsulamiento 30 recibe paquetes PES para los flujos
elementales de una representación de codificador de audio 26 y codificador de video
28 y forma unidades de capa de abstracción de red (NAL) correspondientes de los
paquetes PES. Los segmentos de video codificados pueden ser organizados en
unidades NAL, que proporcionan una representación de video “amigable con la red”
dando cauce a aplicaciones tales como telefonía de video, almacenamiento, difusión o
streaming. Las unidades NAL se pueden categorizar en unidades NAL de Capa de
Codificación de Video (VCL) y unidades NAL no VCL. Las unidades VCL pueden
contener el motor de compresión del núcleo y pueden incluir datos de bloque,
macrobloque, y/o nivel de porción. Otras unidades NAL pueden ser unidades NAL no
VCL. En algunos ejemplos, una imagen codificada en un instante de tiempo,
normalmente presentada como una imagen codificada principal, puede estar contenida
en una unidad de acceso, que puede incluir una o más unidades NAL.
[00119] Las unidades NAL no VCL pueden incluir unidades NAL de conjuntos de
parámetros y unidades SEI NAL, entre otras. Los conjuntos de parámetros pueden
contener información de cabecera de nivel de secuencia (en conjuntos de secuencias
de parámetros (SPS)) y la información de cabecera de nivel de imagen cambiante con
poca frecuencia (en conjuntos de parámetros de imagen (PPS)). Con los conjuntos de
parámetros (por ejemplo, PPS y SPS), la información de cambio con poca frecuencia
no necesita ser repetida para cada secuencia o imagen, por lo tanto, la eficiencia de
codificación puede mejorarse. Además, el uso de conjuntos de parámetros puede
permitir la transmisión fuera de banda de la información de cabecera importante,
evitando la necesidad de transmisiones redundantes para la capacidad de
recuperación de error. En ejemplos de transmisión fuera de banda, las unidades NAL
de conjuntos de parámetros se pueden transmitir en un canal diferente que otras
unidades NAL, tal como unidades de SEI NAL.
[00120] La Información de Mejora Suplementaria (SEI) puede contener información
que no es necesaria para la decodificación de las muestras de imágenes codificadas
de unidades NAL VCL, pero puede ayudar en los procesos relacionados con la
decodificación, visualización, capacidad de recuperación de error, y otros propósitos.
Los mensajes SEI pueden estar contenidos en unidades NAL no VCL. Los mensajes
SEI son la parte normativa de algunas especificaciones de estándar, y por lo tanto no
siempre son obligatorios para la implementación de decodificador compatible con
estándar. Los mensajes SEI pueden ser mensajes SEI a nivel de secuencia o
mensajes SEI a nivel de imagen. Cierta información de nivel de secuencia puede estar
32
contenida en los mensajes SEI, tal como mensajes SEI de información de
escalabilidad en el ejemplo de SVC y mensajes SEI de información de escalabilidad de
vista en MVC. Estos mensajes SEI de ejemplo pueden llevar información sobre, por
ejemplo, la extracción de puntos de operación y características de los puntos de
operación. Además, la unidad de encapsulamiento 30 puede formar un archivo de
manifiesto, tal como un descriptor de presentación de medios (MPD) que describe
características de las representaciones. La unidad de encapsulamiento 30 puede
formatear la MPD de acuerdo con lenguaje de marcado extensible (XML).
[00121] La unidad de encapsulamiento 30 puede proporcionar datos para una o más
representaciones de contenido multimedia, junto con el archivo de manifiesto (por
ejemplo, la MPD) a la interfaz de salida 32. La interfaz de salida 32 puede comprender
una interfaz de red o una interfaz para escribir en un medio de almacenamiento, tal
como una interfaz de bus de serie universal (USB), un grabador de CD o DVD, una
interfaz para medios de almacenamiento magnético o flash, u otras interfaces para
almacenar o transmitir datos de medios. La unidad de encapsulamiento 30 puede
proporcionar datos de cada una de las representaciones de contenido multimedia a la
interfaz de salida 32, que puede enviar los datos al dispositivo de servidor 60 a través
de la red de transmisión o medio de almacenamiento. En el ejemplo de la FIG. 9, el
dispositivo de servidor 60 incluye medio de almacenamiento 62 que almacena varios
contenidos multimedia 64, incluyendo cada uno un respectivo archivo de manifiesto 66
y una o más representaciones 68A-68N (representaciones 68). En algunos ejemplos,
la interfaz de salida 32 también puede enviar los datos directamente a la red 74.
[00122] En algunos ejemplos, las representaciones 68 pueden separarse en conjuntos
de adaptación. Es decir, varios subconjuntos de representaciones 68 pueden incluir
respectivos conjuntos de características comunes, tales como códec, perfil y nivel,
resolución, número de puntos de vista, formato de archivo para segmentos,
información del tipo de texto que puede identificar un idioma u otras características del
texto para ser exhibidas con la representación y/o datos de audio a ser decodificados y
presentados, por ejemplo, por altavoces, información de ángulo de cámara que pueda
describir una perspectiva de ángulo de cámara o cámara en el mundo real de un
escenario para representaciones en el conjunto de adaptación, información de
clasificación, que describe la adecuación de contenido para audiencias particulares, o
similares.
[00123] El archivo de manifiesto 66 puede incluir datos indicativos de los subconjuntos
de representaciones 68 correspondientes a conjuntos de adaptación particulares, así
33
como características comunes de los conjuntos de adaptación. El archivo de
manifiesto 66 también puede incluir datos representativos de las características
individuales, tales como velocidades de bits, para las representaciones individuales de
los conjuntos de adaptación. De esta manera, un conjunto de adaptación puede
proporcionar adaptación simplificada de ancho de banda de la red. Las
representaciones en un conjunto de adaptación se pueden indicar utilizando elementos
secundarios de un elemento de conjunto de adaptación de archivo de manifiesto 66.
En algunos ejemplos, el archivo de manifiesto 66 puede incluir algunos o todos los
datos de FisheyeOmnidirectionalVideoInfo () discutidos en la presente, o datos
similares. Adicional o alternativamente, los segmentos de representaciones 68 pueden
incluir algunos o todos los datos de FisheyeOmnidirectionalVideoInfo () discutidos en
la presente, o datos similares.
[00124] El dispositivo de servidor 60 incluye una unidad de procesamiento de solicitud
70 e interfaz de red 72. En algunos ejemplos, el dispositivo de servidor 60 puede
incluir una pluralidad de interfaces de red. Además, cualquiera o todas las
características del dispositivo de servidor 60 se puede implementar en otros
dispositivos de una red de entrega de contenido, tal como routers, puentes,
dispositivos de proxy, interruptores, u otros dispositivos. En algunos ejemplos, los
dispositivos intermedios de una red de entrega de contenido pueden almacenar en
memoria caché de datos de contenido multimedia 64, e incluyen componentes
sustancialmente conformes con el dispositivo de servidor 60. En general, la interfaz de
red 72 está configurada para enviar y recibir datos a través de la red 74.
[00125] La unidad de procesamiento de solicitud 70 está configurada para recibir
solicitudes de red de los dispositivos de cliente, tal como dispositivo de cliente 40, para
los datos de medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento
de solicitud 70 puede implementar el protocolo de transferencia de hipertexto (HTTP)
versión 1.1, como se describe en RFC 2616 “Hypertext Transfer Protocol - HTTP /
1.1,” de R. Fielding et al, Network Working Group, IETF, June 1999. Es decir, la unidad
de procesamiento de solicitud 70 puede estar configurada para recibir solicitudes
HTTP GET o GET parciales y proporcionar datos de contenido multimedia 64 en
respuesta a las solicitudes. Las solicitudes pueden especificar un segmento de una de
las representaciones 68, por ejemplo, mediante una URL del segmento. En algunos
ejemplos, las solicitudes también pueden especificar uno o más intervalos de bytes del
segmento, que comprenden por lo tanto solicitudes GET parciales. La unidad de
procesamiento de solicitud 70 puede estar configurada para servir solicitudes HTTP
34
HEAD para proporcionar datos de cabecera de un segmento de una de las
representaciones 68. En cualquier caso, la unidad de procesamiento de solicitud 70
puede estar configurada para procesar las solicitudes para proporcionar datos
solicitados a un dispositivo de solicitud, tal como dispositivo de cliente 40.
[00126] Adicional o alternativamente, la unidad de procesamiento de solicitud 70 se
puede configurar para entregar datos de medios a través de un protocolo de difusión o
multidifusión, tal como eMBMS. El dispositivo de preparación de contenidos 20 puede
crear segmentos DASH y/o sub-segmentos sustancialmente de la misma manera que
se describe, pero el dispositivo de servidor 60 puede entregar estos segmentos o sub-
segmentos utilizando eMBMS u otro protocolo de transporte de red de difusión o de
multidifusión. Por ejemplo, la unidad de procesamiento de solicitud 70 puede estar
configurada para recibir una solicitud de unión a un grupo de multidifusión del
dispositivo de cliente 40. Es decir, el dispositivo de servidor 60 puede anunciar una
dirección de protocolo de Internet (IP) asociada con un grupo de multidifusión a los
dispositivos de cliente, incluyendo el dispositivo de cliente 40, asociada con contenido
de medios particular (por ejemplo, una transmisión de un evento en vivo). El
dispositivo de cliente 40, a su vez, pueden presentar una solicitud para unirse al grupo
de multidifusión. Esta solicitud puede propagarse a través de la red 74, por ej., routers
que componen la red 74, de manera se fuerza a tales routers a dirigir el tráfico
destinado a la dirección de IP asociada con el grupo de múltiples transmisiones a los
dispositivos de clientes suscriptos, tal como dispositivo de cliente 40.
[00127] Como se ilustra en el ejemplo de la FIG. 9, el contenido multimedia 64 incluye
un archivo de manifiesto 66, que puede corresponder a una descripción de
presentación de medios (MPD). El archivo de manifiesto 66 puede contener
descripciones de diferentes representaciones alternativas 68 (por ejemplo, servicios de
video con diferentes cualidades) y la descripción puede incluir, por ejemplo,
información de códec, un valor de perfil, un valor de nivel, una velocidad de bits, y
otras características descriptivas de las representaciones 68. El dispositivo de cliente
40 puede recuperar la MPD de una presentación de medios para determinar cómo
acceder a segmentos de representaciones 68.
[00128] En particular, la unidad de recuperación 52 puede recuperar datos de
configuración (no mostrado) del dispositivo de cliente 40 para determinar las
capacidades de decodificación de decodificador de video 48 y las capacidades de
renderización de salida de video 44. Los datos de configuración pueden también incluir
cualquiera o todos de una preferencia de idioma seleccionada por un usuario del
35
dispositivo de cliente 40, una o más perspectivas de cámara correspondientes a las
preferencias de profundidad establecidas por el usuario del dispositivo de cliente 40,
y/o una preferencia de clasificación seleccionada por el usuario del dispositivo de
cliente 40. La unidad de recuperación 52 puede comprender, por ejemplo, un
navegador web o cliente de medios configurado para enviar solicitudes HTTP GET y
GET parciales. La unidad de recuperación 52 puede corresponder a instrucciones de
software ejecutadas por uno o más procesadores o unidades de procesamiento (no
mostrado) del dispositivo de cliente 40. En algunos ejemplos, la totalidad o porciones
de la funcionalidad descrita con respecto a la unidad de recuperación 52 pueden
implementarse en hardware, o una combinación de hardware, software, y/o firmware,
donde el requisito de hardware puede proporcionarse para ejecutar instrucciones para
software o firmware.
[00129] La unidad de recuperación 52 puede comparar las capacidades de
decodificación y renderización del dispositivo de cliente 40 con las características de
las representaciones 68 indicadas por la información de archivo de manifiesto 66. Por
ejemplo, la unidad de recuperación 52 puede determinar si el dispositivo de cliente 40
(tal como la salida de video 44) es capaz de renderización de datos estereoscópicos o
sólo de datos monoscópicos. La unidad de recuperación 52 puede recuperar
inicialmente al menos una porción de archivo de manifiesto de 66 para determinar las
características de las representaciones 68. Por ejemplo, la unidad de recuperación 52
puede solicitar una porción del archivo de manifiesto 66 que describe características
de uno o más conjuntos de adaptación. La unidad de recuperación 52 puede
seleccionar un subconjunto de representaciones 68 (por ejemplo, un conjunto de
adaptación) que tiene características que pueden ser satisfechas por las capacidades
de codificación y renderización del dispositivo de cliente 40. La unidad de recuperación
52 puede entonces determinar velocidades de bits para las representaciones en el
conjunto de adaptación, determinar una cantidad actualmente disponible de ancho de
banda de red, y recuperar segmentos de una de las representaciones que tienen una
velocidad de bits que puede ser satisfecha por el ancho de banda de red. De acuerdo
con las técnicas de la presente divulgación, la unidad de recuperación 52 puede
recuperar datos que indican si los datos de video de ojo de pez correspondientes son
monoscópicos o estereoscópicos. Por ejemplo, la unidad de recuperación 52 puede
recuperar una porción inicial de un archivo (por ejemplo, un segmento) de una de las
representaciones 68 para determinar si el archivo incluye datos de video de ojo de pez
monoscópicos o estereoscópicos, y determinar si recuperar datos de video del archivo,
36
o un archivo diferente de una diferente de las representaciones 68, de acuerdo con si
el dispositivo de cliente 40 es capaz de renderización de los datos de video de ojo de
pez del archivo.
[00130] En general, las representaciones de velocidad de bits más altas pueden
proporcionar reproducción de video de mayor calidad, mientras que las
representaciones de velocidad de bits inferiores pueden proporcionar reproducción de
video de suficiente calidad cuando el ancho de banda disponible de la red disminuye.
Por consiguiente, cuando el ancho de banda de red disponible es relativamente alto, la
unidad de recuperación 52 puede recuperar datos de representaciones de velocidad
de bits relativamente alta, mientras que cuando el ancho de banda de red disponible
es bajo, la unidad de recuperación 52 puede recuperar datos de representaciones de
velocidad de bits relativamente baja. De esta manera, el dispositivo de cliente 40
puede transmitir datos multimedia a través de la red 74 y al mismo tiempo adaptarse a
cambios en la disponibilidad de ancho de banda de la red 74.
[00131] Adicional o alternativamente, la unidad de recuperación 52 puede estar
configurada para recibir datos de acuerdo con un protocolo de difusión o red de
multidifusión, tal como eMBMS o multidifusión IP. En tales ejemplos, la unidad de
recuperación 52 puede presentar una solicitud para unirse a un grupo de red de
multidifusión asociada con contenido de medios particular. Después de unirse al grupo
de multidifusión, la unidad de recuperación 52 puede recibir datos del grupo de
multidifusión sin solicitudes adicionales emitidas al dispositivo del servidor 60 o el
dispositivo de preparación de contenidos 20. La unidad de recuperación 52 puede
enviar una solicitud para abandonar el grupo de multidifusión cuando los datos del
grupo de multidifusión ya no sean necesarios, por ejemplo, para detener la
reproducción o para cambiar de canal a un grupo de multidifusión diferente.
[00132] La interfaz de red 54 puede recibir y proporcionar datos de segmentos de una
representación seleccionada a la unidad de recuperación 52, que puede a su vez
proporcionar los segmentos a una unidad de desencapsulamiento 50. La unidad de
desencapsulamiento 50 puede desencapsular elementos de un archivo de video en
flujos de PES constituyentes, desempaquetar los flujos de PES para recuperar los
datos codificados, y enviar los datos codificados al decodificador de audio 46 o
decodificador de video 48, dependiendo de si los datos codificados son una porción de
un flujo de audio o de video, por ejemplo, como se indica por cabeceras de paquetes
PES del flujo. El decodificador de audio 46 decodifica datos de audio codificados y
envía los datos de audio decodificados a la salida de audio 42, mientras que el
37
decodificador de video 48 decodifica los datos de video codificados y envía los datos
de video decodificados, que pueden incluir una pluralidad de vistas de un flujo, a la
salida de video 44.
[00133] El codificador de video 28, decodificador de video 48, codificador de audio 26,
decodificador de audio 46, unidad de encapsulamiento 30, unidad de recuperación 52,
y unidad de desencapsulamiento 50 pueden implementarse como cualquiera de una
variedad de circuitos de procesamiento adecuados, según corresponda, tal como uno
o más microprocesadores, procesadores de señales digitales (DSP), circuitos
integrados de aplicación específica (ASIC), matrices de puertas programables (FPGA),
circuitos de lógica discreta, software, hardware, firmware o cualquier combinación de
los mismos. Cada uno de codificador de video 28 y decodificador de video 48 pueden
incluirse en uno o más codificadores o decodificadores, cualquiera de los cuales puede
estar integrado como porción de un codificador/decodificador de video combinado
(CÓDEC). Del mismo modo, cada uno de codificador de audio 26 y decodificador de
audio 46 pueden incluirse en uno o más codificadores o decodificadores, cualquiera de
los cuales puede estar integrado como parte de un CÓDEC combinado. Un aparato
que incluye codificador de video 28, decodificador de video 48, codificador de audio
26, decodificador de audio 46, unidad de encapsulamiento 30, unidad de recuperación
52, y/o unidad de desencapsulamiento 50 puede comprender un circuito integrado, un
microprocesador, y/o dispositivo de comunicación inalámbrica, tal como un teléfono
celular.
[00134] El dispositivo de cliente 40, dispositivo de servidor 60, y/o dispositivo de
preparación de contenidos 20 puede estar configurado para operar de acuerdo con las
técnicas de la presente divulgación. Para los propósitos de ejemplo, esta divulgación
describe estas técnicas con respecto al dispositivo de cliente 40 y el dispositivo de
servidor 60. Sin embargo, debe comprenderse que el dispositivo de preparación de
contenidos 20 puede estar configurado para llevar a cabo estas técnicas, en lugar del
(o además del) dispositivo de servidor 60.
[00135] La unidad de encapsulamiento 30 puede formar unidades NAL que
comprenden una cabecera que identifica a un programa al que pertenece la unidad
NAL, así como una carga útil, por ejemplo, datos de audio, datos de video, o datos que
describen el flujo de transporte o programa al que corresponde la unidad NAL. Por
ejemplo, en H.264/AVC, una unidad NAL incluye una cabecera de 1 byte y una carga
útil de tamaño variable. Una unidad NAL que incluye datos de video en su carga útil
puede comprender varios niveles de granularidad de datos de video. Por ejemplo, una
38
unidad NAL puede comprender un bloque de datos de video, una pluralidad de
bloques, una porción de datos de video, o una imagen completa de datos de video. La
unidad de encapsulamiento 30 puede recibir datos de video codificados del codificador
de video 28 en forma de paquetes PES de flujos elementales. La unidad de
encapsulamiento 30 puede asociar cada flujo elemental con un programa
correspondiente.
[00136] La unidad de encapsulamiento 30 puede también ensamblar unidades de
acceso de una pluralidad de unidades NAL. En general, una unidad de acceso puede
comprender una o más unidades NAL para representar un cuadro de datos de video,
así como datos de audio correspondientes a la trama cuando tales datos de audio
están disponibles. Una unidad de acceso incluye en general todas las unidades NAL
para un ejemplo de tiempo de salida, por ejemplo, todos los datos de audio y de video
para una instancia de tiempo. Por ejemplo, si cada vista tiene una velocidad de 20
cuadros por segundo (fps), entonces cada instante de tiempo puede corresponder a un
intervalo de tiempo de 0,05 segundos. Durante este intervalo de tiempo, los cuadros
específicos para todas las vistas de la misma unidad de acceso (el mismo instante de
tiempo) se pueden representar simultáneamente. En un ejemplo, una unidad de
acceso puede comprender una imagen codificada en un instante de tiempo, que puede
ser presentada como una imagen codificada principal.
[00137] En consecuencia, una unidad de acceso puede comprender todos los cuadros
de audio y video de una instancia temporal común, por ejemplo, todas las vistas
correspondientes al tiempo X. Esta divulgación también se refiere a una imagen
codificada de una vista particular tal como un “componente de vista”. Es decir, un
componente de vista puede comprender una imagen codificada (o marco) para una
vista particular en un momento particular. En consecuencia, una unidad de acceso se
puede definir como que comprende todos los componentes de vista de una instancia
temporal común. El orden de decodificación de unidades de acceso no tiene que ser
necesariamente igual al orden de salida o visualización.
[00138] Una presentación de medios puede incluir una descripción de presentación de
medios (MPD), que puede contener descripciones de diferentes representaciones
alternativas (por ejemplo, servicios de video con diferentes cualidades) y la descripción
pueden incluir, por ejemplo, información códec, un valor de perfil, y un valor de nivel.
Una MPD es un ejemplo de un archivo de manifiesto, tal como archivo de manifiesto
66. El dispositivo de cliente 40 puede recuperar la MPD de una presentación
multimedia para determinar cómo acceder a fragmentos de película de varias
39
presentaciones. Los fragmentos de película pueden estar situados en cajas de
fragmentos de película (cajas moof) de archivos de video.
[00139] El archivo de manifiesto 66 (que puede comprender, por ejemplo, una MPD)
puede anunciar la disponibilidad de segmentos de representaciones 68. Es decir, la
MPD puede incluir información que indica el tiempo de reloj de pared al que un primer
segmento de una de las representaciones 68 se torna disponible, así como
información que indica las duraciones de segmentos dentro de las representaciones
68. De esta manera, la unidad de recuperación 52 del dispositivo de cliente 40 puede
determinar cuándo cada segmento está disponible, con base en la hora de inicio, así
como las duraciones de los segmentos precedentes a un segmento particular.
[00140] Después de que la unidad de encapsulamiento 30 ha ensamblado las
unidades NAL y/o unidades de acceso en un archivo de video con base en los datos
recibidos, la unidad de encapsulamiento 30 pasa el archivo de video a la interfaz de
salida 32 para la salida. En algunos ejemplos, la unidad de encapsulamiento 30 puede
almacenar el archivo de video de forma local o enviar el archivo de video a un servidor
remoto a través de la interfaz de salida 32, en lugar de enviar el archivo de video
directamente a un dispositivo de cliente 40. La interfaz de salida 32 puede
comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para la
escritura de datos a un medio legible por ordenador tal como, por ejemplo, una unidad
óptica, una unidad de medios magnético (por ejemplo, unidad de disco flexible), un
puerto de bus de serie universal (USB), una interfaz de red, u otra interfaz de salida.
La interfaz de salida 32 da salida al archivo de video a un medio legible por ordenador,
tal como, por ejemplo, una señal de transmisión, un medio magnético, un medio
óptico, una memoria, una unidad flash, u otro medio legible por ordenador.
[00141] La interfaz de red 54 puede recibir una unidad NAL o unidad de acceso a
través de la red 74 y proporcionar la unidad NAL o unidad de acceso a la unidad de
desencapsulamiento 50, a través de la unidad de recuperación 52. La unidad de
desencapsulamiento 50 puede desencapsular elementos de un archivo de video en
flujos PES constituyentes, desempaquetar los flujos PES para recuperar los datos
codificados, y enviar los datos codificados al decodificador de audio 46 o decodificador
de video 48, dependiendo de si los datos codificados son parte de un flujo de audio o
de video, por ejemplo, como se indica por PES cabeceras de los paquetes del flujo. El
decodificador de audio 46 decodifica datos de audio codificados y envía los datos de
audio decodificados a la salida de audio 42, mientras que el decodificador de video 48
decodifica los datos de video codificados y envía los datos de video decodificados, que
40
pueden incluir una pluralidad de vistas de un flujo, a la salida de video 44.
[00142] De esta manera, el dispositivo de cliente 40 representa un ejemplo de un
dispositivo para la recuperación de datos de medios, el dispositivo incluye un
dispositivo para la recuperación de archivos de datos de video de ojo de pez como se
ha descrito anteriormente y/o como se reivindica a continuación. Por ejemplo, el
dispositivo de cliente 40 puede recuperar archivos de datos de video de ojo de pez y/o
representar video de ojo de pez sobre la base de una determinación de si el video de
ojo de pez es monoscópico o estereoscópico y esta determinación puede estar basada
en un elemento de sintaxis que especifica explícitamente si el video de ojo de pez es
monoscópico o estereoscópico.
[00143] De manera similar, el dispositivo de preparación de contenidos 20 representa
un dispositivo para generar archivos de datos de video de ojo de pez como se ha
descrito anteriormente y/o como se reivindica a continuación. Por ejemplo, el
dispositivo de preparación de contenidos 20 puede incluir, en datos de video de ojo de
pez, un elemento de sintaxis que especifica explícitamente si el video de ojo de pez
son monoscópico o estereoscópico.
[00144] La FIG. 10 es un diagrama conceptual que ilustra elementos de contenido
multimedia de ejemplo 120. El contenido multimedia 120 puede corresponder a un
contenido multimedia 64 (FIG. 9), u otro contenido multimedia almacenado en un
medio de almacenamiento 62. En el ejemplo de la FIG. 10, el contenido multimedia
120 incluye descripción de presentación de medios (MPD) 122 y una pluralidad de
representaciones 124A-124N (representaciones 124). La representación 124A incluye
datos de cabecera opcionales 126 y segmentos 128A-128N (segmentos 128),
mientras que la representación 124N incluye datos de cabecera opcionales 130 y
segmentos 132A-132N (segmentos 132). La letra N se utiliza para designar el último
fragmento de película en cada una de las representaciones 124 como una cuestión de
conveniencia. En algunos ejemplos, puede haber diferentes números de fragmentos
de películas entre las representaciones 124.
[00145] MPD 122 puede comprender una estructura de datos separada de las
representaciones 124. MPD 122 puede corresponder al archivo de manifiesto 66 de la
FIG. 9. En general, MPD 122 puede incluir datos que describen generalmente
características de representaciones 124, tal como las características de codificación y
renderización, conjuntos de adaptación, un perfil al que MPD 122 corresponde,
información de tipo de texto, información de ángulo de la cámara, información de
calificación, información de modo de truco (por ejemplo, información indicativa de las
41
representaciones que incluyen sub-secuencias temporales), y/o información para la
recuperación de períodos remotos (por ejemplo, para la inserción de anuncios dirigidos
en contenido de medios durante la reproducción).
[00146] Los datos de cabecera 126, cuando están presentes, pueden describir
características de segmentos 128, por ejemplo, ubicaciones temporales de puntos de
acceso aleatorio (RAP, también denominados puntos de acceso de flujo (SAP)), cuyos
segmentos 128 incluyen puntos de acceso aleatorio, desplazamientos de bytes
aleatorios de puntos de acceso dentro de los segmentos 128, localizadores de
recursos uniformes (URL) de los segmentos 128, u otros aspectos de los segmentos
128. Los datos de cabecera 130, cuando están presentes, pueden describir
características similares para los segmentos 132. Adicional o alternativamente, tales
características pueden estar completamente incluidas dentro de MPD 122.
[00147] Los segmentos 128, 132 incluyen uno o más muestras de video codificado,
cada una de las cuales puede incluir cuadros o porciones de datos de video. Cada una
de las muestras de video codificado de segmentos 128 puede tener características
similares, por ejemplo, requisitos de altura, ancho, y ancho de banda. Tales
características pueden ser descritas por los datos de MPD 122, aunque estos datos no
se ilustran en el ejemplo de la FIG. 10. MPD 122 puede incluir características de
acuerdo con lo descrito en la Especificación 3GPP, con la adición de cualquiera o toda
la información señalada que se describe en esta divulgación.
[00148] Cada uno de los segmentos 128, 132 puede estar asociado con un
localizador de recursos uniformes (URL). Por lo tanto, cada uno de los segmentos 128,
132 puede ser independientemente recuperable utilizando un protocolo de red de
streaming, tal como DASH. De esta manera, un dispositivo diana, tal como el
dispositivo de cliente 40, puede utilizar una solicitud HTTP GET para recuperar
segmentos 128 o 132. En algunos ejemplos, el dispositivo de cliente 40 puede utilizar
solicitudes HTTP GET parciales para recuperar intervalos de bytes específicos de
segmentos 128 o 132.
[00149] La FIG. 11 es un diagrama de bloque de elementos de un ejemplo de archivo
de video 150, que puede corresponder a un segmento de una representación, tal como
uno de los segmentos 114, 124 de la FIG. 10. Cada uno de los segmentos 128, 132
puede incluir datos que se ajusta sustancialmente a la disposición de los datos
ilustrados en el ejemplo de la FIG. 11. Puede decirse que el archivo de video 150
encapsula un segmento. Como se describió anteriormente, los archivos de video de
acuerdo con el formato de archivo multimedia de base ISO y sus extensiones
42
almacenan datos en una serie de objetos, denominados “cajas”. En el ejemplo de la
FIG. 11, el archivo de video 150 incluye la caja de tipo de archivo (ftyp) 152, la caja de
película (MOOV) 154, la caja de índice de segmento (SIDX) 162, la caja de fragmento
de película (MOOF) 164, y la caja de fragmento de película acceso aleatorio (MFRA)
166. Aunque la FIG. 11 representa un ejemplo de un archivo de video, debe
comprenderse que otros archivos de medios pueden incluir otros tipos de datos de
medios (por ej., datos de audio, datos de texto temporizado, o similares) estructurados
de manera similar a los datos de archivo de video 150, de acuerdo con el formato de
archivo multimedia de base ISO y sus extensiones.
[00150] La caja de tipo de archivo (FTYP) 152 describe en general un tipo de archivo
para archivo de video 150. La caja de tipo de archivo 152 puede incluir datos que
identifican una especificación que describe un mejor uso para tipo de video 150. La
caja de tipo de archivo 152 alternativamente puede estar colocada antes de la caja
MOOV 154, cajas de fragmentos de película de 164, y/o una caja MFRA 166.
[00151] En algunos ejemplos, un segmento, tal como archivo de video 150, puede
incluir una caja de actualización MPD (no mostrado) antes de la caja FTYP 152. La
caja de actualización MPD puede incluir información que indique que una MPD
correspondiente a una renderización que incluye archivo de video 150 está siendo
actualizada, junto con la información para la actualización de la MPD. Por ejemplo, la
caja de actualización MPD puede proporcionar URI o URL de un recurso que se utiliza
para actualizar la MPD. Como otro ejemplo, la caja de actualización MPD puede incluir
datos para la actualización de la MPD. En algunos ejemplos, la caja de actualización
de la MPD puede seguir inmediatamente a una caja de tipo de segmento (STYP) (no
mostrado) del archivo de video 150, donde la caja STYP puede definir un tipo de
segmento para el archivo de video 150.
[00152] La caja MOOV 154, en el ejemplo de la FIG. 11, incluye caja de cabecera de
película (MVHD) 156, caja de pista (TRAK) 158, y una o más cajas de extensión de
película (MVEX) 160. En general, la caja MVHD 156 puede describir las características
generales de archivo de video 150. Por ejemplo, la caja MVHD 156 puede incluir datos
que describen cuándo se creó originalmente un archivo de video 150, cuándo se
modificó por última vez un archivo de video 150, una escala de tiempo para el archivo
de video 150, una duración de la reproducción de archivos de video 150, u otros datos
que generalmente describen archivos de video 150.
[00153] La caja TRAK 158 puede incluir datos para un registro de archivo de video
150. La caja TRAK 158 puede incluir una caja de cabecera de pista (TKHD) que
43
describe las características de la pista correspondiente a la caja TRAK 158. En
algunos ejemplos, la caja TRAK 158 puede incluir imágenes de video codificado,
mientras que, en otros ejemplos, las imágenes de video codificado de la pista pueden
ser incluidas en fragmentos de película 164, que pueden ser referenciados por los
datos de imagen de la caja TRAK 158 y/o cajas sidx 162.
[00154] En algunos ejemplos, el archivo de video 150 puede incluir más de una pista.
De acuerdo con ello, la caja MOOV 154 puede incluir un número de cajas TRAK igual
al número de pistas en archivo de video 150. La caja TRAK 158 puede describir las
características de una pista correspondiente del archivo de video 150. Por ejemplo, la
caja TRAK 158 puede describir información temporal y/o espacial para la pista
correspondiente. Una caja TRAK similar a la caja TRAK 158 de la caja MOOV 154
puede describir las características de una pista de conjunto de parámetros, cuando la
unidad de encapsulamiento 30 (FIG. 9) incluye una pista de conjunto de parámetros en
un archivo de video, tal como archivo de video 150. La unidad de encapsulamiento 30
puede señalar la presencia de nivel de secuencia de mensajes SEI en la pista de
conjunto de parámetros dentro de la caja TRAK que describe la pista de conjunto de
parámetros.
[00155] Las cajas MVEX 160 pueden describir las características de los fragmentos
de película correspondientes 164, por ejemplo, para indicar que el archivo de video
150 incluye fragmentos de película 164, además de datos de video incluidos dentro de
la caja MOOV 154, si existen. En el contexto de streaming de datos de video, pueden
incluirse imágenes codificadas de video en los fragmentos de película 164 en lugar de
en la caja MOOV 154. En consecuencia, todas las muestras de video codificado se
pueden incluir en los fragmentos de película de 164, en lugar de en la caja MOOV 154.
[00156] La caja MOOV 154 puede incluir un número de cajas MVEX 160 igual al
número de fragmentos de película 164 en archivo de video 150. Cada una de las cajas
MVEX 160 puede describir las características de un fragmento de película 164
correspondiente. Por ejemplo, cada imagen de MVEX puede incluir una caja de
cabecera de extensión de película (MEHD) que describe una duración temporal del
fragmento de película correspondiente 164.
[00157] Además, de acuerdo con las técnicas de esta divulgación, el archivo de video
150 puede incluir una FisheyeOmnidirectionalVideoBox en una
SchemeInformationBox, que puede estar incluida en la caja MOOV 154. En algunos
ejemplos, la FisheyeOmnidirectionalVieoBox puede incluirse en la caja TRAK 158, si
las diferentes pistas de archivo de video 150 puede incluir datos de video de ojo de
44
pez monoscópicos o estereoscópicos. En algunos ejemplos, la
FisheyeOmnidirectionalVieoBox puede incluirse en la caja FOV 157.
[00158] Como se señaló anteriormente, la unidad de encapsulamiento 30 puede
almacenar una secuencia de datos establecidos en una muestra de video que no
incluye datos reales de video codificados. Una muestra de video puede corresponder
generalmente a una unidad de acceso, que es una representación de una imagen
codificada en un instante de tiempo específico. En el contexto de AVC, la imagen
codificada puede incluir una o más unidades VCL NAL que contienen la información
para construir todos los píxeles de la unidad de acceso y otras unidades no VCL NAL
asociadas, tal como mensajes SEI. En consecuencia, la unidad de encapsulamiento 30
puede incluir un conjunto de datos de secuencia, que puede incluir mensajes SEI de
nivel de secuencia, en uno de los fragmentos de película 164. La unidad de
encapsulamiento 30 puede además señalar la presencia de mensajes SEI de datos de
secuencia y/o nivel de secuencia presentes en uno de los fragmentos de película 164
dentro de una de las cajas MVEX 160 correspondiente a uno de los fragmentos de
película 164.
[00159] Las cajas SIDX 162 son elementos opcionales del archivo de video 150. Es
decir, los archivos de video que cumplen con el formato de archivo 3GPP, u otros
formatos de archivo, no necesariamente incluyen cajas SIDX 162. De acuerdo con el
ejemplo del formato de archivo 3GPP, una caja SIDX puede utilizarse para identificar
un sub-segmento de un segmento (por ejemplo, un segmento de contenido dentro de
un archivo de video 150). El formato de archivo 3GPP define un sub-segmento como
“un conjunto autónomo de una o más cajas consecutivas de fragmento de película con
la caja correspondiente de Datos de Medios y una Caja de Datos de Medios que
contiene datos referenciados por una Caja de Fragmento de Película deben seguir tal
caja de Fragmento de Película y preceder a la siguiente caja de Fragmento de Película
que contiene información sobre la misma pista”. El formato de archivo 3GPP también
indica que una caja SIDX “contiene una secuencia de referencias a sub-segmentos del
(sub)segmento documentado por la caja. Los subsegmentos referenciados son
contiguos en el tiempo de presentación. De manera similar, los bytes referenciados por
una caja de Índice de Segmento son siempre contiguos dentro del segmento. El
tamaño referenciado da la cuenta del número de bytes en el material referenciado”.
[00160] Las cajas SIDX 162 generalmente proporcionan información representativa de
una o más sub-segmentos de un segmento incluido en el archivo de video 150. Por
ejemplo, tal información puede incluir tiempos de reproducción a los que los sub-
45
segmentos comienzan y/o terminan, desplazamientos de bytes para los sub-
segmentos, si los sub-segmentos incluyen (por ejemplo, comienzan con) un punto de
acceso de flujo (SAP), un tipo para el SAP (por ejemplo, si el SAP es una imagen de
refresco de decodificador instantáneo (IDR), una imagen de acceso aleatorio limpio
(CRA) , una imagen de acceso a enlace roto (BLA), o similares), una posición del SAP
(en términos de tiempo de reproducción y/o desplazamiento de bytes) en el sub-
segmento, y similares.
[00161] Los fragmentos de película 164 pueden incluir una o más imágenes de video
codificado. En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o
más grupos de imágenes (GOP), cada uno de los cuales puede incluir un número de
imágenes de video codificado, por ejemplo, cuadros o imágenes. Además, como se
describe anteriormente, los fragmentos de película 164 pueden incluir conjuntos de
datos de secuencias en algunos ejemplos. Cada uno de los fragmentos de película
164 puede incluir una caja de fragmento de película de cabecera (MFHD, que no se
muestra en la FIG. 11). La caja MFHD puede describir características del fragmento de
película correspondiente, tal como un número de secuencia para el fragmento de
película. Los fragmentos de película 164 se pueden incluir en el orden de número de
secuencia en el archivo de video 150.
[00162] La caja MFRA 166 puede describir puntos de acceso aleatorios dentro de
fragmentos de película 164 de archivo de video 150. Esto puede ayudar con la
realización de modos de truco, tal como la realización pretendida en ubicaciones
temporales particulares (es decir, tiempos de reproducción) dentro de un segmento de
encapsulado por archivo de video 150. La caja MFRA 166 es generalmente opcional y
no debe figurar en los archivos de video, en algunos ejemplos. Del mismo modo, un
dispositivo de cliente, tal como el dispositivo de cliente 40, no necesariamente tiene
que hacer referencia a la caja MFRA 166 para decodificar correctamente y exhibir
datos de archivo de video 150. La caja MFRA 166 puede incluir un número de cajas de
acceso aleatorio a fragmento de pista (TFRA) (no mostrado) igual al número de pistas
de archivo de video 150, o en algunos ejemplos, igual al número de pistas de medios
(por ejemplo, pistas no indicadas) de archivo de video 150.
[00163] En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o
más puntos de acceso de flujo (SAP), tal como imágenes IDR. Del mismo modo, la
caja MFRA 166 puede proporcionar indicaciones de lugares dentro de archivo de video
150 de los SAP. Por consiguiente, una sub-secuencia temporal de archivo de video
150 puede estar formada de SAP de archivo de video 150. La sub-secuencia temporal
46
también puede incluir otras imágenes, tal como cuadros P y/o cuadros B que
dependen de SAP. Los cuadros y/o porciones de la sub-secuencia temporal pueden
estar dispuestos dentro de los segmentos de tal manera que los cuadros/porciones de
la sub-secuencia temporal que dependen de otras imágenes/porciones de la sub-
secuencia puede ser decodificados correctamente. Por ejemplo, en la disposición
jerárquica de los datos, los datos utilizados para la predicción para otros datos pueden
también incluirse en la sub-secuencia temporal.
procesar un archivo que incluye datos de video de ojo de pez, de acuerdo con una o
más técnicas de la presente divulgación. Las técnicas de la FIG. 12 se describen como
realizadas por el dispositivo de cliente 40 de la FIG. 9, aunque dispositivos que tienen
configuraciones distintas del dispositivo de cliente 40 pueden llevar a cabo la técnica
de la FIG. 12.
[00165] El dispositivo de cliente 40 puede recibir un archivo que incluye datos de
video de ojo de pez y una estructura de sintaxis que incluye una pluralidad de
elementos de sintaxis que especifican atributos de los datos de video de ojo de pez
(1202). Como se discutió anteriormente, la pluralidad de elementos de sintaxis puede
incluir un primer elemento de sintaxis que indica explícitamente si los datos de video
de ojo de pez son monoscópicos o estereoscópicos, y uno o más elementos de
sintaxis que indican implícitamente si los datos de video de ojo de pez son
monoscópicos o estereoscópicos. Los uno o más elementos de sintaxis que indican
implícitamente si los datos de video de ojo de pez son monoscópicos o
estereoscópicos puede ser elementos de sintaxis que indican explícitamente los
ojo de pez. En algunos ejemplos, los uno o más elementos de sintaxis pueden ser, o
pueden ser similares a, elementos de sintaxis incluidos en la estructura de sintaxis
FisheyeOmnidirectionalVideoInfo () en el proyecto actual de OMAF DIS. En algunos
ejemplos, el primer elemento de sintaxis se puede incluir en un conjunto de bits
iniciales de la estructura de sintaxis (por ejemplo, 24 bits iniciales de la estructura de
sintaxis FisheyeOmnidirectionalVideoInfo( )).
[00166] El dispositivo de cliente 40 puede determinar, con base en el primer elemento
de sintaxis, si los datos de video de ojo de pez son monoscópicos o estereoscópicos
(1204). Un valor del primer elemento de sintaxis puede indicar explícitamente si los
datos de video de ojo de pez son monoscópicos o estereoscópicos. Como un ejemplo,
donde el primer elemento de sintaxis tiene un primer valor, el dispositivo de cliente 40
47
puede determinar que los datos de video de ojo de pez son monoscópicos (es decir,
que las imágenes circulares incluidas en las imágenes de los datos de video de ojo de
pez tienen ejes ópticos alineados y están orientadas en direcciones opuestas). Como
otro ejemplo, donde el primer elemento de sintaxis tiene un segundo valor, el
dispositivo de cliente 40 puede determinar que los datos de video de ojo de pez son
estereoscópicos (es decir, que las imágenes circulares que se incluyen en las
imágenes de los datos de video de ojo de pez tienen ejes ópticos paralelos y están
orientadas en la misma dirección).
[00167] Como se discutió anteriormente, si bien puede ser posible para el dispositivo
de cliente 40 determinar si los datos de video de ojo de pez son monoscópicos o
estereoscópicos con base en los elementos de sintaxis que indican explícitamente
ojo de pez, un cálculo de este tipo puede aumentar la carga computacional en el
dispositivo de cliente 40. Como tal, con el fin de reducir los cálculos realizados (y por
tanto los recursos computacionales utilizados), el dispositivo de cliente 40 puede
determinar si los datos de video de ojo de pez son monoscópicos o estereoscópicos
con base en el primer elemento de sintaxis.
[00168] El dispositivo de cliente 40 puede renderizar los datos de video de ojo de pez
con base en la determinación. Por ejemplo, en respuesta a determinar que los datos
de video de ojo de pez son monoscópicos, el dispositivo de cliente 40 puede
renderizar los datos de ojo de pez como monoscópicos (1206). Por ejemplo, el
dispositivo de cliente 40 puede determinar una ventana gráfica (es decir, una porción
de la esfera en la que un usuario está actualmente “mirando”), identificar una porción
de las imágenes circulares de los datos de video de ojo de pez que corresponden a la
ventana, y mostrar la misma porción de las imágenes circulares a cada uno de los ojos
del espectador. De manera similar, en respuesta a determinar que los datos de video
de ojo de pez son estereoscópicos, el dispositivo de cliente 40 puede renderizar los
datos de ojo de pez como estereoscópicos (1208). Por ejemplo, el dispositivo de
cliente 40 puede determinar una ventana gráfica (es decir, una porción de la esfera en
la que un usuario está actualmente “mirando”), identificar una porción respectiva de
cada una de las imágenes circulares de los datos de video de ojo de pez que
corresponden a la ventana gráfica, y mostrar las porciones respectivas de las
imágenes circulares a los ojos del espectador
generar un archivo que incluye datos de video de ojo de pez, de acuerdo con una o
48
más técnicas de la presente divulgación. Las técnicas de la FIG. 13 se describen como
realizadas por el dispositivo de preparación de contenidos 20 de la FIG. 9, aunque
dispositivos que tienen configuraciones distintas del dispositivo de preparación de
contenidos 20 pueden realizar la técnica de la FIG. 13.
[00170] El dispositivo de preparación de contenidos 20 puede obtener datos de video
de ojo de pez y parámetros extrínsecos de las cámaras utilizadas para capturar los
datos de video de ojo de pez (1302). Por ejemplo, el dispositivo de preparación de
contenidos 20 puede obtener imágenes de los datos de video de ojo de pez que se
codifican utilizando un códec de video, tal como HEVC. Cada una de la imagen de
datos de video de ojo de pez puede incluir una pluralidad de imágenes circulares
donde cada una corresponde a una imagen captada por una cámara diferente con una
lente de ojo de pez (por ejemplo, una imagen puede incluir una primera imagen
circular capturada a través de la lente de ojo de pez 12A de la FIG. 1A y una segunda
imagen circular capturada a través de la lente de ojo de pez 12B de la FIG. 1A). Los
parámetros extrínsecos pueden especificar varios atributos de las cámaras. Por
ejemplo, los parámetros extrínsecos pueden especificar un ángulo de guiñada, un
ángulo de paso, un ángulo de balanceo, y uno o más desplazamientos espaciales de
cada una de las cámaras utilizadas para capturar los datos de video de ojo de pez.
[00171] El dispositivo de preparación de contenidos 20 puede determinar, con base en
los parámetros extrínsecos, si los datos de video de ojo de pez son monoscópicos o
estereoscópicos (1304). Como un ejemplo, cuando los dos conjuntos de valores de los
parámetros extrínsecos de cámara son de la siguiente manera, el dispositivo de
preparación de contenidos 20 puede determinar que el video de ojo de pez es
estereoscópico:
1er conjunto:
2do conjunto:
49
[00172] Como otro ejemplo, cuando los dos conjuntos de valores de los parámetros
extrínsecos de cámara son de la siguiente manera, el dispositivo de preparación de
contenidos 20 puede determinar que el video de ojo de pez es monoscópico:
1er conjunto:
2do conjunto:
[00173] El dispositivo de preparación de contenidos 20 puede codificar, en un archivo,
los datos de video de ojo de pez y una estructura de sintaxis que incluye una
pluralidad de elementos de sintaxis que especifican atributos de los datos de video de
ojo de pez (1306). La pluralidad de elementos de sintaxis incluye: un primer elemento
de sintaxis que indica explícitamente si los datos de video de ojo de pez son
explícitamente los parámetros extrínsecos de las cámaras utilizadas para capturar los
datos de video de ojo de pez.
[00174] En uno o más ejemplos, las funciones descritas pueden implementarse en
hardware, software, firmware, o cualquier combinación de los mismos. Si se
implementan en software, las funciones pueden almacenarse en o transmitirse como
una o más instrucciones o código en un medio legible por ordenador y ejecutarse por
una unidad de procesamiento con base en hardware. Los medios legibles por
ordenador pueden incluir medios de almacenamiento legibles por ordenador, lo que
corresponde a un medio tangible tal como un medio de almacenamiento de datos, o
50
medios de comunicación que incluyen cualquier medio que facilite la transferencia de
un programa informático de un lugar a otro, por ejemplo, de acuerdo con un protocolo
de comunicación. De esta manera, los medios legibles por ordenador generalmente
pueden corresponder a (1) medios de almacenamiento legibles por ordenador
tangibles no transitorios o (2) un medio de comunicación tal como una onda de señal o
portadora. Los medios de almacenamiento de datos pueden ser cualquier medio
disponible al que se puede acceder por uno o más ordenadores o uno o más
procesadores para recuperar instrucciones, código y/o estructuras de datos para la
aplicación de las técnicas descritas en la presente divulgación. Un producto de
programa de ordenador puede incluir un medio legible por ordenador.
[00175] A modo de ejemplo, y no de limitación, tales medios de almacenamiento
legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro
almacenamiento en disco óptico, almacenamiento en disco magnético u otros
dispositivos de almacenamiento magnético, memoria flash, o cualquier otro medio que
pueda utilizarse para almacenar código de programa deseado en forma de
instrucciones o estructuras de datos y al que se pueda acceder por un ordenador.
Además, cualquier conexión se denomina correctamente un medio legible por
ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, un
servidor u otra fuente remota utilizando un cable coaxial, cable de fibra óptica, par
trenzado, línea de abonado digital (DSL), o tecnologías inalámbricas tal como
infrarroja, de radio y microondas, entonces el cable coaxial, cable de fibra óptica, par
trenzado, DSL o tecnologías inalámbricas tal como infrarroja, de radio y microondas se
incluyen en la definición de medio. Debe comprenderse, sin embargo, que los medios
de almacenamiento legibles por ordenador y medios de almacenamiento de datos no
incluyen conexiones, ondas portadoras, señales, u otros medios transitorios, sino que
se dirigen a medios de almacenamiento tangibles no transitorios. Disk y disc, de
acuerdo con lo utilizado en la presente, incluye disco compacto (CD), disco láser, disco
óptico, disco versátil digital (DVD), disco flexible y disco Blu-ray donde los disks
generalmente reproducen datos magnéticamente, mientras que los discs reproducen
datos ópticamente con láseres. También deben incluirse combinaciones de los
anteriores dentro del alcance de los medios legibles por ordenador.
[00176] Las instrucciones pueden ser ejecutadas por uno o más procesadores, tal
como uno o más procesadores de señal digital (DSP), microprocesadores de propósito
general, circuitos integrados de aplicación específica (ASIC), matrices lógicas
programables en campo (FPGA), u otro circuito equivalente integrado o lógica discreta.
51
De acuerdo con ello, el término “procesador”, de acuerdo con lo utilizado en la
presente puede referirse a cualquiera de la estructura anterior o cualquier otra
estructura adecuada para la aplicación de las técnicas descritas en la presente.
Además, en algunos aspectos, la funcionalidad descrita en la presente puede
proporcionarse dentro de los módulos de hardware y/o software dedicados
configurados para la codificación y decodificación, o incorporarse en un códec
combinado. Además, las técnicas pueden ser implementadas completamente en uno o
más circuitos o elementos lógicos.
[00177] Las técnicas de la presente divulgación pueden implementarse en una amplia
variedad de dispositivos o aparatos, incluyendo un teléfono inalámbrico, un circuito
integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chip). Diversos
componentes, módulos o unidades se describen en esta divulgación para enfatizar los
aspectos funcionales de los dispositivos configurados para llevar a cabo las técnicas
divulgadas, pero no necesariamente requieren realización por diferentes unidades de
hardware. Más bien, como se ha descrito anteriormente, diversas unidades pueden
combinarse en una unidad de hardware códec o proporcionarse por una colección de
unidades de hardware interoperativas, incluyendo uno o más procesadores como se
describen anteriormente, en conjunción con el software y/o firmware adecuado.
[00178] Se han descrito varios ejemplos. Estos y otros ejemplos están dentro del
alcance de las siguientes reivindicaciones.
52

Descripción

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Descripción

Cargado por

Copyright:

Formatos disponibles

SEÑALIZACIÓN DE ALTO NIVEL PARA DATOS DE VIDEO DE OJO DE PEZ

[0001] Esta solicitud reivindica el beneficio de la Solicitud Provisoria de los Estados

indica el valor del coeficiente igual a polynomial_coefficient_K_lsc_R,

También podría gustarte