ES2767288T3 - Transmisión en continuo de vídeo de baja latencia - Google Patents

Transmisión en continuo de vídeo de baja latencia Download PDF

Info

Publication number
ES2767288T3
ES2767288T3 ES16712103T ES16712103T ES2767288T3 ES 2767288 T3 ES2767288 T3 ES 2767288T3 ES 16712103 T ES16712103 T ES 16712103T ES 16712103 T ES16712103 T ES 16712103T ES 2767288 T3 ES2767288 T3 ES 2767288T3
Authority
ES
Spain
Prior art keywords
media
media segment
segment
format
segments
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
ES16712103T
Other languages
English (en)
Inventor
Thomas Stockhammer
Ye-Kui Wang
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 ES2767288T3 publication Critical patent/ES2767288T3/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/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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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
    • 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]
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • 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
    • 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/234327—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 by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • 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/44016—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 splicing one content stream with another content stream, e.g. for substituting a video clip

Landscapes

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

Abstract

Un procedimiento de recuperación de datos de medios, comprendiendo el procedimiento: recibir (328), desde un dispositivo servidor (60), un archivo de manifiesto (66) que comprende información que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación (68A a N) de un contenido de medios (64) se ajusta, en el que la pluralidad de tipos de segmentos de medios incluye: un formato de segmento de medios de unidad de entrega (202), en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene uno o más fragmentos de película autónomos completos; un formato de segmento de medios de acceso aleatorio (204), en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) se ajusta al formato de segmento de medios de unidad de entrega (202), y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1, 2 o 3; un formato de segmento de medios sin superposición (206), en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición (206) se ajusta al formato de segmento de medios de unidad de entrega (202) y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación (68A a N) y otros segmentos de otras representaciones (68A a N) de un conjunto de adaptación que incluye la representación (68A a N); y un formato de segmento de medios de conmutación (208), en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación (208) se ajusta al formato de segmento de medios de acceso aleatorio (204), y en el que la primera muestra del primer fragmento de película es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios basado en ISO de tipo 1 30 o 2; determinar (330), a partir de dicha información, a qué tipo de la pluralidad de tipos de segmentos de medios incluidos en la representación (68A a B) del contenido de medios (64) se ajustan; y usar dicho tipo determinado para recuperar (334, 340) segmentos de medios de dicho flujo de contenido de medios (64) desde el dispositivo servidor (60).

Description

