ES2892329T3 - Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua - Google Patents

Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua Download PDF

Info

Publication number
ES2892329T3
ES2892329T3 ES18701857T ES18701857T ES2892329T3 ES 2892329 T3 ES2892329 T3 ES 2892329T3 ES 18701857 T ES18701857 T ES 18701857T ES 18701857 T ES18701857 T ES 18701857T ES 2892329 T3 ES2892329 T3 ES 2892329T3
Authority
ES
Spain
Prior art keywords
data
media
video
data structure
multimedia
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18701857T
Other languages
English (en)
Inventor
Ye-Kui Wang
Thomas Stockhammer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2892329T3 publication Critical patent/ES2892329T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/44029—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un procedimiento para recuperar los datos multimedia, comprendiendo el procedimiento: recibir (202), mediante un dispositivo multimedia de un dispositivo servidor en un mensaje DASH Asistido por Servidor y Red (SAND) de Entrega de Mejora de Parámetros, PED, que se separa de un archivo de manifiesto de los datos multimedia, la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos de un contenido multimedia común que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, cada una de las estructuras de datos que incluye los datos multimedia, comprendiendo la al menos una estructura de datos una primera estructura de datos y la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que una segunda estructura de datos diferente de la pluralidad de estructuras de datos; y en respuesta a la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que la segunda estructura de datos, extraer (204), mediante el dispositivo multimedia de la información recibida del dispositivo servidor, la información que indica que una primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario; y recuperar (206), mediante del dispositivo multimedia del dispositivo servidor, los datos multimedia de la primera estructura de datos antes de recibir las solicitudes de los datos multimedia de la primera estructura de datos de los dispositivos de usuario.

Description