DESCRIPCIÓN
Transmisión en continuo de vídeo de baja latencia
CAMPO TÉCNICO
[0001] Esta divulgación se refiere al almacenamiento y transporte de datos de vídeo codificados.
ANTECEDENTES
[0002] Las capacidades de vídeo digital se pueden incorporar a una amplia gama de dispositivos, que incluye televisores digitales, sistemas de radiodifusión directa digital, sistemas de radiodifusión inalámbrica, asistentes digitales personales (PDA), ordenadores portátiles o de sobremesa, cámaras digitales, dispositivos de grabación digitales, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, teléfonos móviles o de radio por satélite, dispositivos de videoconferencia y similares. Los dispositivos de vídeo digital implementan técnicas de compresión de vídeo, tales como las descritas en los estándares definidos por MPEG-2, m PeG-4, ITU-T H.263, ITU-T H.264/MPEG-4, parte 10, Codificación avanzada de vídeo (Av C), ITU-T H.265/Codificación de vídeo de alta eficacia (HEVC), y ampliaciones de dichos estándares, para transmitir y recibir información de vídeo digital más eficazmente.
[0003] Las técnicas de compresión de vídeo realizan predicción espacial y/o predicción temporal para reducir o eliminar la redundancia inherente a las secuencias de vídeo. Para la codificación de vídeo basada en bloques, una trama o un sector de vídeo se pueden dividir en macrobloques. Cada macrobloque se puede dividir aún más. Los macrobloques de una trama o un sector intracodificados (I) se codifican usando predicción espacial con respecto a unos macrobloques vecinos. Los macrobloques de una trama o un sector intercodificados (P o B) pueden usar predicción espacial con respecto a unos macrobloques vecinos de la misma trama o sector, o predicción temporal con respecto a otras tramas de referencia.
[0004] Después de que se hayan codificado los datos de vídeo, los datos de vídeo se pueden agrupar en paquetes para su transmisión o almacenamiento. Los datos de vídeo se pueden ensamblar en un archivo de vídeo que se ajusta a cualquiera de una variedad de estándares, tales como el formato de archivo de medios de base de la Organización Internacional de Normalización (ISO) y ampliaciones del mismo, tales como la AVC.
[0005] El texto de ISO/IEC 23001-6: Dynamic adaptive streaming over HTTP (DASH) especifica formatos para la transmisión en continuo adaptativa de medios MPEG a través de HTTP. La Sección B.3, “Segment List Generation”, describe cómo un cliente puede generar una lista de segmentos a partir de una MPD.
[0006] El documento ISO/IEC JTC1/SC29/WG11 “Response for EE#5: Indexing Information and its Carriage for MPEG-2 TS” de Zhije Zhao et al. proporciona una descripción de propuestas para el formato de entrega de un flujo de transporte MPEG-2 para DASH. La propuesta incluye indexación de RAP y un mecanismo de transporte.
SUMARIO
[0007] El alcance de la protección está definido por las reivindicaciones independientes, a las que se deberá hacer referencia a continuación. Las características opcionales están incluidas en las reivindicaciones dependientes.
[0008] En general, esta divulgación describe técnicas que se pueden usar para lograr la una transmisión en continuo de vídeo (y/u otros datos de medios) de baja latencia. Por ejemplo, el contenido de medios puede incluir una variedad de representaciones que actúan entre sí como alternativas. De acuerdo con las técnicas de esta divulgación, una representación puede incluir puntos de acceso de flujo (SAP) relativamente frecuentes, mientras que otra representación alternativa puede incluir SAP relativamente infrecuentes. Un archivo de manifiesto (tal como una descripción de presentación de medios (MPD) de transmisión en continuo dinámica adaptativa a través de HTTP (DASH) puede señalizar tipos de segmentos (o formatos a los que se ajustan los segmentos), así como las ubicaciones de dichos segmentos (o frecuencias relativas a las que dichos segmentos aparecen en una representación correspondiente). Un dispositivo cliente puede usar el archivo de manifiesto para determinar una de las representaciones que tienen SAP relativamente frecuentes, y a continuación recuperar segmentos o partes de segmentos de esa representación hasta que un SAP está disponible en una representación objetivo diferente. La representación objetivo puede tener una calidad relativamente mayor debido a que tiene menos SAP (es decir, SAP menos frecuentes). En algunos ejemplos, las diferentes representaciones pueden estar disponibles por medio de diferentes mecanismos de recuperación, tales como unidifusión o radiodifusión. Por ejemplo, la representación inicial puede estar disponible por medio de unidifusión, mientras que la representación objetivo puede estar disponible por medio de radiodifusión.
[0009] De acuerdo con un aspecto de la invención reivindicada, un procedimiento de recuperación de datos de medios incluye recibir, desde un dispositivo servidor, un archivo de manifiesto que comprende información que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación de un contenido de medios se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye: un formato de segmento de medios de unidad de entrega, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega contiene uno o más fragmentos de película autónomos completos; un formato de segmento de medios de acceso aleatorio, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio se ajusta al formato de segmento de medios de unidad de entrega, y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1, 2 o 3; un formato de segmento de medios sin superposición, en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición se ajusta al formato de segmento de medios de unidad de entrega y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación y otros segmentos de otras representaciones de un conjunto de adaptación que incluye la representación; y un formato de segmento de medios de conmutación, en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación se ajusta al formato de segmento de medios de acceso aleatorio, y en el que la primera muestra del primer fragmento de película es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2 que determina, a partir de dicha información, a qué tipo de la pluralidad de tipos de segmentos de medios incluidos en la representación del contenido de medios se ajustan; y usar dicho tipo determinado para recuperar segmentos de medios de dicho flujo continuo de contenido de medios desde el dispositivo servidor.
[0010] De acuerdo con otro aspecto de la invención reivindicada, un dispositivo cliente para recuperar datos de medios incluye medios para recibir, desde un dispositivo servidor, un archivo de manifiesto que comprende información que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación de un contenido de medios se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye: un formato de segmento de medios de unidad de entrega, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega contiene uno o más fragmentos de película autónomos completos; un formato de segmento de medios de acceso aleatorio, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio se ajusta al formato de segmento de medios de unidad de entrega, y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1, 2 o 3; un formato de segmento de medios sin superposición, en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición se ajusta al formato de segmento de medios de unidad de entrega y no se superpone unos tiempos de inicio y fin de otros segmentos de la representación y otros segmentos de otras representaciones en un conjunto de adaptación que incluye la representación; y un formato de segmento de medios de conmutación, en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación se ajusta al formato de segmento de medios de acceso aleatorio, y en el que la primera muestra del primer fragmento de película es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2; medios para determinar, a partir de dicha información, a qué tipo de la pluralidad de tipos de segmentos de medios incluidos en la representación de contenido de medios se ajustan; y medios para usar dicho tipo determinado para recuperar segmentos de medios de dicho flujo de contenido de medios desde el dispositivo servidor.
[0011] En otro ejemplo, un medio de almacenamiento legible por ordenador tiene instrucciones almacenadas en el mismo que, cuando se ejecutan, hacen que un procesador realice el procedimiento de recuperación de datos de medios.
[0012] De acuerdo con otro aspecto de la invención reivindicada, un procedimiento de señalización de información de medios para la recuperación de segmentos de medios de un contenido de medios incluye construir un archivo de manifiesto que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación del contenido de medios se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye: un formato de segmento de medios de unidad de entrega, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega contiene uno o más fragmentos de película autónomos completos; un formato de segmento de medios de acceso aleatorio, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio se ajusta al formato de segmento de medios de unidad de entrega, y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1, 2 o 3; un formato de segmento de medios sin superposición, en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición se ajusta al formato de segmento de medios de unidad de entrega y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación y otros segmentos de otras representaciones en un conjunto de adaptación que incluye la representación; y un formato de segmento de medios de conmutación, en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación se ajusta al formato de segmento de medios de acceso aleatorio, y en el que la primera muestra del primer fragmento de película es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2; enviar el archivo de manifiesto a un dispositivo cliente; y como respuesta a una petición del dispositivo cliente para un segmento de medios que se ajusta a uno de la pluralidad de tipos de segmento de medios, enviar un segmento de medios que se ajusta al tipo de segmento de medios al dispositivo cliente.
[0013] De acuerdo con otro aspecto de la invención reivindicada, un dispositivo servidor para señalizar información de medios para la recuperación de segmentos de medios de un contenido de medios incluye medios para construir un archivo de manifiesto que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación de los medios el contenido se ajustan, en el que la pluralidad de tipos de segmento de medios incluye: un formato de segmento de medios de unidad de entrega, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega contiene uno o más fragmentos de película autónomos completos; un formato de segmento de medios de acceso aleatorio, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio se ajusta al formato de segmento de medios de unidad de entrega, y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1,2 o 3; un formato de segmento de medios sin superposición, en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición se ajusta al formato de segmento de medios de unidad de entrega y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación y otros segmentos de otras representaciones en un conjunto de adaptación que incluye la representación; y un formato de segmento de medios de conmutación, en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación se ajusta al formato de segmento de medios de acceso aleatorio, y en el que la primera muestra del primer fragmento de película es un ISAU de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2; medios para enviar el archivo de manifiesto a un dispositivo cliente; y medios para enviar, como respuesta a una petición del dispositivo cliente para un segmento de medios que se ajusta a uno de la pluralidad de tipos de segmentos de medios, un segmento de medios que se ajusta al tipo de segmento de medios al dispositivo cliente.
[0014] En otro ejemplo, un medio de almacenamiento legible por ordenador que tiene almacenadas en el mismo instrucciones que, cuando se ejecutan, hacen que un procesador realice el procedimiento de señalización de información de medios para la recuperación de segmentos de medios de un contenido de medios.
[0015] Los detalles de uno o más ejemplos se exponen en los dibujos adjuntos y en la siguiente descripción. Otras características, objetos y ventajas resultarán evidentes a partir de la descripción y de los dibujos, y a partir de las reivindicaciones.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0016]
La FIG. 1 es un diagrama conceptual que ilustra un ejemplo de caso de uso para la unión rápida a un flujo.
La FIG. 2 es un diagrama de Venn que ilustra las relaciones entre diversos tipos de segmentos de medios.
La FIG. 3 es un diagrama conceptual que ilustra un ejemplo de estructura de una representación y un archivo de formato de archivo de medios de base (BMFF) ISO.
La FIG. 4 es un diagrama de bloques que ilustra un ejemplo de sistema que implementa técnicas para transmitir en continuo datos de medios a través de una red.
La FIG. 5A es un diagrama conceptual que ilustra elementos de un ejemplo de contenido multimedia.
La FIG. 5B es un diagrama conceptual que ilustra un ejemplo de contenido de una descripción de presentación de medios de acuerdo con las técnicas de esta divulgación.
La FIG. 6 es un diagrama de bloques que ilustra elementos de un ejemplo de archivo de vídeo, que puede corresponder a un segmento de una representación, tal como uno de los segmentos de la FIG. 5A.
La FIG. 7 es un diagrama conceptual que ilustra un ejemplo de oferta de segmento para un caso de uso de acuerdo con las técnicas de esta divulgación.
La FIG. 8 es un diagrama conceptual que ilustra un caso de uso que incluye una sintonización rápida con la HEVC escalable (SHVC) de acuerdo con las técnicas de esta divulgación.
La FIG. 9 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye una sintonización rápida con un punto de acceso de flujo (SAP) de tipo 3 de acuerdo con las técnicas de esta divulgación.
La FIG. 10 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye una sintonización rápida e hibridación.
La FIG. 11 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye sintonización rápida, hibridación y GOP abiertos.
La FIG. 12 es un diagrama conceptual que ilustra otro ejemplo de caso de uso que incluye sintonización rápida e hibridación con GOP abiertos.
La FIG. 13 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye sintonización rápida y latencia muy baja.
La FIG. 14 es un diagrama conceptual que ilustra otro ejemplo de caso de uso que incluye sintonización rápida y latencia muy baja.
La FIG. 15 es un diagrama de flujo que ilustra un ejemplo de procedimiento para recuperar un segmento de una representación de contenido de medios de acuerdo con las técnicas de esta divulgación.
DESCRIPCIÓN DETALLADA
[0017] En general, esta divulgación describe técnicas para transmisión en continuo de vídeo de baja latencia basada en, por ejemplo, contenido de medios formateado de acuerdo con el formato de archivo de medios de base ISO (ISOBMFF) y la transmisión en continuo dinámica adaptativa a través de HTTP (DASH). La técnica DASH se describe en, por ejemplo, el documento 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (edición 12) V12.2.0, diciembre de 2013. Esta divulgación describe diversos procedimientos para la definición y señalización de datos que se pueden ajustar a un nuevo perfil DASH (por ejemplo, perfil avanzado en directo) y algunos tipos nuevos de segmentos de medios que pueden permitir la transmisión en continuo de vídeo de baja latencia, que incluye tiempos de adquisición de canal y de cambio de canal reducidos en radiodifusión y multidifusión, mientras que potencialmente permite estructuras de codificación de vídeo de alta eficacia al mismo tiempo.
[0018] Los estándares de codificación de vídeo incluyen ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 o ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual, ITU-T H.264 o ISO/IEC MPEG-4 AVC, incluyendo sus ampliaciones de codificación de vídeo escalable (SVC) y codificación de vídeo multivista (MVC), y codificación de vídeo de alta eficacia (HEVC), también conocida como ITU-T H.265 e ISO/IEC 23008-2, incluyendo su ampliación de codificación escalable (es decir, codificación de vídeo escalable de alta eficacia, SHVC) y su ampliación multivista (es decir, codificación de vídeo multivista de alta eficacia, MV-HEVC).
[0019] El acceso aleatorio se refiere a una descodificación de un flujo de bits de vídeo comenzando a partir de una imagen codificada que no es la primera imagen codificada del flujo de bits. Se puede usar acceso aleatorio a un flujo de bits en muchas aplicaciones de vídeo, tales como radiodifusión y transmisión en continuo, por ejemplo, para que los usuarios se sintonicen con un programa en cualquier momento, para cambiar entre diferentes canales, para saltar a partes específicas del vídeo o para cambiar a un flujo de bits diferente para la adaptación de flujo (de la tasa de bits, tasa de tramas, resolución espacial y similares). Esta característica se habilita insertando imágenes de acceso aleatorio o puntos de acceso aleatorios, muchas veces a intervalos regulares, en el flujo de bits de vídeo.
[0020] El empalme de flujos de bits se refiere a la concatenación de dos o más flujos de bits o partes de los mismos. Por ejemplo, un segundo flujo de bits se puede anexar a un primer flujo de bits, posiblemente con algunas modificaciones a uno cualquiera o a ambos flujos de bits para generar un flujo de bits empalmado. La primera imagen codificada del segundo flujo de bits también se denomina punto de empalme. Por lo tanto, las imágenes que siguen al punto de empalme en el flujo de bits empalmado se originan a partir del segundo flujo de bits, mientras que las imágenes que preceden al punto de empalme en el flujo de bits empalmado se originan a partir del primer flujo de bits.
[0021] El empalme de flujos de bits se puede realizar mediante empalmadores de flujos de bits. Los empalmadores de flujos de bits suelen ser ligeros y mucho menos inteligentes que los codificadores. Por ejemplo, los empalmadores de flujos de bits pueden no estar equipados con capacidades de descodificación y codificación de entropía.
[0022] La conmutación de flujos de bits se puede usar en entornos de transmisión en continuo adaptativa. Una operación de conmutación de flujos de bits, realizada en una imagen determinada en el flujo de bits al que se ha conmutado es en realidad una operación de empalme de flujos de bits en la que el punto de empalme es el punto de conmutación de flujos de bits, es decir, la primera imagen del flujo de bits al que se ha conmutado. Las representaciones separadas también se pueden denominar (o proporcionar) como los flujos de bits respectivos.
[0023] Las imágenes de actualización de descodificación instantánea (IDR), como se especifica en ITU-T H.264/AVC (codificación de vídeo avanzada) o codificación de vídeo de alta eficacia (HEVC), se pueden usar para acceso aleatorio. Sin embargo, dado que las imágenes que siguen a una imagen IDR en orden de descodificación no pueden usar imágenes descodificadas anteriores la imagen IDR como referencia (por ejemplo, para predicción interimagen), los flujos de bits que dependen de imágenes IDR para acceso aleatorio pueden tener una eficacia de codificación significativamente menor.
[0024] Para mejorar la eficacia de codificación, se introdujo el concepto de imágenes de acceso aleatorio limpio (CRA) en la HEVC para permitir que las imágenes que siguen a una imagen CRA en orden de descodificación, pero que la preceden en orden de salida, usen imágenes descodificadas antes de la imagen CRA como referencia. Las imágenes que siguen a una imagen CRA en orden de descodificación, pero preceden a la imagen CRA en orden de salida, se denominan imágenes principales asociadas con la imagen CRA (o imágenes principales de la imagen CRA). Las imágenes principales de una imagen CRA se pueden descodificar correctamente si la descodificación comienza a partir de una imagen IDR o CRA anterior a la imagen CRA actual. Sin embargo, las imágenes principales de una imagen CRA pueden no ser descodificables cuando se produce un acceso aleatorio a partir de la imagen CRA. En consecuencia, las imágenes principales se descartan típicamente durante la descodificación de acceso aleatorio. Para evitar la propagación de errores por imágenes de referencia que pueden no estar disponibles dependiendo de dónde comienza la descodificación, todas las imágenes que siguen a una imagen CRA tanto en orden de descodificación como en orden de salida no deben usar ninguna imagen que precede a la imagen CRA en orden de descodificación u orden de salida (que incluye las imágenes principales) como referencia.
[0025] El concepto de imagen de acceso de enlace roto (BLA) se introdujo además en la HEVC después de la introducción de las imágenes CRA, y está basado en el concepto de imágenes CRA. Una imagen BLA se origina típicamente a partir de un empalme de flujos de bits en la posición de una imagen CRA y, en el flujo de bits empalmado, la imagen CRA de punto de empalme se cambia por una imagen BLA.
[0026] Las imágenes IDR, las imágenes CRA y las imágenes BLA se denominan conjuntamente imágenes de punto de acceso aleatorio (RAP). Las imágenes IDR corresponden a los denominados RAP basados en un grupo de imágenes (GOP) cerrado, mientras que las imágenes CRA y BLA corresponden a los convencionalmente denominados RAP basados en un grupo de imágenes (GOP) abierto.
[0027] Una diferencia entre las imágenes BLA y las imágenes CRA es la siguiente. Para una imagen CRA, las imágenes principales asociadas son correctamente descodificables si la descodificación comienza a partir de una imagen RAP anterior a la imagen CRA en orden de descodificación, y pueden no ser correctamente descodificables cuando se produce un acceso aleatorio a partir de la imagen CRA (es decir, cuando la descodificación comienza a partir de la imagen CRA, o en otras palabras, cuando la imagen CRA sea la primera imagen en el flujo de bits). Para una imagen BLA, las imágenes principales asociadas pueden ser no descodificables en todos los casos, incluso cuando la descodificación comienza a partir de una imagen RAP anterior a la imagen BLA en orden de descodificación.
[0028] Los estándares de formato de archivo incluyen el formato de archivo de medios de base ISO (ISOBMFF, ISO/iEc 14496-12) y otros derivados de ISOBMFF, incluyendo el formato de archivo MPEG-4 (ISO/IEC 14496-14), el formato de archivo 3GPP (3GPP TS 26.244) y el formato de archivo AVC (ISO/IEC 14496-15).
[0029] El ISOBMFF se usa como la base para muchos formatos de encapsulación de códec, tales como el formato de archivo AVC, así como 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 DVB.
[0030] Además de los medios continuos, tales como el audio y el vídeo, los medios estáticos, tales como las imágenes, así como los metadatos, se pueden almacenar en un archivo que se ajusta al ISOBMFF. Los archivos estructurados de acuerdo con el ISOBMFF se pueden usar para muchos propósitos, incluyendo la reproducción local de archivos de medios, la descarga progresiva de un archivo remoto, segmentos para la transmisión en continuo dinámica adaptativa a través de HTTP (DASH), contenedores para contenido que se va a transmitir en continuo y sus instrucciones de empaquetado y el registro de flujos de medios recibidos en tiempo real.
[0031] Una caja es la estructura sintáctica elemental en el ISOBMFF, que incluye un tipo de caja codificada de cuatro caracteres, un recuento de bytes de la caja y la carga útil. Un archivo ISOBMFF consiste en una secuencia de cajas, y las cajas pueden contener otras cajas. Una caja de película ("moov") contiene los metadatos para los flujos de medios continuos presentes en el archivo, cada uno representado en el archivo como una pista. Los metadatos para una pista están contenidos en una caja de pista ("trak"), mientras que el contenido de medios de una pista está contenido en una caja de datos de medios ("mdat") o directamente en un archivo separado. El contenido de medios para pistas consiste en una secuencia de muestras, tales como unas unidades de acceso de audio o vídeo.
[0032] El ISOBMFF especifica los siguientes tipos de pistas: una pista de medios, que contiene un flujo de medios elemental, una pista de indicaciones, que incluye instrucciones de transmisión de medios o representa un flujo de paquetes recibido, y una pista de metadatos temporizados, que comprende metadatos sincronizados en el tiempo.
[0033] Aunque originalmente se diseñó para el almacenamiento, el ISOBMFF ha demostrado ser muy valioso para la transmisión en continuo, por ejemplo, para una descarga progresiva o DASH. Para propósitos de transmisión en continuo, se pueden usar los fragmentos de película definidos en el ISOBMFF.
[0034] Los metadatos para 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 está asociada con una de las entradas de descripción de muestra de la pista.
[0035] El ISOBMFF permite especificar metadatos específicos de muestra con diversos mecanismos. Las cajas específicas dentro de la caja de tabla de muestras ("stbl") se han estandarizado para responder a unas necesidades comunes. Por ejemplo, se usa una caja de muestras de sincronización ("stss") para enumerar las muestras de acceso aleatorio de la pista. El mismo mecanismo de agrupación de muestras permite la correlación de muestras de acuerdo con un tipo de agrupación de cuatro caracteres en grupos de muestras que comparten la misma propiedad especificada como una entrada de descripción de grupo de muestras en el archivo. Se han especificado diversos tipos de agrupación en el ISOBMFF.
[0036] Las técnicas de esta divulgación se pueden aplicar a los archivos de vídeo que se ajustan a datos de vídeo encapsulados de acuerdo con cualquiera del ISOBMFF, el formato de archivo de codificación de vídeo escalable (SVC), el formato de archivo de codificación de vídeo avanzada (AVC), el formato de archivo del Proyecto de Colaboración de Tercera Generación (3GPP) y/o el formato de archivo de codificación de vídeo multivista (MVC) u otros formatos de archivo de vídeo similares.
[0037] El estándar ISO/IEC 23001-7 define el cifrado común para el formato de archivo de medios de base ISO. En el caso de este estándar, el cifrado está basado en el flujo elemental. Además, el estándar permite los modos de AES-128 CTR y CBC. Para descifrar los medios en un punto de acceso aleatorio, se requiere toda la información relacionada con DRM, incluyendo la información específica del sistema de protección así como los vectores de inicialización.
[0038] La transmisión en continuo dinámica adaptativa a través de HTTP (DASH), especificada en ISO/IEC 23009-1, es un estándar para aplicaciones de transmisión en continuo (adaptativa) HTTP. Especifica principalmente el formato de la descripción de presentación de medios (MPD), también denominada en general archivo de manifiesto, y el formato del segmento de medios. La MPD describe los medios disponibles en el servidor y permite que el cliente DASH descargue de forma autónoma la versión de medios en el tiempo de medios en el que está interesado.
[0039] Un ejemplo de procedimiento para la transmisión en continuo HTTP basada en DASH incluye las siguientes etapas:
1) Un cliente obtiene la MPD de un contenido de transmisión en continuo, por ejemplo, una película. La MPD incluye información sobre diferentes representaciones alternativas, por ejemplo, tasa de bits, resolución de vídeo, tasa de tramas, idioma de audio, del contenido de transmisión en continuo, así como las URL de los recursos HTTP (el segmento de inicialización y los segmentos de medios).
2) En base a la información en la MPD y la información local del cliente, por ejemplo, ancho de banda de red, capacidades de descodificación/visualización y preferencia del usuario, el cliente solicita la(s) representación(es) deseada(s), a razón de un segmento (o una parte del mismo) cada vez.
3) Cuando el cliente detecta un cambio en el ancho de banda de la red, el cliente solicita segmentos de una representación diferente con una tasa de bits más parecida, comenzando idealmente a partir de un segmento que comienza con un punto de acceso aleatorio.
[0040] Durante una "sesión" de transmisión en flujo HTTP, para responder a una petición de usuario para búsqueda hacia atrás hasta una posición pasada o hacia adelante hasta una posición futura, el cliente solicita segmentos pasados o futuros comenzando a partir de un segmento que está cerca de la posición deseada y que idealmente comienza con un punto de acceso aleatorio. El usuario también puede solicitar un avance rápido del contenido, lo que se puede realizar solicitando suficientes datos para descodificar solo las imágenes de vídeo intracodificadas o solo un subconjunto temporal del flujo de vídeo.
[0041] La última especificación ISOBMFF especifica seis tipos de puntos de acceso de flujo (SAP) para usar con DASH. Los dos primeros tipos de SAP (tipos 1 y 2) corresponden a imágenes IDR en H.264/AVC y HEVC. El tercer tipo de SAP (tipo 3) corresponde a puntos de acceso aleatorio de GOP abierto, por consiguiente, a imágenes BLA o CRA en HEVC.
[0042] En la transmisión en flujo HTTP, por ejemplo, de acuerdo con DASH, las operaciones usadas con frecuencia incluyen HEAD, GET y GET parcial. La operación HEAD recupera una cabecera de un archivo asociado a un localizador uniforme de recursos (URL) o un nombre uniforme de recurso (URN), sin recuperar una carga útil asociada al URL o al URN. La operación GET recupera un archivo completo asociado a un URL o URN dado. La operación GET parcial recibe una gama 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 a la gama de bytes recibida. Por tanto, se pueden proporcionar fragmentos de película para transmisión en flujo 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 en flujo HTTP, una presentación de medios puede ser un grupo de datos estructurado que es accesible para el cliente. El cliente puede solicitar y descargar información de datos de medios para presentar un servicio de transmisión en continuo a un usuario.
[0043] En el ejemplo de transmisión en continuo de datos 3GPP usando transmisión en continuo HTTP, puede haber múltiples representaciones para datos de vídeo y/o audio de contenido multimedia. Como se describe a continuación, 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 vídeo), diferentes estándares de codificación o ampliaciones de estándares de codificación (tales como ampliaciones multivista y/o escalables), o diferentes tasas de bits. El manifiesto de dichas representaciones se puede definir en una estructura de datos de descripción de presentación de medios (MPD). Una presentación de medios puede corresponder a un grupo de datos estructurado que es accesible para un dispositivo cliente de transmisión en continuo HTTP. El dispositivo cliente de transmisión en continuo HTTP puede solicitar y descargar información de datos de medios para presentar un servicio de transmisión en continuo a un usuario del dispositivo cliente. Una presentación de medios se puede describir en la estructura de datos MPD, que puede incluir actualizaciones de la MPD.
[0044] Una presentación de medios puede contener una secuencia de uno o más períodos. Los períodos pueden estar definidos por un elemento Period en la MPD. Cada período puede tener un atributo start en la MPD. La MPD puede incluir un atributo start y un atributo availableStartTime para cada período. Para servicios en directo, la suma del atributo start del período y del atributo availableStartTime de la MPD puede especificar el tiempo de disponibilidad del periodo en formato UTC, en particular, el primer segmento de medios de cada representación en el período correspondiente. Para servicios a la carta, el atributo start del primer período puede ser 0. Para cualquier otro período, el atributo start puede especificar un desplazamiento temporal entre el tiempo de inicio del período correspondiente con respecto al tiempo de inicio del primer periodo. Cada período se puede ampliar hasta el inicio del siguiente período, o hasta el final de la presentación de medios en el caso del último período. Los tiempos de inicio de período pueden ser precisos. Pueden reflejar la temporización real resultante de la reproducción de los medios de todos los periodos anteriores.
[0045] Cada período puede contener una o más representaciones para el mismo contenido de medios. Una representación puede ser una de un número de versiones codificadas alternativas de datos de audio o vídeo. Las representaciones pueden diferir según el tipo de codificación, por ejemplo, según la tasa de bits, la resolución y/o el códec para los datos de vídeo y la tasa de bits, el idioma y/o el códec para los datos de audio. El término representación se puede usar para referirse a una sección de datos de audio o vídeo codificados correspondientes a un período en particular del contenido multimedia y codificados de una forma en particular.
[0046] Las representaciones de un período en particular se pueden asignar a un grupo indicado en la MPD por un atributo indicativo de un conjunto de adaptación al que pertenecen las representaciones. Las representaciones del mismo conjunto de adaptación en general se consideran alternativas mutuas, en la medida en que un dispositivo cliente puede alternar entre estas representaciones de manera dinámica y sin fisuras, por ejemplo, para realizar una adaptación de ancho de banda. Por ejemplo, cada representación de datos de vídeo para un período en particular se puede asignar al mismo conjunto de adaptación, de modo que cualquiera de las representaciones se puede seleccionar para descodificar a fin de presentar datos de medios, tales como datos de vídeo o datos de audio, del contenido multimedia para el período correspondiente. El contenido de medios dentro de un período se puede representar mediante una representación cualquiera del grupo 0, si está presente, o bien la combinación de como máximo una representación de cada grupo no cero, en algunos ejemplos. Los datos de temporización para cada representación de un período se pueden expresar con respecto al tiempo de inicio del período.
[0047] Una representación puede incluir uno o más segmentos. Cada representación puede incluir un segmento de inicialización, o cada segmento de una representación puede ser autoinicializador. Cuando está presente, el segmento de inicialización puede contener información de inicialización para acceder a la representación. En general, el segmento de inicialización no contiene datos de medios. Un segmento se puede referenciar de forma única mediante un identificador, tal como un localizador uniforme de recursos (URL), un nombre uniforme de recurso (URN) o un identificador uniforme de recurso (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD también puede proporcionar gamas de bytes en forma de un atributo range, que puede corresponder a los datos para un segmento dentro de un archivo accesible mediante el URL, el URN o el URI.
[0048] Se pueden seleccionar diferentes representaciones para una recuperación sustancialmente simultánea para diferentes tipos de datos de medios. Por ejemplo, un dispositivo cliente puede seleccionar una representación de audio, una representación de vídeo y una representación de texto temporizado a partir de las cuales se pueden recuperar segmentos. En algunos ejemplos, el dispositivo cliente puede seleccionar conjuntos de adaptación en particular para realizar una adaptación de ancho de banda. Es decir, el dispositivo cliente puede seleccionar un conjunto de adaptación que incluye representaciones de vídeo, un conjunto de adaptación que incluye representaciones de audio y/o un conjunto de adaptación que incluye texto temporizado. De forma alternativa, el dispositivo cliente puede seleccionar conjuntos de adaptación para determinados tipos de medios (por ejemplo, vídeo) y seleccionar directamente representaciones para otros tipos de medios (por ejemplo, audio y/o texto temporizado).
[0049] Pueden surgir diversos problemas en las técnicas DASH convencionales. Por ejemplo, para los servicios de transmisión en continuo de vídeo de baja latencia, tales como la distribución de un servicio en directo de baja latencia, es pertinente que cada segmento se pueda generar tan rápido como sea posible para que esté disponible en el servidor de origen. En otras palabras, son necesarios segmentos cortos en dichos contextos. Actualmente, hay dos opciones para crear segmentos cortos:
1) Usar el perfil ISOBMFF de directo: esto significa que cada segmento debe comenzar con un SAP de tipo 1 o 2, pero todos los segmentos deben tener la misma duración en un conjunto de adaptación. En otras palabras, las imágenes IDR que se han de usar para proporcionar unos RAP, RAP de GOP abierto, que corresponden al SAP tipo 3, no se pueden usar. En consecuencia, la eficacia de codificación de vídeo se va a debilitar.
2) Usar el perfil ISOBMFF principal: Sin embargo, esto significa que no es posible la señalización basada en MPD en los puntos de conmutación (SAP tipo 1 o 2) y que el cliente necesita analizar los segmentos para averiguar cómo acceder a la muestra.
[0050] Además, puede surgir un problema de sobrecarga de segmento. Es decir, en la especificación DASH básica, los segmentos son unidades de entrega que deben incluir un número integral de fragmentos de película. Sin pérdida de generalidad, se va a suponer que un segmento contiene un solo fragmento de película. Los fragmentos de película por sí solos solo tienen restricciones por lo que respecta a la provisión de un número integral de muestras en orden de descodificación.
[0051] En DASH básico, los segmentos se pueden generar con el propósito de crear unidades direccionables y entregables sin más restricciones. Sin embargo, en perfiles restringidos (por ejemplo, el perfil ISO de directo), se usan segmentos al mismo tiempo para permitir la conmutación de representación. Esto último añade restricciones significativas:
• Cada segmento debe comenzar con un GOP cerrado
• los segmentos no se deben superponer en el tiempo de presentación dentro de una representación
[0052] Estas dos restricciones dan como resultado una eficacia de codificación reducida, especialmente si los segmentos son relativamente cortos.
[0053] Además, para aplicaciones de radiodifusión, el acceso aleatorio a una unidad de entrega es pertinente. La duración de los segmentos determina el tiempo de acceso aleatorio que es pertinente para la adquisición de canal y el cambio de canal. Para el acceso aleatorio, un GOP abierto más eficaz es suficiente, y los segmentos pueden incluso tener una superposición de tiempo de presentación hasta cierto punto, lo que puede dar como resultado una calidad de reproducción reducida en el acceso (algunas tramas omitidas), pero aun así permitir un acceso rápido al flujo.
[0054] Las técnicas de esta divulgación, como se analizan a continuación, pueden abordar los diferentes aspectos funcionales de un segmento y diferenciar segmentos en diferentes clases.
[0055] La FIG. 1 es un diagrama conceptual que ilustra un ejemplo de caso de uso para la unión rápida a un flujo. En este ejemplo, algunos segmentos están disponibles por medio de radiodifusión, mientras que otros segmentos están disponibles por medio de unidifusión. En particular, los segmentos marcados como "8" y "9" están disponibles por medio de radiodifusión, mientras que los segmentos marcados como 7A a 7D, 8A a 8D y 9A a 9D están disponibles por medio de unidifusión. En este caso de uso, un dispositivo cliente recupera los segmentos 7D y 8A a 8D por medio de unidifusión (donde los segmentos 8A a 8D incluyen los mismos datos de medios que el segmento 8 disponible a través de radiodifusión), y a continuación recibe el segmento 9 por medio de radiodifusión. En particular, el dispositivo cliente se sintoniza con la radiodifusión en el tiempo de sintonización 2, que es durante la transmisión del segmento 8 por medio de radiodifusión. Por lo tanto, el dispositivo cliente no puede recibir el segmento 8 por medio de radiodifusión, sino que, en su lugar, el dispositivo cliente recupera los segmentos 7D y 8A a 8D, antes de recibir el segmento 9 por medio de radiodifusión. Por tanto, el dispositivo cliente conmuta de radiodifusión a unidifusión después de recuperar el segmento 8D. En consecuencia, cuando se reproducen datos de medios, el dispositivo cliente reproduce datos de medios de los segmentos 7D y 8A a 8D (recibidos por medio de unidifusión), y a continuación conmuta a la reproducción a partir del segmento 9 (recibido por medio de radiodifusión).
[0056] Este caso de uso ilustra la "sintonización rápida" con unidifusión. En este caso, un proveedor de servicios deseará distribuir una representación que tiene una alta frecuencia de SAP (típicamente, el tipo 3 es posible) para un acceso rápido. Sin embargo, después de la sintonización, el cliente deseará conmutar a una representación que es más eficaz y que tiene menos tramas IDR. La representación a la que se ha conmutado puede tener incluso un tamaño de segmento diferente. Este contexto puede ser el caso de la unidifusión, pero también de un caso híbrido. Este contexto se muestra en la FIG. 1. En este diagrama, los segmentos más cortos se hacen accesibles por medio de unidifusión, incluyendo cada segmento una trama IDR. Si un cliente se une a un programa en un tiempo determinado y sin el soporte de unidifusión, transcurrirá cierto tiempo hasta que se reciba el segmento y se pueda comenzar a reproducir (segmento 9 en la FIG. 1). Esto se debe al hecho de que se necesita recibir el segmento completo (para inicializar apropiadamente, por ejemplo, un descodificador de medios para descodificar datos de medios del segmento).
[0057] En este caso, se ofrece una representación de unidifusión con un cuarto de la duración del segmento. El cliente puede elegir de inmediato reproducir los segmentos cortos de unidifusión hasta que la representación de radiodifusión eficaz (segmento largo, distancia de trama IDR larga) llega por medio de radiodifusión. La señalización de estas capacidades (posición de puntos de acceso aleatorio y puntos de conmutación) en la MPD es pertinente, pero imposible actualmente.
[0058] Otro caso de uso similar implica una sintonización rápida con la SHVC. Puede haber una oferta de una capa base con baja frecuencia de RAP e incluso un tamaño de segmento bajo, y una capa de mejora que tiene una mayor frecuencia de GOP. Entonces, se deberá lograr lo mismo que se analiza con respecto a la FIG. 1. Señalizar estas características no es posible actualmente.
[0059] Otro caso de uso deseable es el uso de una memoria intermedia de desplazamiento de tiempo eficaz. En determinados casos, se puede ofrecer una representación en el borde de directo con segmentos pequeños, pero en cuanto el cliente pasa a la memoria intermedia de desplazamiento de tiempo, el tamaño del segmento se incrementa. Las representaciones aún deberán estar en un conjunto de adaptación para expresar capacidades de conmutación sin interrupciones, pero no se deberán forzar a tener los mismos tamaños de segmento y/o la misma frecuencia de puntos de conmutación/puntos de acceso aleatorio. Lo mismo se aplica a la grabación de un acontecimiento en directo para un futuro uso a la carta.
[0060] Otro caso de uso implica una sintonización rápida con GOP abiertos. Un GOP abierto en general puede corresponder a un GOP que incluye imágenes que se pueden predecir en relación con imágenes fuera del GOP. Esto contrasta con un GOP cerrado, que es autónomo, ya que todas las imágenes del GOP se predicen a partir de otras imágenes dentro del GOP. Por ejemplo, un GOP abierto puede comenzar con una imagen de interpredicción (o una trama de interpredicción clave), mientras que un GOP cerrado puede comenzar con una imagen de intrapredicción.
[0061] El caso de sintonización rápida con GOP abiertos puede ser un caso típico para una sintonización rápida de radiodifusión. El problema es que hay casos para los que se desea sintonizar rápidamente, conmutar entre representaciones y posiblemente proporcionar baja latencia. Esto puede dar como resultado casos de uso complejos para la señalización, a saber, segmentos de señalización, GOP abiertos, GOP cerrados, alineaciones de segmentos, y así sucesivamente.
[0062] Otro caso de uso implica un apagado rápido para la continuidad. Este caso también puede ser típico para un contexto de sintonización rápida de radiodifusión. El problema es que hay casos para los que se desea sintonizar rápidamente, conmutar entre representaciones y posiblemente proporcionar baja latencia. Esto puede dar como resultado casos de uso complejos para la señalización, a saber, segmentos de señalización, GOP abiertos, GOP cerrados, alineaciones de segmentos, y así sucesivamente.
[0063] Otro caso de uso implica disponibilidades de segmentos. Para reducir las latencias, no solo se necesita que los segmentos sean cortos, sino que también se necesita que el tiempo entre la generación de los segmentos y la publicación sea corto. Para evitar errores HTTP 404, los tiempos de disponibilidad de segmento deben estar disponibles (por ejemplo, señalizados) para el receptor. Las plantillas de segmento proporcionan un patrón para comunicar tiempos de disponibilidad, pero esto requiere que los segmentos estén disponibles en un tiempo exacto y, por lo tanto, las variaciones en las duraciones de segmento se deben tener en cuenta al comunicar los tiempos de inicio de disponibilidad de segmento y el codificador debe seguir este patrón. Si el proveedor de contenido no está forzado a generar una trama IDR con tiempos de disponibilidad de segmento, puede variar más fácilmente las ubicaciones de las tramas IDR y los tiempos de disponibilidad de segmento se pueden comunicar con mayor exactitud. Este aspecto se deberá considerar en las duraciones de segmento de señalización.
[0064] En diferentes casos de uso, las diferentes características de conmutación, entrega y acceso aleatorio son más o menos pertinentes, pero es posible que se deban proporcionar dentro de una oferta de contenido. Existen varios contextos que se deberán considerar:
• Implementación de una distribución de radiodifusión con un tiempo de adquisición de canal bajo junto con la capacidad de conmutar a una representación de unidifusión a una frecuencia más baja.
• Entrega de una versión de baja latencia en el borde de directo a través de unidifusión que se sincroniza con una radiodifusión.
• Entrega de una versión de baja latencia a través de radiodifusión solo con una frecuencia de acceso aleatorio más alta que las unidades de entrega.
• Duraciones de segmentos variables que se deben tener en cuenta.
[0065] Las técnicas de esta divulgación pueden permitir estos diversos casos de uso, solos o en cualquier combinación, y pueden superar cualquiera o todos los problemas analizados anteriormente.
[0066] La FIG. 2 es un diagrama de Venn 200 que ilustra las relaciones entre diversos tipos de segmentos de medios. Los segmentos de medios se pueden usar para cualquiera o todos los diversos propósitos en DASH, tales como los siguientes:
• Conmutación de representación
o Los GOP cerrados en general son necesarios.
o Los segmentos no se deben superponer en el tiempo dentro de una representación.
o Los segmentos deben estar alineados en diferentes representaciones de un conjunto de adaptación.
• Acceso aleatorio
o Un GOP abierto en general es necesario.
o Los segmentos se pueden superponer en el tiempo dentro de una representación si se permite el acceso aleatorio de GOP abierto.
• Unidad de entrega
o No hay ningún requisito para acceso aleatorio o conmutación.
o El segmento debe incluir un número integral de fragmentos de películas.
[0067] Para abordar diferentes aspectos, se pueden considerar cuatro tipos (o formatos) de segmento diferentes de acuerdo con la FIG. 2:
• Formato de segmento de unidad de entrega 202: solo un fragmento sin restricciones. (Representado por una elipse con contorno continuo en la FIG. 2.)
• Formato de segmento de acceso aleatorio 204: GOP abierto para sintonizar. (Representado por una elipse con contorno de trazos en la FIG. 2.)
• Formato de segmento sin superposición 206: un dispositivo cliente puede conmutar a un segmento de este formato sin ningún problema. (Representado por una elipse con contorno punteado en la FIG. 2.)
• Formato de segmento de conmutación 208: un dispositivo cliente puede conmutar a un segmento de este formato. (Representado por una elipse con contorno de doble punto en la FIG. 2.)
[0068] La FIG. 3 es un diagrama conceptual que ilustra un ejemplo de estructura de una representación 210 y unos archivos BMFF ISO 212A a 212C. La FIG. 3 también muestra una vista despiezada del archivo BMFF ISO 212A, que incluye una caja moof (fragmento de película) y una caja de datos de película (mdat). El ejemplo de archivo BMFF ISO 212A de la FIG. 3 es conceptualmente similar a los fragmentos de película 164 de la FIG. 6, descritos con mayor detalle a continuación. Es pertinente considerar que los fragmentos de película son las unidades de entrega para datos de medios. Los fragmentos de película se generan de modo que contienen una secuencia de una caja moof y una caja mdat, por ejemplo, como se muestra en la FIG. 3.
[0069] La FIG. 4 es un diagrama de bloques que ilustra un ejemplo de sistema 10 que implementa técnicas para transmitir en continuo datos de medios a través de una red. En este ejemplo, el sistema 10 incluye un dispositivo de preparación de contenido 20, un dispositivo servidor 60 y un dispositivo cliente 40. El dispositivo cliente 40 y el dispositivo servidor 60 están acoplados de forma comunicativa por una red 74, que puede comprender Internet. En algunos ejemplos, el dispositivo de preparación de contenido 20 y el dispositivo servidor 60 también pueden estar acoplados por la red 74 u otra red, o pueden estar directamente acoplados de forma comunicativa. En algunos ejemplos, el dispositivo de preparación de contenido 20 y el dispositivo servidor 60 pueden comprender el mismo dispositivo.
[0070] El dispositivo de preparación de contenido 20, en el ejemplo de la FIG. 4, comprende una fuente de audio 22 y una fuente de vídeo 24. La fuente de audio 22 puede comprender, por ejemplo, un micrófono que produce señales eléctricas representativas de datos de audio captado que el codificador de audio 26 va a codificar. De forma alternativa, la fuente de audio 22 puede comprender un medio de almacenamiento que almacena datos de audio previamente registrados, un generador de datos de audio tal como un sintetizador informatizado, o cualquier otra fuente de datos de audio. La fuente de vídeo 24 puede comprender una cámara de vídeo que produce datos de vídeo que el codificador de vídeo 28 va a codificar, un medio de almacenamiento codificado con datos de vídeo previamente registrados, una unidad de generación de datos de vídeo, tal como una fuente de gráficos de ordenador, o cualquier otra fuente de datos de vídeo. El dispositivo de preparación de contenido 20 no está necesariamente acoplado de forma comunicativa al dispositivo servidor 60 en todos los ejemplos, pero puede almacenar contenido multimedia en un medio separado que el dispositivo servidor 60 lee.
[0071] Los datos de audio y vídeo no procesados pueden comprender datos analógicos o digitales. Los datos analógicos se pueden digitalizar antes de que el codificador de audio 26 y/o el codificador de vídeo 28 los codifiquen. La fuente de audio 22 puede obtener datos de audio a partir de un participante que habla mientras el participante que habla está hablando, y la fuente de vídeo 24 puede obtener simultáneamente datos de vídeo del participante que habla. En otros ejemplos, la fuente de audio 22 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de audio almacenados, y la fuente de vídeo 24 puede comprender un medio de almacenamiento legible por ordenador que comprende datos de vídeo almacenados. De esta manera, las técnicas descritas en esta divulgación se pueden aplicar a datos de audio y vídeo en tiempo real, de transmisión en directo y en continuo, o a datos de audio y vídeo archivados y prerregistrados.
[0072] Las tramas de audio que corresponden a tramas de vídeo son en general tramas de audio que contienen datos de audio que la fuente de audio 22 ha captado (o generado) al mismo tiempo que unos datos de vídeo, que la fuente de vídeo 24 ha captado (o generado), que están contenidos dentro de las tramas de vídeo. Por ejemplo, mientras un participante que habla en general produce, al hablar, datos de audio, la fuente de audio 22 capta los datos de audio, y la fuente de vídeo 24 capta los datos de vídeo del participante que habla al mismo tiempo, es decir, mientras la fuente de audio 22 está captando los datos de audio. Así pues, una trama de audio puede corresponder temporalmente a una o más tramas de vídeo en particular. En consecuencia, una trama de audio correspondiente a una trama de vídeo corresponde en general a una situación en la que se han captado datos de audio y datos de vídeo al mismo tiempo, y para la que una trama de audio y una trama de vídeo comprenden, respectivamente, los datos de audio y los datos de vídeo que se han captado al mismo tiempo.
[0073] En algunos ejemplos, el codificador de audio 26 puede codificar una marca de hora en cada trama de audio codificada, que representa una hora a la que se han registrado los datos de audio para la trama de audio codificada y, de forma similar, el codificador de vídeo 28 puede codificar una marca de hora en cada trama de vídeo codificada, que representa una hora a la que se han registrado los datos de vídeo para la trama de vídeo codificada. En dichos ejemplos, una trama de audio correspondiente a una trama de vídeo puede comprender una trama de audio que comprende una marca de hora y una trama de vídeo que comprende la misma marca de hora. El dispositivo de preparación de contenido 20 puede incluir un reloj interno a partir del cual el codificador de audio 26 y/o el codificador de vídeo 28 pueden generar las marcas de hora, o que la fuente de audio 22 y la fuente de vídeo 24 pueden usar para asociar datos de audio y vídeo, respectivamente, a una marca de hora.
[0074] En algunos ejemplos, la fuente de audio 22 puede enviar datos al codificador de audio 26, correspondientes a una hora a la que se han registrado los datos de audio, y la fuente de vídeo 24 puede enviar datos al codificador de vídeo 28, correspondientes a una hora a la que se han registrado los datos de vídeo. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencia en unos datos de audio codificados para indicar un orden temporal relativo de los datos de audio codificados, pero sin indicar necesariamente una hora absoluta a la que se han registrado los datos de audio y, de forma similar, el codificador de vídeo 28 también puede usar identificadores de secuencia para indicar un orden temporal relativo de los datos de vídeo codificados. De forma similar, en algunos ejemplos, un identificador de secuencia se puede asociar a, o correlacionar de otro modo con, una marca de tiempo.
[0075] El codificador de audio 26 en general produce un flujo de datos de audio codificados, mientras que el codificador de vídeo 28 produce un flujo de datos de vídeo codificados. Cada flujo de datos individual (ya sea de audio o vídeo) se puede denominar flujo elemental. Un flujo elemental es un componente único codificado digitalmente (y posiblemente comprimido) de una representación. Por ejemplo, la parte de vídeo o audio codificado de la representación puede ser un flujo elemental. Un flujo elemental se puede convertir en un flujo elemental paquetizado (PES) antes de encapsularse dentro de un archivo de vídeo. Dentro de la misma representación, se puede usar un ID de flujo para distinguir los paquetes PES que pertenecen a un flujo elemental de los otros. La unidad básica de datos de un flujo elemental es un paquete de flujo elemental paquetizado (PES). Por tanto, los datos de vídeo codificados corresponden en general a flujos de vídeo elementales. De forma similar, los datos de audio corresponden a uno o más flujos elementales respectivos.
[0076] Muchos estándares de codificación de vídeo, tales como el de ITU-T H.264/AVC y el de codificación de vídeo de alta eficacia (HEVC), definen la sintaxis, la semántica y los procesos de descodificación para flujos de bits sin errores, cualquiera de los cuales se puede ajustar a un determinado perfil o nivel. Los estándares de codificación de vídeo típicamente no especifican el codificador, pero el codificador se ocupa de garantizar que los flujos de bits generados cumplan los estándares para un descodificador. En el contexto de los estándares de codificación de vídeo, un "perfil" corresponde a un subconjunto de algoritmos, características o herramientas y restricciones que se les aplican. Como se define en el estándar H.264, por ejemplo, un "perfil" es un subconjunto de toda la sintaxis del flujo de bits que está especificada por el estándar H.264. Un "nivel" corresponde a las limitaciones del consumo de recursos del descodificador, tales como, por ejemplo, memoria y cálculo del descodificador, que están relacionadas con la resolución de las imágenes, la tasa de bits y la tasa de procesamiento de bloques. Un perfil se puede señalizar con un valor idc de perfil (indicador de perfil), mientras que un nivel se puede señalizar con un valor level_idc (indicador de nivel).
[0077] El estándar H.264, por ejemplo, reconoce que, dentro de los límites impuestos por la sintaxis de un perfil dado, todavía es posible requerir una gran variación en el rendimiento de los codificadores y descodificadores, dependiendo de los valores adoptados por los elementos sintácticos en el flujo de bits, tales como el tamaño especificado de las imágenes descodificadas. El estándar H.264 reconoce además que, en muchas aplicaciones, no es ni práctico ni económico implementar un descodificador capaz de tratar todos los usos hipotéticos de la sintaxis dentro de un perfil en particular. En consecuencia, el estándar H.264 define un "nivel" como un conjunto especificado de restricciones impuestas a los valores de los elementos sintácticos en el flujo de bits. Estas restricciones pueden ser simples limitaciones de valores. De forma alternativa, estas restricciones pueden adoptar la forma de restricciones sobre combinaciones aritméticas de valores (por ejemplo, la anchura de la imagen multiplicada por la altura de la imagen multiplicada por el número de imágenes descodificadas por segundo). El estándar H.264 establece además que las implementaciones individuales pueden admitir un nivel diferente para cada perfil admitido.
[0078] Un descodificador que se ajusta a un perfil habitualmente admite todas las características definidas en el perfil. Por ejemplo, como característica de codificación, la codificación de imágenes B no está admitida en el perfil de línea de base de H.264/AVC, pero está admitida en otros perfiles de H.264/AVC. Un descodificador que se ajusta a un nivel deberá ser capaz de descodificar cualquier flujo de bits que no requiere recursos fuera 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 vídeo, se pueden negociar y acordar 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 limitaciones en el número de macrobloques que es necesario procesar, el tamaño de la memoria intermedia de imágenes descodificadas (DPB), el tamaño de la memoria intermedia de imágenes codificadas (CPB), el intervalo de vectores de movimiento vertical, el número máximo de vectores de movimiento para cada dos MB consecutivos y si un bloque B puede tener divisiones de submacrobloque inferiores a 8x8 píxeles. De esta manera, un descodificador puede determinar si el descodificador es capaz de descodificar apropiadamente el flujo de bits.
[0079] En el ejemplo de la FIG. 4, la unidad de encapsulación 30 del dispositivo de preparación de contenido 20 recibe flujos elementales que comprenden datos de vídeo codificados desde el codificador de vídeo 28 y flujos elementales que comprenden datos de audio codificados desde el codificador de audio 26. En algunos ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden incluir, cada uno, paquetizadores para formar paquetes PES a partir de datos codificados. En otros ejemplos, el codificador de vídeo 28 y el codificador de audio 26 pueden interactuar, cada uno, con los paquetizadores respectivos para formar paquetes PES a partir de datos codificados. En otros ejemplos más, la unidad de encapsulación 30 puede incluir paquetizadores para formar paquetes PES a partir de datos de audio y de vídeo codificados.
[0080] El codificador de vídeo 28 puede codificar datos de vídeo de contenido multimedia en una variedad de formas, para producir diferentes representaciones del contenido multimedia a diversas tasas de bits y con diversas características, tales como resoluciones de píxeles, tasas de tramas, conformidad con diversos estándares de codificación, conformidad con diversos perfiles y/o niveles de perfiles para diversos estándares de codificación, representaciones que tienen una o múltiples vistas (por ejemplo, para reproducción bidimensional o tridimensional), u otras características de ese tipo. Una representación, como se usa en esta divulgación, puede comprender uno de datos de audio, datos de vídeo, datos de texto (por ejemplo, para subtítulos cerrados) u otros datos de este tipo. La representación puede incluir un flujo elemental, tal como un flujo elemental de audio o un flujo elemental de vídeo. Cada paquete PES puede incluir un identificador stream_id que identifica el flujo elemental al que pertenece el paquete PES. La unidad de encapsulación 30 es responsable de ensamblar flujos elementales en archivos de vídeo (por ejemplo, segmentos) de diversas representaciones.
[0081] La unidad de encapsulación 30 recibe paquetes PES para flujos elementales de una representación desde el codificador de audio 26 y el codificador de vídeo 28 y forma las correspondientes unidades de capa de abstracción de red (NAL) a partir de los paquetes PES. En el ejemplo de H.264/AVC (codificación de vídeo avanzada), los segmentos de vídeo codificados están organizados en unidades NAL, que proporcionan una representación de vídeo adaptada para redes que aborda aplicaciones tales como la videotelefonía, el almacenamiento, la radiodifusión o la transmisión en continuo. Las unidades NAL se pueden clasificar en unidades NAL de capa de codificación de vídeo (VCL) y unidades NAL no VCL. Las unidades VCL pueden contener el motor de compresión central y pueden incluir datos a nivel de bloque, macrobloque y/o sector. 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 estar contenida en una unidad de acceso, que puede incluir una o más unidades NAL.
[0082] Las unidades NAL no VCL pueden incluir unidades NAL de conjunto de parámetros y unidades NAL SEI, entre otras. Los conjuntos de parámetros contienen información de cabecera de nivel de secuencia (en conjuntos de parámetros de secuencia (SPS)) y la información de cabecera de nivel de imagen que cambia raramente (en conjuntos de parámetros de imagen (PPS)). Con los conjuntos de parámetros (por ejemplo, PPS y SPS), la información que cambia raramente no necesita ser repetida para cada secuencia o imagen, de ahí que la eficacia de codificación se pueda mejorar. Además, el uso de conjuntos de parámetros puede permitir la transmisión fuera de banda de la información de cabecera importante, evitando la necesidad de transmisiones redundantes para resistencia a los errores. En los ejemplos de transmisión fuera de banda, las unidades NAL de conjunto de parámetros se pueden transmitir en un canal diferente al de otras unidades NAL, tales como las unidades NAL SEI.
[0083] La información de mejora complementaria (SEI) puede contener información que no es necesaria para descodificar las muestras de imágenes codificadas a partir de las unidades NAL VCL, pero puede ayudar en los procesos relacionados con la descodificación, visualización, resistencia a errores y otros propósitos. Los mensajes SEI pueden estar contenidos en unidades NAL no VCL. Los mensajes SEI son la parte normativa de algunas especificaciones estándar y, por lo tanto, no siempre son obligatorios para la implementación de descodificadores que cumplen los estándares. Los mensajes SEI pueden ser mensajes SEI de nivel de secuencia o mensajes SEI de nivel de imagen. Parte de la información de nivel de secuencia puede estar contenida en mensajes SEI, tales como mensajes SEI de información de escalabilidad en el ejemplo de SVC y mensajes SEI de información de escalabilidad de vistas en MVC. Estos ejemplos de mensajes SEI pueden transmitir información, por ejemplo, sobre extracción de puntos de funcionamiento y características de los puntos de funcionamiento. Además, la unidad de encapsulación 30 puede formar un archivo de manifiesto, tal como una descripción de presentación de medios (MPD) que describe características de las representaciones. La unidad de encapsulación 30 puede formatear la MPD de acuerdo con un lenguaje de marcado extensible (XML).
[0084] La unidad de encapsulación 30 puede proporcionar datos para una o más representaciones de contenido multimedia, junto con el archivo de manifiesto (por ejemplo, la MPD), a la interfaz de salida 32. La interfaz de salida 32 puede comprender una interfaz de red o una interfaz para escribir en un medio de almacenamiento, tal como una interfaz de bus serie universal (USB), un grabador o quemador de CD o DVD, una interfaz para medios de almacenamiento magnéticos o flash, u otras interfaces para almacenar o transmitir datos de medios. La unidad de encapsulación 30 puede proporcionar datos de cada una de las representaciones de contenido multimedia a la interfaz de salida 32, que puede enviar los datos al dispositivo servidor 60 por medio de transmisión por red o medios de almacenamiento. En el ejemplo de la FIG. 4, el dispositivo servidor 60 incluye un medio de almacenamiento 62 que almacena diversos contenidos multimedia 64, incluyendo cada uno un respectivo archivo de manifiesto 66 y una o más representaciones 68A a 68N (representaciones 68). En algunos ejemplos, la interfaz de salida 32 también puede enviar datos directamente a la red 74.
[0085] En algunos ejemplos, las representaciones 68 se pueden separar en conjuntos de adaptación. Es decir, diversos subconjuntos de representaciones 68 pueden incluir respectivos conjuntos comunes de características, tales como códec, perfil y nivel, resolución, número de vistas, formato de archivo para segmentos, información de tipo de texto que puede identificar un idioma u otras características de un texto que se va a visualizar con la representación y/o datos de audio que se van a descodificar y presentar, por ejemplo, mediante altavoces, información de ángulo de cámara que puede describir un ángulo de cámara o una perspectiva de cámara real de una escena para representaciones del conjunto de adaptación, información de calificación que describe la idoneidad del contenido para audiencias en particular, o similares.
[0086] El archivo de manifiesto 66 puede incluir datos indicativos de los subconjuntos de representaciones 68 correspondientes a conjuntos de adaptación en particular, así como características comunes para los conjuntos de adaptación. El archivo de manifiesto 66 también puede incluir datos representativos de características individuales, tales como las tasas de bits, para representaciones individuales de conjuntos de adaptación. De esta manera, un conjunto de adaptación puede hacer posible una adaptación simplificada del ancho de banda de red. Las representaciones de un conjunto de adaptación se pueden indicar usando elementos hijo de un elemento del conjunto de adaptación del archivo de manifiesto 66.
[0087] El dispositivo servidor 60 incluye una unidad de procesamiento de peticiones 70 y una interfaz de red 72. En algunos ejemplos, el dispositivo servidor 60 puede incluir una pluralidad de interfaces de red. Además, una cualquiera o todas las características del dispositivo servidor 60 se pueden implementar en otros dispositivos de una red de entrega de contenido, tales como encaminadores, puentes, dispositivos proxy, conmutadores u otros dispositivos. En algunos ejemplos, los dispositivos intermedios de una red de entrega de contenido pueden almacenar en memoria caché datos de contenido multimedia 64, e incluir componentes que se ajustan sustancialmente a los del dispositivo servidor 60. En general, la interfaz de red 72 está configurada para enviar y recibir datos por medio de la red 74.
[0088] La unidad de procesamiento de peticiones 70 está configurada para recibir peticiones de red desde dispositivos cliente, tales como el dispositivo cliente 40, para datos del medio de almacenamiento 62. Por ejemplo, la unidad de procesamiento de peticiones 70 puede implementar el protocolo de transferencia de hipertexto (HTTP) versión 1.1, como se describe en el documento RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1", de R. Fielding et al., Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de peticiones 70 puede estar configurada para recibir peticiones GET o GET parciales HTTP y proporcionar datos de contenido multimedia 64 como respuesta a las peticiones. Las peticiones pueden especificar un segmento de una de las representaciones 68, por ejemplo, usando un URL del segmento. En algunos ejemplos, las peticiones también pueden especificar uno o más intervalos de bytes del segmento, comprendiendo por lo tanto peticiones GET parciales. La unidad de procesamiento de peticiones 70 puede estar configurada además para atender peticiones HEAD HTTP para proporcionar datos de cabecera de un segmento de una de las representaciones 68. En cualquier caso, la unidad de procesamiento de peticiones 70 puede estar configurada para procesar las peticiones para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 40.
[0089] De forma adicional o alternativa, la unidad de procesamiento de peticiones 70 puede estar configurada para entregar datos de medios por medio de un protocolo de radiodifusión o multidifusión, tal como el eMBMS. El dispositivo de preparación de contenido 20 puede crear segmentos y/o subsegmentos DASH, sustancialmente de la misma manera que se ha descrito, pero el dispositivo servidor 60 puede entregar estos segmentos o subsegmentos usando el eMBMS u otro protocolo de transporte de red de radiodifusión o multidifusión. Por ejemplo, la unidad de procesamiento de peticiones 70 puede estar configurada para recibir una petición para unirse a un grupo de multidifusión desde el dispositivo cliente 40. Es decir, el dispositivo servidor 60 puede comunicar una dirección de protocolo de Internet (IP), asociada a un grupo de multidifusión a unos dispositivos cliente, que incluyen el dispositivo cliente 40, asociados a un contenido de medios en particular (por ejemplo, radiodifusión de un acontecimiento en directo). El dispositivo cliente 40, a su vez, puede presentar una petición para unirse al grupo de multidifusión. Esta petición se puede propagar por toda la red 74, por ejemplo, los encaminadores que componen la red 74, de modo que se hace que los encaminadores dirijan el tráfico destinado a la dirección IP asociada al grupo de multidifusión a los dispositivos cliente abonados, tales como el dispositivo cliente 40.
[0090] Como se ilustra en el ejemplo de la FIG. 4, el contenido multimedia 64 incluye el archivo de manifiesto 66, que puede corresponder a una descripción de presentación de medios (MPD). El archivo de manifiesto 66 puede contener descripciones de diferentes representaciones alternativas 68 (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil, un valor de nivel, una tasa de bits y otras características descriptivas de las representaciones 68. El dispositivo cliente 40 puede recuperar la MPD de una presentación de medios para determinar cómo acceder a segmentos de las representaciones 68.
[0091] En particular, la unidad de recuperación 52 puede recuperar datos de configuración (no mostrados) del dispositivo cliente 40 para determinar las capacidades de descodificación del descodificador de vídeo 48 y las capacidades de representación de la salida de vídeo 44. Los datos de configuración también pueden incluir cualquiera o todas las preferencias de idioma seleccionadas por un usuario del dispositivo cliente 40, una o más perspectivas de cámara correspondientes a las preferencias de profundidad establecidas por el usuario del dispositivo cliente 40 y/o una preferencia de calificació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 de medios configurados para presentar peticiones GET y GET parcial HTTP. La unidad de recuperación 52 puede corresponder a unas instrucciones de software ejecutadas por uno o más procesadores o unidades de procesamiento (no mostrados) del dispositivo cliente 40. En algunos ejemplos, la totalidad o unas partes de la funcionalidad descrita con respecto a la unidad de recuperación 52 se pueden implementar en hardware, o una combinación de hardware, software y/o firmware, donde se puede proporcionar el hardware requerido para ejecutar instrucciones para software o firmware.
[0092] La unidad de recuperación 52 puede comparar las capacidades de descodificació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 parte 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 parte 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 características que se pueden satisfacer mediante las capacidades de codificación y representación del dispositivo cliente 40. La unidad de recuperación 52 puede, a continuación, determinar las tasas de bits para las representaciones del conjunto de adaptación, determinar una cantidad actualmente disponible de ancho de banda de red y recuperar segmentos de una de las representaciones que tiene una tasa de bits que se puede satisfacer mediante el ancho de banda de red.
[0093] En general, las representaciones de tasas de bits mayores pueden producir una reproducción de vídeo de mayor calidad, mientras que las representaciones de tasas de bits más bajas pueden proporcionar una reproducción de vídeo de calidad suficiente cuando el ancho de banda de red disponible se reduce. En consecuencia, cuando el ancho de banda de red disponible es relativamente alto, la unidad de recuperación 52 puede recuperar datos de representaciones de tasa de bits relativamente alta, mientras que cuando el ancho de banda de red disponible es bajo, la unidad de recuperación 52 puede recuperar datos de representaciones de tasa de bits relativamente baja. De esta manera, el dispositivo cliente 40 puede transmitir en continuo datos multimedia a través de la red 74 mientras que también se adapta a la disponibilidad cambiante de ancho de banda de red de la red 74.
[0094] De forma adicional o alternativa, la unidad de recuperación 52 puede estar configurada para recibir datos de acuerdo con un protocolo de red de radiodifusión o multidifusión, tal como la multidifusión eMBMS o IP. En dichos ejemplos, la unidad de recuperación 52 puede presentar una petición para unirse a un grupo de red de multidifusión asociado a un contenido de medios en particular. Después de unirse al grupo de multidifusión, la unidad de recuperación 52 puede recibir datos del grupo de multidifusión sin peticiones adicionales emitidas al dispositivo servidor 60 o al dispositivo de preparación de contenido 20. La unidad de recuperación 52 puede presentar una petición para abandonar el grupo de multidifusión cuando ya no se necesitan datos del grupo de multidifusión, por ejemplo, para detener la reproducción o para cambiar canales a un grupo de multidifusión diferente.
[0095] La interfaz de red 54 puede recibir y proporcionar datos de segmentos de una representación seleccionada a la unidad de recuperación 52, que a su vez puede proporcionar los segmentos a la unidad de desencapsulación 50. La unidad de desencapsulación 50 puede desencapsular elementos de un archivo de vídeo en flujos PES constituyentes, despaquetizar los flujos PES para recuperar datos codificados y enviar los datos codificados al descodificador de audio 46 o bien al descodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como lo indican las cabeceras de paquetes PES del flujo. El descodificador de audio 46 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 42, mientras que el descodificador de vídeo 48 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de vídeo 44.
[0096] De acuerdo con las técnicas de esta divulgación, el archivo de manifiesto 66 puede señalizar diversos formatos de segmento a los que los segmentos se pueden ajustar (también denominados en el presente documento tipos de segmento). El archivo de manifiesto 66 también puede señalizar ubicaciones de segmentos que se ajustan a cada formato (es decir, ubicaciones de cada uno de los diversos tipos de segmento). Por ejemplo, el archivo de manifiesto 66 puede señalizar frecuencias a las que aparecen cada uno de los diversos tipos de segmentos en cada una de las representaciones 68.
[0097] Usando el archivo de manifiesto 66, el dispositivo cliente 40 puede lograr una reproducción de baja latencia de datos de medios. Por ejemplo, una de las representaciones 68 (por ejemplo, la representación 68A) puede incluir unos SAP a una frecuencia relativamente alta, como se indica en el archivo de manifiesto 66, mientras que otra de las representaciones 68 (por ejemplo, la representación 68N) puede incluir unos SAP a una frecuencia relativamente baja. En particular, los SAP pueden formar parte de segmentos que se ajustan a formatos en particular, por ejemplo, el formato de segmento de medios de acceso aleatorio y/o el formato de segmento de medios de conmutación. Además, las representaciones 68 pueden estar disponibles para su recuperación por medio de diferentes servicios de transmisión. Por ejemplo, la representación 68A puede estar disponible por medio de unidifusión, mientras que la representación 68N puede estar disponible por medio de radiodifusión.
[0098] De acuerdo con algunos ejemplos de las técnicas de esta divulgación, el dispositivo cliente 40 puede determinar, según el ejemplo anterior, que la representación 68A incluye una frecuencia relativamente alta de SAP (por ejemplo, segmentos de medios de acceso aleatorio altamente frecuentes y/o segmentos de medios de conmutación altamente frecuentes), como se indica en el archivo de manifiesto 66. Además, el dispositivo cliente 40 puede determinar que la representación 68N incluye una frecuencia relativamente baja de SAP, pero que tiene también una calidad relativamente mayor. Por tanto, para iniciar la recuperación de datos de medios, el dispositivo cliente 40 puede comenzar recuperando segmentos de medios de la representación 68A, hasta que el dispositivo cliente 40 puede conmutar a la representación 68N, por ejemplo, en un segmento de medios de acceso aleatorio o un segmento de medios de conmutación de 68N, como se indica en el archivo de manifiesto 66. A continuación, se describen diversos casos de uso detallados que describen ejemplos de estas técnicas, con respecto, por ejemplo, a las FIGS. 7 a 14.
[0099] El codificador de vídeo 28, el descodificador de vídeo 48, el codificador de audio 26, el descodificador de audio 46, la unidad de encapsulación 30, la unidad de recuperación 52 y la unidad de desencapsulación 50 se pueden implementar cada uno como cualquiera de una variedad de circuitos de procesamiento adecuados, según corresponda, tales como uno o más microprocesadores, procesadores de señales digitales (DSP), circuitos integrados específicos de la aplicación (ASIC), matrices de puertas programables in situ (FPGA), circuitos lógicos discretos, software, hardware, firmware o cualquier combinación de los mismos. Tanto el codificador de vídeo 28 como el descodificador de vídeo 48 pueden estar incluidos en uno o más codificadores o descodificadores, ambos de los cuales pueden estar integrados como parte de un codificador/descodificador (CÓDEC) de vídeo combinado. Asimismo, tanto el codificador de audio 26 como el descodificador de audio 46 pueden estar incluidos en uno o más codificadores o descodificadores, ambos de los cuales puede estar integrado como parte de un CÓDEC combinado. Un aparato que incluye un codificador de vídeo 28, un descodificador de vídeo 48, un codificador de audio 26, un descodificador de audio 46, una unidad de encapsulación 30, una unidad de recuperación 52 y/o una 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 móvil.
[0100] El dispositivo cliente 40, el dispositivo servidor 60 y/o el dispositivo de preparación de contenido 20 pueden estar configurados para funcionar de acuerdo con las técnicas de esta divulgación. Con propósitos ejemplificativos, esta divulgación describe estas técnicas con respecto al dispositivo cliente 40 y al dispositivo servidor 60. Sin embargo, se deberá entender que el dispositivo de preparación de contenido 20 puede estar configurado para realizar estas técnicas, en lugar (o además) del dispositivo servidor 60.
[0101] La unidad de encapsulación 30 puede formar unidades NAL que comprenden una cabecera que identifica un programa al cual pertenece la unidad NAL, así como una carga útil, por ejemplo, datos de audio, datos de vídeo o datos que describen el flujo de transporte o de programa al cual corresponde la unidad NAL. Por ejemplo, en H.264/AVC, una unidad NAL incluye una cabecera de 1 byte y una carga útil de tamaño variable. Una unidad NAL que incluye datos de vídeo en su carga útil puede comprender diversos niveles de granularidad de datos de vídeo. Por ejemplo, una unidad NAL puede comprender un bloque de datos de vídeo, una pluralidad de bloques, un sector de datos de vídeo o una imagen completa de datos de vídeo. La unidad de encapsulación 30 puede recibir datos de vídeo codificados desde el codificador de vídeo 28 en forma de paquetes PES de flujos elementales. La unidad de encapsulación 30 puede asociar cada flujo elemental a un programa correspondiente.
[0102] La unidad de encapsulación 30 también puede ensamblar unidades de acceso de una pluralidad de unidades NAL. En general, una unidad de acceso puede comprender una o más unidades NAL para representar una trama de datos de vídeo, así como datos de audio correspondientes a la trama cuando dichos datos de audio están disponibles. Una unidad de acceso incluye en general todas las unidades NAL para una instancia de tiempo de salida, por ejemplo, todos los datos de audio y vídeo para una instancia de tiempo. Por ejemplo, si cada vista tiene una tasa de tramas de 20 tramas por segundo (fps), 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) se pueden representar simultáneamente. En un ejemplo, una unidad de acceso puede comprender una imagen codificada en una instancia de tiempo, que se puede presentar como una imagen codificada primaria.
[0103] En consecuencia, una unidad de acceso puede comprender todas las tramas de audio y vídeo de una instancia temporal común, por ejemplo, todas las vistas correspondientes al tiempo X. Esta divulgación también se refiere a una imagen codificada de una vista en particular como un "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista en particular en un tiempo en particular. En consecuencia, se puede definir una unidad de acceso que comprende todos los componentes de vista de una instancia temporal común. El orden de descodificación de las unidades de acceso no necesita ser el mismo que el orden de salida o de visualización.
[0104] Una presentación de medios puede incluir una descripción de presentación de medios (MPD), que puede contener descripciones de diferentes representaciones alternativas (por ejemplo, servicios de vídeo con diferentes calidades) y la descripción puede incluir, por ejemplo, información de códec, un valor de perfil y un valor de nivel. Una 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 de medios para determinar cómo acceder a fragmentos de película de diversas presentaciones. Los fragmentos de película pueden estar situados en cajas de fragmento de película (cajas moof) de archivos de vídeo.
[0105] El archivo de manifiesto 66 (que puede comprender, por ejemplo, una MPD) puede comunicar la disponibilidad de segmentos de representaciones 68. Es decir, la MPD puede incluir información que indica la hora de reloj de tiempo real a la cual un primer segmento de una de las representaciones 68 queda disponible, así como 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 de las duraciones de los segmentos que preceden a un segmento en particular.
[0106] Después de que la unidad de encapsulación 30 haya ensamblado las unidades NAL y/o las unidades de acceso en un archivo de vídeo, en base a los datos recibidos, la unidad de encapsulación 30 pasa el archivo de vídeo a la interfaz de salida 32 para su salida. En algunos ejemplos, la unidad de encapsulación 30 puede almacenar el archivo de vídeo localmente o enviar el archivo de vídeo a un servidor remoto por medio de la interfaz de salida 32, en lugar de enviar el archivo de vídeo directamente al dispositivo cliente 40. La interfaz de salida 32 puede comprender, por ejemplo, un transmisor, un transceptor, un dispositivo para escribir 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 disquetes), un puerto de bus serie universal (USB), una interfaz de red u otra interfaz de salida. La interfaz de salida 32 facilita el archivo de vídeo 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.
[0107] La interfaz de red 54 puede recibir una unidad NAL o unidad de acceso por medio de la red 74 y proporcionar la unidad NAL o la unidad de acceso a la unidad de desencapsulación 50, por medio de la unidad de recuperación 52. La unidad de desencapsulación 50 puede desencapsular un elemento de un archivo de vídeo en flujos PES constituyentes, desempaquetar los flujos PES para recuperar datos codificados y enviar los datos codificados al descodificador de audio 46 o al descodificador de vídeo 48, dependiendo de si los datos codificados forman parte de un flujo de audio o vídeo, por ejemplo, como se indica en las cabeceras de paquetes PES del flujo. El descodificador de audio 46 descodifica datos de audio codificados y envía los datos de audio descodificados a la salida de audio 42, mientras que el descodificador de vídeo 48 descodifica datos de vídeo codificados y envía los datos de vídeo descodificados, que pueden incluir una pluralidad de vistas de un flujo, a la salida de vídeo 44.
[0108] De acuerdo con las técnicas de esta divulgación, cualquiera o la totalidad de entre el dispositivo de preparación de contenido 20, el dispositivo servidor 60 y/o el dispositivo cliente 40 pueden estar configurados para realizar diversos procedimientos para definir, señalizar y/o procesar datos de medios de acuerdo con un nuevo perfil DASH (por ejemplo, perfil avanzado de directo). Del mismo modo, cualquiera o la totalidad de estos dispositivos pueden estar configurados para procesar nuevos tipos de segmentos de medios, lo que puede permitir la transmisión en continuo de vídeo de latencia, incluyendo el tiempo de cambio de canal reducido en radiodifusión y multidifusión, mientras se permiten al mismo tiempo estructuras de codificación de vídeo de alta eficacia. En general, se analizan los siguientes aspectos, que se pueden realizar individualmente o en cualquier combinación:
• Definición de diferentes tipos de segmento de medios y sus estructuras.
• Revisión de atributos actuales.
• Consideraciones de solución.
• Señalización de MPD.
• Señalización del tipo en el segmento.
• Señalización del tipo en la MPD.
• Habilitación de conjuntos de adaptación para diferentes casos de uso.
[0109] En algunos ejemplos, el dispositivo de preparación de contenido 20, el dispositivo servidor 60 y el dispositivo cliente 40 pueden estar configurados para utilizar segmentos de medios que se ajustan a cualquiera de los siguientes formatos: un formato de segmento de medios de unidad de entrega, un formato de segmento de medios de acceso aleatorio, un formato de segmento sin superposición y/o un formato de segmento de medios de conmutación. Estos formatos se describen con más detalle a continuación.
[0110] Un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega se puede definir como sigue:
• Cada segmento de medios deberá contener uno o más fragmentos de película autónomos completos. Un fragmento de película autónomo completo es una caja de fragmento de película ('moof') y una caja de datos de medios ('mdat') que contiene todas las muestras de medios que no usan referencias de datos externas referenciadas por las pistas de la caja de fragmento de película.
• Cada caja 'moof' deberá contener al menos un fragmento de pista.
• Las cajas 'moof' no deberán usar referencias de datos externas, se deberá establecer el señalizador 'defaultbase-is-moof, y se deberá usar el desplazamiento de datos, es decir, no se deberá usar 'base-data-offset-present'. Esta combinación de valores se puede denominar direccionamiento relativo de fragmento de película para datos multimedia.
• Cada segmento de medios puede llevar 'dums' en la caja de tipo de segmento ('styp') como una marca compatible. Los requisitos de conformidad de esta marca pueden ser como se define en esta divulgación.
[0111] Un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio se define como sigue:
• El segmento de medios deberá ajustarse al formato de segmento de medios de unidad de entrega como se especifica anteriormente.
• La primera unidad de acceso de cada fragmento de película de un segmento de medios de acceso aleatorio deberá corresponder al Isau de un SAP de tipo 1,2 o 3 (por ejemplo, incluir una imagen IDR, CRA o BLA).
• El segmento de medios llevará información suficiente para acceder a los medios en el flujo, por ejemplo, todo el cifrado necesario en combinación con el segmento de inicialización, si está disponible.
• Cada caja 'traf' (caja de fragmento de pista) deberá contener una caja 'tfdt' (caja de tiempo de descodificación de fragmento de pista).
• Cada segmento de medios puede llevar 'rams' en la caja de tipo de segmento ('styp') como una marca compatible. Los requisitos de conformidad de esta marca se definen en esta subcláusula.
• Cada segmento de medios puede contener una o más cajas 'sidx'. Si está presente, la primera caja 'sidx' se deberá colocar antes de cualquier caja 'moof' y la primera caja de índice de segmento deberá documentar todo el segmento.
[0112] Un segmento de medios que se ajusta al formato de segmento sin superposición se puede definir como sigue:
• El segmento de medios deberá ajustarse al formato de segmento de medios de unidad de entrega como se especifica anteriormente.
• El segmento deberá satisfacer la propiedad de no superposición como se define en 4.5.3 de ISO/IEC 23009-1, en el sentido de que el segmento y su segmento anterior satisfacen la propiedad de no superposición.
[0113] Un segmento de medios que se ajusta al formato de segmento de medios de conmutación se puede definir como sigue:
• El segmento de medios se deberá ajustar al formato de segmento de medios de acceso aleatorio como se especifica anteriormente.
• La primera muestra del primer fragmento de película de un segmento de medios de conmutación deberá corresponder al Isau de un SAP de tipo 1 o 2 (por ejemplo, una imagen IDR).
• Cada segmento de medios puede llevar 'swms' en la caja de tipo de segmento ('styp') como una marca compatible. Los requisitos de conformidad de esta marca se definen en esta subcláusula.
[0114] Los segmentos de los diversos formatos pueden realizar diferentes funciones. Por ejemplo, los segmentos de medios de la unidad de entrega en general desempeñan la función de entregar datos de medios. Como otro dato, los segmentos de medios de acceso aleatorio desempeñan la función de proporcionar puntos de acceso aleatorio (que incluyen datos de inicialización) a una representación que incluye los segmentos de medios de acceso aleatorio. Los segmentos sin superposición pueden desempeñar la función de indicar la alineación de segmentos entre representaciones, lo que puede permitir una conmutación de representaciones simple. Los segmentos de medios de conmutación proporcionan la función de permitir la conmutación de representaciones, sin incluir datos de inicialización adicionales que se requerirán para un segmento de medios de acceso aleatorio.
[0115] Además, el dispositivo de preparación de contenido 20, el dispositivo servidor 60 y el dispositivo cliente 40 pueden estar configurados para procesar datos que representan los formatos analizados anteriormente y/u otros datos de acuerdo con las técnicas de esta divulgación, por ejemplo, en un archivo de manifiesto 66 (tal como una MPD). Las siguientes características se pueden señalizar en el archivo de manifiesto 66, individualmente o en cualquier combinación:
• El tipo de cada segmento de medios de la representación, ya esté explícitamente señalizado o bien señalizado a través de un patrón.
• La capacidad de tener diferentes tamaños de segmento en un conjunto de adaptación, pero seguir teniendo puntos de conmutación alineados, es decir, segmentos de medios de conmutación que comienzan al mismo tiempo.
• Las consecuencias para el cálculo de minBufferTime y el ancho de banda (deberán comenzar en un punto de acceso aleatorio)
[0116] Para cada una de las representaciones 68, y posiblemente en un nivel de conjunto de adaptación predeterminado, se puede señalizar lo siguiente en el archivo de manifiesto 66:
• Patrón de la representación:
o Cada segmento es un segmento de tipo de medios de unidad de entrega, cada N segmento es un segmento de medios de acceso aleatorio, cada M segmento es un segmento de conmutación, siendo M> = N. Puede ser factible cierta abreviación y predeterminación de valores.
Esto se puede señalizar con unos nuevos atributos: frecuencia de rams y frecuencia de swms.
o Otros patrones de abreviación que permiten la expresión del patrón sin actualizar la MPD.
• Patrón en línea de tiempo de segmento
o Añadir un campo de tipo opcional en la línea de tiempo del segmento para cada elemento." tipo de segmento. o El campo de tipo también puede expresar un patrón como el patrón anterior.
o Habilitar la señalización de irregularidades con actualizaciones del elemento S en la línea de tiempo del segmento.
• Explícita
o Añadir un campo que permite señalizar patrones de segmento en una lista explícita, posiblemente alternando con algunos patrones.
o Esto también puede incluir la señalización de la duración del segmento.
[0117] Puede darse el caso de que las representaciones de un conjunto de adaptación común tengan duraciones de segmento diferentes. Sin embargo, el problema para la conmutación es que los puntos de conmutación en todas las representaciones se deben alinear para permitir la conmutación sin interrupciones. La posición de los puntos de conmutación se puede señalizar como se analiza anteriormente. También se puede considerar la siguiente señalización:
• Todas las representaciones tienen puntos de conmutación en la misma posición y están alineados. Esto se puede señalizar con un solo señalizador.
• Cuando se señaliza un punto de conmutación en un tiempo específico (en este caso, el tiempo MPD, que puede ser complejo), este se alinea con todos los demás puntos de conmutación de la representación. Esto también se puede señalizar con un solo señalizador y se puede usar el mismo señalizador como se analiza anteriormente.
• En algunos ejemplos, incluso en caso de que no haya ningún segmento de medios de conmutación siguiente, sigue sin haber superposición, de modo que el dispositivo cliente 40 puede conmutar de un punto sin superposición a un segmento de medios de conmutación.
• Otra señalización más explícita de puntos de conmutación se puede señalizar adicionalmente en el archivo de manifiesto 66.
[0118] Como se indica anteriormente, en algunos ejemplos, el dispositivo de preparación de contenido 20, el dispositivo servidor 60 y/o el dispositivo cliente 40 pueden estar configurados para utilizar un perfil de directo avanzado de DASH. El perfil de directo avanzado puede incluir todas las características y los tipos de segmento definidos anteriormente. El perfil de directo avanzado se puede identificar mediante el nombre uniforme de recurso (URN): "urn:mpeg:dash:profile:advanced-live:2015".
[0119] En algunos ejemplos, si el perfil de directo avanzado se usa en un conjunto de adaptación:
• Cada segmento de medios de conmutación deberá llevar 'swms' en la caja de tipo de segmento ('styp') como marca compatible.
• Cada segmento de medios de acceso aleatorio que no lleva 'swms' deberá llevar 'rams' en la caja de tipo de segmento ('styp') como marca compatible.
[0120] Esta divulgación reconoce los siguientes problemas y limitaciones para la señalización convencional para atributos MPD:
1. Señalización de tiempo de disponibilidad de segmento:
• o @duration o línea de tiempo de segmento:
La propuesta es simplificar el nuevo perfil y usar solo la línea de tiempo del segmento para este propósito, ya que es un superconjunto de @duration.
Sin embargo, la línea de tiempo del segmento es más compleja ya que permite excepciones.
También se debe aclarar si el tiempo en la línea de tiempo del segmento es una duración de segmento exacta (permite menos flexibilidad en autoría de contenido) o una duración exenta de deriva y solo señaliza los tiempos de disponibilidad del segmento.
Es importante tener en cuenta que mediante la aplicación apropiada de @timescale, este problema se puede resolver.
2. Señalización de conmutación de propiedad, es decir, sin superposición
• Mediante establecimiento de alineación de segmentos en true en un conjunto de adaptación.
El problema es que esto significa que cada segmento debe tener la misma duración.
La no superposición se debe expresar en una granularidad más fina.
3. Señalización de acceso aleatorio
• Comienza con SAP establecido en 1,2 o 3:
El problema es que esto no está expuesto muy explícitamente.
Asimismo, se deben establecer otros requisitos, véase la definición ampliada del segmento de acceso aleatorio.
4. Señalización de punto de conmutación.
• Comienza con SAP establecido en 1 o 2:
El problema es que esto no está expuesto muy explícitamente.
o Se puede aplicar otro tipo de conmutación, pero esto requerirá más consideraciones. Se debe agregar cierta flexibilidad.
5. Señalización de URL de segmento
• Plantilla basada en número
El problema es que, básicamente, se supone que cada segmento tiene el mismo número en cada representación de cada conjunto de adaptación. Se debe tener en cuenta que esto no es un requisito, pero es un supuesto probable en las implementaciones. Si se cambia para tener diferentes tamaños de segmentos en un conjunto de adaptación, deja de existir una correspondencia de numeración.
Por simplicidad, por el momento no se usan números.
• Plantilla basada en tiempo
El problema es que, básicamente, se supone que cada segmento tiene el mismo tiempo en cada representación de cada conjunto de adaptación. Se debe tener en cuenta que esto no es un requisito, pero es un supuesto probable en las implementaciones.
Sin embargo, también se debe tener en cuenta que esto se puede expresar en una línea de tiempo común. Y la línea de tiempo es más adecuada que la numeración para expresar la relación entre diferentes representaciones.
• Lista de segmentos
El problema es que aquí la posición de la lista alinea segmentos y puede darse el caso de que la denominación sea arbitraria. El cliente necesita mantener la correlación exacta de la lista y el orden de cada representación en un conjunto de adaptación.
[0121] Las técnicas de esta divulgación para asignar diferentes piezas según se necesite. El dispositivo servidor 60 y el dispositivo cliente 40 pueden estar configurados de acuerdo con el siguiente enfoque, en algunos ejemplos:
• La línea de tiempo de duración/segmento se asigna a la unidad de entrega, ya que expresa el tiempo cuando el segmento está disponible en el servidor.
o El tiempo puede no ser exacto en términos de tiempo de medios, pero se utiliza para calcular el tiempo de inicio de disponibilidad del segmento.
o Esta temporización puede ser diferente para diferentes representaciones de un conjunto de adaptación. Por ejemplo, puede haber representaciones que están disponibles con más unidades de entrega que otras. Véase análisis de casos de uso.
o Se necesitan instrucciones claras sobre cómo calcular el tiempo de inicio de disponibilidad de segmento en base a las señales anteriores. El modelo existente es eficaz, pero los expertos en la materia deberán asegurarse de usar el modelo existente apropiadamente, si el modelo existente para el cálculo del tiempo de inicio de la disponibilidad del segmento se va a usar de acuerdo con las técnicas de esta divulgación.
o Esto incluye que el tiempo de disponibilidad del segmento se puede ajustar para determinadas representaciones o baseURL según el desplazamiento temporal de la disponibilidad.
o Otro problema importante que se debe aclarar es cómo las duraciones de segmentos irregulares afectan al tiempo de inicio y la señalización de la disponibilidad. En general, los segmentos deberán ser del mismo tamaño. o El acceso aleatorio puede ser diferente en diferentes representaciones.
o Es necesario aclarar si el acceso aleatorio es en términos de temporización solo al comienzo de un segmento o si también podría estar en el medio de un segmento.
o De acuerdo con el modelo 4.2.2, actualmente se halla al comienzo de un segmento, pero esto puede dar como resultado tamaños de segmento irregulares si los puntos de acceso aleatorio están colocados de manera irregular. o Esto afecta de nuevo a la latencia ya que la disponibilidad del segmento es menos predecible.
o Sin embargo, como hipótesis de trabajo, se deberá mantener el modelo 4.2.2 en el que el acceso aleatorio está al comienzo de un segmento.
• El acceso aleatorio se puede señalizar en dos dominios, en el tiempo o en la numeración de segmentos.° Para llegar a una herramienta común, se puede usar un enfoque basado en el tiempo.
• Se analizaron al menos dos enfoques de conmutación en los experimentos básicos:
o Conmutación de flujo de bits:
El cliente DASH desconoce las estructuras internas de las representaciones. Solo sabe dónde puede empalmar representaciones y las provee al descodificador de medios como un único flujo de bits. El codificador se asegura de que las representaciones están codificadas de modo que esta propiedad se satisface en el nivel de encapsulación y flujo de medios.
Esto permitirá básicamente al cliente crear una secuencia/flujo de bits como sigue:
• segmento init para el conjunto de adaptación
• segmento de medios 1 de representación 1
• ...
• segmento de medios X de representación 1
• segmento de medios X+1 de representación 2
• ...
o La conmutación se habilita mediante unas propiedades específicas en los medios. Esto es lo que se hizo en DASH. Se crearon algunas reglas sobre cómo se puede realizar una conmutación en un nivel de reproducción de archivos. La regla básica es que se sabe que si la alineación de segmentos está establecida en true, el inicio con SAP es 1 o 2, y la siguiente secuencia proporciona una conmutación sin interrupciones:
representación de segmento init 1
segmento de medios 1 de representación 1
segmento de medios X de representación 1
representación de segmento init 2
segmento de medios X+1 de representación 2
o Conmutar en GOP abierto u otros aspectos que requieren una comprensión más detallada de un procesamiento de medios.
[0122] Se pueden aplicar ampliaciones y restricciones al archivo de manifiesto 66 (por ejemplo, una MPD) en base al análisis anterior, donde las ampliaciones y restricciones se pueden aplicar a nuevas herramientas). Por ejemplo, se pueden aplicar las siguientes ampliaciones, individualmente o en cualquier combinación:
• Añadir un nuevo atributo @randomAccessPeriod (o cualquier otro medio para expresar el período de acceso aleatorio) que se expresa en la escala de @timescale en el nivel de representación. Cualquier segmento para el cual $Time$ desciende a un múltiplo entero del producto de @timescale y @randomAccessPeriod es un segmento de acceso aleatorio, es decir, permite acceder al conjunto de adaptación de esta representación.
o El acceso aleatorio se puede calificar aún más, por ejemplo, se puede indicar qué tipo de SAP está disponible y en qué período, es decir, un SAP de tipo 1,2 o 3. Se debe tener en cuenta que 3 significará que el tipo de SAP experimentado también puede ser 1 o 2.
• Añadir un nuevo elemento de segmento de medios de conmutación (o cualquier otro medio para expresar la conmutación) con dos atributos en el nivel de conjunto de adaptación (uno o más pueden estar presentes): o @period se expresa en la escala de @timescale. Cualquier posición de tiempo para la cual $Time$ desciende a un múltiplo entero del producto de @timescale y proporciona una oportunidad de conmutación, es decir, permite conmutar a esta representación.
o @type que expresa que el tipo de conmutación está habilitado. Se definen al menos dos tipos, a saber, conmutación de flujo de bits y conmutación de nivel de medios. Se pueden definir otros tipos, tales como la conmutación de GOP abierto.
[0123] Otra forma de expresar dicha conmutación será usar el tipo de descriptor cuando el descriptor expresa el tipo de conmutación y el valor de la frecuencia de conmutación.
• En la línea de tiempo del segmento y el elemento S, proporcionar un atributo adicional @reset, que de forma predeterminada está establecido en false. Un reinicio significa que la periodicidad del período de acceso aleatorio y el período de conmutación se reinicia en este punto. Esto permite que se añadan IDR y la línea de tiempo del segmento se reinicia básicamente en tiempos más arbitrarios.
[0124] El contexto anterior no necesariamente admite el caso de uso en el que las plantillas de segmento proporcionan las disponibilidades de segmento analizadas anteriormente. Para abordar también este caso de uso, se puede añadir la siguiente ampliación:
• Añadir un nuevo elemento de conmutación (o cualquier otro medio o elemento para expresar la conmutación) con dos atributos en el nivel de representación (uno o más pueden estar presentes):
o @period se expresa en la escala de @timescale. Cualquier posición de tiempo para la cual $Time$ desciende a un múltiplo entero del producto de @timescale y proporciona una oportunidad de conmutación, es decir, permite conmutar a esta representación.
o @type que expresa que el tipo de conmutación está habilitado. Se definen al menos dos tipos, a saber, conmutación de flujo de bits y conmutación de nivel de medios. Se pueden definir otros tipos, tales como la conmutación de GOP abierto.
[0125] Se proponen las siguientes restricciones para solicitar el perfil de directo avanzado para habilitar los casos de uso más avanzados:
• Usar una sola @timescale para todas las representaciones de un conjunto de adaptación.
• Usar la línea de tiempo del segmento para señalización de duraciones de segmento (para simplificar).
o Usar solo $Time$ para la señalización del URL (para simplificar ahora).
o La temporización de la duración del segmento es exacta (hipótesis de trabajo, se deben comprender las consecuencias).- La exactitud de la duración del segmento se puede controlar mediante el atributo @timescale en uso (nota), por ejemplo, si la escala de tiempo es solo 1/5 de la tasa de muestreo real, se tiene cierta flexibilidad en la tasa de muestreo exacta.
o La línea de tiempo del segmento es para cada representación para permitir diferentes duraciones de segmento en diferentes representaciones. Sin embargo, puede estar predeterminada en el nivel del conjunto de adaptación.
o La línea de tiempo del segmento puede usar @r (-1) abiertos o @r (> = 0) cerrados.
• La alineación de segmentos y el inicio con SAP se pueden usar para implementaciones retrocompatibles, pero en general no se deberán usar. La señalización siempre se debe proporcionar mediante @randomAccessPeriod y el elemento de conmutación.
• Se debe asegurar que, si un conjunto de adaptación contiene una o más representaciones, se proporcione una lógica de conmutación para el nivel de representación en el conjunto de adaptación.
[0126] Aunque se describe principalmente con respecto a DASH, las técnicas de esta divulgación también se pueden usar para otros formatos de medios, tales como MPEG-2 TS (flujo de transporte) o WebM.
[0127] De esta manera, el dispositivo cliente 40 representa un ejemplo de dispositivo para recuperar datos de medios que comprende uno o más procesadores configurados para recuperar un segmento de medios que se ajusta a al menos uno de un formato de segmento de medios de unidad de entrega, un formato de segmento de medios de acceso aleatorio, un formato de segmento sin superposición o un formato de segmento de medios de conmutación, y procesar el segmento de medios en base, al menos en parte, a si el segmento de medios se ajusta al formato de segmento de medios de unidad de entrega, el formato de segmento de medios de acceso aleatorio, el formato de segmento sin superposición o el formato de segmento de medios de conmutación.
[0128] El dispositivo cliente 40 también representa un ejemplo de dispositivo para recuperar datos de medios que comprende uno o más procesadores configurados para recibir un archivo de manifiesto que incluye datos que indican un patrón para segmentos de medios de diversos tipos en una representación, y recuperar uno o más de los segmentos de medios en base al menos en parte al patrón.
[0129] Además, el dispositivo cliente 40 representa un ejemplo de dispositivo para recuperar datos multimedia que comprende uno o más procesadores configurados para determinar, a partir de un archivo de manifiesto, una pluralidad de tipos de segmentos incluidos en una representación de contenido de medios, una o más funciones proporcionadas por cada uno de los tipos de segmentos y las posiciones de los segmentos que se ajustan a cada uno de los tipos de segmentos de la representación, en el que al menos uno de los tipos de segmentos proporciona un punto en el que comenzar a recuperar datos de la representación, determinar, a partir del archivo de manifiesto, un segmento de la representación que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, y recuperar el segmento determinado de la representación.
[0130] De forma similar, el dispositivo servidor 60 y el dispositivo de preparación de contenido 20 representan ejemplos de dispositivo para enviar datos de medios, comprendiendo el dispositivo uno o más procesadores configurados para formar un segmento de medios que se ajusta a al menos uno de un formato de segmento de medios de unidad de entrega, un formato de segmento de medios de acceso aleatorio, un formato de segmento sin superposición o un formato de segmento de medios de conmutación, y enviar el segmento de medios a un dispositivo cliente.
[0131] El dispositivo servidor 60 y el dispositivo de preparación de contenido 20 también representan ejemplos de dispositivo para enviar datos de medios, comprendiendo el dispositivo uno o más procesadores configurados para enviar un archivo de manifiesto que incluye datos que indican un patrón para segmentos de medios de diversos tipos en una representación a un dispositivo cliente, y enviar, como respuesta a una o más peticiones, uno o más de los segmentos de medios en base, al menos en parte, al patrón al dispositivo cliente.
[0132] El dispositivo servidor 60 y el dispositivo de preparación de contenido 20 también representan ejemplos de dispositivo para señalizar información de medios, incluyendo el dispositivo uno o más procesadores configurados para construir un archivo de manifiesto que indica una pluralidad de tipos de segmentos incluidos en una representación de contenido de medios, una o más funciones proporcionadas por cada uno de los tipos de segmentos, posiciones de segmentos que se ajustan a cada uno de los tipos de segmentos de la representación, en el que al menos uno de los tipos de segmentos proporciona un punto en el que se ha de comenzar a recuperar datos de la representación, y un segmento de la representación que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, enviar el archivo de manifiesto a un dispositivo cliente y, como respuesta a una petición del dispositivo cliente para el segmento que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, enviar el segmento que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación al dispositivo del cliente.
[0133] La FIG. 5A es un diagrama conceptual que ilustra elementos del ejemplo de contenido multimedia 102. El contenido multimedia 102 puede corresponder al contenido multimedia 64 (FIG. 4), o a otro contenido multimedia almacenado en el medio de almacenamiento 62. En el ejemplo de la FIG. 5A, el contenido multimedia 102 incluye una descripción de presentación de medios (MPD) 104 y una pluralidad de representaciones 110A a 110n (representaciones 110). La representación 110A incluye datos de cabecera 112 y segmentos 114A a 114N (segmentos 114) opcionales, mientras que la representación 110N incluye datos de cabecera 122 y segmentos 124A a 124N (segmentos 124) opcionales. La letra N se usa para designar, por razones de conveniencia, el último fragmento de película en cada una de las representaciones 110. En algunos ejemplos, puede haber diferentes números de fragmentos de películas entre las representaciones 110.
[0134] La MPD 104 puede comprender una estructura de datos separada de las representaciones 110. La MPD 104 puede corresponder al archivo de manifiesto 66 de la FIG. 4. Del mismo modo, las representaciones 110 pueden corresponder a las representaciones 68 de la FIG. 4. En general, la MPD 104 puede incluir datos que en general describen características de las representaciones 110, tales como características de codificación y representación, conjuntos de adaptación, un perfil al que corresponde la MPD 104, información de tipo de texto, información de ángulo de cámara, información de calificación, la información de modo truco (por ejemplo, información indicativa de representaciones que incluyen subsecuencias temporales) y/o información para recuperar períodos remotos (por ejemplo, para inserción de publicidad dirigida en el contenido de medios durante la reproducción).
[0135] Los datos de cabecera 112, cuando están presentes, pueden describir características de los segmentos 114, por ejemplo, ubicaciones temporales de puntos de acceso aleatorio (RAP, también denominados puntos de acceso de flujo (SAP)), cuáles de los segmentos 114 incluyen puntos de acceso aleatorio, desplazamientos de bytes a puntos de acceso aleatorio dentro de los segmentos 114, localizadores uniformes de recursos (URL) de los segmentos 114 u otros aspectos de los segmentos 114. Los datos de cabecera 122, cuando están presentes, pueden describir características similares para los segmentos 124. De forma adicional o alternativa, dichas características pueden estar incluidas por completo dentro de la MPD 104.
[0136] Los segmentos 114, 124 incluyen una o más muestras de vídeo codificadas, cada una de las cuales puede incluir tramas o sectores de datos de vídeo. Cada una de las muestras de vídeo codificadas de los segmentos 114 puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Dichas características se pueden describir mediante datos de la MPD 104, aunque dichos datos no se ilustran en el ejemplo de la FIG. 5A. La MPD 104 puede incluir características como se describen en la especificación 3GPP, con la adición de cualquiera o toda la información señalizada descrita en esta divulgación.
[0137] Cada uno de los segmentos 114, 124 puede estar asociado a un único localizador uniforme de recursos (URL). Por tanto, cada uno de los segmentos 114, 124 puede ser independientemente recuperable usando un protocolo de red de transmisión en continuo, tal como DASH. De esta manera, un dispositivo de destino, tal como el dispositivo cliente 40, puede usar una petición GET HTTP para recuperar los segmentos 114 o 124. En algunos ejemplos, el dispositivo cliente 40 puede usar peticiones GET parciales HTTP para recuperar intervalos de bytes específicos de los segmentos 114 o 124.
[0138] La FIG. 5B es un diagrama conceptual que ilustra ejemplos de contenidos de descripción de presentación de medios (MPD) 104 de acuerdo con las técnicas de esta divulgación. En general, entre otros datos señalizados en la MPD 104, en el ejemplo de la FIG. 5B, la MPD 104 incluye información de período 130, información de conjunto de adaptación 132 e información de representación 134A a 134N (información de representación 134). Aunque en este ejemplo solo se muestra un único conjunto de información de conjunto de adaptación 132, se debe entender que, en general, se puede incluir una pluralidad de conjuntos de información de conjunto de adaptación. Del mismo modo, aunque solo se muestra un único conjunto de información de período 130, se deberá entender que, en general, se puede incluir una pluralidad de conjuntos de información de período.
[0139] De acuerdo con las técnicas de esta divulgación, la información de representación 134A incluye información de tipos de segmento 136A, información de funciones de segmento 138A y ubicaciones de segmento 140A. Del mismo modo, la información de representación 134N incluye información de tipos de segmento 136N, información de funciones de segmento 138N y ubicaciones de segmento 140N. En general, la información de tipos de segmento 136A, 136N describe diversos tipos de segmentos incluidos en representaciones correspondientes a información de representación 134A, 134N, respectivamente. Por ejemplo, los tipos de segmento 136A, 136N pueden incluir cualquiera o la totalidad de un tipo (o formato) de segmento de medios de unidad de entrega, un tipo (o formato) de segmento de medios de acceso aleatorio, un tipo (o formato) de segmento sin superposición y un tipo (o formato) de segmento de medios de conmutación.
[0140] La información de funciones de segmento 138A, 138N en general describe funciones desempeñadas por los diversos tipos de segmento. Por ejemplo, la información de funciones de segmento 138A, 138N puede describir funciones desempeñadas por cualquiera o la totalidad de un tipo (o formato) de segmento de medios de unidad de entrega, un tipo (o formato) de segmento de medios de acceso aleatorio, un tipo (o formato) de segmento sin superposición, y un tipo (o formato) de segmento de medios de conmutación, suponiendo que dichos tipos/formatos estén presentes en la información de tipos de segmento correspondiente 136A, 136N. La información de funciones de segmento 138A, 138N puede indicar que un tipo de segmento de medios de unidad de entrega se usa en general para llevar datos de medios, un tipo de segmento de medios de acceso aleatorio se usa para proporcionar un punto de acceso aleatorio (que incluye información de inicialización), un tipo de segmento sin superposición indica que dichos segmentos no se superponen a otros segmentos de la misma representación u otras representaciones, y un tipo de segmento de medios de conmutación permite conmutar entre representaciones dentro del conjunto de adaptación.
[0141] La información de ubicaciones de segmento 140A, 140N en general puede señalizar ubicaciones (o posiciones) de segmentos de los diversos tipos dentro de las representaciones correspondientes. Por ejemplo, la información de ubicaciones de segmento 140A, 140N puede señalizar frecuencias a las que aparecen los segmentos de cada uno del tipo de segmento de medios de unidad de entrega, tipo de segmento de medios de acceso aleatorio, tipo de segmento sin superposición y/o tipo de segmento de medios de conmutación dentro de las representaciones correspondientes. La información de ubicaciones de segmento 140A, 140N puede indicar dicha información en forma de patrón (por ejemplo, cada N-ésimo segmento es un segmento de tipo X). De forma adicional o alternativa, la información de ubicaciones de segmento 140A, 140N puede enumerar explícitamente ubicaciones de segmentos individuales.
[0142] La FIG. 6 es un diagrama de bloques que ilustra elementos de un ejemplo de archivo de vídeo 150, que puede corresponder a un segmento de una representación, tal como uno de los segmentos 114, 124 de la FIG.
5A. Cada uno de los segmentos 114, 124 puede incluir datos que se ajustan sustancialmente a la disposición de datos ilustrada en el ejemplo de la FIG. 6. Se puede decir que el archivo de vídeo 150 encapsula un segmento. Como se describe anteriormente, los archivos de vídeo de acuerdo con el formato de archivo de medios de base ISO y las ampliaciones del mismo almacenan datos en una serie de objetos, denominados "cajas". En el ejemplo de la FIG. 6, el archivo de vídeo 150 incluye la caja de tipo de archivo (FTYP) 152, la caja de película (MOOV) 154, las cajas de índices de segmento (sidx) 162, las cajas de fragmento de película (MOOF) 164 y la caja de acceso aleatorio de fragmento de película (MFRA) 166. Aunque la FIG. 6 representa un ejemplo de archivo de vídeo, se deberá entender que otros archivos de medios pueden incluir otros tipos de datos de medios (por ejemplo, datos de audio, datos de texto temporizado o similares) que están estructurados de forma similar a los datos del archivo de vídeo 150, de acuerdo con el formato de archivo de medios de base ISO y sus ampliaciones.
[0143] La caja de tipo de archivo (FTYP) 152 describe en general un tipo de archivo para el archivo de vídeo 150. La caja de tipo de archivo 152 puede incluir datos que identifican una especificación que describe un mejor uso para el archivo de vídeo 150. La caja de tipo de archivo 152 puede estar colocada de forma alternativa antes de la caja MOOV 154, las cajas de fragmento de película 164 y/o la caja MFRA 166.
[0144] En algunos ejemplos, un segmento, tal como el archivo de vídeo 150, puede incluir una caja de actualización de MPD (no mostrada) antes de la caja FTYP 152. El caja de actualización de MPD puede incluir información que indica que se va a actualizar una MPD correspondiente a una representación que incluye el archivo de vídeo 150, junto con información para actualizar la MPD. Por ejemplo, la caja de actualización de MPD puede proporcionar un URI o URL para un recurso que se va a usar para actualizar la MPD. Como otro ejemplo, la caja de actualización de MPD puede incluir datos para actualizar la MPD. En algunos ejemplos, la caja de actualización de MPD puede seguir inmediatamente a una caja de tipo de segmento (STYP) (no mostrada) del archivo de vídeo 150, donde la caja STYP puede definir un tipo de segmento para el archivo de vídeo 150. La FIG. 7, analizada con mayor detalle a continuación, proporciona información adicional con respecto a la caja de actualización de MPD.
[0145] El caja MOOV 154, en el ejemplo de la FIG. 6, incluye la caja de cabecera de película (MVHD) 156, la caja de pista (TRAK) 158 y uno o más cajas de ampliación de película (MVEX) 160. En general, la caja MVHD 156 puede describir características generales del archivo de vídeo 150. Por ejemplo, la caja MVHD 156 puede incluir datos que describen cuándo se creó originalmente el archivo de vídeo 150, cuándo se modificó por última vez el archivo de vídeo 150, una escala de tiempo para el archivo de vídeo 150, una duración de reproducción para el archivo de vídeo 150 u otros datos que describen en general el archivo de vídeo 150.
[0146] El caja TRAK 158 puede incluir datos para una pista del archivo de vídeo 150. El caja TRAK 158 puede incluir una caja de cabecera de pista (TKHD) que describe las características de la pista correspondiente a la caja TRAK 158. En algunos ejemplos, la caja TRAK 158 puede incluir imágenes de vídeo codificadas, mientras que, en otros ejemplos, las cajas de vídeo codificado de la pista pueden estar incluidas en fragmentos de película 164, se pueden referenciar mediante unos datos de la caja TRAK 158 y/o las cajas SIDX 162.
[0147] En algunos ejemplos, el archivo de vídeo 150 puede incluir más de una pista. Por consiguiente, la caja MOOV 154 puede incluir un número de cajas TRAK igual al número de pistas del archivo de vídeo 150. El caja TRAK 158 puede describir las características de una pista correspondiente del archivo de vídeo 150. Por ejemplo, la caja TRAK 158 puede describir información temporal y/o espacial para la pista correspondiente. Una caja TRAK similar a la caja TRAK 158 de la caja MOOV 154 puede describir características de una pista de conjunto de parámetros, cuando la unidad de encapsulación 30 (FIG. 4) incluye una pista de conjunto de parámetros en un archivo de vídeo, tal como el archivo de vídeo 150. La unidad de encapsulación 30 puede señalizar la presencia de mensajes SEI de nivel de secuencia en la pista de conjunto de parámetros dentro de la caja TRAK que describe la pista de conjunto de parámetros.
[0148] Las cajas MVEX 160 pueden describir características de unos correspondientes fragmentos de película 164, por ejemplo, para señalizar que el archivo de vídeo 150 incluye fragmentos de película 164, además de los datos de vídeo incluidos dentro de la caja MOOV 154, si los hubiera. En el contexto de la transmisión en continuo de datos de vídeo, las imágenes de vídeo codificadas pueden estar incluidas en los fragmentos de película 164 en lugar de en la caja MOOV 154. En consecuencia, todas las muestras de vídeo codificadas pueden estar incluidas en fragmentos de película 164, en lugar de en la caja MOOV 154.
[0149] La caja MOOV 154 puede incluir un número de cajas MVEX 160 iguales al número de fragmentos de película 164 del archivo de vídeo 150. Cada una de las cajas MVEX 160 puede describir características de uno correspondiente de los fragmentos de película 164. Por ejemplo, cada caja MVEX puede incluir una caja de cabecera de ampliación de película (MEHD) que describe una duración temporal para el uno correspondiente de los fragmentos de película 164.
[0150] Como se indica anteriormente, la unidad de encapsulación 30 puede almacenar un conjunto de datos de secuencia en una muestra de vídeo que no incluye datos de vídeo codificados reales. Una muestra de vídeo puede corresponder en general 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 la 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 NAL no VCL asociadas, tales como mensajes SEI. Por consiguiente, la unidad de encapsulación 30 puede incluir un conjunto de datos de secuencia, que puede incluir mensajes SEI de nivel de secuencia, en uno de los fragmentos de película 164. La unidad de encapsulación 30 puede señalizar además la presencia de un conjunto de datos de secuencia y/o de mensajes SEI de nivel de secuencia con la presencia de estos en uno de los fragmentos de película 164 dentro de una de las cajas MVEX 160 correspondiente al uno de los fragmentos de película 164.
[0151] Las cajas SIDX 162 son elementos opcionales del archivo de vídeo 150. Es decir, los archivos de vídeo que se ajustan al formato de archivo 3GPP u otros formatos de archivo de este tipo, no incluyen necesariamente cajas SIDX 162. De acuerdo con el ejemplo del formato de archivo 3GPP, se puede usar una caja SIDX para identificar un subsegmento de un segmento (por ejemplo, un segmento contenido dentro del archivo de vídeo 150). El formato de archivo 3GPP define un subsegmento como "un conjunto autónomo de una o más cajas de fragmento de película consecutivos con una(s) caja(s) de datos de medios correspondiente(s), y una caja de datos de medios que contiene datos referenciados por una caja de fragmento de película debe seguir esa caja de fragmento de película y preceder a la siguiente caja de fragmento de película que contiene información sobre la misma pista". El formato de archivo 3GPP también indica que una caja SIDX "contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por la caja. Los subsegmentos referenciados son contiguos en el tiempo de presentación. De forma similar, los bytes a los que una caja de índice de segmento hace referencia siempre son contiguos dentro del segmento. El tamaño referenciado da el recuento del número de bytes en el material referenciado".
[0152] Las cajas SIDX 162 en general proporcionan información representativa de uno o más subsegmentos de un segmento incluido en el archivo de vídeo 150. Por ejemplo, dicha información puede incluir tiempos de reproducción en los que comienzan y/o terminan los subsegmentos, desplazamientos de bytes para los subsegmentos, si los subsegmentos incluyen (por ejemplo, comienzan con) un punto de acceso de flujo (SAP), un tipo para el SAP (por ejemplo, si el SAP es una imagen de actualización de descodificador instantánea (IDR), una imagen de acceso aleatorio limpio (CRA), una imagen de acceso de enlace roto (BLA) o similares), una posición del SAP (en términos de tiempo de reproducción y/o desplazamiento de bytes) en el subsegmento y similares.
[0153] Los fragmentos de película 164 pueden incluir una o más imágenes de vídeo 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 vídeo codificadas, por ejemplo, tramas o imágenes. Además, como se describe anteriormente, los fragmentos de película 164 pueden incluir conjuntos de datos de secuencia en algunos ejemplos. Cada uno de los fragmentos de película 164 puede incluir una caja de cabecera de fragmento de película (MFHD, no mostrada en la FIG. 6). La caja MFHD puede describir características del fragmento de película correspondiente, tales como un número de secuencia para el fragmento de película. Los fragmentos de película 164 pueden estar incluidos en orden de número de secuencia en el archivo de vídeo 150.
[0154] La caja MFRA 166 puede describir puntos de acceso aleatorio dentro de fragmentos de película 164 del archivo de vídeo 150. Esto puede ayudar a realizar modos de truco, tales como realizar búsquedas hasta ubicaciones temporales en particular (es decir, tiempos de reproducción) dentro de segmento encapsulado por el archivo de vídeo 150. La caja MFRA 166 en general es opcional y no necesita estar incluida en los archivos de vídeo, en algunos ejemplos. Del mismo modo, un dispositivo cliente, tal como el dispositivo cliente 40, no tiene necesariamente que referenciar la caja MFRA 166 para descodificar y visualizar correctamente los datos de vídeo del archivo de vídeo 150. La caja MFRA 166 puede incluir un número de cajas de acceso aleatorio de fragmento de pista (TFRA) (no mostradas) igual al número de pistas del archivo de vídeo 150 o, en algunos ejemplos, igual al número de pistas de medios (por ejemplo, pistas no de indicaciones) del archivo de vídeo 150.
[0155] En algunos ejemplos, los fragmentos de película 164 pueden incluir uno o más puntos de acceso de flujo (SAP), tales como imágenes IDR. Del mismo modo, la caja MFRA 166 puede proporcionar indicaciones de ubicaciones dentro del archivo de vídeo 150 de los SAP. En consecuencia, se puede formar una subsecuencia temporal del archivo de vídeo 150 a partir de los SAP del archivo de vídeo 150. La subsecuencia temporal también puede incluir otras imágenes, tales como tramas P y/o tramas B que dependen de los SAP. Las tramas y/o sectores de la subsecuencia temporal pueden estar dispuestos dentro de los segmentos de modo que las tramas/sectores de la subsecuencia temporal que dependen de otras tramas/sectores de la subsecuencia pueden descodificarse apropiadamente. Por ejemplo, en la disposición jerárquica de los datos, los datos usados para predicción para otros datos también pueden estar incluidos en la subsecuencia temporal.
[0156] El perfil de directo avanzado es un nuevo perfil previsto que se centra en la distribución de servicios en directo. El perfil anticipado no se considera necesariamente retrocompatible con el perfil común ampliado. Sin embargo, se considera que un proveedor de contenido puede generar una versión retrocompatible del contenido compatible si se considera esencial. Las figuras analizadas a continuación representan diversos casos de uso en los que se pueden aplicar las técnicas de esta divulgación.
[0157] La FIG. 7 es un diagrama conceptual que ilustra un ejemplo de oferta de segmento para un caso de uso de acuerdo con las técnicas de esta divulgación. En particular, la FIG. 7 ilustra un conjunto de adaptación 230, que incluye la representación 232 y la representación 234. La representación 232 incluye los segmentos 236A a 236E, que incluyen el segmento IDR 236A y el segmento IDR 236E, mientras que la representación 234 incluye los segmentos 238A a 238A, que incluyen el segmento IDR 238A y el segmento IDR 238E.
[0158] Este caso de uso incluye servicios de transmisión en continuo de vídeo de baja latencia y conmutación. Se va a suponer que un segmento tiene una duración de 0,5 segundos (en términos de tiempo de reproducción) y que la tasa de tramas es de 50 tramas por segundo (FPS). En este ejemplo, y en base a las técnicas de esta divulgación, la configuración y la señalización pueden ser como sigue:
• Cada cuarto segmento es un segmento de conmutación/IDR (actualización de descodificador instantánea)
• Cada segmento es una unidad de entrega
[0159] La señalización puede ser como sigue para el conjunto de adaptación 230 de acuerdo con la FIG. 7: • AdaptationSet
o @timescale = 50
o SegmentTimeline.S: @t=0, @d=25, @r=-1
o @randomAccessPeriod = 100
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID$” /segment $Time$.mp4 Representation: @id=232
Representation: @id=234
[0160] Otro caso de uso de acuerdo con las técnicas de esta divulgación que incluyen servicios de transmisión en continuo de vídeo de baja latencia y conmutación se describe con respecto a la FIG. 1. La FIG. 1 ilustra la oferta de segmento en el caso de este caso de uso. Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización para este caso de uso pueden ser como sigue:
• Cada segmento es un segmento de acceso aleatorio.
• Los segmentos en una representación de radiodifusión tienen un tamaño cuatro veces más grande que los de una representación de unidifusión.
• El segmento en la posición de la superposición de radiodifusión/unidifusión es un segmento de conmutación.
[0161] La señalización puede ser como sigue para el conjunto de adaptación 230 de acuerdo con la FIG. 7: • AdaptationSet
o @timescale = 50
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID$” /segment_$Time$.mp4 Representation: @id=1, @randomAccessPeriod = 100
• SegmentTimeline.S: @t=0, @d=100, @r=-1
• Representation: @id=2, @randomAccessPeriod = 25
• SegmentTimeline.S: @t=0, @d=25, @r=-1
[0162] La FIG. 8 es un diagrama conceptual que ilustra un caso de uso que incluye una sintonización rápida con la HEVC escalable (SHVC) de acuerdo con las técnicas de esta divulgación. El ejemplo de la FIG. 8 ilustra el conjunto de adaptación 240 que incluye una representación de capa base (unidifusión) 242 y una representación de capa de mejora (radiodifusión) 244. La representación de capa de base 242 incluye los segmentos 246A a 246E (segmentos 246), mientras que la representación de capa de mejora 244 incluye los segmentos 248A, 248B (segmentos 248). Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas descritas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada uno de los segmentos 246, 248 es un segmento de acceso aleatorio (aunque el segmento 246A que se muestra en la FIG. 8 incluye una IDR, el punto de acceso aleatorio no está necesariamente limitado a la iDr , ya que puede haber otros puntos de entrada funcionales. Puede bastar con unos GOP abiertos).
• Los segmentos 248 en la representación de capa de mejora 244 (es decir, la representación de radiodifusión) tienen una duración temporal cuatro veces mayor que la de los segmentos 246 en la representación de capa de base 242 (es decir, la representación de unidifusión).
[0163] La señalización puede ser como sigue para el conjunto de adaptación 240 de acuerdo con el ejemplo de la FIG. 8:
• AdaptationSet
o @timescale = 50
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID$”/se gment_$Time$.mp4 Representation: @id=242, @randomAccessPeriod = 25
• SegmentTimeline.S: @t=0, @d=25, @r=-1
Representation: @id=244, @randomAccessPeriod = 100, @dependencyID=242
• SegmentTimeline.S: @t=0, @d=100, @r=-1
[0164] La FIG. 9 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye una sintonización rápida con un punto de acceso de flujo (SAP) de tipo 3 de acuerdo con las técnicas de esta divulgación. En particular, en el ejemplo de la FIG. 9, el conjunto de adaptación 254 incluye la representación 250, que incluye los segmentos 252A a 252E, cada uno de los cuales incluye un GOP abierto. Aunque no se muestra en la FIG. 9, el conjunto de adaptación 254 puede incluir representaciones adicionales a la representación 250. Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. La señalización puede ser como sigue para el conjunto de adaptación 254 de acuerdo con el ejemplo de la FIG. 9:
• AdaptationSet
o @timescale = 50
o @randomAccessPeriod = 25
o SegmentTimeline.S: @t=0, @d=25, @r=-1
o SegmentTemplate@media=“http://example.com/$RepresentationID$7 segment $Time$.mp4 Representation: @id=250
[0165] La FIG. 10 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye una sintonización rápida e hibridación. En particular, en este ejemplo, el conjunto de adaptación 260 incluye la representación 262 y la representación 264. La representación 262 incluye los segmentos 266A a 266F (segmentos 266), mientras que la representación 264 incluye los segmentos 268A a 268F (segmentos 268). Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada segmento es un segmento de acceso aleatorio.
• Cada cuarto segmento es un segmento de conmutación para conmutación de medios.
[0166] La señalización puede ser como sigue para el conjunto de adaptación 260 de acuerdo con la FIG. 10:
• AdaptationSet
o @timescale = 50
o SegmentTimeline.S: @t=0, @d=25, @r=-1
o @randomAccessPeriod = 25
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID$”/se gment_$Time$.mp4 Representation: @id=262
Representation: @id=264
[0167] La FIG. 11 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye sintonización rápida, hibridación y GOP abiertos. En la FIG. 11, se muestra la misma oferta de segmento que la de la FIG. 10. Además, el ejemplo de la FIG. 11 ilustra la transversal de segmento 270, que representa segmentos recuperados por un dispositivo cliente, tal como el dispositivo cliente 40 (FIG. 1). Es decir, el dispositivo cliente 40 puede recuperar originalmente el segmento 266A de la representación 262 y, a continuación, conmutar a la representación 264 (por ejemplo, debido a un cambio en el ancho de banda de red disponible). Para conmutar, el dispositivo cliente 40 puede recuperar el segmento 268B. En este ejemplo, el segmento 266A es un segmento IDR, mientras que el segmento 268B es un segmento GOP abierto. De acuerdo con las técnicas de esta divulgación, dado que el segmento 268B es un segmento GOP abierto, el dispositivo cliente 40 puede efectuar la conmutación en 268B, sin esperar un segmento IDR (por ejemplo, el segmento 268E) de la representación 264. El dispositivo cliente 40 también recupera el segmento 268C de la representación 264. Posteriormente, el dispositivo cliente 40 vuelve a conmutar representaciones, esta vez a la representación 262, recuperando el segmento 266D, que también es un segmento GOP abierto. En este ejemplo, el dispositivo cliente 40 recupera los segmentos 266E y 266F de la representación 262, de acuerdo con la transversal de segmento 270.
[0168] La conmutación se puede producir en los SAP de tipo 3. Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada segmento es un segmento de acceso aleatorio.
• Cada cuarto segmento es un segmento de conmutación para conmutación de medios.
• Cada segmento es un segmento de conmutación para la conmutación de GOP abierto.
[0169] La señalización puede ser como sigue para el conjunto de adaptación 260 de acuerdo con la FIG. 11:
• AdaptationSet
o @timescale = 50
o SegmentTimeline.S: @t=0, @d=25, @r=-1
o @randomAccessPeriod = 25
o Switching: @period=100, @type=“media”
o Switching: @period=25, @type=“open GOP”
o SegmentTemplate@media=“http://example.com/$RepresentationID $”/segment_$Time$.mp4 Representation: @id=262
Representation: @id=264
[0170] La FIG. 12 es un diagrama conceptual que ilustra otro ejemplo de caso de uso que incluye sintonización rápida e hibridación con GOP abiertos. En este ejemplo, el conjunto de adaptación 280 incluye la representación de unidifusión 282 y la representación de radiodifusión 284. La representación de unidifusión 282 incluye los segmentos 286A a 286F (segmentos 286), mientras que la representación de radiodifusión 284 incluye los segmentos 288A, 288B (segmentos 288). Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada segmento es un segmento de acceso aleatorio.
• Los segmentos 288 de la representación de radiodifusión 284 tienen una duración 4 veces mayor que la de los segmentos 286 de la representación de unidifusión 282.
• Los segmentos en las posiciones de superposición de radiodifusión/unidifusión (por ejemplo, los segmentos 286A, 286E, 288A, 288B) son segmentos de conmutación.
[0171] La señalización puede ser como sigue para el conjunto de adaptación 280 de acuerdo con la FIG. 12:
• AdaptationSet
o @timescale = 50
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID $”/segment_$Time$.mp4 Representation: @id=282, @randomAccessPeriod = 100
• SegmentTimeline.S: @t=0, @d=100, @r=-1
Representation: @id=284, @randomAccessPeriod = 25
o SegmentTimeline.S: @t=0, @d=25, @r=-1
[0172] La FIG. 13 es un diagrama conceptual que ilustra un ejemplo de caso de uso que incluye sintonización rápida y latencia muy baja. En este ejemplo, el conjunto de adaptación 290 incluye la representación de unidifusión 292 y la representación de radiodifusión 294. La representación de unidifusión 292 incluye los segmentos 296A a 296F (segmentos 296), mientras que la representación de radiodifusión 294 incluye los segmentos 298A, 298B (segmentos 298). Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada segmento es un segmento de acceso aleatorio.
• Los segmentos 298 de la representación de radiodifusión 294 tienen una duración 4 veces mayor que la de los segmentos 296 de la representación de unidifusión 292.
• Los segmentos en las posiciones de superposición de radiodifusión/unidifusión (por ejemplo, los segmentos 296A, 296E, 298A, 298B) son segmentos de conmutación.
[0173] Además, no todos los segmentos 296 de la representación 292 proporcionan información para la conmutación. Por ejemplo, el segmento 296C permite conmutar de la representación de radiodifusión 294 a la representación de unidifusión 292 (por ejemplo, si el servicio de radiodifusión deja de estar disponible). Sin embargo, los segmentos 296B, 296D y 296F se ajustan a un formato de segmento de medios de unidad de entrega y no incluyen puntos de conmutación. Esto permite que se asignen más bits de los segmentos 296B, 296D y 296F a tramas de no intrapredicción (por ejemplo, tramas de interpredicción), por ejemplo, de modo que estas tramas se pueden codificar con una calidad superior.
[0174] La señalización puede ser como sigue para el conjunto de adaptación 290 de acuerdo con la FIG. 13:
• AdaptationSet
o @timescale = 50
o Switching: @period=100, @type=“media”
o SegmentTemplate@media=“http://example.com/$RepresentationID $”/segment_$Time$.mp4 Representation: @id=292, @randomAccessPeriod = 100
• SegmentTimeline.S: @t=0, @d=100, @r=-1
Representation: @id=294, @randomAccessPeriod = 50
• SegmentTimeline.S: @t=0, @d=25, @r=-1
[0175] La FIG. 14 es un diagrama conceptual que ilustra otro ejemplo de caso de uso que incluye sintonización rápida y latencia muy baja. En este ejemplo, el conjunto de adaptación 300 incluye la representación 302 y la representación 304. La representación 302 incluye los segmentos 306A a 306F (segmentos 306), mientras que la representación 304 incluye los segmentos 308A a 308F (segmentos 308). Se va a suponer que un segmento corto tiene una duración de 0,5 segundos y que la tasa de tramas es de 50 FPS. En base a las técnicas analizadas anteriormente, la configuración y la señalización pueden ser como sigue:
• Cada uno de los segmentos 306 de la representación 302 es un segmento de acceso aleatorio.
[0176] Es decir, como se muestra en la FIG. 14, cada uno de los segmentos 306 incluye una imagen IDR. Sin embargo, los segmentos 308A y 308E de representación 304 incluyen imágenes IDR, mientras que los segmentos 308B, 308C, 308D y 308F no incluyen imágenes IDR. Esto permite que un dispositivo cliente, tal como el dispositivo cliente 40 (FIG. 1) sintonice rápidamente con el contenido de medios del conjunto de adaptación 300 recuperando uno de los segmentos 306 disponibles más recientemente y, a continuación, conmutando a la representación 304 cuando uno siguiente de los segmentos 308 que incluye una IDR está disponible.
[0177] La señalización puede ser como sigue para el conjunto de adaptación 300 de acuerdo con la FIG. 14:
• AdaptationSet
o @timescale = 50
o Switching: @period=100, @type=“media”
o SegmentTimeline.S: @t=0, @d=25, @r=-1
o SegmentTemplate@media=“http://example.com/$RepresentationID $”/segment_$Time$.mp4 Representation: @id=302, @randomAccessPeriod = 25
• Switching: @period=25, @type=“media”
Representation: @id=304, @randomAccessPeriod = 100
• Switching: @period=100, @type=“media”
[0178] De esta manera, las técnicas de esta divulgación incluyen
• Nuevos tipos de segmento adicionales.
• Señalización MPD adicional para conmutación y @randomAccessPeriod.
• Definiciones para diferentes tipos de conmutación.
o Conmutación de medios: Alineación de segmentos y tipo 1 o 2 de SAP.
o Conmutación de flujo de bits: se permite la concatenación.
o Conmutación de GOP abierto.
• Añadir un perfil que documenta las ampliaciones y restricciones.
• Documentar cualquier problema de retrocompatibilidad.
• Proporcionar ejemplos más detallados.
[0179] Quedan preguntas abiertas y alternativas. Los siguientes problemas permanecen abiertos:
• La señalización basada en números como adición o alternativa a las técnicas de esta divulgación es posible, lo que puede proporcionar determinadas implicaciones y beneficios.
• También son posibles diferentes tipos de conmutación de GOP abierto como adición o alternativa a las técnicas de esta divulgación, que pueden ser remuestreo paralelo y no remuestreo.
• Se pueden usar formatos de medios adicionales o alternativos con respecto a los analizados anteriormente. • Los subsegmentos, de forma adicional o alternativa a los segmentos completos, también se pueden usar en algunos ejemplos. Una caja de índice de segmento (SIDX) como se muestra en la FIG. 6 anterior puede señalizar la ubicación de los subsegmentos, y/o se puede señalizar información adicional (por ejemplo, en metadatos de archivo y/o en un archivo de manifiesto, tal como en una MPD).
[0180] La FIG. 15 es un diagrama de flujo que ilustra un ejemplo de procedimiento para recuperar un segmento de una representación de contenido de medios de acuerdo con las técnicas de esta divulgación. El procedimiento de la FIG. 15 que se describe es realizado por el dispositivo servidor 60 y el dispositivo cliente 40 de la FIG. 4. Sin embargo, se debe entender que el procedimiento puede ser realizado por otros dispositivos. Por ejemplo, la totalidad o unas partes del procedimiento atribuido al dispositivo servidor se pueden realizar mediante el dispositivo de preparación de contenido 20 de la FIG. 4 (por ejemplo, de forma adicional o alternativa al dispositivo servidor 60 de la FIG. 4). Del mismo modo, la totalidad o unas partes del procedimiento atribuido al dispositivo cliente se pueden realizar mediante una unidad de middleware del dispositivo cliente que está configurada para recibir datos de medios por medio de una transmisión de radiodifusión y/o unidifusión.
[0181] En este ejemplo, el dispositivo servidor 60 recibe inicialmente un flujo de medios codificado (320). En algunos ejemplos, el dispositivo servidor 60 recibe el flujo de medios codificado desde el dispositivo de preparación de contenido 20, mientras que en otros ejemplos, el dispositivo servidor 60 puede incluir uno o más codificadores para codificar datos de medios sin procesar para formar el flujo de medios codificado.
[0182] A continuación, el dispositivo servidor 60, en este ejemplo, determina los tipos y las ubicaciones de los segmentos dentro del flujo de medios codificado (322). En algunos ejemplos, el dispositivo servidor 60 puede formar los segmentos (es decir, archivos recuperables independientemente), mientras que en otros ejemplos, el dispositivo servidor 60 puede recibir y analizar los segmentos como parte del flujo de medios codificado, y determinar tipos para los segmentos en base a sus características. Anteriormente, se han analizado las características de diversos tipos de segmentos, tales como segmentos de medios de unidad de entrega, segmentos de medios de acceso aleatorio, segmentos sin superposición y segmentos de medios de conmutación. Por tanto, el dispositivo servidor 60 puede analizar cada segmento para determinar cuál de estos tipos de segmento coincide con las características del segmento que se analiza. Además, el dispositivo servidor 60 puede determinar las ubicaciones de los segmentos de cada tipo dentro del flujo de medios codificado. Por ejemplo, el dispositivo servidor 60 puede determinar las frecuencias a las que aparece cada tipo de segmento. Como ejemplo, con respecto a la FIG. 7, los segmentos que incluyen una iDr (es decir, los segmentos de medios de acceso aleatorio) aparecen cada cuarto segmento de cada una de las representaciones 232, 234.
[0183] En este ejemplo, el dispositivo servidor 60 construye a continuación un archivo de manifiesto (tal como una MPD) que señaliza los tipos y las ubicaciones de los segmentos (324). De forma alternativa, el dispositivo servidor 60 puede recibir el archivo de manifiesto, parcial o totalmente construido de acuerdo con las técnicas de esta divulgación, desde el dispositivo de preparación de contenido 20. El dispositivo servidor 60 puede construir el archivo de manifiesto para que incluya información (es decir, "señalice") los tipos y las ubicaciones de los segmentos dentro de cada representación correspondiente de cada conjunto de adaptación representado por el archivo de manifiesto. El dispositivo servidor 60 puede construir el archivo de manifiesto para que incluya datos similares a los analizados anteriormente con respecto a los ejemplos de las FIGS. 7 a 14. Se deberá entender que el archivo de manifiesto está separado de las representaciones y los datos de medios de las propias representaciones. Por ejemplo, el archivo de manifiesto puede estar disponible para su petición por separado de las peticiones realizadas para los datos de medios (por ejemplo, segmentos o partes de segmentos) descritos por el archivo de manifiesto.
[0184] El dispositivo servidor 60 puede, a continuación, enviar el archivo de manifiesto (326), por ejemplo, al dispositivo cliente 40. En algunos ejemplos, el dispositivo cliente 40 puede solicitar inicialmente el archivo de manifiesto, por ejemplo, por medio de una petición de unidifusión para el archivo de manifiesto. En otros ejemplos, el dispositivo cliente 40 se puede abonar a una transmisión de radiodifusión, y el dispositivo servidor 60 puede facilitar periódicamente el archivo de manifiesto por medio de la radiodifusión. En cualquier caso, el dispositivo cliente 40 puede recibir el archivo de manifiesto (328) que el dispositivo servidor 60 ha facilitado.
[0185] A continuación, el dispositivo cliente 40 puede determinar los tipos y las ubicaciones de los segmentos a partir del archivo de manifiesto (330). Por ejemplo, el dispositivo cliente 40 puede determinar que el archivo de manifiesto indica que un conjunto de adaptación en particular incluye representaciones que incluyen, por ejemplo, segmentos de medios de unidad de entrega, segmentos de medios de acceso aleatorio, segmentos sin superposición y segmentos de medios de conmutación. El dispositivo cliente 40 también puede determinar las ubicaciones de cada uno de estos tipos de segmentos. Por ejemplo, el dispositivo cliente 40 puede determinar las frecuencias a las que aparecen la totalidad o una parte de estos tipos de segmentos a partir del archivo de manifiesto.
[0186] El dispositivo cliente 40 puede determinar una de las representaciones a partir de la cual se ha de comenzar a recuperar datos de medios. El dispositivo cliente 40 puede realizar cualquiera de los diversos casos de uso analizados anteriormente. Para lograr una reproducción de baja latencia, el dispositivo cliente 40 puede determinar cuál de las representaciones, si la hubiera, tiene los segmentos más frecuentes que incluyen puntos de acceso de flujo (SAP), por ejemplo, tramas IDR. Dicha representación puede incluir segmentos disponibles para recuperación por medio de unidifusión. El dispositivo cliente 40 puede estar configurado para recuperar inicialmente dichos segmentos a partir de la representación de unidifusión y, a continuación, para conmutar a una representación de radiodifusión en el siguiente SAP disponible de la representación de radiodifusión (de nuevo, como se indica en el archivo de manifiesto).
[0187] En cualquier caso, el dispositivo cliente 40 puede determinar un segmento de una representación que proporciona un punto de partida (332). Como se analiza anteriormente, el segmento puede comprender un segmento de medios de acceso aleatorio, es decir, ajustarse a un formato de segmento de medios de acceso aleatorio. Del mismo modo, el dispositivo cliente 40 puede determinar un localizador uniforme de recursos (URL) para el segmento determinado, por ejemplo, de acuerdo con una plantilla especificada por el archivo de manifiesto. El dispositivo cliente 40 puede, a continuación, solicitar el segmento determinado (334), por ejemplo, presentando una petición Get o Get parcial HTTP para el URL al dispositivo servidor 60.
[0188] El dispositivo servidor 60 puede, a continuación, recibir la petición (336) y, a continuación, enviar el segmento solicitado al dispositivo cliente 40 (338) como respuesta a la petición. Después de recibir el segmento (340), el dispositivo cliente 40 puede inicialmente almacenar temporalmente los datos del segmento recibido y, por último, descodificar y presentar los datos del segmento recibido (342).
[0189] Como se analiza anteriormente, después de recuperar inicialmente el segmento determinado de la representación, el dispositivo cliente 40 puede determinar si ha de conmutar a una representación diferente y cuándo ha de hacerlo. Por ejemplo, la representación inicial puede incluir unos SAP muy frecuentes, y una representación objetivo puede incluir unos SAP relativamente infrecuentes. El dispositivo cliente 40 puede continuar solicitando segmentos de la representación inicial hasta alcanzar un segmento que incluye un SAP (por ejemplo, un segmento de medios de acceso aleatorio o un segmento de medios de conmutación) de la representación objetivo. A continuación, el dispositivo cliente 40 puede comenzar a solicitar segmentos de la representación objetivo (si la representación objetivo está disponible por medio de unidifusión) o abonarse a un servicio de radiodifusión que está transportando datos de medios de la representación objetivo (si la representación objetivo está disponible a través de radiodifusión).
[0190] De esta manera, la FIG. 15 representa un ejemplo de procedimiento que incluye determinar, a partir de un archivo de manifiesto, una pluralidad de tipos de segmentos incluidos en una representación de contenido de medios, una o más funciones proporcionadas por cada uno de los tipos de segmentos y posiciones de segmento que se ajustan a cada uno los tipos de segmentos de la representación, en el que al menos uno de los tipos de segmentos proporciona un punto en el que se ha de comenzar a recuperar datos de la representación, determinar, a partir del archivo de manifiesto, un segmento de la representación que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, y recuperar el segmento determinado de la representación.
[0191] La FIG. 15 también representa un ejemplo de procedimiento que incluye construir un archivo de manifiesto que indica una pluralidad de tipos de segmentos incluidos en una representación de contenido de medios, una o más funciones proporcionadas por cada uno de los tipos de segmentos, posiciones de segmentos que se ajustan a cada uno de los tipos de segmentos de la representación, en el que al menos uno de los tipos de segmentos proporciona un punto en el que se ha de comenzar a recuperar datos de la representación, y un segmento de la representación que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, enviar el archivo de manifiesto a un dispositivo cliente y, como respuesta a una petición del dispositivo cliente para el segmento que se ajusta al tipo que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación, enviar el segmento que proporciona el punto en el que se ha de comenzar a recuperar datos de la representación al dispositivo cliente.
[0192] En uno o más ejemplos, las funciones descritas se pueden implementar en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador, como una o más instrucciones o código, y ejecutar 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 unos medios de almacenamiento de datos, o unos medios de comunicación que incluyen cualquier medio que facilita la transferencia de un programa informático de un lugar a otro, por ejemplo, de acuerdo con un protocolo de comunicación. De esta manera, los medios legibles por ordenador pueden corresponder, en general, a (1) unos medios de almacenamiento tangibles y legibles por ordenador que son no transitorios o (2) un medio de comunicación tal como una señal o una onda portadora. Los medios de almacenamiento de datos pueden ser medios disponibles cualesquiera a los que se puede acceder desde uno o más ordenadores o uno o más procesadores para recuperar instrucciones, código 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.
[0193] A modo de ejemplo, y no de limitación, dichos medios de almacenamiento legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que se pueda usar para almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Asimismo, cualquier conexión recibe apropiadamente la denominación de medio legible por ordenador. Por ejemplo, si las instrucciones se transmiten desde un sitio web, un servidor u otra fuente remota usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o unas tecnologías inalámbricas tales 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 están incluidas en la definición de medio. Sin embargo, se deberá entender 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, sino que, en cambio, están dirigidos a medios de almacenamiento no transitorio tangibles. El término disco, como se usa en el presente documento, incluye disco compacto (CD), disco láser, disco óptico, disco versátil digital (DVD), disco flexible y disco Blu-ray, de los cuales el disco flexible reproduce normalmente datos magnéticamente, mientras que los demás discos reproducen datos ópticamente con láseres. Las combinaciones de los anteriores se deberán incluir también dentro del alcance de los medios legibles por ordenador.
[0194] Las instrucciones se pueden ejecutar mediante uno o más procesadores, tales como uno o más procesadores de señales digitales (DSP), microprocesadores de propósito general, circuitos integrados específicos de la aplicación (ASIC), matrices lógicas programables in situ (FPGA) u otros circuitos lógicos equivalentes, integrados o discretos. En consecuencia, el término "procesador", como se usa en el presente documento, se puede referir a cualquier estructura anterior o a cualquier otra estructura adecuada para la implementación de las técnicas descritas en el presente documento. Además, en algunos aspectos, la funcionalidad descrita en el presente documento se puede proporcionar dentro de módulos de hardware y/o software dedicados, configurados para la codificación y la descodificación, o incorporar en un códec combinado. Asimismo, las técnicas se pueden implementar totalmente en uno o más circuitos o elementos lógicos.
[0195] Las técnicas de esta divulgación se pueden implementar en una amplia variedad de dispositivos o aparatos, incluyendo un microteléfono inalámbrico, un circuito integrado (CI) o un conjunto de CI (por ejemplo, un conjunto de chips). Diversos componentes, módulos o unidades se describen en esta divulgación para destacar aspectos funcionales de dispositivos configurados para realizar las técnicas divulgadas, aunque no se requiere necesariamente su realización mediante diferentes unidades de hardware. En cambio, como se describe anteriormente, diversas unidades se pueden combinar en una unidad de hardware de códec o proporcionar mediante un grupo de unidades de hardware interoperativas, que incluye uno o más procesadores, como se describe anteriormente, junto con software y/o firmware adecuados.
[0196] Se han descrito diversos ejemplos. Estos y otros ejemplos están dentro del alcance de las siguientes reivindicaciones.