DESCRIPCIÓN
Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua
Esta solicitud reivindica el beneficio de la Solicitud Provisional de los Estados Unidos Núm. 62/444,730, presentada el 10 de enero de 2017.
Campo técnico
Esta divulgación se refiere al transporte de datos multimedia codificados.
Antecedentes
Las capacidades de video digital pueden incorporarse en un amplio rango de dispositivos, incluidos televisores digitales, sistemas de difusión digital directa, sistemas de difusión inalámbrica, asistentes digitales personales (PDA), ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de grabación digital, reproductores de medios digitales, dispositivos de video juegos, consolas de video juegos, teléfonos celulares o de radio por satélite, dispositivos de video conferencia y similares. Los dispositivos de video digital implementan técnicas de compresión de video, tales como las descritas en los estándares definidos por ITU-T H,261, ISO/IEC MPEG-1 Visual, ITU-T H,262 o ISO/IEC MPEG-2 Visual, MPEG-2, MPEG-4, ITU-T H,263 o ITU-T H,264/MPEG-4 Visual, Parte 10, Codificación de Video Avanzada (AVC), ITU-T H,265 (también denominada Codificación de Video de Alta Eficiencia (HEVC) e ISO/IEC 23008-2) y extensiones de tales estándares tales como Codificación de Video Escalable (SVC) y Codificación de Video Multivista (MVC), para transmitir y recibir información de video digital más eficientemente. Las extensiones HEVC incluyen su extensión de codificación escalable (es decir, codificación de video escalable de alta eficiencia, SHVC) y extensión multivista (es decir, codificación de video de alta eficiencia multivista, MV-HEVC). Después de que los datos de video se han codificado, los datos de video pueden empaquetarse para su transmisión o almacenamiento. Los datos de video pueden ensamblarse en un archivo de video de conformidad con cualquiera de una variedad de estándares, tal como el formato de archivos multimedia base Organización Internacional de Normalización (ISO) y extensiones del mismo, tal como AVC.
El documento US 2004/010613 A1 divulga un procedimiento para la prebúsqueda de datos multimedia en una red de transmisión continua.
Sumario
En general, esta divulgación describe técnicas para la señalización de la información que indica que es más probable que se usen determinados datos que otros datos, por ejemplo, durante la transmisión continua u otro transporte de los datos. Tal información puede usarse para la prebúsqueda de datos por parte de dispositivos cliente o elementos de red intermedios entre clientes y un servidor de origen en sistemas de transmisión continua adaptables. En particular, un dispositivo multimedia puede usar las técnicas de esta divulgación para prebuscar los datos que es más probable que se usen.
Un procedimiento de recuperación de datos multimedia se define en la reivindicación 1.
Un dispositivo multimedia para la recuperación de datos multimedia se define en la reivindicación 8.
Un medio de almacenamiento legible por ordenador, que tiene almacenadas en el mismo las instrucciones que, cuando se ejecutan, hacen que un procesador de un dispositivo multimedia lleve a cabo el procedimiento de la reivindicación 1, que se define en la reivindicación 9.
Los detalles de uno o más ejemplos se establecen en los dibujos acompañantes y en la descripción de más abajo. Otras características, objetivos y ventajas serán evidentes a partir de la descripción y los dibujos, y a partir de las reivindicaciones.
Breve descripción de los dibujos
La Figura 1 es un diagrama de bloques que ilustra un sistema de ejemplo que implementa técnicas para los datos multimedia de transmisión continua sobre una red.
La Figura 2 es un diagrama de bloques que ilustra un ejemplo del conjunto de componentes de una unidad de recuperación de la Figura 1 con mayor detalle.
La Figura 3 es un diagrama conceptual que ilustra elementos de contenido multimedia de ejemplo.
La Figura 4 es un diagrama de bloques que ilustra los elementos de un archivo de video de ejemplo, que puede corresponder a un segmento de una representación.
La Figura 5 es un diagrama de flujo que ilustra un procedimiento de ejemplo para realizar las técnicas de esta divulgación.
La Figura 6 es un diagrama de flujo que ilustra un procedimiento de ejemplo para realizar las técnicas de esta divulgación.
Descripción detallada
En general, esta divulgación describe técnicas para la señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua, tal como, mediante el uso de la Transmisión Continua Dinámica Adaptativa sobre HTTP (DASH). La DASH se describe en, por ejemplo, Proyecto de Asociación de 3ra Generación; Servicios del Grupo de Especificaciones Técnicas y Aspectos del Sistema; Servicio de Transmisión continua con Conmutación de Paquetes (PSS) Transparente de extremo a extremo; Descarga Progresiva y Transmisión Continua Dinámica Adaptativa sobre HTTP (3GP-DASH) (versión 12) (diciembre de 2013). La DASH también se especifica en Tecnología de la información - Transmisión Continua Dinámica Adaptativa sobre HTTP (DASH) - Parte 1: Descripción de presentación multimedia y formatos de segmento, ISO/IEC 23009-1 (1 de abril de 2012).
Aunque se discute principalmente con respecto a la DASH, con propósitos de explicación y ejemplo, debe entenderse que estas técnicas pueden aplicarse a otras tecnologías de transmisión continua. Por ejemplo, las técnicas de esta divulgación pueden realizarse junto con la Transmisión Continua en Vivo HTTP (HLS) de Apple o el Formato de Aplicación Multimedia Común (CMAf ). Las técnicas de esta divulgación también pueden realizarse junto con la Transmisión Continúa Fluida de Microsoft.
Como se discute con mayor detalle más abajo, los protocolos de transmisión continua de multimedia a menudo implican transmitir un archivo de manifiesto desde un dispositivo servidor a un dispositivo cliente, donde el archivo de manifiesto describe las características de una presentación multimedia correspondiente. Por ejemplo, en la DASH, una descripción de presentación multimedia (MPD) describe conjuntos de adaptación que incluyen representaciones conmutables. Cada una de las representaciones incluye una pluralidad de segmentos, es decir, archivos recuperables individualmente (que pueden asociarse con un localizador uniforme de recursos (URL) correspondiente).
Las técnicas de esta divulgación generalmente incluyen la información de señalización que indica qué estructura de datos de una pluralidad de estructuras de datos es más probable que se recupere (por ejemplo, mediante un dispositivo de usuario), de manera que un dispositivo multimedia puede prebuscar los datos multimedia de la estructura de datos. Por ejemplo, la estructura de datos puede ser una presentación multimedia particular (por ejemplo, un título de película particular), un conjunto de adaptación particular de una presentación multimedia, una representación de una presentación multimedia o incluso un conjunto de segmentos de una representación. La información puede formar parte de un archivo de manifiesto (tal como una MPD) en el nivel de archivo de manifiesto o en un nivel de conjunto de representación o adaptación (por ejemplo, dentro de la MPD). Adicional o alternativamente, la información puede señalarse como información lateral por separado del archivo de manifiesto, por ejemplo, para los dispositivos de red intermedios, tales como los elementos de red con reconocimiento multimedia (MANE) o los elementos de red con reconocimiento DASH (DANE).
Como se señaló anteriormente, los segmentos en la DASH son ejemplos de archivos recuperables individualmente. En general, tales archivos pueden formatearse de acuerdo con el Formato de Archivos Multimedia Base ISO (ISOBMFF) o una extensión de ISOBMFF. Las técnicas de esta divulgación pueden aplicarse a los archivos de video de conformidad con los datos de video encapsulados de acuerdo con cualquier formato de archivo ISO BMFF, Codificación de Video Escalable (SVC), formato de archivo de Codificación de Video Avanzada (AVC), formato de archivo de Proyecto de Asociación de 3ra Generación (3GPP) y/o formato de archivo de Codificación de Video Multivista (MVC) u otros formatos de archivo de video similares.
Los estándares de formato de archivo incluyen el formato de archivos multimedia base ISO (ISOBMFF, ISO/IEC 14496-12) y otros estándares derivados de ISOBMFF, incluido el formato de archivo MPEG-4 (ISO/IEC 14496-15), el formato de archivo 3GPP (3GPP TS 26,244) y los formatos de archivo para las familias de códecs de video AVC y HEVC (ISO/IEC 14496-15). Los proyectos de los textos de las ediciones para ISO/IEC 14496-12 y 14496-15 están disponibles en phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zip y wg11.sc29.org/doc_end_user/documents/115_Geneva/wg11/w16169-v2-w16169.zip, respectivamente. El ISo Bm fF se usa como la base para muchos formatos de encapsulación de códec, tal como el formato de archivo AVC, así como también para muchos formatos de contenedor multimedia, tales como el formato de archivo MPEG-4, el formato de archivo 3GPP (3GP) y el formato de archivo de difusión de video digital (DVB).
Además de las multimedias continuas, tales como audio y video, pueden almacenarse multimedias estáticas, tal como imágenes, así como también metadatos en un archivo de conformidad con el ISOBMFF. Los archivos estructurados de acuerdo con el ISOBMFF pueden usarse para muchos propósitos, incluido la reproducción de archivos multimedia locales, la descarga progresiva de un archivo remoto, los segmentos para la DASH, los contenedores para el contenido que se transmite y sus instrucciones de empaquetización y grabación de transmisiones multimedia recibidas en tiempo real.
Un cuadro es una estructura de sintaxis elemental en el ISOBMFF, que incluye un tipo de cuadro codificado de cuatro caracteres, un recuento de bytes para el cuadro y una carga útil. Un archivo ISOBMFF incluye una secuencia de cuadros y los cuadros pueden contener otros cuadros. Un cuadro de película ("moov") contiene los metadatos para las transmisiones multimedia continuas presentes en el archivo, cada uno representado en el archivo como una pista. Los metadatos de una pista se encierran en un cuadro de Pista ("trak"), mientras que el contenido multimedia de una pista se encierra en un cuadro de Datos Multimedia ("mdat") o directamente en un archivo separado. El contenido multimedia para las pistas incluye una secuencia de muestras, tal como las unidades de acceso de audio o video.
El ISOBMFF especifica los siguientes tipos de pistas: una pista multimedia, que contiene una transmisión multimedia elemental; una pista de pistas, que incluye instrucciones de transmisión multimedia o representa una transmisión de paquetes recibido; y una pista de metadatos temporizada, que comprende los metadatos sincronizados en el tiempo. Aunque originalmente diseñado para almacenamiento, el ISOBMFF ha demostrado ser muy valioso para la transmisión continua, por ejemplo, para la descarga progresiva o la DASH. Para propósitos de transmisión continua, pueden usarse los fragmentos de película definidos en el ISOBMFF.
Los metadatos de cada pista incluyen una lista de entradas de descripción de muestra, cada una de las cuales proporciona el formato de codificación o encapsulación usado en la pista y los datos de inicialización necesarios para procesar ese formato. Cada muestra se asocia con una de las entradas de descripción de muestra de la pista.
El ISOBMFF permite la especificación de metadatos específicos de muestra con varios mecanismos. Se han estandarizado cuadros específicos dentro del cuadro de Tabla de Muestra ("stbl") para responder a las necesidades comunes. Por ejemplo, un cuadro de Muestra de Sincronización ("stss") es usado para enumerar las muestras de acceso aleatorio de la pista. El mecanismo de agrupación de la muestra permite el mapeo de las muestras de acuerdo con un tipo de agrupación de cuatro caracteres en los grupos de muestras que comparten la misma propiedad especificada como una entrada de descripción del grupo de muestra en el archivo. Se han especificado varios tipos de agrupación en el ISOBMFF.
En la transmisión continua HTTP, tal como, de acuerdo con la DASH, las operaciones usadas frecuente incluyen HEAD, GET y GET parcial. La operación HEAD recupera un encabezado de un archivo asociado con un localizador uniforme de recursos (URL) o un nombre de recurso uniforme (URN) dado, sin recuperar una carga útil asociada con la URL o URN. La operación GET recupera un archivo completo asociado con una URL o URN dada. La operación GET parcial recibe un rango 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 tanto, pueden proporcionarse los fragmentos de película para la transmisión continua HTTP, porque una operación GET parcial puede obtener uno o más fragmentos de película individuales. En un fragmento de película, puede haber varios fragmentos de pista de diferentes pistas. En la transmisión continua HTTP, una presentación multimedia puede ser una colección estructurada de datos a la que puede acceder el cliente. El cliente puede solicitar y descargar la información de los datos multimedia para presentar un servicio de transmisión continua a un usuario.
En el ejemplo de la DASH, puede haber múltiples representaciones para los datos de video y/o audio de contenido multimedia. Como se explica más abajo, 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 multivista y/o escalables) o diferentes velocidades de bits. El manifiesto de tales representaciones puede definirse en una estructura de datos de Descripción de Presentación Multimedia (MPD). Una presentación multimedia puede corresponder a una colección estructurada de datos a la que puede acceder un dispositivo cliente de transmisión continua HTTP. El dispositivo cliente de transmisión continua HTTP puede solicitar y descargar la información de datos multimedia para presentar un servicio de transmisión continua a un usuario del dispositivo cliente. Puede describirse una presentación multimedia en la estructura de datos de la MPD, que puede incluir las actualizaciones de la MPD.
Una presentación multimedia puede contener una secuencia de uno o más Períodos. Cada período puede extenderse hasta el inicio del siguiente Período o hasta el final de la presentación multimedia, en el caso del último período. Cada período puede contener una o más representaciones para el mismo contenido multimedia. Una representación puede ser una de un número de versiones codificadas alternativas de audio, video, texto temporizado u otros datos similares. Las representaciones pueden diferir por los tipos de codificación, por ejemplo, por velocidad de bits, resolución y/o códec para los datos de video y velocidad de bits, idioma y/o códec para los datos de audio. El término representación puede usarse para referirse a una sección de datos de audio o video codificados correspondiente a un período particular del contenido multimedia y codificados de una manera particular.
Las representaciones de un período particular pueden asignarse a un grupo indicado por un atributo en la MPD indicativa de un conjunto de adaptación al que pertenecen las representaciones. Las representaciones en el mismo conjunto de adaptación se consideran generalmente alternativas entre sí, en el sentido de que un dispositivo cliente puede conmutar de forma dinámica y sin problemas entre estas representaciones, por ejemplo, para realizar una adaptación de 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 puede seleccionarse para la decodificación para presentar los datos multimedia, tales como los datos de video o los datos de audio, del contenido multimedia para el período correspondiente. El contenido multimedia dentro de un período puede representarse por una representación del grupo 0, si está presente, o la combinación de como máximo 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 la hora de inicio del período.
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 inicializarse automáticamente. Cuando está presente, el segmento de inicialización puede contener la información de inicialización para acceder a la representación. En general, el segmento de inicialización no contiene los datos multimedia. Un segmento puede ser una referencia únicamente mediante un identificador, tal como un localizador uniforme de recursos (URL), el nombre de recursos uniforme (URN) o el identificador de recursos uniforme (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD también puede proporcionar los rangos de bytes en forma de rango atributo, que puede corresponder a los datos de un segmento dentro de un archivo accesible por la URL, URN o URI Pueden seleccionarse diferentes representaciones para la recuperación sustancialmente simultánea para diferentes tipos de datos multimedia. Por ejemplo, un dispositivo cliente puede seleccionar una representación de audio, una representación de video y una representación de texto temporizado de la que recuperar los segmentos. En algunos ejemplos, el dispositivo cliente puede seleccionar los conjuntos de adaptación particulares para realizar la adaptación del ancho de banda. Es decir, el dispositivo cliente puede seleccionar un conjunto de adaptación que incluye las representaciones de video, un conjunto de adaptación que incluye las representaciones de audio y/o un conjunto de adaptación que incluye el texto temporizado. Alternativamente, el dispositivo cliente puede seleccionar los conjuntos de adaptación para determinados los tipos de multimedias (por ejemplo, video) y seleccionar directamente las representaciones para otros tipos de multimedias (por ejemplo, audio y/o texto temporizado).
La DASH es un estándar para las aplicaciones de transmisión continua HTTP (adaptable). La DASH especifica principalmente el formato de la descripción de presentación multimedia (MPD), un ejemplo de un archivo de manifiesto y el formato del segmento de multimedia. La MPD describe las multimedias disponibles en un dispositivo servidor y deja que el cliente DASH descargue de forma autónoma la versión multimedia en un momento de interés particular de la multimedia.
Un procedimiento típico para la transmisión continua HTTP basada en DASH incluye las siguientes etapas:
1. Un dispositivo cliente obtiene una MPD de un contenido de transmisión continua (presentación multimedia), por ejemplo, una película. La MPD incluye la información sobre diferentes representaciones alternativas, por ejemplo, la velocidad de bits, la resolución de video, la velocidad de trama, el idioma de audio, del contenido de transmisión continua, así como también la URL de recursos HTTP (un segmento de inicialización y los segmentos multimedia).
2. En base a la información en la MPD y la información local del cliente, por ejemplo, el ancho de banda de la red, las capacidades de decodificación/visualización y la preferencia del usuario, el cliente solicita la(s) representación(es) deseadas, un segmento (o una parte de las mismas) a la vez.
3. Cuando el cliente detecta un cambio en el ancho de banda de la red, solicita los segmentos de una representación diferente con una velocidad de bits más compatible, idealmente iniciando desde un segmento que inicia con un punto de acceso aleatorio (RAP).
Durante una "sesión" de transmisión continua HTTP, para responder a la solicitud del usuario de buscar hacia atrás a una posición pasada o hacia adelante a una posición futura (también denominados como modo truco), el dispositivo cliente solicita los segmentos pasados o iniciando desde un segmento que está cerca de la posición deseada y que, idealmente, inicia con un punto de acceso aleatorio. El usuario también puede solicitar adelantar el contenido (otro ejemplo de un modo truco), lo que puede realizarse al solicitar los datos suficientes para decodificar solamente las imágenes de video intracodificadas o solamente un subconjunto temporal de la transmisión de video. La ISO/IEC 23009-5 especifica la DASH asistida por servidor y red (SAND). La SAND introduce los mensajes intercambiados entre los dispositivos cliente DASH y los elementos de red o entre varios elementos de red, con el propósito de mejorar la eficiencia de las sesiones de transmisión continua al proporcionar la información sobre las características operativas en tiempo real de redes, servidores, proxies, cachés, redes de entrega de contenido (CDN), así como también el rendimiento y el estado del cliente DASh .
En la SAND, un elemento de red que tiene al menos la inteligencia mínima sobre la DASH se denomina como un Elemento de Red con Reconocimiento DASH (DANE). Los DANE, por ejemplo, pueden configurarse para reconocer los objetos entregados con formato DASH, tal como los segmentos MPD o DASH y pueden priorizar, analizar o incluso modificar tales objetos. Un servidor de origen DASH también se considera como un DANE.
Los mensajes SAND se refieren a los mensajes intercambiados entre los clientes DASH, DANE y/o los Servidores de Métricas con el fin de mejorar la recepción o la entrega del servicio DASH o para informar el estado o las métricas del cliente DASH a los Elementos de Red con reconocimiento DASH
Los Servidores de Métricas. Los mensajes SAND se categorizan en los siguientes cuatro tipos:
• Mensajes de Entrega de Mejora de Parámetros (PED) que se intercambian entre los DANE,
• Mensajes de Recepción de Mejora de Parámetros (PER) que se envían desde los DANE a los clientes DASH, • Mensajes de Estado que se envían desde los clientes DASH a los DANE y
• Mensajes de Métricas que se envían desde los clientes DASH a los Servidores de Métricas.
Los mensajes de estado definidos en la SAND incluyen un mensaje SAND AnticipatedRequests, que permite a un cliente DASh anunciar a un DANE en qué conjunto específico de segmentos se interesa. La intención es señalar el conjunto de segmentos en las representaciones que es probable que el cliente DASH seleccione y solicite pronto. Actualmente, no hay mensajes p Ed definidos en la SAND
La realidad virtual (VR) es la capacidad de estar virtualmente presente en un mundo no físico creado mediante la representación de imágenes y sonidos naturales y/o sintéticos correlacionados por los movimientos de un usuario inmerso, permitiendo al usuario interactuar con ese mundo. Con los progresos recientes hecho en los dispositivos de representación, tal como los visualizadores montados en la cabeza (HMD) y la creación de video de VR (a menudo también denominados como video de 360 grados), puede ofrecerse una experiencia de calidad significativa. Las aplicaciones de VR que incluyen juegos, formación, educación, videos deportivos, compras en línea, entrenamiento, etc.
Un sistema de VR típico incluye los siguientes componentes y etapas:
• Un conjunto de cámaras, que normalmente incluye múltiples cámaras individuales que apuntan en diferentes direcciones, que pueden cubrir colectivamente todos los puntos de vista alrededor del conjunto de cámaras.
• La unió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 unen en el dominio del espacio, para formar un video esférico, pero mapeado a un formato rectangular, tal como equi-rectangular (como un mapa del mundo) o mapa de cubos.
• El video en el formato rectangular mapeado se codifica/comprime mediante el uso de un códec de video, por ejemplo, H,265/HEVC o H,264/AVC.
• El(los) flujo(s) de bits de video comprimido pueden almacenarse y/o encapsularse en un formato multimedia y transmitirse (posiblemente solo el subconjunto que cubre solamente el área que se ve por un usuario) a través de una red a un dispositivo receptor (es decir, un dispositivo cliente).
• El dispositivo receptor recibe el(los) flujo(s) de bits de video, o parte del mismo, posiblemente encapsulado en un formato y envía la señal de video decodificada o parte de la misma a un dispositivo de representación (que puede formar parte del mismo dispositivo o un dispositivo separado).
• El dispositivo de representación puede ser, por ejemplo, un visualizador montado en la cabeza (HMD), que puede rastrear el movimiento de la cabeza e incluso puede rastrear el movimiento de los ojos y representar la parte correspondiente del video de manera que se entregue al usuario una experiencia inmersiva.
En el momento de escribir este documento, MPEG estaba desarrollando el Formato de Aplicación Multimedia Omnidireccional (OMAF) para definir un formato de aplicación multimedia que habilite las aplicaciones multimedia omnidireccionales, centrándose en las aplicaciones de VR con video de 360 grados y audio asociado. El OMAF especifica una lista de procedimientos de proyección que pueden usarse para la conversión de un video esférico o de 360 grados en un video rectangular bidimensional, seguido de cómo almacenar las multimedias omnidireccionales y los metadatos asociados mediante el uso del formato de archivos multimedia base ISO (ISOBMFF) y cómo encapsular, señalizar y transmitir las multimedias omnidireccionales mediante el uso de la transmisión continua dinámica adaptativa sobre HTTP (DASH) y finalmente, qué códecs de video y audio, así como también qué configuraciones de codificación de multimedias, pueden usarse para la compresión y reproducción de la señal de multimedias omnidireccionales. Se planea que el OMAF se convierta en la ISO/IEC 23000-20 y su proyecto de memoria descriptiva está disponible en wg11.sc29.org/doc_end_user/documents/116_Chengdu/wg11/w16439.zip.
Hay casos de uso deseables de datos multimedia de transmisión continua que involucran la generación, señalización y uso de la información que indica las regiones de interés o las regiones más interesadas. En la contribución MPEG m37819, fue discutido un caso de uso sobre la señalización y mediante el uso de la información del corte de un director, de manera que la reproducción de VR puede incluir la visualización de una ventana de visualización que cambia dinámicamente en el que un director quiere que la audiencia se enfoque, incluso cuando el usuario no está girando su cabeza o cambiando la ventana de visualización a través de otras interfaces de usuario (UI). Tales ventanas de visualización pueden proporcionarse con un video omnidireccional, escena por escena. La Solicitud de los Estados Unidos Núm. 15/589,782, presentada el 8 de mayo de 2017, publicada como la Publicación de Patente de los Estados Unidos Núm. 2017/0339415, describe las técnicas para la generación de la información sobre las regiones más interesadas a partir de las estadísticas de usuarios por un proveedor de servicios o contenido, por ejemplo, a través de las estadísticas de qué regiones se han solicitado/visto más por los usuarios cuando el contenido de video de VR se proporcionó a través de un servicio de transmisión continua, en el que una región más interesada en una imagen de video de VR es una de las regiones que estadísticamente es más probable que se represente al usuario en el momento de la presentación de la imagen. También divulgado en la Solicitud Provisional Núm. 63/339,009 son técnicas para usar la información en las regiones más interesadas para varios propósitos de mejora del rendimiento de la VR, tal como la prebúsqueda de datos en la transmisión continua adaptativa de VR por los servidores de borde o los clientes, la optimización de la transcodificación cuando se transcodifica un video de VR, por ejemplo, a un códec diferente o el mapeo de proyección, la gestión de caché por un servidor de borde o caché y la gestión de contenido por un servidor de transmisión continua de video Vr . También se ha divulgado la señalización de las regiones más interesadas, por ejemplo, mediante el uso de mensajes SEI en un flujo de bits de video, un grupo de muestra de formato de archivo en un archivo multimedia, o elementos o atributos de descripción de presentación multimedia (MPD) DASH mediante el uso de un grupo de muestra.
La Solicitud de los Estados Unidos Núm. 14/491,805, presentada el 24 de mayo de 2016, publicada como la Publicación de Patente de los Estados Unidos Núm. 2017/0344843, describe varios procedimientos para la señalización avanzada de una o más regiones más interesadas en video de VR, que incluye los siguientes, entre otros:
• Un grupo de muestra que, cuando se incluye en un cuadro de fragmentos de pista, puede documentar la información de muestras que está en fragmentos de pista posteriores después del que contiene el grupo de muestra (el SampleToGroupBox del tipo de agrupación y el cuadro de descripción del grupo de muestra correspondiente) en la pista.
• Ejemplos del grupo de muestra mencionado anteriormente.
• La señalización de las regiones más interesadas directamente mediante el uso del ID de mosaico como se especifica en HEVC, el ID de grupo como se define en la ISO/IEC 14496-15, el ID de pista como se define en la ISO/IEC 14496-12 o el ID de representación DASH como se define en la ISO/IEC 23009-1.
Una región de interés (ROI) en VR/video 360 puede definirse en al menos dos formas. La primera forma de ejemplo es definirlo en base a un sistema de coordenadas de esfera, por ejemplo, al definir una región en la superficie esférica del video 360. La segunda forma de ejemplo es definir un ROI en base al sistema de coordenadas cartesianas 2D en una imagen 2D. Este último es lo que se usó en los identificados anteriormente de las Solicitudes Provisionales de los Estados Unidos Núm. 62/339,009 y 62/341,017.
El documento de salida MPEG N16440 menciona varios procedimientos para definir las regiones de interés en base al sistema de coordenadas de esfera. Específicamente, estos procedimientos especifican una región en una superficie esférica que se encierra por los cuatro segmentos de cuatro círculos grandes o dos círculos grandes y dos círculos pequeños, cada segmento entre dos puntos en la superficie esférica. En la presente memoria, un círculo, un círculo grande y un círculo pequeño se definen de la siguiente manera:
La intersección de un plano y una esfera es un círculo (excepto cuando la intersección es un punto). Todos los puntos de este círculo pertenecen a la superficie de la esfera. Un círculo grande, también conocido como un ortodromo o círculo de Riemann, de una esfera es la intersección de la esfera y un plano que pasa a través del punto central de la esfera. El centro de la esfera y el centro de un círculo grande siempre se coubican Cualquier otra intersección de un plano y una esfera que no cumpla esta condición y que no sea un punto, es un círculo pequeño.
Cuando se reproduce un video VR/360 en un visualizador montado en la cabeza (HMD) o un visualizador que no sea HMD, tal como un televisor, se representa una ventana de visualización para el usuario. Típicamente, una ventana de visualización es una región rectangular en un plano que es tangente a una esfera (es decir, intercepta con la esfera en un punto), donde el plano de la ventana de visualización es ortogonal a la dirección de visualización del usuario. Puede generarse una ventana de visualización al aplicar la proyección rectilínea, por ejemplo, como se discute en J. Boyce, E. Alshina, A. Abbas, Y. Ye, "JVET common test conditions and evaluation procedures for 360° video", Equipo Conjunto de Exploración de Video de ITU-T SG16WP3 e ISO/IEC JTC1/SC29/WG11, JVET-D1030, 4ta Reunión, octubre de 2016.
La región de la esfera que corresponde a una ventana de visualización es la que se encierra por los cuatro segmentos de los cuatro círculos grandes.
Otras técnicas para la señalización dual de una o más regiones más interesadas en el video VR incluyen la señalización, una en base a una región de la superficie esférica y la otra en base a una región de la imagen decodificada.
Las técnicas de esta divulgación pueden aplicarse para abordar determinados problemas que pueden surgir relacionados con la señalización de las regiones de interés, por ejemplo, en VR y/o en las técnicas de transmisión continua de multimedias. El mensaje SAND AnticipatedRequests puede ser usado por un cliente DASH para anunciar a un DANE en qué conjunto específico de segmentos se interesa y para señalar el conjunto de segmentos en las representaciones que el cliente DASH es probable que seleccione y solicite pronto. Este mensaje SAND es adecuado en escenarios en los que el cliente DASh está participando en una sesión de transmisión continua DASH y tiene una buena estimación de qué segmentos son probables que se quieran representar al usuario en base al estado en tiempo real del cliente y los comportamientos del usuario además de otra información relacionada disponible para el cliente.
La información de qué regiones en un video de VR que comprende el corte del director, u otras regiones más interesadas, como se indica a través del análisis de estadísticas, puede aplicarse a todo un contenido de video de VR. El cliente DASH puede usar tal información, además del estado en tiempo real del cliente y los comportamientos del usuario, para determinar qué segmentos se incluirán en un mensaje SAND AnticipatedRequests durante una sesión de transmisión continua DASH. El cliente DASH puede acceder directamente a tal información, si está presente como metadatos del formato de archivo. Sin embargo, esto requiere que el cliente DASH analice los metadatos del formato de archivo además de la MPD y también puede requerir que el cliente DASH aplique un proceso geométrico para la proyección y el empaquetado regional usado para la generación de las imágenes antes de codificar el video de VR.
Además, la información anterior (de qué regiones en un video de VR comprenden el corte del director u otras regiones más interesadas por las estadísticas) también puede usarse por un DANE (el servidor de origen y/o un elemento de caché o CDN) para prebuscar todos los Segmentos de las Representaciones DASH que comprenden el corte del director o las regiones más interesadas. Debido a su naturaleza en tiempo real y al ser un mensaje de estado originado solamente desde el cliente DASH, el mensaje SAND AnticipatedRequests no es adecuado para comunicar tal información a los DANE.
Otro problema más asociado con los diseños convencionales para comunicar el corte del director o las regiones más interesadas a los DANE es que puede haber diferentes niveles de intereses o probabilidades de las regiones de interés.
Otro problema más con el uso de las solicitudes anticipadas es que los dispositivos cliente necesitan soportar SAND. Sin embargo, muchos dispositivos cliente no soportan SAND. Además, las solicitudes anticipadas típicamente solo abordan dependencias a corto plazo para un único cliente, posiblemente incluso creando un estado del cliente con el MANE o el DANE
Además, puede haber diferentes niveles de interés o velocidades de uso para diferentes contenidos a nivel de contenido. Por ejemplo, los usuarios consumen mucho más algunas películas o títulos que otros. El diseño actual de DASH no proporciona la señalización de tal información, que también puede usarse para la prebúsqueda de los contenidos más consumidos.
La Figura 1 es un diagrama de bloques que ilustra un sistema 10 de ejemplo que implementa técnicas para los datos multimedia de transmisión continua sobre una red. En este ejemplo, el sistema 10 incluye el dispositivo de preparación de contenido 20, el dispositivo servidor 60, el elemento de red con reconocimiento multimedia (MANE) 76 y el dispositivo cliente 40. El dispositivo cliente 40, el MANE 76, el dispositivo de preparación de contenido 20 y el dispositivo servidor 60 se acoplan comunicativamente por la red 74, que puede comprender el Internet. En algunos ejemplos, el dispositivo de preparación de contenido 20 y el dispositivo servidor 60 pueden comprender el mismo dispositivo.
El dispositivo de preparación de contenido 20, en el ejemplo de la Figura 1, comprende la fuente de audio 22 y la 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 los datos de audio previamente grabados, un generador de datos de audio tal como un sintetizador computarizado o cualquier otra fuente de datos de audio. La fuente de video 24 puede comprender una cámara de video que produce los datos de video para ser codificados por el codificador de video 28, un medio de almacenamiento codificado con los datos de video previamente grabados, una unidad de generación de datos de video tal como una fuente de gráficos por ordenador o cualquier otra fuente de datos de video. El dispositivo de preparación de contenido 20 no se acopla necesariamente de forma comunicativa al dispositivo servidor 60 en todos los ejemplos, pero puede almacenar el contenido multimedia en un medio separado que es leído por el dispositivo servidor 60.
Los datos de audio y video sin procesar pueden comprender los datos analógicos o digitales. Los datos analógicos pueden digitalizarse antes de que sean codificados por el codificador de audio 26 y/o el codificador de video 28. La fuente de audio 22 puede obtener los 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 los 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 los datos de audio almacenados y la fuente de video 24 puede comprender un medio de almacenamiento legible por ordenador que comprende los datos de video almacenados. De esta manera, las técnicas descritas en esta divulgación pueden aplicarse a los datos de audio y video en tiempo real, en transmisión continua y en vivo o a los datos de audio y video pregrabados y archivados.
Las tramas de audio que corresponden a las tramas de video son generalmente tramas de audio que contienen los datos de audio que fueron capturados (o generados) por la fuente de audio 22 contemporáneamente con los datos de video capturados (o generados) por la fuente de video 24 que se contienen dentro de las tramas de video. Por ejemplo, mientras que un participante que habla generalmente produce los datos de audio al hablar, la fuente de audio 22 captura los datos de audio y la fuente de video 24 captura los datos de video del participante que habla al mismo tiempo, es decir, mientras que la fuente de audio 22 está capturando los datos de audio. Por tanto, una trama de audio puede corresponder temporalmente a una o más tramas de video particulares. En consecuencia, una trama de audio que corresponde a una trama de video generalmente corresponde a una situación en la que los datos de audio y los datos de video fueron capturados al mismo tiempo y para la cual una trama de audio y una trama de video comprenden, respectivamente, los datos de audio y los datos de video que fueron capturados al mismo tiempo.
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 el que se grabaron 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 trama de video codificada que representa un momento en el que se grabaron los datos de video para la trama de video codificada. En tales ejemplos, una trama de audio que corresponde a una trama de video puede comprender una trama de audio que comprende una marca de tiempo y una trama de video que comprende la misma marca de tiempo. El dispositivo de preparación de contenido 20 puede incluir un reloj interno desde el cual el codificador de audio 26 y/o el codificador de video 28 pueden generar las marcas de tiempo o que la fuente de audio 22 y la fuente de video 24 pueden usar para asociar los datos de audio y video, respectivamente, con una marca de tiempo.
En algunos ejemplos, la fuente de audio 22 puede enviar los datos al codificador de audio 26 que corresponde a un momento en el que se grabaron los datos de audio y la fuente de video 24 puede enviar los datos al codificador de video 28 que corresponde a un momento en el que se grabaron los datos de video. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencia en los datos de audio codificados para indicar un orden temporal relativo de los datos de audio codificados, pero sin indicar necesariamente un momento absoluto en el que se grabaron los datos de audio y de manera similar, el codificador de video 28 también puede usar los identificadores de secuencia para indicar un orden temporal relativo de los datos de video codificados. De manera similar, en algunos ejemplos, un identificador de secuencia puede mapearse o correlacionarse de otro modo con una marca de tiempo.
El codificador de audio 26 generalmente produce una transmisión de datos de audio codificados, mientras que el codificador de video 28 produce una transmisión de los datos de video codificados. Cada transmisión de datos individual (ya sea de audio o video) puede denominarse transmisión elemental. Una transmisión elemental es un único componente codificado digitalmente (posiblemente comprimido) de una representación. Por ejemplo, la parte codificada de video o audio de la representación puede ser una transmisión elemental. Una transmisión elemental puede convertirse en una transmisión elemental empaquetada (PES) antes de encapsularse dentro de un archivo de video. Dentro de la misma representación, puede usarse un ID de transmisión para distinguir los paquetes PES que pertenecen a una transmisión elemental del otro. La unidad básica de datos de una transmisión elemental es un paquete de transmisión elemental empaquetada (PES). Por tanto, los datos de video codificados generalmente corresponden a transmisiones de video elementales. De manera similar, los datos de audio corresponden a una o más transmisiones elementales respectivas.
Muchos estándares de codificación de video, tal como ITU-T H,264/AVC y el estándar de Codificación de Video de Alta Eficiencia (HEVC), definen la sintaxis, la semántica y el proceso de decodificación para los flujos de bits sin errores, cualquiera de los cuales de conformidad con un determinado perfil o nivel. Los estándares de 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, características o herramientas y restricciones que se les aplican. Como se define por el estándar H,264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits que se especifica por el estándar H,264. Un "nivel" corresponde a las limitaciones del consumo de recursos del decodificador, tales como, por ejemplo, la memoria y el cálculo del decodificador, que se relacionan con la resolución de las imágenes, la velocidad de bits y la velocidad de procesamiento de bloques. Un perfil puede señalarse con un valor de idc de perfil (indicador de perfil), mientras que un nivel puede señalarse con un valor de niveljdc (indicador de nivel).
El estándar H,264, por ejemplo, reconoce que, dentro de los límites impuestos por la sintaxis de un perfil dado, aún es posible requerir una gran variación en el rendimiento de los codificadores y decodificadores que depende 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 práctico ni económico implementar un decodificador capaz de tratar con todos los usos hipotéticos de la sintaxis dentro de un perfil particular. En consecuencia, el estándar H,264 define un "nivel" como un conjunto específico de restricciones impuestas a los valores de los elementos de sintaxis en el flujo de bits. Estas restricciones pueden ser simples límites de valores. Alternativamente, estas restricciones pueden tomar la forma de restricciones sobre combinaciones aritméticas de valores (por ejemplo, el ancho de la imagen multiplicado por el alto de la 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.
Un decodificador de conformidad con 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 soporta en el perfil básico de H,264/AVC, pero sí se soporta en otros perfiles de H,264/AVC. Un decodificador de conformidad con un nivel debería 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 la interpretabilidad. Por ejemplo, durante la transmisión de video, pueden negociarse y acordarse un par de definiciones de perfil y nivel para una sesión de transmisión completa. Más específicamente, en H,264/AVC, un nivel puede definir las limitaciones en el número de macrobloques que necesitan procesarse, el tamaño de búfer de la imagen decodificada (DPB), el tamaño de búfer de la imagen codificada (CPB), el rango de vector de movimiento vertical, el número máximo de vectores de movimiento por dos MB consecutivos y si un bloque B puede tener particiones de submacrobloques de menos de 8x8 píxeles. De esta manera, un decodificador puede determinar si el decodificador es capaz de decodificar correctamente el flujo de bits.
En el ejemplo de la Figura 1, la unidad de encapsulación 30 del dispositivo de preparación de contenido 20 recibe las transmisiones elementales que comprenden los datos de video codificados del codificador de video 28 y las transmisiones elementales que comprenden los 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 los datos codificados. En otros ejemplos, el codificador de video 28 y el codificador de audio 26 pueden interactuar cada uno con los respectivos empaquetadores para formar paquetes PES a partir de los datos codificados. En otros ejemplos más, la unidad de encapsulación 30 puede incluir empaquetadores para formar paquetes PES de los datos de audio y video codificados.
El codificador de video 28 puede codificar los datos de video de contenido multimedia en una variedad de formas, para producir diferentes representaciones del contenido multimedia a varias velocidades de bits y con varias características, tales como resoluciones de píxeles, velocidades de trama, conformidad con varios estándares de codificación, conformidad con varios perfiles y/o niveles de perfiles para varios estándares de codificación, representaciones que tienen una o múltiples vistas (por ejemplo, para reproducción bidimensional o tridimensional) u otras de tales características. Una representación, como se usa 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 una transmisión elemental, tal como una transmisión elemental de audio o una transmisión elemental de video. Cada paquete PES puede incluir un transm_id que identifica la transmisión elemental a la que pertenece el paquete PES. La unidad de encapsulación 30 es responsable de ensamblar las transmisiones elementales en los archivos de video (por ejemplo, los segmentos) de diversas representaciones.
La unidad de encapsulación 30 recibe los paquetes PES para las transmisiones elementales de una representación del codificador de audio 26 y el codificador de video 28 y forma las correspondientes unidades de capa de abstracción de red (NAL) de los paquetes PES. Los segmentos de video codificados pueden organizarse en unidades NAL, que proporcionan una representación de video "amigable con la red" que aborda las aplicaciones tales como la videotelefonía, el almacenamiento, la difusión o la transmisión continua. Las unidades NAL pueden categorizarse 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 central y pueden incluir los datos a nivel de bloque, macrobloque y/o segmento. Otras unidades NAL pueden ser unidades NAL no VCL. En algunos ejemplos, una imagen codificada en una instancia de tiempo, normalmente presentada como una imagen codificada primaria, puede contenerse en una unidad de acceso, que puede incluir una o más unidades NAL.
Las unidades NAL no VCL pueden incluir unidades NAL del conjunto de parámetros y unidades NAL SEI, entre otras. Los conjuntos de parámetros pueden contener la información de encabezado a nivel de secuencia (en los conjuntos de parámetros de secuencia (SPS)) y la información de encabezado a nivel de imagen que cambia con poca frecuencia (en los conjuntos de parámetros de imagen (PPS)). Con los conjuntos de parámetros (por ejemplo, PPS y SPS), no es necesario repetir la información que cambia con poca frecuencia para cada secuencia o imagen, por tanto, puede mejorarse la eficiencia de codificación. Además, el uso de los conjuntos de parámetros puede permitir la transmisión fuera de banda de la información de encabezado importante, evitando la necesidad de las transmisiones redundantes para la resistencia a errores. En los ejemplos de transmisión fuera de banda, las unidades NAL del conjunto de parámetros pueden transmitirse en un canal diferente al de otras unidades NAL, tal como las unidades NAL SEI.
La Información de Mejora Complementaria (SEI) puede contener la información que no es necesaria para decodificar las muestras de imágenes codificadas de las unidades NAL VCL, pero puede ayudar en los procesos relacionados con la decodificación, visualización, resistencia a errores y otros propósitos. Los mensajes SEI pueden contenerse en las 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 los decodificadores que cumplen con los estándares. Los mensajes SEI pueden ser mensajes SEI de nivel de secuencia o mensajes SEI de nivel de imagen. Alguna información de nivel de secuencia puede contenerse en mensajes SEI, tal como los mensajes SEI de información de escalabilidad en el ejemplo de SVC y los mensajes SEI de información de escalabilidad de vista en MVC. Estos mensajes SEI de ejemplo pueden transmitir la información sobre, por ejemplo, la extracción de puntos de operación y las características de los puntos de operación. Además, la unidad de encapsulación 30 puede formar un archivo de manifiesto, tal como un descriptor de presentación multimedia (MPD) que describe las características de las representaciones. La unidad de encapsulación 30 puede formatear la MPD de acuerdo con el lenguaje de marcado extensible (XML).
La unidad de encapsulación 30 puede proporcionar los 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 serie universal (USB), un escritor o quemador de CD o DVD, una interfaz para medios de almacenamiento magnéticos o flash, u otras interfaces para almacenar o transmitir los datos multimedia. La unidad de encapsulación 30 puede proporcionar los datos de cada una de las representaciones de contenido multimedia a la interfaz de salida 32, que puede enviar los datos al dispositivo servidor 60 a través de los medios de almacenamiento o la transmisión de red. En el ejemplo de la Figura 1, el dispositivo servidor 60 incluye el medio de almacenamiento 62 que almacena diversos contenidos multimedia 64, cada uno incluye un archivo de manifiesto 66 respectivo y una o más representaciones 68A-68N (las representaciones 68). En algunos ejemplos, la interfaz de salida 32 también puede enviar los datos directamente a la red 74.
En algunos ejemplos, las representaciones 68 pueden separarse en conjuntos de adaptación. Es decir, varios subconjuntos de representaciones 68 pueden incluir los conjuntos comunes de características respectivos, tales como el códec, el perfil y nivel, la resolución, el número de vistas, el formato de archivo para los segmentos, la información del tipo de texto que puede identificar un idioma u otras características del texto a visualizarse con la representación y/o los datos de audio para decodificarse y presentarse, por ejemplo, por altavoces, la información del ángulo de la cámara que puede describir un ángulo de la cámara o la perspectiva de la cámara del mundo real de una escena para las representaciones en el conjunto de adaptación, la información de clasificación que describe la idoneidad de los contenidos para audiencias particulares, o similares.
El archivo de manifiesto 66 puede incluir los datos indicativos de los subconjuntos de las representaciones 68 que corresponden a los conjuntos de adaptación particulares, así como también las características comunes para los conjuntos de adaptación. El archivo de manifiesto 66 también puede incluir los datos representativos de las características individuales, tales como las velocidades de bits, para las representaciones individuales de los conjuntos de adaptación. De esta manera, un conjunto de adaptación puede proporcionar una adaptación simplificada del ancho de banda de la red. Las representaciones en un conjunto de adaptación pueden indicarse mediante el uso de los elementos secundarios de un elemento del conjunto de adaptación del archivo de manifiesto 66.
El dispositivo servidor 60 incluye la unidad de procesamiento de solicitudes 70 y la interfaz de red 72. En algunos ejemplos, el dispositivo servidor 60 puede incluir una pluralidad de interfaces de red. Además, cualquiera o todas las características del dispositivo servidor 60 pueden implementarse en otros dispositivos de una red de entrega de contenido, tales como enrutadores, puentes, dispositivos proxy, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de entrega de contenido pueden almacenar en caché los datos de contenido multimedia 64 e incluir los componentes de conformidad sustancialmente con los del dispositivo servidor 60. En general, la interfaz de red 72 se configura para enviar y recibir los datos a través de la red 74.
La unidad de procesamiento de solicitudes 70 se configura para recibir las solicitudes de red de los dispositivos cliente, tales como el dispositivo cliente 40, para los datos del medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento de solicitudes 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 y otros, Grupo de Trabajo de la Red, IETF, junio de 1999. Es decir, la unidad de procesamiento de solicitudes 70 puede configurarse para recibir las solicitudes HTTP GET o GET parciales y proporcionar los 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 el uso de una URL del segmento. En algunos ejemplos, las solicitudes también pueden especificar uno o más rangos de bytes del segmento, por tanto, comprenden las solicitudes GET parciales. La unidad de procesamiento de solicitudes 70 puede configurarse además para atender las solicitudes HTTP HEAD para proporcionar los datos de encabezado de un segmento de una de las representaciones 68. En cualquier caso, la unidad de procesamiento de solicitudes 70 puede configurarse para procesar las solicitudes para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 40.
Adicional o alternativamente, la unidad de procesamiento de solicitudes 70 puede configurarse para entregar los datos multimedia a través de un protocolo de difusión o multidifusión, tal como eMBMS. El dispositivo de preparación de contenido 20 puede crear los segmentos y/o subsegmentos DASH sustancialmente de la misma manera que se describe, pero el dispositivo servidor 60 puede entregar estos segmentos o subsegmentos mediante el uso de eMBMS u otro protocolo de transporte de red de difusión o multidifusión. Por ejemplo, la unidad de procesamiento de solicitudes 70 puede configurarse para recibir una solicitud de unión a un grupo de multidifusión desde el dispositivo cliente 40. Es decir, el dispositivo servidor 60 puede anunciar una dirección de protocolo de Internet (IP) asociada con un grupo de multidifusión a los dispositivos cliente, incluido el dispositivo cliente 40, asociado con el contenido multimedia particular (por ejemplo, una difusión de un evento en vivo). El dispositivo cliente 40, a su vez, puede enviar una solicitud para unirse al grupo de multidifusión. Esta solicitud puede propagarse a través de la red 74, por ejemplo, los enrutadores que forman la red 74, de manera que los enrutadores se encarguen de dirigir el tráfico destinado a la dirección IP asociada con el grupo de multidifusión a los dispositivos cliente suscritos, tal como el dispositivo cliente 40.
Como se ilustra en el ejemplo de la Figura 1, el contenido multimedia 64 incluye el archivo de manifiesto 66, que puede corresponder a una descripción de presentación multimedia (MPD). El archivo de manifiesto 66 puede contener las descripciones de diferentes representaciones alternativas 68 (por ejemplo, los servicios de video con diferentes calidades) y la descripción puede incluir, por ejemplo, la 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 cliente 40 puede recuperar la MPD de una presentación multimedia para determinar cómo acceder a los segmentos de las representaciones 68.
En particular, la unidad de recuperación 52 puede recuperar los datos de configuración (no mostrados) del dispositivo cliente 40 para determinar las capacidades de decodificación del decodificador de video 48 y las capacidades de representación de la salida de video 44. Los datos de configuración también pueden incluir cualquiera o la totalidad de una preferencia de idioma seleccionada por un usuario del dispositivo cliente 40, una o más perspectivas de la cámara que corresponden a las preferencias de profundidad establecidas por el usuario del dispositivo cliente 40 y/o una preferencia de clasificación seleccionada por el usuario del dispositivo cliente 40. La unidad de recuperación 52 puede comprender, por ejemplo, un navegador web o un cliente multimedia configurado para enviar las solicitudes HTTP GET y GET parciales. La unidad de recuperación 52 puede corresponder a las instrucciones de software ejecutadas por uno o más procesadores o unidades de procesamiento (no mostradas) del dispositivo cliente 40. En algunos ejemplos, toda o parte de la funcionalidad descrita con respecto a la unidad de recuperación 52 puede implementarse en hardware, o una combinación de hardware, software y/o microprograma, donde puede proporcionarse el hardware requerido para ejecutar las instrucciones para el software o el microprograma.
La unidad de recuperación 52 puede comparar las capacidades de decodificación y representación del dispositivo cliente 40 con las características de las representaciones 68 indicadas por la información del archivo de manifiesto 66. La unidad de recuperación 52 puede recuperar inicialmente al menos una porción del archivo de manifiesto 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 las 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 las características que pueden satisfacerse por las capacidades de codificación y representación del dispositivo cliente 40. La unidad de recuperación 52 puede entonces determinar las velocidades de bits para las representaciones en el conjunto de adaptación, determinar una cantidad de ancho de banda de la red actualmente disponible y recuperar los segmentos de una de las representaciones que tiene una velocidad de bits que puede satisfacerse por el ancho de banda de la red.
En general, las representaciones de velocidades de bits más altas pueden dar lugar a una reproducción de video de mayor calidad, mientras que las representaciones de velocidades de bits más bajas pueden proporcionar una reproducción de video de calidad suficiente cuando el ancho de banda de la red disponible disminuye. En consecuencia, cuando el ancho de banda de la red disponible es relativamente alto, la unidad de recuperación 52 puede recuperar los datos de las representaciones de velocidades de bits relativamente altas, mientras que cuando el ancho de banda de la red disponible es bajo, la unidad de recuperación 52 puede recuperar los datos de las representaciones de velocidades de bits relativamente bajas. De esta manera, el dispositivo cliente 40 puede transmitir los datos multimedia sobre la red 74 mientras que también se adapta a la disponibilidad cambiante del ancho de banda de la red 74.
Adicional o alternativamente, la unidad de recuperación 52 puede configurarse para recibir los datos de acuerdo con un protocolo de red de difusión o multidifusión, tal como eMBMS o multidifusión IP. En tales ejemplos, la unidad de recuperación 52 puede enviar una solicitud para unirse a un grupo de red de multidifusión asociado con el contenido multimedia particular. Después de unirse al grupo de multidifusión, la unidad de recuperación 52 puede recibir los datos del grupo de multidifusión sin más solicitudes emitidas al dispositivo servidor 60 o al dispositivo de preparación de contenido 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 cambiar de canal a un grupo de multidifusión diferente.
La interfaz de red 54 puede recibir y proporcionar los datos de los segmentos de una representación seleccionada a la unidad de recuperación 52, que a su vez puede proporcionar los segmentos a la unidad de desencapsulación 50. La unidad de desencapsulación 50 puede desencapsular los elementos de un archivo de video en transmisiones PES constituyentes, desempaquetar las transmisiones PES para recuperar los datos codificados y enviar los datos codificados al decodificador de audio 46 o al decodificador de video 48, en función de si los datos codificados son parte de una transmisión de audio o video, por ejemplo, como se indican por los encabezados de paquete PES de la transmisión. El decodificador de audio 46 decodifica los 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 pueden incluir una pluralidad de vistas de una transmisión, a la salida de video 44.
El codificador de video 28, el decodificador de video 48, el codificador de audio 26, el decodificador de audio 46, la unidad de encapsulación 30, la unidad de recuperación 52 y la unidad de desencapsulación 50 pueden implementarse cada uno como cualquiera de una variedad de circuitos de procesamiento adecuados, como sea aplicable, tal como el circuitos de procesamiento de función fija y/o de programación, que puede incluir uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados para aplicaciones específicas (ASIC), matrices de puertas lógicas programables en campo (FPGA), circuitos lógicos discretos, software, hardware, microprograma o cualquier combinación de los mismos. Cada uno del codificador de video 28 y decodificador de video 48 puede incluirse en uno o más codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un codificador/decodificador de video (CODEC) combinado. Del mismo modo, cada uno del codificador de audio 26 y decodificador de audio 46 puede incluirse en uno o más codificadores o decodificadores, cualquiera de los cuales puede integrarse como parte de un CODEC combinado. Un aparato que incluye el codificador de video 28 y/o el decodificador de video 48, el codificador de audio 26, el decodificador de audio 46, la unidad de encapsulación 30, la unidad de recuperación 52 y/o la unidad de desencapsulación 50 puede comprender un circuito integrado, un microprocesador y/o un dispositivo de comunicación inalámbrica, tal como un teléfono celular.
El dispositivo cliente 40, el dispositivo servidor 60 y/o el dispositivo de preparación de contenido 20 pueden configurarse para operar de acuerdo con las técnicas de esta divulgación. Para propósitos de ejemplo, esta divulgación describe estas técnicas con respecto al dispositivo cliente 40 y al dispositivo servidor 60. Sin embargo, debe entenderse que el dispositivo de preparación de contenido 20 puede configurarse para realizar estas técnicas, en lugar del (o además de) dispositivo servidor 60.
La unidad de encapsulación 30 puede formar las unidades NAL que comprenden un encabezado que identifica un programa al que pertenece la unidad NAL, así como también una carga útil, por ejemplo, los datos de audio, los datos de video o los datos que describen la transmisión de transporte o el programa al que corresponde la unidad NAL. Por ejemplo, en H,264/AVC, una unidad NAL incluye un encabezado de 1 byte y una carga útil de tamaño variable. Una unidad NAL que incluye los datos de video en su carga útil puede comprender varios niveles de granularidad de los datos de video. Por ejemplo, una unidad NAL puede comprender un bloque de datos de video, una pluralidad de bloques, un segmento de datos de video o toda una imagen de datos de video. La unidad de encapsulación 30 puede recibir los datos de video codificados desde el codificador de video 28 en forma de paquetes PES de transmisiones elementales. La unidad de encapsulación 30 puede asociar cada transmisión elemental con un programa correspondiente.
La unidad de encapsulación 30 también puede ensamblar las unidades de acceso desde una pluralidad de unidades NAL. En general, una unidad de acceso puede comprender una o más unidades NAL para representar una trama de datos de video, así como los datos de audio que corresponden a la trama cuando tales datos de audio están disponibles. Una unidad de acceso generalmente incluye todas las unidades NAL para una instancia de tiempo de salida, por ejemplo, todos los datos de audio y video para una instancia de tiempo. Por ejemplo, si cada vista tiene una velocidad de trama de 20 tramas por segundo (fps), entonces cada instancia de tiempo puede corresponder a un intervalo de tiempo de 0,05 segundos. Durante este intervalo de tiempo, las tramas específicas para todas las vistas de la misma unidad de acceso (la misma instancia de tiempo) pueden representarse simultáneamente. En un ejemplo, una unidad de acceso puede comprender una imagen codificada en una instancia de tiempo, que puede presentarse como una imagen codificada primaria.
En consecuencia, una unidad de acceso puede comprender todas las tramas de audio y video de una instancia temporal común, por ejemplo, todas las vistas que corresponden al tiempo X. Esta divulgación también se refiere a una imagen codificada de una vista particular como un "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista particular en un momento particular. En consecuencia, una unidad de acceso puede definirse como que comprende todos los componentes de vista de una instancia temporal común. El orden de decodificación de las unidades de acceso no tiene que ser necesariamente el mismo que el orden de salida o visualización.
Una presentación multimedia puede incluir una descripción de presentación multimedia (MPD), que puede contener las descripciones de diferentes representaciones alternativas (por ejemplo, servicios de video con diferentes calidades) y la descripción puede incluir, por ejemplo, la información de códec, un valor de perfil y un valor de nivel. Un MPD es un ejemplo de archivo de manifiesto, tal como el archivo de manifiesto 66. El dispositivo cliente 40 puede recuperar la MPD de una presentación multimedia para determinar cómo acceder a los fragmentos de película de varias presentaciones. Los fragmentos de película pueden estar ubicados en cuadros de fragmentos de película (cuadros moof) de archivos de video.
El archivo de manifiesto 66 (que puede comprender, por ejemplo, una MPD) puede anunciar la disponibilidad de los segmentos de las representaciones 68. Es decir, la MPD puede incluir la información que indique la hora del reloj de pared en la que un primer segmento de una de las representaciones 68 se vuelve disponible, así como también la información que indica las duraciones de los segmentos dentro de las representaciones 68. De esta manera, la unidad de recuperación 52 del dispositivo cliente 40 puede determinar cuándo está disponible cada segmento, en base al tiempo de inicio, así como también en las duraciones de los segmentos que preceden a un segmento particular.
Después de que la unidad de encapsulación 30 ha ensamblado las unidades NAL y/o las unidades de acceso en un archivo de video en base a los datos recibidos, la unidad de encapsulación 30 pasa el archivo de video a la interfaz de salida 32 para su salida. En algunos ejemplos, la unidad de encapsulación 30 puede almacenar el archivo de video localmente 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 al dispositivo cliente 40. La interfaz de salida 32 puede comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para escribir los datos en un medio legible por ordenador tal como, por ejemplo, una unidad óptica, una unidad de medios magnéticos (por ejemplo, una unidad de disquete), un puerto de bus serie universal (USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 32 envía el 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.
La interfaz de red 54 puede recibir una unidad NAL o la unidad de acceso a través de la red 74 y proporcionar la unidad NAL o la unidad de acceso a la unidad de desencapsulación 50, a través de la unidad de recuperación 52. La unidad de desencapsulación 50 puede desencapsular un elemento de un archivo de video en transmisiones PES constituyentes, desempaquetar las transmisiones PES para recuperar los datos codificados y enviar los datos codificados al decodificador de audio 46 o al decodificador de video 48, en función de si los datos codificados son parte de una transmisión de audio o video, por ejemplo, como se indican por los encabezados de paquete PES de la transmisión. El decodificador de audio 46 decodifica los 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 pueden incluir una pluralidad de vistas de una transmisión, a la salida de video 44.
De acuerdo con las técnicas de esta divulgación, un dispositivo multimedia, tal como el dispositivo cliente 40, puede recibir la información señalizada sobre qué estructuras de datos (por ejemplo, las representaciones, los conjuntos de adaptación, las presentaciones multimedia, los segmentos o similares) se espera que sean de más interés para los usuarios que otros. Los datos multimedia se denominan típicamente como "contenido", pero la popularidad del contenido puede traducirse en estructuras de entrega DASH que se manejan fácilmente mediante los elementos de red HTTP, tales como el dispositivo servidor 60, el dispositivo cliente 40, el dispositivo de preparación de contenido 20 y otros dispositivos (tales como el MANE o el DANE). Si el proveedor de contenido (por ejemplo, el dispositivo de preparación de contenido 20 y/o el dispositivo servidor 60) proporciona tales datos, tal información puede usarse para la prebúsqueda de datos por el dispositivo cliente 40 o los elementos de red intermedios dentro de la red 74 (no mostrada en el ejemplo de la Figura 1) entre los dispositivos cliente y los dispositivos servidor de origen en los sistemas de transmisión continua adaptativa, tal como el sistema 10. Tal información también puede usarse, por ejemplo, para entregar los datos que se consideran más relevantes en un enlace de datos preferido, por ejemplo, en multidifusión o difusión, mientras que los datos menos populares solamente pueden proporcionarse en unidifusión desde el servidor de origen (por ejemplo, el dispositivo servidor 60). El dispositivo cliente 40 o un dispositivo de red intermedio de la red 74 también pueden prebuscar los datos que se espera sean populares con una mayor calidad, con el fin de garantizar que tales datos estén disponibles en buena calidad para muchos usuarios. Una o más de estas técnicas pueden aplicarse independientemente o en combinación con otras.
En un ejemplo, el dispositivo servidor 60 proporciona la señalización a nivel de MPD en el archivo de manifiesto 66 que indica el consumo relativo a nivel de contenido o a nivel de archivo de manifiesto (por ejemplo, a nivel de MPD) o la tasa de solicitud entre los diferentes contenidos del medio de almacenamiento 62. Por ejemplo, la indicación puede no tener unidad y un valor mayor puede indicar una mayor posibilidad o probabilidad de que se consuma/solicite una Representación (por ejemplo, una de las representaciones 68) o el Conjunto de Adaptación de la Presentación Multimedia. Esta información puede usarse por los DANE para prebuscar los títulos más populares (por ejemplo, los más solicitados) o partes de los mismos para prepararlos y que es probable que sean solicitados pronto por los dispositivos cliente, tal como el dispositivo cliente 40.
Como un ejemplo, el dispositivo servidor 60 puede agregar un atributo opcional @contentRequestRate al archivo de manifiesto 66 (por ejemplo, una MPD), que puede asignarse en el nivel de la Representación, el Conjunto de Adaptación y/o la MPD. Cuando está presente, el valor de este atributo indica el consumo relativo a nivel de contenido o nivel de MPD o la tasa de solicitud entre los diferentes contenidos. El valor de este atributo puede ser sin unidades. Un valor mayor puede indicar una mayor posibilidad de que se consuma/solicite la Representación, el Conjunto de Adaptación o la Presentación Multimedia. Alternativamente, un valor más bajo puede indicar una mayor posibilidad o probabilidad de que se consuman/soliciten los datos.
Por tanto, un MANE, DANE o dispositivo cliente 40 puede usar los valores de este atributo para determinar las posibilidades relativas de que, por ejemplo, cada una de las representaciones 68 se consuma y prebuscar los datos multimedia de una de las representaciones 68 que tiene la posibilidad/probabilidad más alta de que se consuma/solicite. Es decir, el MANE/DANE/dispositivo cliente 40 puede prebuscar los datos multimedia correspondientes, ya que el MANE/DANE/dispositivo cliente 40 puede recuperar los datos multimedia sin una solicitud explícita, por ejemplo, de un usuario (o en el caso de un MANE/DANE, desde el dispositivo cliente 40 u otros dispositivos cliente).
Adicional o alternativamente, el dispositivo servidor 60 puede proporcionar un Conjunto de Adaptación y/o una señalización a nivel de Representación (por ejemplo, en el archivo de manifiesto 66, tal como una MPD) que indica el consumo relativo temporal/parcial o la tasa de solicitud de una representación entre todas las representaciones dentro de la misma Presentación Multimedia (por ejemplo, las representaciones 68). El dispositivo cliente 40 y/o un MANE/DANE pueden usar esta información para prebuscar las piezas solicitadas más probables de la Presentación Multimedia para prepararse y que es probable que sean solicitadas pronto por algunos dispositivos cliente, por ejemplo, el dispositivo cliente 40. Estas piezas, por ejemplo, pueden cubrir una representación del corte del director de un contenido de video VR/360.
En un ejemplo, el dispositivo servidor 60 puede señalar un elemento de nivel de Representación RepRequestRate, que puede ser un elemento opcional del archivo de manifiesto 66. Este elemento puede comprender una matriz de pares de dos atributos de {@repRequestRate, @validTimeEnd}, donde @repRequestRate puede indicar el consumo relativo o la tasa de solicitud dentro de la misma Presentación Multimedia (que nuevamente puede ser sin unidades y un valor mayor puede significar mayor posibilidad de que se consuman/soliciten los (Sub)Segmentos dentro de la duración de tiempo especificada más abajo) y @validTimeEnd puede indicar el final, en la línea de tiempo de la multimedia, de la duración dentro del cual se aplica el consumo relativo o el valor de la tasa de solicitud @repRequestRate. El inicio de la duración del tiempo puede ser el comienzo del período actual o un tiempo indicado por una instancia anterior de @validTimeEnd. Por tanto, el dispositivo cliente 40 o un MANE/DANE, puede determinar y prebuscar uno o más segmentos dentro del tiempo correspondiente de la representación correspondiente que tiene la mayor probabilidad de que se solicite/consuma.
Adicional o alternativamente, el dispositivo servidor 60 puede señalar la información a nivel de Representación de consumo relativo o la tasa de solicitud de la Representación entre todas las Representaciones dentro de la misma Presentación Multimedia (por ejemplo, las representaciones 68) como un valor fijado por todo un tiempo de duración de la Representación, es decir, no temporal/parcial. Por tanto, el dispositivo cliente 40 (o un MANE/DANE) puede determinar un consumo relativo o una tasa de solicitud para una representación individual para toda una duración de la representación.
Adicional o alternativamente, el dispositivo servidor 60 puede señalar el consumo relativo o las tasas de solicitud en uno o más de un nivel de Período, un nivel de Conjunto de Adaptación, un nivel de Representación y/o un nivel de SubRepresentación. El dispositivo cliente 40 puede configurarse para determinar que un valor para una señalización de nivel inferior, si existe, sobrescribe cualquier señalización de nivel superior. Es decir, los valores pueden señalarse en dos o más de un nivel de período DASH, un nivel de conjunto de adaptación DASH, un nivel de representación DASH o un nivel de subrepresentación DASH y el cliente DASH 40 puede determinar que los valores señalados en niveles inferiores sustituyen a los valores señalados en niveles superiores. Alternativamente, un valor más bajo puede indicar una mayor posibilidad o probabilidad de que se consuman/soliciten los datos.
Adicional o alternativamente, el dispositivo servidor 60 puede señalar la información en un nivel de metadatos temporizado, donde el dispositivo servidor 60 puede proporcionar los metadatos como una pista separada que puede entenderse por el dispositivo cliente 40 o un MANE/DANE que hace uso de esta información. La pista de metadatos puede multiplexarse con determinada pista multimedia en la misma Representación o encapsularse exclusivamente en su propia Representación.
Como otro ejemplo más, el dispositivo servidor 60 puede señalar un nuevo mensaje PED que puede llevar el consumo relativo o la información de la tasa de solicitud como se describe anteriormente para una Presentación Multimedia. El cuerpo del mensaje puede llevar solamente el consumo relativo o la información de la tasa de solicitud y un ID de MPD que identifica la MPD al que se aplica la información, pero sin otras partes de la MPD. Alternativamente, el cuerpo del mensaje PED puede simplemente llevar el propio MPD, que contiene el consumo relativo o la información de la tasa de solicitud, así como también todas las otras partes de la MPD. El mensaje PED que lleva solamente el consumo relativo o la información de la tasa de solicitud puede usarse cuando todos los destinos tienen acceso al MPD, mientras que el mensaje PED que lleva el propio MPD puede usarse cuando al menos uno de los destinos no tiene acceso al MPD.
Por ejemplo, para los MANE/DANE que tienen acceso al propio MPD, el dispositivo servidor 60 puede construir el mensaje PED para incluir la información para actualizar el consumo relativo o las tasas de solicitud y el mensaje puede incluir: un valor para @mpdId que identifica la MPD a la que se aplica este mensaje; un valor para @contentRequestRate como se discutió anteriormente; y valores para una matriz de {@repId, RepRequestRate}, donde @repId es el ID de Representación y RepRequestRate es un elemento con la misma sintaxis y semántica que se discutió anteriormente. Alternativamente, para los MANE/DANE que no tienen acceso al propio MPD, entonces el mensaje PED puede contener el propio MPD, con el consumo relativo actualizado o la información de la tasa de solicitud.
De esta manera, el dispositivo cliente 40 representa un ejemplo de un dispositivo multimedia para recuperar los datos multimedia, el dispositivo multimedia que incluye uno o más procesadores configurados para recibir la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que sea de interés para un usuario, la estructura de datos que incluye los datos multimedia y recupera los datos multimedia de la estructura de datos antes de recibir una solicitud de los datos multimedia del usuario. En este ejemplo, el dispositivo cliente 40 puede recuperar (es decir, prebuscar) los datos multimedia del dispositivo servidor 60.
El MANE 76 generalmente representa un dispositivo multimedia que puede realizar la prebúsqueda de datos multimedia de acuerdo con las técnicas de esta divulgación. El MANE 76 puede incluir una memoria configurada para, por ejemplo, almacenar los datos multimedia recuperados y uno o más procesadores implementados en circuitos y configurados para realizar las técnicas de esta divulgación. Por tanto, el MANE 76 representa un ejemplo de un dispositivo multimedia para recuperar los datos multimedia, el dispositivo multimedia que incluye uno o más procesadores configurados para recibir la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que sea recuperada por un pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, la estructura de datos que incluye los datos multimedia y recupera los datos multimedia de la estructura de datos antes de recibir las solicitudes de los datos multimedia de los dispositivo de usuario. Los dispositivos de usuario pueden incluir el dispositivo cliente 40. El MANE 76 puede recuperar (es decir, prebuscar) los datos multimedia de, por ejemplo, el dispositivo servidor 60. En algunos ejemplos, el MANE 76 puede ser un elemento de red con reconocimiento DASH (DANE). Adicionalmente, el dispositivo cliente 40 puede recuperar los datos multimedia del MANE 76, en lugar del dispositivo servidor 60. Por tanto, cualquiera o ambos del dispositivo cliente 40 y el MANE 76 pueden aplicar las técnicas de esta divulgación para prebuscar los datos multimedia particulares que pueden ser de interés para un usuario.
La Figura 2 es un diagrama de bloques que ilustra un ejemplo del conjunto de componentes de la unidad de recuperación 52 de la Figura 1 con mayor detalle. En este ejemplo, la unidad de recuperación 52 incluye la unidad de software intermedio eMBMS 100, el cliente DASH 110 y la aplicación multimedia 112.
En este ejemplo, la unidad de software intermedio eMBMS 100 incluye además la unidad de recepción eMBMS 106, la caché 104 y la unidad de servidor proxy 102. En este ejemplo, la unidad de recepción eMBMS 106 se configura para recibir los datos a través de eMBMS, por ejemplo, de acuerdo con Entrega de Archivos sobre Transporte Unidireccional (FLUTE), descrito en T. Paila y otros, "FLUTE-File Delivery over Unidirectional Transport", Grupo de Trabajo de la Red, RFC 6726, noviembre de 2012, disponible en http://tools.ietf.org/html/rfc6726. Es decir, la unidad de recepción eMBMS 106 puede recibir los archivos a través de la difusión desde, por ejemplo, el dispositivo servidor 60, que puede actuar como un BM-SC.
A medida que la unidad de software intermedio eMBMS 100 recibe los datos para los archivos, la unidad de software intermedio eMBMS puede almacenar los datos recibidos en la caché 104. La caché 104 puede comprender un medio de almacenamiento legible por ordenador, tal como una memoria flash, un disco duro, RAM o cualquier otro medio de almacenamiento adecuado.
La unidad de servidor proxy 102 puede actuar como servidor para el cliente DASH 110. Por ejemplo, la unidad de servidor proxy 102 puede proporcionar un archivo MPD u otro archivo de manifiesto al cliente DASH 110. La unidad de servidor proxy 102 puede anunciar los tiempos de disponibilidad para los segmentos en el archivo MPD, así como también los hipervínculos desde los cuales pueden recuperarse los segmentos. Estos hipervínculos pueden incluir un prefijo de dirección de host local que corresponde al dispositivo cliente 40 (por ejemplo, 127,0,0,1 para IPv4). De esta manera, el cliente DASH 110 puede solicitar los segmentos desde la unidad de servidor local 102 mediante el uso de las solicitudes HTTP GET o GET parciales. Por ejemplo, para un segmento disponible desde el enlace http://127,0,0,1/rep1/seg3, el cliente DASH 110 puede construir una solicitud HTTP GET que incluye una solicitud para http://127,0,0,1/rep1/seg3 y enviar la solicitud a la unidad de servidor proxy 102. La unidad de servidor proxy 102 puede recuperar los datos solicitados de la caché 104 y proporcionar los datos al cliente DASH 110 en respuesta a tales solicitudes. El cliente DASH 110 entrega los datos multimedia recuperados de la unidad de servidor proxy 102 a la aplicación multimedia 112 para su reproducción.
De acuerdo con determinados ejemplos de las técnicas de esta divulgación, la unidad de software intermedio eMBMS 100 puede recibir los datos multimedia que es más probable que se presenten a un usuario a través del eMBMS (por ejemplo, a través de difusión/multidifusión), mientras que la unidad de recuperación 52 (ver la Figura 1) (por ejemplo, la unidad de software intermedio eMBMS 100 o el cliente DASH 110) pueden recuperar otros datos multimedia que no es probable que se presenten al usuario a través de unidifusión.
La Figura 3 es un diagrama conceptual que ilustra los elementos de contenido multimedia de ejemplo 120. El contenido multimedia 120 puede corresponder al contenido multimedia 64 (Figura 1) u otro contenido multimedia almacenado en el medio de almacenamiento 62. En el ejemplo de la Figura 3, el contenido multimedia 120 incluye una descripción de presentación multimedia (MPD) 122 y una pluralidad de representaciones 124A-124N (las representaciones 124). La representación 124A incluye los datos de encabezado opcionales 126 y los segmentos 128A-128N (los segmentos 128), mientras que la representación 124N incluye los datos de encabezado opcionales 130 y los segmentos 132A-132N (los segmentos 132). La letra N se usa 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.
La MPD 122 puede comprender una estructura de datos separada de las representaciones 124. La MPD 122 puede corresponder al archivo de manifiesto 66 de la Figura 1. Del mismo modo, las representaciones 124 pueden corresponder a las representaciones 68 de la Figura 2. En general, la MPD 122 puede incluir los datos que generalmente describen las características de las representaciones 124, tales como las características de codificación y representación, los conjuntos de adaptación, un perfil al que corresponde la MPD 122, la información de tipo de texto, la información de ángulo de cámara, la información de clasificación, la información de modo truco (por ejemplo, la información indicativa de las representaciones que incluyen las subsecuencias temporales) y/o la información para recuperar períodos remotos (por ejemplo, para la inserción de publicidad dirigida en el contenido multimedia durante la reproducción).
La MPD 122 generalmente señala las características sobre varias estructuras de datos en varios niveles. Por ejemplo, la MPD 122 señala las características sobre los conjuntos de adaptación que incluyen una pluralidad de representaciones, las representaciones en sí mismas, los grupos de segmentos dentro de una representación y los segmentos individuales. La MPD 122 puede formarse como un documento de Lenguaje de Marcado Extensible (XML), que incluye los conjuntos recursivos de las etiquetas. Por tanto, puede formarse un nivel de conjunto de adaptación mediante el uso de una etiqueta de conjunto de adaptación, puede formarse un nivel de conjunto de representación mediante el uso de una etiqueta de representación dentro de un conjunto de adaptación, puede formarse un nivel de grupo de segmentos mediante el uso de una etiqueta de grupo de segmentos dentro de una representación y puede formarse un nivel de segmento mediante el uso de una etiqueta de segmento dentro de un grupo de segmentos o dentro de una representación.
De acuerdo con las técnicas de esta divulgación, la MPD 122 puede incluir la información que indique al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que sea de interés para un usuario, la estructura de datos que incluye los datos multimedia. Por ejemplo, la estructura de datos puede ser una presentación multimedia, un conjunto de adaptación, una representación o una subsección de una representación (por ejemplo, un conjunto de uno o más segmentos o subsegmentos).
Como se discutió anteriormente, la MPD 122 puede incluir un elemento RepRequestRate que incluye una matriz de pares de dos atributos de {@repRequestRate, @validTimeEnd}. En este ejemplo, un valor sin unidades para @repRequestRate puede indicar un consumo relativo o una tasa de solicitud dentro de la misma presentación multimedia para una representación correspondiente y un valor para @validTimeEnd puede indicar un tiempo de finalización de la línea de tiempo de la multimedia para un período de tiempo dentro del cual se aplica el valor @repRequestRate.
En algunos ejemplos, la MPD 122 puede incluir un valor para un elemento de sintaxis que representa un consumo relativo o la tasa de solicitud de una representación correspondiente entre todas las representaciones dentro de la misma presentación multimedia por todo un tiempo de duración de la representación. El elemento de sintaxis puede corresponder a todas las representaciones dentro de la misma presentación multimedia para uno o más de un período DASH, un conjunto de adaptación DASH, una representación DASH o una subrepresentación DASH.
En algunos ejemplos, la MPD 122 puede incluir los datos que representan el consumo relativo temporal parcial o las tasas de solicitud de los datos de un conjunto de adaptación entre todos los conjuntos de adaptación dentro de la misma presentación multimedia.
Los datos de encabezado 126, cuando están presentes, pueden describir las características de los segmentos 128, por ejemplo, las ubicaciones temporales de los puntos de acceso aleatorio (RAP, también denominados puntos de acceso de transmisión (SAP)), cuáles de los segmentos 128 incluye los puntos de acceso aleatorio, el desplazamiento de bits a los puntos de acceso aleatorio dentro de los segmentos 128, los localizadores uniformes de recursos (URL) de los segmentos 128 u otros aspectos de los segmentos 128. Los datos de encabezado 130, cuando están presentes, pueden describir características similares para los segmentos 132. Adicional o alternativamente, tales características pueden incluirse completamente dentro de la MPD 122.
Los segmentos 128, 132 incluyen una o más muestras de video codificadas, cada una de las cuales puede incluir tramas o segmentos de los datos de video. Cada una de las muestras de video codificadas de los segmentos 128 puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Tales características pueden describirse mediante los datos de la MPD 122, aunque tales datos no se ilustran en el ejemplo de la Figura 3. La MPD 122 puede incluir las características como se describe por la Memoria descriptiva 3GPP, con la adición de cualquier o toda la información señalada descrita en esta divulgación.
Cada uno de los segmentos 128, 132 puede asociarse con un localizador uniforme de recursos (URL) único. Por tanto, cada uno de los segmentos 128, 132 puede recuperarse independientemente mediante el uso de un protocolo de red de transmisión continua, tal como DASH. De esta manera, un dispositivo de destino, tal como el dispositivo cliente 40, puede usar una solicitud HTTP GET para recuperar los segmentos 128 o 132. En algunos ejemplos, el dispositivo cliente 40 puede usar las solicitudes HTTP GET parciales para recuperar los rangos de bytes específicos de los segmentos 128 o 132.
La Figura 4 es un diagrama de bloques que ilustra los elementos de un archivo de video 150 de ejemplo, que puede corresponder a un segmento de una representación, tal como uno de los segmentos 128, 132 de la Figura 3. Cada uno de los segmentos 128, 132 puede incluir los datos de conformidad sustancialmente con la disposición de los datos ilustrada en el ejemplo de la Figura 4. 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 archivos multimedia base ISO y sus extensiones almacenan datos en una serie de objetos, denominados como "cuadros". En el ejemplo de la Figura 4, el archivo de video 150 incluye el cuadro de tipo de archivo (FTYP) 152, el cuadro de película (MOOV) 154, el cuadro de índice de segmento (sidx) 162, los cuadros de fragmentos de película (MOOF) 164 y el cuadro de acceso aleatorio de fragmento de película (MFRA) 166. Aunque la Figura 4 representa un ejemplo de un archivo de video, debe entenderse que otros archivos multimedia pueden incluir otros tipos de datos multimedia (por ejemplo, datos de audio, datos de texto temporizados o similares) que se estructuran de manera similar a los datos del archivo de video 150, de acuerdo con el formato de archivos multimedia base ISO y sus extensiones.
El cuadro de tipo de archivo (FTYP) 152 generalmente describe un tipo de archivo para el archivo de video 150. El cuadro de tipo de archivo 152 puede incluir los datos que identifican una especificación que describe un mejor uso para el archivo de video 150. El cuadro de tipo de archivo 152 puede, en varias alternativas, colocarse inmediatamente antes del cuadro MOOV 154, los cuadros de fragmentos de película 164 o el cuadro MFRA 166. En algunos ejemplos, un Segmento, tal como el archivo de video 150, puede incluir un cuadro de actualización de MPD (no mostrado) antes del cuadro FTYP 152. El cuadro de actualización de MPD puede incluir la información que indique que una MPD que corresponde a una representación que incluye un archivo de video 150 debe actualizarse, junto con la información para actualizar la MPD. Por ejemplo, el cuadro de actualización de MPD puede proporcionar un URI o URL para un recurso que se utilizará para actualizar la MPD. Como otro ejemplo, el cuadro de actualización de MPD puede incluir los datos para actualizar la MPD. En algunos ejemplos, el cuadro de actualización de MPD puede seguir inmediatamente a un cuadro de tipo de segmento (STYP) (no mostrado) del archivo de video 150, donde el cuadro STYP puede definir un tipo de segmento para el archivo de video 150.
La caja MOOV 154, en el ejemplo de la Figura 4, incluye el cuadro de encabezado de película (MVHD) 156, el cuadro de pista (TRAK) 158 y uno o más cuadros de extensión de película (MVEX) 160. En general, el cuadro MVHD 156 puede describir las características generales del archivo de video 150. Por ejemplo, el cuadro MVHD 156 puede incluir los datos que describen cuándo se creó originalmente el archivo de video 150, cuándo se modificó por última vez el archivo de video 150, una escala de tiempo para el archivo de video 150, una duración de la reproducción del archivo de video 150 u otros datos que generalmente describen el archivo de video 150.
El cuadro TRAK 158 puede incluir los datos para una pista del archivo de video 150. El cuadro TRAK 158 puede incluir un cuadro de encabezado de pista (TKHD) que describe las características de la pista que corresponden al cuadro TRAK 158. En algunos ejemplos, el cuadro TRAK 158 puede incluir las imágenes de video codificadas, mientras que, en otros ejemplos, las imágenes de video codificadas de la pista pueden incluirse en los fragmentos de película 164, que pueden referenciarse mediante los datos del cuadro TRAK 158 y/o los cuadros sidx 162.
De acuerdo con las técnicas de esta divulgación, el cuadro TRAK 158 puede incluir la información que indique al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, la estructura de datos que incluye los datos multimedia. Por ejemplo, el cuadro TRAK 158 puede incluir una pluralidad multiplexada de pistas, la pluralidad de pistas incluye las pistas multimedia para los fragmentos de película 164 y una pista separada que tiene los elementos de sintaxis señalizados en un nivel de metadatos temporizados que especifican la información que indica la al menos una estructura de datos de la pluralidad de estructuras de datos que es probable que se recuperen. La estructura de datos puede comprender, por ejemplo, uno o más fragmentos de película 164. En algunos ejemplos, la pista separada puede formarse como una representación que no incluye ningún dato multimedia y multiplexarse con otras pistas que incluyen las representaciones respectivas que sí incluyen los datos multimedia.
En algunos ejemplos, el archivo de video 150 puede incluir más de una pista. En consecuencia, el cuadro MOOV 154 puede incluir un número de cuadros TRAK igual al número de pistas en el archivo de video 150. El cuadro TRAK 158 puede describir las características de una pista correspondiente del archivo de video 150. Por ejemplo, el cuadro TRAK 158 puede describir la información temporal y/o espacial para la pista correspondiente. Un cuadro TRAK similar al cuadro TRAK 158 del cuadro MOOV 154 puede describir características de una pista de conjunto de parámetros, cuando la unidad de encapsulación 30 (Figura 3) incluye una pista de conjunto de parámetros en un archivo de video, tal como un archivo de video 150. La unidad de encapsulación 30 puede señalar la presencia de mensajes SEI de nivel de secuencia en la pista de conjunto de parámetros dentro del cuadro TRAK que describe la pista de conjunto de parámetros.
El cuadro MVEX 160 pueden describir las características de los fragmentos de película 164 correspondientes, por ejemplo, para indicar que el archivo de video 150 incluye los fragmentos de película 164, además de los datos de video incluidos en el cuadro MOOV 154, si los hay. En el contexto de la transmisión continua de datos de video, las imágenes de video codificadas pueden incluirse en los fragmentos de película 164 en lugar de en el cuadro MOOV 154. En consecuencia, todas las muestras de video codificadas pueden incluirse en los fragmentos de película 164, en lugar de en el cuadro MOOV 154.
El cuadro MOOV 154 puede incluir un número de cuadros MVEX 160 igual al número de fragmentos de película 164 en el archivo de video 150. Cada uno de los cuadros MVEX 160 puede describir las características de uno de los fragmentos de película 164 correspondiente. Por ejemplo, cada cuadro MVEX puede incluir un cuadro de encabezado de extensión de película (MEHD) que describe una duración temporal para uno de los fragmentos de película 164 correspondiente.
Como se indicó anteriormente con respecto a la Figura 1, la unidad de encapsulación 30 puede almacenar un conjunto de datos de secuencia en una muestra de video que no incluye los datos de video codificados reales. Una muestra de video puede corresponder generalmente a una unidad de acceso, que es una representación de una imagen codificada en una instancia de tiempo específica. En el contexto de AVC, la imagen codificada incluye una o más unidades NAL VCL que contienen la información para construir todos los píxeles de la unidad de acceso y otras unidades asociadas a las unidades NAL no VCL, tal como los mensajes SEI. En consecuencia, la unidad de encapsulación 30 puede incluir un conjunto de datos de secuencia, que puede incluir los mensajes SEI de nivel de secuencia, en uno de los fragmentos de película 164. La unidad de encapsulación 30 puede señalar además la presencia de un conjunto de datos de secuencia y/o mensajes SEI de nivel de secuencia como que están presentes en uno de los fragmentos de película 164 dentro de uno de los cuadros MVEX 160 correspondiente a uno de los fragmentos de película 164.
Los cuadros SIDX 162 son elementos opcionales del archivo de video 150. Es decir, los archivos de video de conformidad con el formato de archivo 3GPP, u otros de tales formatos de archivo, no necesariamente incluyen los cuadros SIDX 162. De acuerdo con el ejemplo del formato de archivo 3GPP, puede usarse un cuadro SIDX para identificar un subsegmento de un segmento (por ejemplo, un segmento contenido dentro del archivo de video 150). El formato de archivo 3GPP define un subsegmento como "un conjunto autónomo de uno o más cuadros de fragmentos de película consecutivos con el (los) cuadro(s) de Datos Multimedia correspondiente(s) y un cuadro de Datos Multimedia que contiene los datos referenciados por un cuadro de Fragmentos de Película que debe seguir ese cuadro de Fragmento de Película y preceda al siguiente cuadro de Fragmento de Película que contiene la información sobre la misma pista". El formato de archivo 3GPP también indica que un cuadro SIDX "contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por el cuadro. Los subsegmentos referenciados son contiguos en el tiempo de presentación. De manera similar, los bytes a los que se refiere un cuadro de Índice de Segmento son siempre contiguos dentro del segmento. El tamaño referenciado da el recuento del número de bytes en el material referenciado".
Los cuadros SIDX 162 generalmente proporcionan la información representativa de uno o más subsegmentos de un segmento incluido en el archivo de video 150. Por ejemplo, tal información puede incluir los tiempos de reproducción en los que comienzan y/o terminan los subsegmentos, el desplazamiento de bytes para los subsegmentos, una indicación de si los subsegmentos incluyen (por ejemplo, inician con) un punto de acceso de transmisión (SAP), un tipo para el SAP (por ejemplo, si el SAP es una imagen de actualización instantánea del decodificador (IDR), una imagen de acceso aleatorio limpio (CRA), una imagen de acceso a enlace roto (BLA), o similar), una posición del SAP (en términos de tiempo de reproducción y/o desplazamiento de bytes) en el subsegmento y similares.
Los fragmentos de película 164 pueden incluir una o más imágenes de video codificadas. 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 codificadas, por ejemplo, tramas o imágenes. Además, como se describió anteriormente, los fragmentos de película 164 pueden incluir los conjuntos de datos de secuencia en algunos ejemplos. Cada uno de los fragmentos de película 164 puede incluir un cuadro de encabezado de fragmento de película (MFHD, no mostrado en la Figura 4). El cuadro MFHD puede describir las 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 pueden incluirse en orden de número de secuencia en el archivo de video 150.
El cuadro MFRA 166 puede describir los puntos de acceso aleatorio dentro de los fragmentos de película 164 del archivo de video 150. Esto puede ayudar con la realización de modos truco, tal como realizar las búsquedas en ubicaciones temporales particulares (es decir, tiempos de reproducción) dentro de un segmento encapsulado por el archivo de video 150. El cuadro MFRA 166 es generalmente opcional y no es necesario incluirla en los archivos de video, en algunos ejemplos. Del mismo modo, un dispositivo cliente, tal como el dispositivo cliente 40, no necesita necesariamente hacer referencia al cuadro MFRA 166 para decodificar y visualizar correctamente los datos de video del archivo de video 150. El cuadro MFRA 166 puede incluir un número de cuadros de acceso aleatorio de fragmentos de pista (TFRA) (no mostrados) igual al número de pistas del archivo de video 150, o en algunos ejemplos, igual al número de pistas multimedia (por ejemplo, pistas sin pistas) del archivo de video 150.
En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o más puntos de acceso de transmisión (SAP), tal como las imágenes IDR. Del mismo modo, el cuadro MFRA 166 puede proporcionar las indicaciones de ubicaciones dentro del archivo de video 150 de los SAP. En consecuencia, puede formarse una subsecuencia temporal del archivo de video 150 desde los SAP del archivo de video 150. La subsecuencia temporal también puede incluir otras imágenes, tal como tramas P y/o tramas B que dependen de los SAP. Las tramas y/o segmentos de la subsecuencia temporal pueden disponerse dentro de los segmentos de manera que las tramas/segmentos de la subsecuencia temporal que dependen de otras tramas/segmentos de la subsecuencia puedan decodificarse apropiadamente. Por ejemplo, en la disposición jerárquica de los datos, los datos usados para la predicción de otros datos también pueden incluirse en la subsecuencia temporal.
La Figura 5 es un diagrama de flujo que ilustra un procedimiento de ejemplo para realizar las técnicas de esta divulgación. El procedimiento de la Figura 5 se explica con respecto al dispositivo servidor 60, el MANE 76 y el dispositivo cliente 40 de la Figura 1. Sin embargo, debe entenderse que este o un procedimiento similar puede realizarse por otros dispositivos, por ejemplo, además o como alternativa al dispositivo servidor 60, el MANE 76 y el dispositivo cliente 40. Por ejemplo, las técnicas de prebúsqueda atribuidas al MANE 76 pueden realizarse en su lugar por el propio dispositivo cliente 40. Como otro ejemplo, el dispositivo de preparación de contenido 20 puede realizar las técnicas atribuidas al dispositivo servidor 60. En este ejemplo, el dispositivo cliente 40 representa uno de una pluralidad de dispositivos de usuario (por ejemplo, equipo de usuario (UE)), cada uno de los cuales puede ser operado por un usuario diferente respectivo.
Inicialmente, en este ejemplo, el dispositivo servidor 60 envía la información que indica los datos multimedia que es probable que se recuperen por una pluralidad de usuarios (200), por ejemplo, los usuarios de dispositivos cliente tales como el dispositivo cliente 40. Esta información puede indicar uno o más títulos (es decir, películas individuales, también denominadas presentaciones multimedia), los conjuntos de adaptación de una presentación multimedia, las representaciones de una presentación multimedia y/o segmentos, los grupos de segmentos o subsegmentos de una presentación multimedia. Como se discutió anteriormente, tal información puede incluirse en un archivo de manifiesto, tal como un DASH MPD, por ejemplo, a un nivel de MPD, un nivel de conjunto de adaptación, un nivel de representación, un nivel de segmento o similar. Adicional o alternativamente, esta información puede incluirse en una pista que se multiplexa con otras pistas de un archivo de video. Adicional o alternativamente, esta información puede incluirse en un mensaje PED especial, por ejemplo, que identifica particularmente una MPD al que se aplica el mensaje PED, un consumo relativo o tasa de solicitud para una presentación multimedia que corresponde a la MPD y/o los datos que indican el consumo relativo o tasa de solicitud para una o más representaciones de la presentación multimedia.
En este ejemplo, el MANE 76 recibe la información (202) y usa la información para determinar los datos multimedia que es probable que se recuperen (204). Por ejemplo, el MANE 76 puede extraer la información de una MPD, un mensaje PED especial o una pista separada de un archivo multimedia. El MANE 76 puede entonces solicitar los datos multimedia que es probable que se recuperen (206). En particular, el MANE 76 puede prebuscar los datos multimedia que es probable que se recuperen. Es decir, en este ejemplo, el MANE 76 recupera los datos multimedia que es probable que se recuperen antes de que cualquiera de la pluralidad de dispositivos cliente (por ejemplo, el dispositivo cliente 40) solicite los datos multimedia. En otras palabras, el MANE 76 recupera los datos multimedia mediante el uso de la información que indica que los datos multimedia que es probable que se recuperen, no en respuesta a las solicitudes del dispositivo cliente 40 (u otros dispositivos cliente).
El dispositivo servidor 60 recibe la solicitud para los datos multimedia (208) y, en respuesta a la solicitud, envía los datos multimedia solicitados al MANE 76 (210), en este ejemplo. El MANE 76 recibe y almacena en caché los datos multimedia (212), por ejemplo, en una memoria del MANE 76 configurada como una caché. De esta manera, el MANE 76 tiene los datos multimedia que es probable que se recuperen por los dispositivos cliente antes de que los dispositivos cliente hayan solicitado realmente los datos multimedia. En consecuencia, el MANE 76 puede atender las solicitudes de los datos multimedia de la caché del MANE 76, en lugar de recuperar los datos multimedia del dispositivo servidor 60 después de recibir una solicitud de los datos multimedia.
En particular, como se muestra en el ejemplo de la Figura 5, el dispositivo cliente 40 solicita los datos multimedia que es probable que se recuperen (214). El MANE 76 recibe la solicitud de los datos multimedia del dispositivo cliente 40 (216). Dado que el MANE 76 prebuscó los datos multimedia, el MANE 76 puede enviar los datos multimedia solicitados al dispositivo cliente 40 (218), sin recuperar los datos multimedia del dispositivo servidor 60 después de recibir la solicitud del dispositivo cliente 40. El dispositivo cliente 40 puede entonces recibir y presentar los datos multimedia (220). De esta manera, las técnicas de esta divulgación pueden reducir la latencia de responder a solicitudes de datos multimedia. Reducir la latencia de esta manera puede mejorar las experiencias de los usuarios y también reducir el procesamiento requerido por el MANE 76. En particular, al almacenar en caché los datos multimedia que es probable que se recuperen a través de la prebúsqueda de tales datos multimedia, el MANE 76 puede garantizar que estos datos estén disponibles para una pluralidad de usuarios y, por lo tanto, reducir el número de veces que el MANE 76 debe recuperar los datos multimedia del dispositivo servidor 60 con el fin de servir los datos multimedia a la pluralidad de usuarios.
De esta manera, el procedimiento de la Figura 5 representa un ejemplo de un procedimiento que incluye recibir, por un dispositivo multimedia, la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, la estructura de datos que incluye los datos multimedia y recuperar, por el dispositivo multimedia, los datos multimedia de la estructura de datos antes de recibir las solicitudes de los datos multimedia de los dispositivos de usuario.
Como se discutió anteriormente, el procedimiento de la Figura 5 se explica, para propósitos de ejemplo, con respecto a la prebúsqueda de datos multimedia del MANE 76. En otros ejemplos, el dispositivo cliente 40 puede prebuscar los datos multimedia, por ejemplo, del MANE 76 o del dispositivo servidor 60, antes de recibir una solicitud de un usuario del dispositivo cliente 40 de una manera similar.
La Figura 6 es un diagrama de flujo que ilustra un procedimiento de ejemplo para realizar las técnicas de esta divulgación. El procedimiento de la Figura 6 se explica con respecto al servidor MANE 76 de la Figura 1, para propósitos de ejemplo. Sin embargo, debe entenderse que este o un procedimiento similar puede realizarse por otros dispositivos, por ejemplo, además o como alternativa al MANE 76. Por ejemplo, el dispositivo cliente 40 de la Figura 1 puedo realizar este o un procedimiento similar. Del mismo modo, el dispositivo servidor 60 puede realizar un procedimiento conceptualmente similar, aunque recíproco, al que se muestra en la Figura 6. Es decir, el dispositivo servidor 60 puede enviar la información indicada como se recibe y se recupera por el MANE 76 en la Figura 6. Inicialmente, el MANE 76 recibe la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, la estructura de datos que incluye los datos multimedia (230). El MANE 76 recupera entonces los datos multimedia de la estructura de datos antes de recibir las solicitudes de los datos multimedia de los dispositivos de usuario (232). Es decir, el MANE 76 recupera los datos multimedia sin recibir inicialmente las solicitudes de los datos multimedia de los dispositivos cliente, es decir, no en respuesta a cualquier solicitud de los datos multimedia de los dispositivos cliente. De esta manera, el MANE 76 puede prebuscar los datos multimedia antes de que los datos multimedia se soliciten por los dispositivos cliente, de manera que los datos multimedia estén disponibles para su distribución a los dispositivos cliente en el evento de solicitudes de los datos multimedia de los dispositivos cliente. Cuando se realiza por un dispositivo cliente, tal como el dispositivo cliente 40 (Figura 1), el procedimiento de la Figura 6 generalmente incluye que el dispositivo cliente 40 recupere los datos multimedia antes de recibir cualquier solicitud de los datos multimedia de un usuario del dispositivo cliente 40 (es decir, no en respuesta a una solicitud de datos multimedia del usuario).
En uno o más ejemplos, las funciones descritas pueden implementarse en hardware, software, microprograma o cualquiera de sus combinaciones. 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 que se ejecutan mediante una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador, que corresponden a un medio tangible, tal como medios de almacenamiento de datos, o medios de comunicación, que incluyen cualquier medio que facilite transferir 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 que no son transitorios o (2) un medio de comunicación como una señal u onda portadora. Los medios de almacenamiento de datos pueden ser cualquier medio disponible al que pueda accederse mediante uno o más ordenadores o uno o más procesadores para recuperar las instrucciones, códigos y/o estructuras de datos para la implementación de las técnicas descritas en esta divulgación. Un producto de programa informático puede incluir un medio legible por ordenador.
A manera de ejemplo, y no de limitación, tales medios legibles por ordenador pueden comprender RAM, ROM, EPROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnéticos, memoria flash o cualquier otro medio que pueda usarse para almacenar el código del programa deseado en forma de instrucciones o estructuras de datos y al que puede accederse por un ordenador. También, cualquier conexión apropiadamente se califica un medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, servidor, u otra fuente remota mediante el uso de un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de suscriptor digital (DSL), o las tecnologías inalámbricas como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas tales como infrarrojos, radio y microondas se incluyen en la definición de medio. Sin embargo, debe entenderse que los medios de almacenamiento legibles por ordenador y los medios de almacenamiento de datos no incluyen conexiones, ondas portadoras, señales u otros medios transitorios, pero en cambio se dirigen a medios de almacenamiento tangibles y no transitorios. Disco, como se usa en la presente memoria, incluye el disco compacto (CD), el disco de láser, el disco óptico, el disco digital versátil (DVD), el disquete, y el disco Blu-ray donde existen los discos que usualmente reproducen los datos de manera magnética, mientras que otros discos reproducen los datos de manera óptica con láseres. Las combinaciones de los medios anteriores pueden incluirse además dentro del ámbito de los medios legibles por ordenador.
Las instrucciones pueden ejecutarse por uno o más procesadores, como uno o más procesadores de señales digitales (DSP), microprocesadores de propósito general, circuitos integrados para aplicaciones específicas (ASIC), matriz de puertas lógicas programable en campo (FPGA) u otro circuito integrado lógico o discreto equivalente. En consecuencia, el término "procesador", como se usa en la presente memoria puede referirse a cualquiera de las estructuras anteriores o cualquier otra estructura adecuada para la implementación de las técnicas descritas en la presente memoria. Además, en algunos aspectos, la funcionalidad descrita en la presente memoria puede proporcionarse dentro de módulos de hardware y/o software dedicados configurados para la codificación y decodificación, o incorporarse en un códec combinado. Asimismo, las técnicas se podrían implementar completamente en uno o más circuitos o elementos lógicos.
Las técnicas de esta divulgación pueden implementarse en una amplia variedad de dispositivos o aparatos, que incluyen un teléfono inalámbrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). En esta divulgación se describen varios componentes, módulos o unidades para enfatizar los aspectos funcionales de los dispositivos configurados para realizar las técnicas divulgadas, pero no necesariamente requieren la realización por diferentes unidades de hardware. En lugar de, como se describió anteriormente, varias unidades pueden combinarse en una unidad de hardware de códec o proporcionarse por una colección de unidades de hardware interoperativas, que incluyen uno o más procesadores como se describió anteriormente, junto con software y/o microprograma adecuados.
Se han descrito varios ejemplos. El ámbito de la invención se define mediante las reivindicaciones adjuntas.

Claims (9)

REIVINDICACIONES
1. Un procedimiento para recuperar los datos multimedia, comprendiendo el procedimiento:
recibir (202), mediante un dispositivo multimedia de un dispositivo servidor en un mensaje DASH Asistido por Servidor y Red (SAND) de Entrega de Mejora de Parámetros, PED, que se separa de un archivo de manifiesto de los datos multimedia, la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos de un contenido multimedia común que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, cada una de las estructuras de datos que incluye los datos multimedia, comprendiendo la al menos una estructura de datos una primera estructura de datos y la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que una segunda estructura de datos diferente de la pluralidad de estructuras de datos; y en respuesta a la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que la segunda estructura de datos,
extraer (204), mediante el dispositivo multimedia de la información recibida del dispositivo servidor, la información que indica que una primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario; y
recuperar (206), mediante del dispositivo multimedia del dispositivo servidor, los datos multimedia de la primera estructura de datos antes de recibir las solicitudes de los datos multimedia de la primera estructura de datos de los dispositivos de usuario.
2. El procedimiento de la reivindicación 1, en el que el dispositivo multimedia comprende un elemento de red con reconocimiento multimedia, MANE, en comunicación con el dispositivo servidor y la pluralidad de dispositivos de usuario o un elemento de red con reconocimiento DASH, DANE, de la Transmisión Continua Dinámica Adaptativa sobre HTTP.
3. El procedimiento de la reivindicación 1, en el que la primera estructura de datos comprende una de una representación de Transmisión Continua Dinámica Adaptativa sobre HTTP, DASH, un conjunto de adaptación DASH o un conjunto de presentaciones multimedia que incluyen una pluralidad de representaciones DASH relacionadas y que corresponden a un título de película particular.
4. El procedimiento de la reivindicación 1, en el que recibir la información comprende recibir la información en un archivo de manifiesto para los datos multimedia, en el que el archivo de manifiesto comprende una Descripción de Presentación Multimedia, MPD, de Transmisión Continua Dinámica Adaptativa sobre HTTP, DASH.
5. El procedimiento de la reivindicación 1, en el que el dispositivo multimedia comprende un elemento de red con reconocimiento multimedia, MANE, o un elemento de red con reconocimiento DASH, DANE, comprendiendo además el procedimiento, extraer la información del mensaje PED y actualizar el consumo relativo o las tasas de solicitud mediante el uso de la información extraída.
6. El procedimiento de la reivindicación 1, en el que el mensaje PED incluye un valor para un elemento @mpdId que identifica una descripción de presentación multimedia, MPD, a la que se aplica el mensaje PED, un valor para el elemento @contentRequestRate que indica un consumo relativo o la tasa de solicitud de los datos multimedia que corresponden a la MPD y una matriz de elementos de sintaxis {@repld, RepRequestRate} que indican el consumo relativo o las tasas de solicitud para las respectivas representaciones.
7. El procedimiento de la reivindicación 1, en el que el mensaje PED incluye un DASH MPD para los datos multimedia.
8. Un dispositivo multimedia para recuperar los datos multimedia, comprendiendo el dispositivo multimedia: medios para recibir, de un dispositivo servidor en un mensaje DASH Asistido por Servidor y Red (SAND) de Entrega de Mejora de Parámetros, PED, que se separa de un archivo de manifiesto de los datos multimedia, la información que indica al menos una estructura de datos de una pluralidad de estructuras de datos de un contenido multimedia común que es probable que se recupere por una pluralidad de dispositivos de usuario operados por una pluralidad respectiva de usuarios, cada una de las estructuras de datos que incluye los datos multimedia, comprendiendo la al menos una estructura de datos una primera estructura de datos y la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que una segunda estructura de datos diferente de la pluralidad de estructuras de datos; y
medios para extraer (204), de la información recibida del dispositivo servidor, la información que indica que una primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario; y medios para recuperar, del dispositivo servidor, los datos multimedia de la primera estructura de datos antes de recibir las solicitudes de los datos multimedia de la primera estructura de datos de los dispositivos de usuario en respuesta a la información que indica que la primera estructura de datos es más probable que se recupere por la pluralidad de dispositivos de usuario que la segunda estructura de datos.
9. Un medio de almacenamiento legible por ordenador que tiene almacenadas en el mismo las instrucciones que, cuando se ejecutan, hacen que un procesador de un dispositivo multimedia lleve a cabo el procedimiento de cualquiera de las reivindicaciones 1 a 7.
ES18701857T 2017-01-10 2018-01-05 Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua Active ES2892329T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762444730P 2017-01-10 2017-01-10
US15/862,251 US11290755B2 (en) 2017-01-10 2018-01-04 Signaling data for prefetching support for streaming media data
PCT/US2018/012600 WO2018132319A1 (en) 2017-01-10 2018-01-05 Signaling data for prefetching support for streaming media data

Publications (1)

Publication Number Publication Date
ES2892329T3 true ES2892329T3 (es) 2022-02-03

Family

ID=62783504

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18701857T Active ES2892329T3 (es) 2017-01-10 2018-01-05 Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua

Country Status (9)

Country Link
US (1) US11290755B2 (es)
EP (1) EP3568991B1 (es)
KR (1) KR102580982B1 (es)
CN (1) CN110089122B (es)
AU (1) AU2018207060A1 (es)
BR (1) BR112019014070A2 (es)
ES (1) ES2892329T3 (es)
TW (1) TW201830974A (es)
WO (1) WO2018132319A1 (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016204815A1 (en) * 2015-06-16 2016-12-22 Intel IP Corporation Adaptive video streaming using dynamic radio access network information
WO2018131813A1 (en) * 2017-01-10 2018-07-19 Samsung Electronics Co., Ltd. Method and apparatus for generating metadata for 3d images
US20190373245A1 (en) * 2017-03-29 2019-12-05 Lg Electronics Inc. 360 video transmission method, 360 video reception method, 360 video transmission device, and 360 video reception device
US10924822B2 (en) 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
WO2019148498A1 (en) * 2018-02-05 2019-08-08 Telefonaktiebolaget Lm Ericsson (Publ) A method, a user equipment and a computer program product for enabling a dynamic adaptive streaming over http, dash, player to fetch media segments from a network
US11050843B2 (en) * 2018-03-30 2021-06-29 Facebook, Inc. Systems and methods for prefetching content
JP7028811B2 (ja) * 2019-01-29 2022-03-02 Kddi株式会社 コンテンツ配信ネットワークの転送装置
GB2582014A (en) * 2019-03-08 2020-09-09 Canon Kk Method, device, and computer program for optimizing transmission of portions of encapsulated media content
EP4202734B1 (en) * 2019-03-26 2026-02-11 Google LLC Separating the authorization of content access and content delivery using multiple cryptographic digital signatures
US10979477B1 (en) * 2019-03-26 2021-04-13 Amazon Technologies, Inc. Time synchronization between live video streaming and live metadata
US12284416B2 (en) * 2020-02-04 2025-04-22 Dolby International Ab Method and device for adaptive playout of media content
US11546406B2 (en) * 2020-04-13 2023-01-03 Tencent America LLC Media systems and methods including mixed event message tracks
US11394932B2 (en) 2020-06-03 2022-07-19 Honeywell International Inc. System and method for auto selecting a video for display on a mobile device based on the proximity of the mobile device relative to the video source
US11750815B2 (en) 2020-09-17 2023-09-05 Lemon, Inc. Versatile video coding track coding
US11611752B2 (en) 2020-10-07 2023-03-21 Lemon Inc. Adaptation parameter set storage in video coding
US12346291B2 (en) * 2021-11-03 2025-07-01 Vimeo.Com, Inc. On-the-fly/transparent fragmented ISOBMFF to progressive ISOBMFF transmultiplexing proxy
US12567274B2 (en) * 2021-11-29 2026-03-03 RedShred LLC Geographic management of document content
US12132954B2 (en) * 2022-04-14 2024-10-29 Tencent America LLC Smart client for streaming of scene-based immersive media
US11910032B1 (en) 2022-08-02 2024-02-20 Rovi Guides, Inc. Systems and methods for distributed media streaming
CN116582691A (zh) * 2023-05-18 2023-08-11 北京字跳网络技术有限公司 视频数据加载方法、装置、存储介质及电子设备
US12477026B2 (en) * 2023-10-30 2025-11-18 Microsoft Technology Licensing, Llc Media server proxy that switches streaming media protocols
US20250335310A1 (en) * 2024-04-25 2025-10-30 Dell Products L.P. Synthesizing full content using file extents without namespace impact

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090761B2 (en) 2002-07-12 2012-01-03 Hewlett-Packard Development Company, L.P. Storage and distribution of segmented media data
DE102005001286A1 (de) * 2005-01-11 2006-07-20 Siemens Ag Verfahren und Vorrichtung zur Übertragung von skalierbaren Daten
US20090183215A1 (en) * 2008-01-16 2009-07-16 Qualcomm Incorporated Hybrid services: data, audio, and clipcast
CN101242430B (zh) 2008-02-22 2012-03-28 华中科技大学 对等网络点播系统中的定点数据预取方法
US8347340B2 (en) 2008-09-11 2013-01-01 Livetv, Llc Aircraft communications system with video file library and associated methods
WO2011139305A1 (en) * 2010-05-04 2011-11-10 Azuki Systems, Inc. Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction
CN101951395B (zh) 2010-08-30 2013-08-21 中国科学院声学研究所 一种基于访问预测的P2P VoD系统服务端的数据缓存策略
US9282354B2 (en) * 2011-10-28 2016-03-08 Qualcomm Incorporated Method and apparatus to detect a demand for and to establish demand-based multimedia broadcast multicast service
US8903955B2 (en) * 2011-12-02 2014-12-02 Cisco Technology, Inc. Systems and methods for intelligent video delivery and cache management
US9804668B2 (en) * 2012-07-18 2017-10-31 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear TV experience using streaming content distribution
US20140089467A1 (en) * 2012-09-27 2014-03-27 Andre Beck Content stream delivery using pre-loaded segments
US9491457B2 (en) 2012-09-28 2016-11-08 Qualcomm Incorporated Signaling of regions of interest and gradual decoding refresh in video coding
US20140223502A1 (en) * 2013-02-06 2014-08-07 General Instrument Corporation Method of Operating an IP Client
JP6411069B2 (ja) * 2013-05-24 2018-10-24 イマージョン コーポレーションＩｍｍｅｒｓｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎ 触覚データを符号化及びストリーミングする方法及びシステム
US20140365613A1 (en) * 2013-06-06 2014-12-11 Ericsson Television Inc. Defragmentation of adaptive streaming segment files in a content delivery network
EP3017605B1 (en) * 2013-07-03 2022-12-07 Koninklijke KPN N.V. Streaming of segmented content
EP2833640A1 (en) * 2013-08-02 2015-02-04 British Telecommunications public limited company Video caching
US9444856B2 (en) * 2013-09-25 2016-09-13 Ericsson Ab System and method for managing adjacent channels in an adaptive streaming environment
US10841353B2 (en) * 2013-11-01 2020-11-17 Ericsson Ab System and method for optimizing defragmentation of content in a content delivery network
EP3162074A1 (en) 2014-06-27 2017-05-03 Koninklijke KPN N.V. Determining a region of interest on the basis of a hevc-tiled video stream
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
CN104486350B (zh) 2014-12-24 2017-11-10 电子科技大学 一种基于用户行为的网络内容加速方法
KR102379530B1 (ko) 2015-01-07 2022-03-29 삼성전자주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
WO2016117904A1 (ko) * 2015-01-21 2016-07-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN110336843B (zh) 2015-02-24 2021-11-09 庄奇东 一种用于众包的内容分发方法、中心节点及边缘节点
US10375452B2 (en) * 2015-04-14 2019-08-06 Time Warner Cable Enterprises Llc Apparatus and methods for thumbnail generation
WO2016204815A1 (en) 2015-06-16 2016-12-22 Intel IP Corporation Adaptive video streaming using dynamic radio access network information
US10193994B2 (en) 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast
US10096130B2 (en) * 2015-09-22 2018-10-09 Facebook, Inc. Systems and methods for content streaming
US10225546B2 (en) 2016-02-26 2019-03-05 Qualcomm Incorporated Independent multi-resolution coding
US11184624B2 (en) 2016-05-19 2021-11-23 Qualcomm Incorporated Regional random access in pictures
US10582201B2 (en) 2016-05-19 2020-03-03 Qualcomm Incorporated Most-interested region in an image
US10565463B2 (en) 2016-05-24 2020-02-18 Qualcomm Incorporated Advanced signaling of a most-interested region in an image
US10034033B2 (en) * 2016-07-28 2018-07-24 Cisco Technology, Inc. Predictive media distribution system
CN110463208A (zh) * 2017-03-24 2019-11-15 索尼公司 内容处理装置、内容处理方法以及程序
US10062414B1 (en) * 2017-08-22 2018-08-28 Futurewei Technologies, Inc. Determining a future field of view (FOV) for a particular user viewing a 360 degree video stream in a network

Also Published As

Publication number Publication date
KR20190104147A (ko) 2019-09-06
KR102580982B1 (ko) 2023-09-20
AU2018207060A1 (en) 2019-06-13
CN110089122A (zh) 2019-08-02
US20180199075A1 (en) 2018-07-12
US11290755B2 (en) 2022-03-29
EP3568991A1 (en) 2019-11-20
TW201830974A (zh) 2018-08-16
EP3568991B1 (en) 2021-09-01
CN110089122B (zh) 2021-12-10
BR112019014070A2 (pt) 2020-02-04
WO2018132319A1 (en) 2018-07-19

Similar Documents

Publication Publication Date Title
ES2892329T3 (es) Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua
ES2896687T3 (es) Región más interesada en una imagen
ES3061930T3 (en) Virtual reality video signaling in dynamic adaptive streaming over http
KR102614207B1 (ko) Mime 타입 파라미터들을 이용하는 네트워크 비디오 스트리밍에서의 중요 비디오 정보 시그널링
ES3037305T3 (en) Segment types as delimiters and addressable resource identifiers
KR102342274B1 (ko) 이미지에서 가장 관심있는 영역의 진보된 시그널링
US10567734B2 (en) Processing omnidirectional media with dynamic region-wise packing
ES2818622T3 (es) Entradas de muestra y acceso aleatorio
BR112020000110A2 (pt) sinalização de alto nível aprimorada para vídeo de realidade virtual de fisheye em dash
EP3652952A1 (en) Processing media data using a generic descriptor for file format boxes
KR20190039724A (ko) 미디어 데이터 스트리밍을 위한 sei 트랙들의 시스템 레벨 시그널링
ES2821382T3 (es) Entradas de muestra y acceso aleatorio
US10587904B2 (en) Processing media data using an omnidirectional media format
HK40005258A (en) Signaling data for prefetching support for streaming media data
HK40009749B (en) Signaling important video information in network video streaming using mime type parameters
HK40009749A (en) Signaling important video information in network video streaming using mime type parameters