Claims (13)

REIVINDICACIONES
1. Un procedimiento de recuperación de datos de medios, comprendiendo el procedimiento:
recibir (328), desde un dispositivo servidor (60), un archivo de manifiesto (66) que comprende información que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación (68A a N) de un contenido de medios (64) se ajusta, en el que la pluralidad de tipos de segmentos de medios incluye:
un formato de segmento de medios de unidad de entrega (202), en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene uno o más fragmentos de película autónomos completos;
un formato de segmento de medios de acceso aleatorio (204), en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) se ajusta al formato de segmento de medios de unidad de entrega (202), y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1,2 o 3;
un formato de segmento de medios sin superposición (206), en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición (206) se ajusta al formato de segmento de medios de unidad de entrega (202) y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación (68A a N) y otros segmentos de otras representaciones (68A a N) de un conjunto de adaptación que incluye la representación (68A a N); y
un formato de segmento de medios de conmutación (208), en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación (208) se ajusta al formato de segmento de medios de acceso aleatorio (204), y en el que la primera muestra del primer fragmento de película es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios basado en ISO de tipo 1 o 2;
determinar (330), a partir de dicha información, a qué tipo de la pluralidad de tipos de segmentos de medios incluidos en la representación (68A a B) del contenido de medios (64) se ajustan; y
usar dicho tipo determinado para recuperar (334, 340) segmentos de medios de dicho flujo de contenido de medios (64) desde el dispositivo servidor (60).
2. Un procedimiento de señalización de información de medios para la recuperación de segmentos de medios de un contenido de medios (64), comprendiendo el procedimiento:
construir (324) un archivo de manifiesto (66) que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación (68A a N) del contenido de medios (64) se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye:
un formato de segmento de medios de unidad de entrega (202), en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene uno o más fragmentos de película autónomos completos;
un formato de segmento de medios de acceso aleatorio (204), en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) se ajusta al formato de segmento de medios de unidad de entrega (202), y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1,2 o 3;
un formato de segmento de medios sin superposición (206), en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición (206) se ajusta al formato de segmento de medios de unidad de entrega (202) y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación (68A a N) y otros segmentos de otras representaciones (68A a N) de un conjunto de adaptación que incluye la representación (68A a N); y
un formato de segmento de medios de conmutación (208), en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación (208) se ajusta al formato de segmento de medios de acceso aleatorio (204), y en el que la primera muestra del primer fragmento de película es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2;
enviar (326) el archivo de manifiesto (66) a un dispositivo cliente (40); y
como respuesta a una petición (336) del dispositivo cliente (40) para un segmento de medios que se ajusta a uno de la pluralidad de tipos de segmentos de medios, enviar (338) un segmento de medios que se ajusta al tipo de segmento de medios al dispositivo cliente (40).
3. El procedimiento de la reivindicación 1 o la reivindicación 2, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene un valor de "dums" en una caja de tipo de segmento del segmento,
cada uno de los fragmentos de película autónomos comprende una caja de fragmento de película, "moof", y una caja de datos de medios, "mdat", que contiene muestras de medios que no usan referencias de datos externas referenciadas por una pista en la caja de fragmento de película, cada una de las cajas moof contiene al menos un fragmento de pista, cada una de las cajas moof no usa referencias externas, un señalizador "default-base-is-moof 'del segmento de medios está establecido en true y un señalizador " base-data-offset-present" del segmento de medios está establecido en false.
4. El procedimiento de la reivindicación 1 o la reivindicación 2, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) incluye toda la información necesaria para acceder a datos de medios en un flujo de bits que sigue a los segmentos.
5. El procedimiento de la reivindicación 4, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) comprende al menos una de una imagen de actualización de descodificador instantánea, IDR, una imagen de acceso de enlace roto, BLA, o una imagen de acceso aleatorio limpio, CRA.
6. El procedimiento de la reivindicación 1 o la reivindicación 2, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) incluye una o más cajas de índice de segmento, "sidx", y una primera caja sidx ordinal precede a todas las cajas moof del segmento de medios y describe todo el segmento de medios.
7. Un dispositivo (40) para recuperar datos multimedia, comprendiendo el dispositivo cliente:
medios para recibir (328), desde un dispositivo servidor (60), un archivo de manifiesto (66) que comprende información que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación (68A a N) de un contenido de medios (64) se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye:
un formato de segmento de medios de unidad de entrega (202), en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene uno o más fragmentos de película autónomos completos;
un formato de segmento de medios de acceso aleatorio (204), en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) se ajusta al formato de segmento de medios de unidad de entrega (202), y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un I sau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1,2 o 3;
un formato de segmento de medios sin superposición (206), en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición (206) se ajusta al formato de segmento de medios de unidad de entrega (202) y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación (68A a N) y otros segmentos de otras representaciones (68A a N) de un conjunto de adaptación que incluye la representación (68A a N); y
un formato de segmento de medios de conmutación (208), en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación (208) se ajusta al formato de segmento de medios de acceso aleatorio (204), y en el que la primera muestra del primer fragmento de película es un I sau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2;
medios para determinar, a partir de dicha información, a qué tipo de la pluralidad de tipos de segmentos de medios incluidos en la representación (68A a N) de contenido de medios (64) se ajustan; y
medios para usar dicho tipo determinado para recuperar (334, 340) segmentos de medios de dicho flujo de contenido de medios (64) desde el dispositivo servidor (60).
8. Un dispositivo servidor (60) para señalizar información de medios para la recuperación de segmentos de medios de un contenido de medios (64), comprendiendo el dispositivo servidor (60):
medios para construir (324) un archivo de manifiesto (66) que indica a qué tipo de una pluralidad de tipos de segmentos de medios incluidos en una representación (68A a N) del contenido de medios (64) se ajustan, en el que la pluralidad de tipos de segmentos de medios incluye:
un formato de segmento de medios de unidad de entrega (202), en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene uno o más fragmentos de película autónomos completos;
un formato de segmento de medios de acceso aleatorio (204), en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) se ajusta al formato de segmento de medios de unidad de entrega (202), y en el que la primera unidad de acceso de cada uno de los fragmentos de película del segmento es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1,2 o 3;
un formato de segmento de medios sin superposición (206), en el que un segmento de medios que se ajusta al formato de segmento de medios sin superposición (206) se ajusta al formato de segmento de medios de unidad de entrega (202) y no se superpone a unos tiempos de inicio y fin de otros segmentos de la representación (68A a N) y otros segmentos de otras representaciones (68A a N) de un conjunto de adaptación que incluye la representación (68A a N); y
un formato de segmento de medios de conmutación (208), en el que un segmento de medios que se ajusta al formato de segmento de medios de conmutación (208) se ajusta al formato de segmento de medios de acceso aleatorio (204), y en el que la primera muestra del primer fragmento de película es un Isau de un punto de acceso de flujo, SAP, de formato de archivo de medios de base ISO de tipo 1 o 2;
medios para enviar (326) el archivo de manifiesto (66) a un dispositivo cliente (40); y
medios para enviar (338), como respuesta a una petición (336) del dispositivo cliente (40) para un segmento de medios que se ajusta a uno de la pluralidad de tipos de segmento de medios, un segmento de medios que se ajusta al tipo de segmento de medios al dispositivo cliente (40).
9. El dispositivo (40, 60) de la reivindicación 7 o la reivindicación 8, en el que un segmento de medios que se ajusta al formato de segmento de medios de unidad de entrega (202) contiene un valor de "dums" en una caja de tipo de segmento del segmento, cada uno de los fragmentos de película autónomos comprende una caja de fragmento de película, "moof", y una caja de datos de medios, "mdat", que contiene muestras de medios que no usan referencias de datos externas referenciadas por una pista de la caja de fragmento de película, cada una de las cajas moof contiene al menos un fragmento de pista, cada una de las cajas moof no usa referencias externas, un señalizador "default-base-is-moof" del segmento de medios está establecido en true y un señalizador "base-data-offsetpresent" del segmento de medios está establecido en false.
10. El dispositivo (40, 60) de la reivindicación 7 o la reivindicación 8, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) incluye toda la información necesaria para acceder a datos de medios de un flujo de bits que sigue a los segmentos.
11. El dispositivo (40, 60) de la reivindicación 7 o la reivindicación 8, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) comprende al menos una de una imagen de actualización de descodificador instantánea, IDR, una imagen de acceso de enlace roto, BLA, o una imagen de acceso aleatorio limpio, CRA.
12. El dispositivo (40, 60) de la reivindicación 7 o la reivindicación 8, en el que un segmento de medios que se ajusta al formato de segmento de medios de acceso aleatorio (204) incluye una o más cajas de índice de segmento, "sidx", y una primera caja sidx ordinal precede a todas las cajas moof del segmento de medios y describe todo el segmento de medios.
13. Un medio de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo que, cuando se ejecutan, hacen que un procesador realice el procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 6.
ES16712103T 2015-02-10 2016-02-10 Transmisión en continuo de vídeo de baja latencia Active ES2767288T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562114423P 2015-02-10 2015-02-10
US201562183054P 2015-06-22 2015-06-22
US15/019,804 US10270823B2 (en) 2015-02-10 2016-02-09 Low latency video streaming
PCT/US2016/017325 WO2016130657A1 (en) 2015-02-10 2016-02-10 Low latency video streaming

Publications (1)

Publication Number Publication Date
ES2767288T3 true ES2767288T3 (es) 2020-06-17

Family

ID=56567242

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16712103T Active ES2767288T3 (es) 2015-02-10 2016-02-10 Transmisión en continuo de vídeo de baja latencia

Country Status (13)

Country Link
US (1) US10270823B2 (es)
EP (1) EP3257255B1 (es)
JP (1) JP6655091B2 (es)
KR (1) KR102168596B1 (es)
CN (1) CN107251562B (es)
AU (1) AU2016219369B2 (es)
BR (1) BR112017017152A2 (es)
EA (1) EA201791558A1 (es)
ES (1) ES2767288T3 (es)
HU (1) HUE047298T2 (es)
TN (1) TN2017000306A1 (es)
TW (1) TWI686077B (es)
WO (1) WO2016130657A1 (es)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10454985B2 (en) 2015-03-04 2019-10-22 Qualcomm Incorporated File format based streaming with dash formats based on LCT
WO2016204712A1 (en) * 2015-06-16 2016-12-22 Intel IP Corporation Adaptive video content for cellular communication
US10554713B2 (en) * 2015-06-19 2020-02-04 Microsoft Technology Licensing, Llc Low latency application streaming using temporal frame transformation
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10484701B1 (en) * 2016-11-08 2019-11-19 Amazon Technologies, Inc. Rendition switch indicator
EP3560206A1 (en) * 2016-12-22 2019-10-30 Fraunhofer Gesellschaft zur Förderung der Angewand Media streaming with fast tuning and fast channel switching
CN106658042B (zh) * 2016-12-28 2019-07-02 广州华多网络科技有限公司 一种数据推送方法及相关客户端、服务器
US10476943B2 (en) 2016-12-30 2019-11-12 Facebook, Inc. Customizing manifest file for enhancing media streaming
US10440085B2 (en) * 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
GB2560953A (en) * 2017-03-30 2018-10-03 Nokia Technologies Oy Video Streaming
US10924822B2 (en) * 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
US11665219B2 (en) 2017-07-10 2023-05-30 Qualcomm Incorporated Processing media data using a generic descriptor for file format boxes
JP6271072B1 (ja) * 2017-10-10 2018-01-31 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
US10432970B1 (en) * 2018-06-14 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for encoding 360° immersive video
US10862940B1 (en) * 2018-07-31 2020-12-08 Glance Networks, Inc. Low latency live video on a communication session
US11284134B2 (en) * 2018-08-08 2022-03-22 Comcast Cable Communications, Llc Media content enhancement based on content importance
US10779017B2 (en) * 2018-12-10 2020-09-15 Warner Bros. Entertainment Inc. Method and system for reducing drop-outs during video stream playback
JP7238155B2 (ja) * 2019-03-14 2023-03-13 ノキア テクノロジーズ オサケユイチア ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム
US11831879B2 (en) * 2019-09-20 2023-11-28 Comcast Cable Communications, Llc Methods, systems, and apparatuses for enhanced adaptive bitrate segmentation
US11765444B2 (en) * 2020-07-01 2023-09-19 Qualcomm Incorporated Streaming media data including an addressable resource index track
CN113691886B (zh) * 2021-08-25 2024-05-07 三星电子（中国）研发中心 流媒体文件的下载方法和装置
US20230076014A1 (en) * 2021-08-27 2023-03-09 AirMettle, Inc. Partitioning, processing, and protecting media data
CN118044207A (zh) * 2021-09-30 2024-05-14 抖音视界有限公司 用于视频流式传输的方法、装置和介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2749668C (en) * 2009-02-12 2017-07-11 Lg Electronics Inc. Broadcast receiver and 3d subtitle data processing method thereof
US9485546B2 (en) * 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9319448B2 (en) * 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US20130170561A1 (en) * 2011-07-05 2013-07-04 Nokia Corporation Method and apparatus for video coding and decoding
US20130042100A1 (en) * 2011-08-09 2013-02-14 Nokia Corporation Method and apparatus for forced playback in http streaming
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US8935425B2 (en) * 2011-10-05 2015-01-13 Qualcomm Incorporated Switching between representations during network streaming of coded multimedia data
WO2013166411A1 (en) * 2012-05-03 2013-11-07 United Video Properties, Inc. Systems and methods for preventing access to a media asset segment during a fast-access playback operation
JP2014239291A (ja) * 2013-06-06 2014-12-18 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
US20150026358A1 (en) * 2013-07-19 2015-01-22 Futurewei Technologies, Inc. Metadata Information Signaling And Carriage In Dynamic Adaptive Streaming Over Hypertext Transfer Protocol

Also Published As

Publication number Publication date
TW201633783A (zh) 2016-09-16
BR112017017152A2 (pt) 2018-04-03
EA201791558A1 (ru) 2017-12-29
KR102168596B1 (ko) 2020-10-21
US10270823B2 (en) 2019-04-23
AU2016219369B2 (en) 2019-10-31
TN2017000306A1 (en) 2019-01-16
TWI686077B (zh) 2020-02-21
CN107251562A (zh) 2017-10-13
JP2018510545A (ja) 2018-04-12
AU2016219369A1 (en) 2017-07-27
KR20170116027A (ko) 2017-10-18
JP6655091B2 (ja) 2020-02-26
HUE047298T2 (hu) 2020-04-28
EP3257255B1 (en) 2019-10-16
WO2016130657A1 (en) 2016-08-18
US20160234536A1 (en) 2016-08-11
EP3257255A1 (en) 2017-12-20
CN107251562B (zh) 2020-03-20

Similar Documents

Publication Publication Date Title
ES2767288T3 (es) Transmisión en continuo de vídeo de baja latencia
ES2896687T3 (es) Región más interesada en una imagen
ES2848116T3 (es) Transmisión basada en formato de archivo con formatos DASH basados en LCT
ES2788901T3 (es) Procesamiento de contenido multiperiodo continuo
US10587934B2 (en) Virtual reality video signaling in dynamic adaptive streaming over HTTP
ES2864645T3 (es) Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios
ES2796535T3 (es) Proporcionar conjuntos de datos de secuencia para la transmisión continua de datos de vídeo
ES2892329T3 (es) Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua
ES2710702T3 (es) Temporización en vivo para la transmisión continua dinámica adaptativa sobre el HTTP (DASH)
ES2854936T3 (es) Recuperación y acceso a trozos de segmento para transmisión de medios
ES2818622T3 (es) Entradas de muestra y acceso aleatorio
ES2764224T3 (es) Robusto funcionamiento en vivo de DASH
US11665219B2 (en) Processing media data using a generic descriptor for file format boxes
ES2821382T3 (es) Entradas de muestra y acceso aleatorio
US10587904B2 (en) Processing media data using an omnidirectional media format
KR102654999B1 (ko) 강화된 영역별 패킹 및 뷰포트 독립적 hevc 미디어 프로파일
OA18391A (en) Low latency video streaming.
EA045713B1 (ru) Способ и клиентское устройство для извлечения мультимедийных данных из серверного устройства
BR112016022245B1 (pt) Método e dispositivo de recuperar dados de mídia