ES2864645T3 - Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios - Google Patents

Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios Download PDF

Info

Publication number
ES2864645T3
ES2864645T3 ES17701389T ES17701389T ES2864645T3 ES 2864645 T3 ES2864645 T3 ES 2864645T3 ES 17701389 T ES17701389 T ES 17701389T ES 17701389 T ES17701389 T ES 17701389T ES 2864645 T3 ES2864645 T3 ES 2864645T3
Authority
ES
Spain
Prior art keywords
data
dems
media
video
determining
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
ES17701389T
Other languages
English (en)
Inventor
Gordon Walker
Thomas Stockhammer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2864645T3 publication Critical patent/ES2864645T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/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/26208—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 the scheduling operation being performed under constraints
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Warehouses Or Storage Devices (AREA)
  • Communication Control (AREA)

Abstract

Un procedimiento (1400) de transporte de datos de medios, comprendiendo el procedimiento, mediante una unidad de envío de protocolo basado en archivos de un dispositivo de origen: recibir (380) un flujo de datos que comprende segmentos de datos de medios desde un segmentador del dispositivo de origen que forma los segmentos, comprendiendo cada uno de los segmentos un respectivo archivo que puede recuperarse de forma individual asociado a un localizador de recursos uniforme, URL, o un identificador de recursos uniforme, URI, únicos; determinar (382) ubicaciones de eventos de entrega de medios, MDE, en el flujo de datos de medios, donde los MDE incluyen datos para al menos una parte de uno de los segmentos; determinar (384) uno o más requisitos de tiempo de transmisión para los MDE que representan momentos en los que los MDE van a enviarse a un dispositivo cliente; y proporcionar (386) los MDE y los datos que representan los requisitos de tiempo de transmisión a una unidad de envío de capa física del dispositivo de origen de acuerdo con ranuras de entrega disponibles para la unidad de envío de capa física.

Description

DESCRIPCIÓN
Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios
[0001] La presente solicitud reivindica el beneficio de la solicitud provisional de EE. UU. n.° 62/276,674, presentada el 8 de enero de 2016.
CAMPO TÉCNICO
[0002] Esta divulgación se refiere al transporte de datos de medios.
ANTECEDENTES
[0003] Las capacidades de audio y vídeo digital se pueden incorporar a una amplia gama de dispositivos, incluidos televisores digitales, sistemas de radiodifusión directa digital, sistemas de radiodifusión inalámbrica, asistentes personales digitales (PDA), ordenadores portátiles o de escritorio, cámaras digitales, dispositivos de grabación digitales, reproductores de medios digitales, dispositivos de videojuegos, consolas de videojuegos, teléfonos de radio celulares o por satélite, dispositivos de videoconferencia y similares.
[0004] Los datos de medios, tales como los datos de audio y vídeo, pueden comprimirse para su transporte. La compresión incluye, en general, la codificación de los datos de medios. Después de que se hayan codificado los datos de medios, los datos de vídeo se pueden agrupar en paquetes para su transmisión o almacenamiento. Los datos de medios pueden ensamblarse en un archivo de medios conforme a cualquiera de una variedad de normas, tales como el formato de archivos de medios basado en la Organización Internacional de Normalización y extensiones (BMFF ISO) del mismo, tales como AVC.
[0005] Se pueden usar diversas técnicas para transportar datos de medios por medio de una red informática. Por ejemplo, los datos de medios se pueden entregar por medio de un protocolo de radiodifusión o un protocolo de unidifusión. En un protocolo de radiodifusión, un dispositivo servidor envía datos de medios a una pluralidad de dispositivos cliente suscritos. En un protocolo de unidifusión, un dispositivo cliente solicita datos de medios de un dispositivo servidor y el dispositivo servidor entrega los datos de medios en respuesta a la solicitud.
BREVE EXPLICACIÓN
[0006] En general, esta divulgación describe técnicas relacionadas con el soporte de Eventos de Entrega de Medios (MDE) usados, por ejemplo, en la entrega de intervalos de octetos adaptados a medios por medio de ROUTE (ATSC Working Draft: Signaling, Delivery, Synchronization, and Error Protection, 20 de noviembre de 2015) y Mm T (ISO/IEC: ISO/IEC 23008-1 2nd edition, Information technology-High efficiency coding and media delivery in heterogeneous environments-Part 1: MPEG media transport (MMT)) o FLUTE (RFC 6726), que es un subconjunto adecuado de ROUTE. Estas técnicas de entrega pueden usar además Transmisión Continua Dinámica Adaptativa a través de HTTP (DASH) mediante radiodifusión, Formato Común de Aplicaciones de Medios (CMAF) o procedimientos similares de entrega de medios basada en intervalos de octetos adaptados a segmentos o medios. Esta divulgación también describe técnicas para determinar el etiquetado de tiempo de MDE detectados y técnicas adaptativas para la entrega en la capa física que tienen en cuenta el impacto de la entrega de medios temprana en relación con el entramado de capa física alineado con los medios.
[0007] De acuerdo con la invención reivindicada, hay un dispositivo de origen, un medio de almacenamiento legible por ordenador y un procedimiento de transporte de datos de medios que incluye, mediante una unidad de envío de protocolo basado en archivos de un dispositivo de origen, recibir un flujo de datos que comprende segmentos de datos de medios desde un segmentador del dispositivo de origen que forma los segmentos, comprendiendo cada uno de los segmentos un respectivo archivo recuperable individualmente asociado a un único localizador de recursos uniforme (URL) o identificador de recursos uniforme (URI), determinar ubicaciones de los eventos de entrega de medios (MDE) en el flujo de datos de medios, donde los MDE incluyen datos para al menos una parte de uno de los segmentos, determinar uno o más requisitos de tiempo de transmisión para los MDE que representan los momentos en los que los MDE van a enviarse a un dispositivo cliente, y proporcionar los MDE y datos que representan los requisitos de tiempo de transmisión a una unidad de envío de capa física del dispositivo de origen de acuerdo con ranuras de entrega disponibles para la unidad de envío de capa física.
[0008] Los detalles de uno o más ejemplos se exponen en los dibujos adjuntos y la siguiente descripción. Otros rasgos característicos, objetivos y ventajas resultarán evidentes a partir de la descripción y los dibujos, y a partir de las reivindicaciones.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0009]
La FIG. 1 es un diagrama de bloques que ilustra un sistema de ejemplo que implementa técnicas para transmitir en continuo datos de medios a través de una red.
La FIG. 2 es un diagrama de bloques que ilustra con mayor detalle un conjunto de componentes de ejemplo de la unidad de recuperación 52 de la FIG. 1.
La FIG. 3 es un diagrama conceptual que ilustra elementos de contenido multimedia de ejemplo.
La FIG. 4 es un diagrama de bloques que ilustra elementos de un archivo de vídeo de ejemplo, que puede corresponder a un segmento de una representación.
La FIG. 5 es un diagrama de bloques que ilustra un ejemplo de sistema de infraestructura de Transmisión Continua Dinámica Adaptativa a través de HTTP (DASH) mediante radiodifusión.
La FIG. 6 es un diagrama conceptual que ilustra un ejemplo de composición de alto nivel de MDE.
La FIG. 7 es un diagrama conceptual que ilustra un ejemplo de cadencia tipo trama y MDE definidos correspondientes.
La FIG. 8 es un diagrama conceptual que representa una vista simple del tiempo de sistema.
La FIG. 9 es un diagrama de bloques que representa una relación de tiempo en una infraestructura de transmisión.
La FIG. 10 es un diagrama conceptual que ilustra múltiples segmentos por grupo de imágenes (GoP) con una ubicación de punto de acceso aleatorio (RAP) escalonado.
La FIG. 11 es un diagrama conceptual que ilustra un retardo mínimo para descodificar tiempo para la reproducción de medios.
La FIG. 12 es un diagrama conceptual que ilustra una sincronización de capa física opcional y metadatos relacionados.
La FIG. 13 es un diagrama de flujo que ilustra una secuencia de ejemplo de eventos de adquisición.
La FIG. 14 es un diagrama de flujo que ilustra otro procedimiento de ejemplo de acuerdo con las técnicas de esta divulgación.
DESCRIPCIÓN DETALLADA
[0010] En general, esta divulgación describe técnicas relacionadas con el transporte de datos de medios. Las técnicas de esta divulgación pueden ser realizadas por un dispositivo servidor u otro dispositivo de origen que transmita en continuo datos de medios a un dispositivo cliente. En particular, el dispositivo de origen puede incluir un segmentador, una unidad de envío de protocolo basado en archivos y una unidad de envío de capa física. El segmentador puede corresponder a una unidad que forma segmentos de datos de medios, donde los segmentos se ajustan a, por ejemplo, segmentos de Transmisión Continua Dinámica Adaptativa a través de HTTP (DASH). Por ejemplo, el segmentador puede encapsular unidades de capa de abstracción de red (NAL) en respectivos segmentos DASH, donde cada segmento puede estar asociado a un localizador de recursos uniforme (URL) o identificador de recursos uniforme (URI) distinto. La unidad de envío de protocolo basado en archivos puede configurarse para enviar datos usando un protocolo basado en archivos, tal como la Entrega de Archivos mediante Transporte Unidireccional (FLUTE) o ROUTE. La unidad de envío de capa física puede enviar datos de medios a la capa física, por ejemplo, usando Ethernet.
[0011] De acuerdo con las técnicas de esta divulgación, el segmentador puede proporcionar ambos segmentos de datos de medios, en forma de un flujo de segmentos, a la unidad de envío de protocolo basado en archivos. Por tanto, la unidad de envío de protocolo basado en archivos puede recibir desde el segmentador un flujo de datos que incluye los segmentos de datos de medios. La unidad de envío de protocolo basado en archivos puede entonces determinar ubicaciones de eventos de entrega de medios (MDE) en el flujo de datos de medios. En un ejemplo, la unidad de envío de protocolo basado en archivos puede formar los MDE a partir del flujo de datos de medios. Por ejemplo, la unidad de envío de protocolo basado en archivos puede determinar qué partes del flujo se incluirán en un MDE particular de modo que el MDE incluya datos que sean útiles para un descodificador de medios (por ejemplo, datos que pueden ser descodificados correctamente por el descodificador de medios, suponiendo que los datos anteriores se entregaron correctamente).
[0012] Para determinar las ubicaciones de los MDE, la unidad de envío de protocolo basado en archivos puede utilizar técnicas de concordancia de patrones, en las que la unidad de envío de protocolo basado en archivos está configurada con uno o más patrones para los datos de medios incluidos en el flujo. Dichos patrones pueden representar, por ejemplo, una disposición de datos de medios en un orden de descodificación jerárquico. Por ejemplo, los datos de vídeo pueden organizarse de acuerdo con un determinado número de tramas intrapredichas (tramas I), seguidas de un determinado número de tramas interpredichas unidireccionales (tramas P), seguidas de (o intercaladas con) un determinado número de tramas interpredichas bidireccionales (tramas B). La unidad de envío de protocolo basado en archivos puede determinar las ubicaciones de los MDE basándose en la detección de las tramas I, P y B y, por ejemplo, determinar que un MDE incluye una secuencia de vídeo que comienza con una primera trama I y termina con una última trama B antes de una trama I posterior, como un ejemplo. Además, la unidad de envío de protocolo basado en archivos puede determinar que un MDE de vídeo corresponde a un intervalo de octetos particular de un segmento, donde el intervalo de octetos termina en un límite de trama. Como otro ejemplo, la unidad de envío de protocolo basado en archivos puede determinar que los MDE de audio incluyen un número fijo de tramas de audio.
[0013] Como otro ejemplo, para determinar las ubicaciones de los MDE (por ejemplo, para formar los MDE), la unidad de envío de protocolo basado en archivos puede configurarse de acuerdo con reglas que definen ubicaciones de varios tipos de datos de medios, tales como datos de audio, datos de vídeo y/o datos de texto temporizado, en el flujo. Las reglas pueden definir, por ejemplo, una disposición de los diversos tipos de datos de medios en el flujo, de modo que la unidad de envío de protocolo basado en archivos puede diferenciar los tipos de datos de medios y asignar los tipos de datos de medios a MDE respectivos.
[0014] Además, la unidad de envío de protocolo basado en archivos también puede determinar uno o más requisitos de tiempo de entrega (también denominados requisitos de tiempo de transmisión) para los MDE, donde los requisitos de tiempo de transmisión representan momentos en los que los MDE van a enviarse al dispositivo cliente. Por ejemplo, los requisitos de tiempo de transmisión pueden representar los tiempos más tempranos y/o más tardíos en los que los MDE van a enviarse al dispositivo cliente. Los MDE pueden tener requisitos de tiempo más temprano en los que los MDE se pueden enviar al dispositivo cliente para, por ejemplo, evitar un desbordamiento de búfer en el dispositivo cliente. Los MDE también pueden tener requisitos de tiempo más tardío en los que los MDE se pueden enviar al dispositivo cliente para, por ejemplo, evitar un un déficit de almacenamiento en búfer en el dispositivo cliente.
[0015] La unidad de envío de protocolo basado en archivos puede enviar los MDE a la unidad de envío de la capa física, junto con datos representativos de los requisitos de tiempo de transmisión. En particular, la unidad de envío de protocolo basado en archivos puede determinar ranuras de entrega disponibles para la unidad de envío de capa física y enviar los MDE y los datos de requisitos de tiempo de transmisión a la unidad de envío de la capa física de manera que la unidad de envío de capa física pueda entregar los MDE de acuerdo con los requisitos de tiempo de transmisión.
[0016] El dispositivo de origen analizado anteriormente puede configurarse para transmitir en continuo datos de acuerdo con un protocolo de transmisión en continuo de HTTP, tal como DASH. En la transmisión en continuo de HTTP, las operaciones de uso frecuente incluyen HEAD, GET y GET parcial. La operación HEAD recupera una cabecera de un archivo asociado a un localizador de recursos uniforme (URL), un nombre de recursos uniforme (URN) o un identificador de recursos uniforme (URI) dado, sin recuperar una carga útil asociada al URL, URN o URI. La operación GET recupera un archivo entero asociado a un URL, URN o URI dado. La operación GET parcial recibe un intervalo de octetos como un parámetro de entrada y recupera un número continuo de octetos de un archivo, donde el número de octetos corresponde al intervalo de octetos recibido. Por tanto, se pueden proporcionar fragmentos de una película a la transmisión en continuo de HTTP, ya que una operación GET parcial puede obtener uno o más fragmentos de película individuales. En un fragmento de película, pueden existir varios fragmentos de pista de diferentes pistas. En la transmisión en continuo de HTTP, una presentación de medios puede ser una recopilación de datos estructurada que es accesible para el cliente. El cliente puede solicitar y descargar la información de datos de medios para presentar un servicio de transmisión en continuo a un usuario.
[0017] En el ejemplo de transmisión en continuo de datos 3GPP usando transmisión en continuo de 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 una norma de codificación de vídeo), diferentes normas de codificación o ampliaciones de normas de codificación (tales como ampliaciones multivista y/o escalables), o diferentes velocidades de transmisión 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 una recopilación de datos estructurada que es accesible para un dispositivo cliente de transmisión en continuo de HTTP. El dispositivo cliente de transmisión en continuo de 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 de MPD, que puede incluir actualizaciones de la MPD.
[0018] 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 de start del período y del atributo availableStartTime de la MPD puede especificar el tiempo de disponibilidad del período en formato de UTC, en particular, el primer segmento de medios de cada representación en el período correspondiente. Para servicios bajo demanda, el atributo start del primer período puede ser 0. Para cualquier otro período, el atributo start puede especificar un desfase temporal entre el tiempo de inicio del período correspondiente con respecto al tiempo de inicio del primer período. 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 períodos anteriores.
[0019] 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 velocidad de transmisión de bits, la resolución y/o el códec para los datos de vídeo y la velocidad de transmisión de bits, el lenguaje y/o el códec para los datos de audio. El término "representación" se puede usar para hacer referencia 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.
[0020] Las representaciones de un período particular se pueden asignar a un grupo indicado por un atributo de la MPD indicativo de un conjunto de adaptación al que pertenecen las representaciones. Las representaciones en el mismo conjunto de adaptación se consideran, en general, alternativas entre sí, en la medida en que un dispositivo cliente puede conmutar entre estas representaciones de manera dinámica y sin interrupciones, 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 particular se puede asignar al mismo conjunto de adaptación, de modo que cualquiera de las representaciones se puede seleccionar para su descodificación 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 del grupo 0, si está presente, o bien mediante la combinación de, como máximo, una representación de cada grupo distinto de 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.
[0021] 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 autoinicializarse. 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 de recursos uniforme (URL), un nombre de recursos uniforme (URN) o un identificador de recursos uniforme (URI). La MPD puede proporcionar los identificadores para cada segmento. En algunos ejemplos, la MPD también puede proporcionar intervalos de octetos en forma de un atributo range, que puede corresponder a los datos de un segmento dentro de un archivo accesible por el URL, el URN o el URI.
[0022] 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 particulares 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).
[0023] La FIG. 1 es un diagrama de bloques que ilustra un sistema 10 de ejemplo que implementa técnicas para la transmisión en continuo de 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 mediante 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.
[0024] El dispositivo de preparación de contenido 20, en el ejemplo de la FIG. 1, 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 captados 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.
[0025] 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 interlocutor mientras el interlocutor está hablando, y la fuente de vídeo 24 puede obtener simultáneamente datos de vídeo del interlocutor. 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 que se transmiten en directo, en continuo o en tiempo real, o a datos de audio y vídeo archivados o registrados previamente.
[0026] 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 interlocutor produce al hablar, en general, 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 interlocutor 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 particular. Por consiguiente, 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.
[0027] En algunos ejemplos, el codificador de audio 26 puede codificar una marca de tiempo en cada trama de audio codificada, que representa un tiempo en el 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 tiempo en cada trama de vídeo codificada, que representa un tiempo en el 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 tiempo y una trama de vídeo que comprende la misma marca de tiempo. 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 tiempo, 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 tiempo.
[0028] En algunos ejemplos, la fuente de audio 22 puede enviar datos al codificador de audio 26, correspondientes a un tiempo en el que se han registrado datos de audio, y la fuente de vídeo 24 puede enviar datos al codificador de vídeo 28, correspondientes a un tiempo en el que se han registrado datos de vídeo. En algunos ejemplos, el codificador de audio 26 puede codificar un identificador de secuencia en datos de audio codificados para indicar un orden temporal relativo de los datos de audio codificados, pero sin indicar necesariamente un tiempo absoluto en el 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 asignar a o correlacionar de otro modo con una marca de tiempo.
[0029] El codificador de audio 26 produce, en general, 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 codificada 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.
[0030] En el ejemplo de la FIG. 1, 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, tanto el codificador de vídeo 28 como el codificador de audio 26 pueden interactuar con 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.
[0031] El codificador de vídeo 28 puede codificar datos de vídeo de contenido multimedia de varias maneras para producir diferentes representaciones del contenido multimedia a diversas velocidades de transmisión de bits y con diversas características, tales como resoluciones de píxel, velocidades de tramas, conformidad con diversas normas de codificación, conformidad con diversos perfiles y/o niveles de perfiles para diversas normas 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 se encarga de ensamblar flujos elementales en archivos de vídeo (por ejemplo, segmentos) de diversas representaciones.
[0032] 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 la norma 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 "apta para redes" dirigida a 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 fragmento. 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.
[0033] 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 pueden contener información de cabecera a nivel de secuencia (en conjuntos de parámetros de secuencia (SPS)) e información de cabecera a nivel de imagen que cambia ocasionalmente (en conjuntos de parámetros de imagen (PPS)). Con los conjuntos de parámetros (por ejemplo, PPS y SPS), la información que cambia ocasionalmente no necesita ser repetida para cada secuencia o imagen, de ahí que pueda mejorarse la eficacia de la codificación. Además, el uso de conjuntos de parámetros puede permitir la transmisión fuera de banda de la información de cabecera importante, evitando la necesidad de transmisiones redundantes para la 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.
[0034] 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 unidades NAL VCL, pero puede ayudar en los procesos relacionados con la descodificación, visualización, resistencia a los 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 habituales y, por tanto, no siempre son obligatorios para la implementación de descodificadores que cumplen las normas. Los mensajes SEI pueden ser mensajes SEI a nivel de secuencia o mensajes de SEI a nivel de imagen. Parte de la información a 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 acerca de, por ejemplo, la 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).
[0035] 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 una 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), una grabadora o copiadora 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. 1, 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-68N (representaciones 68). En algunos ejemplos, la interfaz de salida 32 también puede enviar datos directamente a la red 74.
[0036] 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 lenguaje 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 particulares, o similares.
[0037] El archivo de manifiesto 66 puede incluir datos indicativos de los subconjuntos de representaciones 68 correspondientes a conjuntos de adaptación particulares, 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 velocidades de transmisión 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 de conjunto de adaptación del archivo de manifiesto 66.
[0038] El dispositivo servidor 60 incluye una unidad de procesamiento de solicitudes 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 apoderados (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.
[0039] La unidad de procesamiento de solicitudes 70 está configurada para recibir solicitudes 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 solicitudes 70 puede implementar el protocolo de transferencia de hipertexto (HTTP) versión 1.1, como se describe en RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1", de R. Fielding et al, Network Working Group, IETF, junio de 1999. Es decir, la unidad de procesamiento de solicitudes 70 puede estar configurada para recibir solicitudes GET o GET parciales de HTTP y proporcionar datos de contenido multimedia 64 como respuesta a las solicitudes. Las solicitudes pueden especificar un segmento de una de las representaciones 68, por ejemplo, usando un URL o URI del segmento. En algunos ejemplos, las solicitudes también pueden especificar uno o más intervalos de octetos del segmento, comprendiendo por tanto solicitudes GET parciales. La unidad de procesamiento de solicitudes 70 puede estar configurada, además, para atender solicitudes HEAD HTTP para proporcionar datos de cabecera de un segmento de una de las representaciones 68. En cualquier caso, la unidad de procesamiento de solicitudes 70 puede estar configurada para procesar las solicitudes para proporcionar los datos solicitados a un dispositivo solicitante, tal como el dispositivo cliente 40.
[0040] De forma adicional o alternativa, la unidad de procesamiento de solicitudes 70 puede estar configurada para entregar datos de medios por medio de un protocolo de radiodifusión o multidifusión, tal como eMBMS o DVB-T/T2. 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 eMBMS, DVB-T/T2 u otro protocolo de transporte de red de radiodifusión o multidifusión. Por ejemplo, la unidad de procesamiento de solicitudes 70 puede estar configurada para recibir una solicitud de unión a 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 dispositivos cliente, que incluyen el dispositivo cliente 40, asociados a un contenido de medios particular (por ejemplo, radiodifusión de un evento en directo). El dispositivo cliente 40, a su vez, puede enviar una solicitud para unirse al grupo de multidifusión. Esta solicitud 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.
[0041] Además, la interfaz de red 72 del dispositivo servidor 60 puede estar configurada para realizar las técnicas de esta divulgación. De forma adicional o alternativa, la unidad de procesamiento de solicitudes 70 y la interfaz de red 72 pueden configurarse para realizar las técnicas de esta divulgación. Con propósitos explicativos, se supone que la interfaz de red 72 incluye subcomponentes que no se muestran explícitamente en la FIG. 1, tales como los diversos ejemplos que se analizan con mayor detalle a continuación. Por ejemplo, la interfaz de red 72 puede incluir un emisor, un planificador, un formador de tramas y un amplificador excitador. Además, en este ejemplo, la unidad de encapsulación 30 representa un ejemplo de un segmentador (es decir, una unidad que forma segmentos de datos de medios, donde los segmentos representan archivos individuales asociados a URL/URI respectivos). En particular, la unidad de encapsulación 30 puede encapsular MDE en segmentos, donde cada segmento puede incluir uno o más MDE.
[0042] De acuerdo con las técnicas de esta divulgación, la unidad de encapsulación 30 puede proporcionar un flujo de segmentos de datos de medios al dispositivo servidor 60 que, en última instancia, dirige el flujo de segmentos a la interfaz de red 72 para su transmisión al dispositivo cliente 40. El flujo de segmentos puede corresponder a una representación, tal como una de las representaciones 68. Además, la unidad de encapsulación 30 puede proporcionar datos que representan requisitos de tiempo de transmisión para los MDE incluidos en los segmentos al dispositivo servidor 60 que, de nuevo, dirige en última instancia los requisitos de tiempo de transmisión a la interfaz de red 72. Por ejemplo, los requisitos de tiempo de transmisión pueden especificarse en el archivo de manifiesto 66. Los requisitos de tiempo de transmisión indican, en general, los tiempos más tempranos y/o más tardíos en los que los MDE van a entregarse al dispositivo cliente 40. Por tanto, la interfaz de red 72 puede enviar los MDE (por ejemplo, segmentos o intervalos de octetos de segmentos) al dispositivo cliente 40 de acuerdo con los requisitos de tiempo de transmisión. Por ejemplo, la interfaz de red 72 puede entregar los MDE de manera que los MDE no lleguen antes de los tiempos de transmisión más tempranos y/o no más tarde de los tiempos de transmisión más tardíos en el dispositivo cliente 40.
[0043] Como se ilustra en el ejemplo de la FIG. 1, 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 velocidad de transmisión 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.
[0044] 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 renderización de la salida de vídeo 44. Los datos de configuración también pueden incluir cualquiera o todas las preferencias de lenguaje 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 enviar solicitudes g Et y GET parcial de HTTP. La unidad de recuperación 52 puede corresponder a 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 parte 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.
[0045] La unidad de recuperación 52 puede comparar las capacidades de descodificación y renderizació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 renderización del dispositivo cliente 40. La unidad de recuperación 52 puede, a continuación, determinar las velocidades de transmisión 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 velocidad de transmisión de bits que se puede satisfacer mediante el ancho de banda de red.
[0046] En general, las representaciones de velocidades de transmisión de bits mayores pueden producir una reproducción de vídeo de mayor calidad, mientras que las representaciones de velocidades de transmisión 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 velocidades de transmisión de bits relativamente altas, mientras que cuando el ancho de banda de red disponible es bajo, la unidad de recuperación 52 puede recuperar datos de representaciones de velocidades de transmisión de bits relativamente bajas. 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.
[0047] 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 enviar una solicitud para unirse a un grupo de red de multidifusión asociado a un contenido de medios particular. Después de unirse al grupo de multidifusión, la unidad de recuperación 52 puede recibir datos del grupo de multidifusión sin solicitudes adicionales emitidas al dispositivo servidor 60 o al dispositivo de preparación de contenido 20. La unidad de recuperación 52 puede enviar una solicitud para abandonar el grupo de multidifusión cuando 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.
[0048] 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, desempaquetar 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.
[0049] 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 se pueden incluir en uno o más codificadores o descodificadores, ambos cuales se pueden integrar 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 cuales pueden estar integrados 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 celular.
[0050] 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 de ejemplo, 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 de (o, además de) el dispositivo servidor 60.
[0051] 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 octeto 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 fragmento 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.
[0052] La unidad de encapsulación 30 también puede ensamblar unidades de acceso a partir 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 velocidad de trama 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.
[0053] Por consiguiente, una unidad de acceso puede comprender todas las tramas de audio y vídeo de una instancia temporal común, por ejemplo, todas las visualizaciones correspondientes al tiempo X. Esta divulgación también se refiere a una imagen codificada de una vista particular como "componente de vista". Es decir, un componente de vista puede comprender una imagen (o trama) codificada para una vista particular en un tiempo particular. Por consiguiente, 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.
[0054] 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 m Pd 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 ubicados en cuadros de fragmento de película (cuadros moof) de archivos de vídeo.
[0055] 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 el tiempo de reloj en el 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, basándose en el tiempo de inicio, así como de las duraciones de los segmentos que preceden a un segmento particular.
[0056] Después de que la unidad de encapsulación 30 haya ensamblado unidades NAL y/o unidades de acceso en un archivo de vídeo, basándose en 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 proporciona 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.
[0057] 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 los 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.
[0058] Determinados elementos del ejemplo de la FIG. 1 pueden configurarse para realizar las técnicas de esta divulgación. Por ejemplo, la interfaz de red 72 y/o la unidad de procesamiento de solicitudes 70 pueden configurarse para funcionar de forma independiente o conjunta para realizar las técnicas de esta divulgación.
[0059] La FIG. 2 es un diagrama de bloques que ilustra con mayor detalle un conjunto de componentes de ejemplo de la unidad de recuperación 52 de la FIG. 1. En este ejemplo, la unidad de recuperación 52 incluye una unidad de middleware eMBMS 100, un cliente DASH 110 y una aplicación de medios 112.
[0060] En este ejemplo, la unidad de middleware eMBMS 100 incluye, además, una unidad de recepción eMBMS 106, una memoria caché 104 y una unidad de servidor 102. En este ejemplo, la unidad de recepción eMBMS 106 está configurada para recibir datos por medio de eMBMS, por ejemplo, de acuerdo con la Entrega de Archivos a través de Transporte Unidireccional (FLUTE), descrita en el documento de T. Paila et al., "FLUTE-File Delivery over Unidirectional Transport", Grupo de trabajo de red, RFC 6726, noviembre de 2012, disponible en http://tools.ietf.org/html/rfc6726. Es decir, la unidad de recepción eMBMS 106 puede recibir archivos por medio de radiodifusión desde, por ejemplo, el dispositivo servidor 60, que puede actuar como un BM-SC.
[0061] A medida que la unidad de middleware eMBMS 100 recibe datos para los archivos, la unidad de middleware eMBMS puede almacenar los datos recibidos en la memoria caché 104. La memoria caché 104 puede comprender un medio de almacenamiento legible por ordenador, tal como memoria flash, un disco duro, RAM o cualquier otro medio de almacenamiento adecuado.
[0062] La unidad de servidor local 102 puede actuar como un servidor para el cliente DASH 110. Por ejemplo, la unidad de servidor local 102 puede proporcionar un archivo MPD u otro archivo de manifiesto al cliente DASH 110. La unidad de servidor local 102 puede anunciar tiempos de disponibilidad para segmentos en el archivo MPD, así como hipervínculos desde los cuales se pueden recuperar los segmentos. Estos hipervínculos pueden incluir un prefijo de dirección de anfitrión local (localhost) correspondiente al dispositivo cliente 40 (por ejemplo, 127.0.0.1 para IPv4). De esta manera, el cliente DASH 110 puede solicitar segmentos de la unidad de servidor local 102 usando solicitudes GET o GET parciales de HTTP. Por ejemplo, para un segmento disponible en el enlace http://127.0.0.1/rep1/seg3, el cliente DASH 110 puede generar una solicitud GET de HTTP que incluya una solicitud para http://127.0.0.1/rep1/seg3, y enviar la solicitud a la unidad de servidor local 102. La unidad de servidor local 102 puede recuperar los datos solicitados de la memoria caché 104 y proporcionar los datos al cliente DASH 110 en respuesta a dichas solicitudes.
[0063] La FIG. 3 es un diagrama conceptual que ilustra elementos del contenido multimedia 120 de ejemplo. El contenido multimedia 120 puede corresponder al contenido multimedia 64 (FIG. 1), o a otro contenido multimedia almacenado en el medio de almacenamiento 62. En el ejemplo de la FIG. 3, el contenido multimedia 120 incluye una descripción de presentación de medios (MPD) 122 y una pluralidad de representaciones 124A-124N (representaciones 124). La representación 124A incluye datos de cabecera 126 y segmentos 128A-128N (segmentos 128) opcionales, mientras que la representación 124N incluye datos de cabecera 130 y segmentos 132A-132N (segmentos 132) opcionales. La letra N se usa para designar, por razones de conveniencia, el último fragmento de película en cada una de las representaciones 124. En algunos ejemplos, puede haber diferentes números de fragmentos de película entre las representaciones 124.
[0064] La MPD 122 puede comprender una estructura de datos separada de las representaciones 124. La MPD 122 puede corresponder al archivo de manifiesto 66 de la FIG. 1. Del mismo modo, las representaciones 124 pueden corresponder a las representaciones 68 de la FIG. 2. En general, la MPD 122 puede incluir datos que, en general, describen características de representaciones 124, tales como características de codificación y representación, conjuntos de adaptación, un perfil al que corresponde la MPD 122, información de tipo de texto, información de ángulo de cámara, información de calificación, 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).
[0065] Los datos de cabecera 126, cuando están presentes, pueden describir características de los segmentos 128, por ejemplo, ubicaciones temporales de puntos de acceso aleatorio (RAP, también denominados puntos de acceso de flujo (SAP)), qué segmentos 128 incluyen puntos de acceso aleatorio, desfases de octetos con respecto a puntos de acceso aleatorio dentro de los segmentos 128, localizadores de recursos uniformes (URL) o URI de los segmentos 128 u otros aspectos de los segmentos 128. Los datos de cabecera 130, cuando están presentes, pueden describir características similares para los segmentos 132. De forma adicional o alternativa, dichas características pueden estar incluidas por completo dentro de la MPD 122.
[0066] Los segmentos 128, 124 incluyen una o más muestras de vídeo codificadas, cada una de las cuales puede incluir tramas o fragmentos de datos de vídeo. Cada una de las muestras de vídeo codificadas de los segmentos 128 puede tener características similares, por ejemplo, requisitos de altura, anchura y ancho de banda. Dichas características pueden describirse por datos de la MPD 122, aunque dichos datos no se ilustran en el ejemplo de la FIG. 3. La MPD 122 puede incluir características como las descritas en la especificación 3GPP, con la adición de cualquiera o toda la información señalizada descrita en esta divulgación.
[0067] Cada uno de los segmentos 128, 132 puede estar asociado a un único localizador de recursos uniforme (URL) o URI. Por tanto, cada uno de los segmentos 128, 132 puede recuperarse de forma independiente 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 solicitud GET de HTTP para recuperar los segmentos 128 o 132. En algunos ejemplos, el dispositivo cliente 40 puede usar solicitudes GET parciales de HTTP para recuperar intervalos de octetos específicos de los segmentos 128 o 132.
[0068] La FIG. 4 es un diagrama de bloques que ilustra elementos de un archivo de vídeo 150 de ejemplo, que puede corresponder a un segmento de una representación, tal como uno de los segmentos 114, 124 de la FIG. 3. Aunque el ejemplo de la FIG. 4 ilustra un archivo de vídeo, debe entenderse que un archivo de audio u otro archivo puede incluir datos similares a los del archivo de vídeo 150. Cada uno de los segmentos 128, 132 puede incluir datos que se ajustan sustancialmente a la disposición de datos ilustrada en el ejemplo de la FIG. 4. Se puede decir que el archivo de vídeo 150 encapsula un segmento. Como se ha descrito 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 "cuadros". En el ejemplo de la FIG. 4, el archivo de vídeo 150 incluye un cuadro de tipo de archivo (FTYP) 152, un cuadro de película (MOOV) 154, cuadros de índices de segmento (SIDX) 162, cuadros de fragmento de película (MOOF) 164 y un cuadro de acceso aleatorio de fragmento de película (MFRA) 166. Aunque la FIG. 4 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.
[0069] El cuadro de tipo de archivo (FTYP) 152 describe, en general, un tipo de archivo para el archivo de vídeo 150. El cuadro de tipo de archivo 152 puede incluir datos que identifican una especificación que describe el mejor uso para el archivo de vídeo 150. El cuadro de tipo de archivo 152 puede estar colocado, de forma alternativa, antes del cuadro MOOV 154, los cuadros de fragmento de película 164 y/o el cuadro MFRA 166.
[0070] En algunos ejemplos, un segmento, tal como el archivo de vídeo 150, puede incluir un cuadro de actualización de MPD (no mostrado) antes del cuadro FTY P152. El cuadro 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, el cuadro 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, el cuadro de actualización de MPD puede incluir datos para actualizar la MPD. En algunos ejemplos, el cuadro de actualización de MPD puede seguir inmediatamente a un cuadro de tipo de segmento (STYP) (no mostrado) de archivo de vídeo 150, donde el cuadro 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 al cuadro de actualización de MPD.
[0071] El cuadro MOOV 154, en el ejemplo de la FIG. 4, incluye el cuadro de cabecera de película (MVHD) 156, el cuadro de pista (TRAK) 158 y uno o más cuadros de ampliación de película (MVEX) 160. En general, el cuadro MVHD 156 puede describir características generales del archivo de vídeo 150. Por ejemplo, el cuadro MVHD 156 puede incluir datos que describen cuándo se creó inicialmente 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.
[0072] El cuadro TRAK 158 puede incluir datos para una pista del archivo de vídeo 150. El cuadro TRAK 158 puede incluir un cuadro de cabecera de pista (TKHD) que describe características de la pista correspondiente al cuadro TRAK 158. En algunos ejemplos, el cuadro TRAK 158 puede incluir imágenes de vídeo codificadas, mientras que, en otros ejemplos, las imágenes de vídeo codificadas de la pista pueden estar incluidas en fragmentos de película 164, a las cuales se puede hacer referencia mediante datos del cuadro TRAK 158 y/o de los cuadros S iDx 162.
[0073] En algunos ejemplos, el archivo de vídeo 150 puede incluir más de una pista. Por consiguiente, el cuadro MOOV 154 puede incluir un número de cuadros TRAK igual al número de pistas del archivo de vídeo 150. El cuadro TRAK 158 puede describir características de una pista correspondiente del archivo de vídeo 150. Por ejemplo, el cuadro TRAk 158 puede describir información temporal y/o espacial para la pista correspondiente. Un cuadro TRAK similar al cuadro TRAK 158 del cuadro MOOV 154 puede describir características de una pista de conjunto de parámetros, cuando la unidad de encapsulación 30 (FIG. 3) 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 a nivel de secuencia en la pista de conjunto de parámetros dentro del cuadro TRAK que describe la pista de conjunto de parámetros.
[0074] Los cuadros MVEX 160 pueden describir características de fragmentos de película 164 correspondientes, 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 del cuadro 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 el cuadro MOOV 154. En consecuencia, todas las muestras de vídeo codificadas pueden estar incluidas en fragmentos de película 164, en lugar de en el cuadro MOOV 154.
[0075] El cuadro MOOV 154 puede incluir un número de cuadros MVEX 160 igual al número de fragmentos de película 164 del archivo de vídeo 150. Cada uno de los cuadros MVEX 160 puede describir características de un fragmento correspondiente de los fragmentos de película 164. Por ejemplo, cada cuadro MVEX puede incluir un cuadro de cabecera de ampliación de película (MEHD) que describe una duración temporal para el fragmento correspondiente de los fragmentos de película 164.
[0076] 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 AVC, la imagen codificada incluye una o más unidades NAL VCL que contienen la información para generar 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 a 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 a nivel de secuencia con la presencia de estos en uno de los fragmentos de película 164 dentro de uno de los cuadros MVEX 160 correspondiente al uno de los fragmentos de película 164.
[0077] Los cuadros 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 de 3GPP, u otros formatos de archivo de este tipo, no incluyen necesariamente cuadros SIDX 162. De acuerdo con el ejemplo del formato de archivo de 3GPP, se puede usar un cuadro SIDX para identificar un subsegmento de un segmento (por ejemplo, un segmento contenido dentro del archivo de vídeo 150). El formato de archivo de 3GPP define un subsegmento como "un conjunto autónomo de uno o más cuadros de fragmento de película consecutivos con uno o más cuadros de datos de medios correspondientes, y un cuadro de datos de medios que contiene datos a los que se hace referencia mediante un cuadro de fragmento de película debe seguir a ese cuadro de fragmento de película y preceder al siguiente cuadro de fragmento de película que contiene información acerca de la misma pista". El formato de archivo de 3GPP también indica que un cuadro SIDX "contiene una secuencia de referencias a subsegmentos del (sub)segmento documentado por el cuadro. Los subsegmentos a los que se hace referencia son contiguos en el tiempo de presentación. De forma similar, los octetos a los que un cuadro de índice de segmento hace referencia siempre son contiguos dentro del segmento. El tamaño al que se hace referencia da el recuento del número de octetos en el material al que se hace referencia".
[0078] Los cuadros SIDX 162 proporcionan, en general, 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, desfases de octetos para los subsegmentos, si los subsegmentos incluyen (por ejemplo, comienzan con) un punto de acceso de flujo (SAP), el tipo de SAP (por ejemplo, si el SAP es una imagen de refresco de descodificador instantáneo (IDR), una imagen de acceso aleatorio limpio (CRA), una imagen de acceso de enlace roto (BLA) o similares), una posición del SAP (en lo que respecta al tiempo de reproducción y/o un desfase de octetos) en el subsegmento y similares.
[0079] 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 un cuadro de cabecera de fragmento de película (MFHD, no mostrado en la FIG. 4). El cuadro 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 incluirse por orden de número de secuencia en el archivo de vídeo 150.
[0080] El cuadro 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 truco, tales como realizar búsquedas hasta ubicaciones temporales particulares (es decir, tiempos de reproducción) dentro de un segmento encapsulado por el archivo de vídeo 150. El cuadro MFRA 166 es, en general, opcional y no necesita estar incluido 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 hacer referencia al cuadro MFRA 166 para descodificar y visualizar correctamente los datos de vídeo del archivo de vídeo 150. El cuadro MFRA 166 puede incluir un número de cuadros de acceso aleatorio de fragmento de pista (TFRA) (no mostrados) 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 sin indicaciones) del archivo de vídeo 150.
[0081] 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, el cuadro 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 fragmentos de la subsecuencia temporal pueden estar dispuestos dentro de los segmentos de modo que las tramas/fragmentos de la subsecuencia temporal que dependen de otras tramas/fragmentos de la subsecuencia puedan descodificarse apropiadamente. Por ejemplo, en la disposición jerárquica de los datos, los datos usados para la predicción de otros datos también pueden estar incluidos en la subsecuencia temporal.
[0082] La FIG. 5 es un diagrama de bloques que ilustra un sistema de infraestructura DASH de radiodifusión 180 de ejemplo. El sistema 180 incluye una unidad de gestión de sistema 198, un búfer de medios de duración de GoP 182, un codificador de medios 184, un segmentador 186, un emisor 188, un planificador 190, un formador de tramas 192 y un excitador/amplificador 194. El sistema 180 y, por tanto, cada uno de estos componentes del sistema 180, puede incluirse en un dispositivo de origen, tal como el dispositivo servidor 60 de la FIG. 1 o el dispositivo de preparación de contenido 20 de la FIG. 1. De nuevo, un dispositivo servidor y un dispositivo de preparación de contenido pueden integrarse funcionalmente en un solo dispositivo.
[0083] En el ejemplo del sistema 180, el búfer de medios de duración de GoP 182 recibe y almacena los datos de medios que se van a codificar. El codificador de medios 184 (que, en realidad, puede representar una pluralidad de codificadores de medios, tal como el codificador de audio 26 de la FIG. 1 y el codificador de vídeo 28 de la FIG.
1) codifica datos de medios (por ejemplo, datos de audio, datos de vídeo y/o datos de texto temporizado), encapsula los datos de medios en unidades de capa de abstracción de red (NAL) y proporciona los datos de medios codificados, en forma de unidad NAL 202, al segmentador 186. Además, el codificador de medios 184 envía datos que representan identificadores de MDE explícitos 200 al segmentador 186.
[0084] El segmentador 186 encapsula las unidades NAL recibidas en segmentos respectivos. Por tanto, en general, el segmentador 186 no proporciona información explícita indicativa de las ubicaciones de los MDE dentro de los segmentos. Efectivamente, sin embargo, el segmentador 186 proporciona los MDE al emisor 188, en forma de intervalos de octetos dentro de los segmentos (206). Además, el segmentador 186 también determina requisitos de tiempo de transmisión 204 para los MDE y envía datos representativos de los requisitos de tiempo de transmisión 204 al emisor 188.
[0085] El emisor 188 representa un ejemplo de una unidad de envío de protocolo basada en archivos de acuerdo con las técnicas de esta divulgación. En este ejemplo, el emisor 188 envía datos de los segmentos recibidos de acuerdo con ROUTE. En otros ejemplos, el emisor 188 puede enviar datos de los segmentos recibidos de acuerdo con FLUTE u otros protocolos similares basados en archivos. De acuerdo con las técnicas de esta divulgación, el emisor 188 envía tanto los datos de MDE (encapsulados dentro de unidades de datos basadas en red, por ejemplo, IP, UDP, ROUTE, ALP o similares) 210 como los requisitos de tiempo de transmisión 208 al planificador 190 y el formador de tramas 192. El formador de tramas 192 forma tramas de red que encapsulan los datos de red parea el excitador/amplificador 194 de acuerdo con los datos de planificación determinados por el planificador 190, donde las tramas de red incluyen además una descripción de banda base de eventos de entrega de datos (DDE) de capa física 212. El excitador/amplificador 194 transmite de forma activa los datos, por ejemplo, por medio de la capa de red física, tal como por medio de una radiodifusión ATSC OTA, Ethernet o similar.
[0086] Un sistema de radiodifusión, tal como un sistema del Comité de Sistemas de Televisión Avanzados (ATSC), puede admitir el uso de intervalos de octetos adaptados a medios implementados con MDE dentro de ROUTE u otros protocolos de entrega de objetos, incluidos intervalos de octetos adaptados a medios. La identificación (definición) de los MDE individuales para el sistema puede ser un comportamiento requerido, por lo que el sistema puede entregar los MDE. Es decir, el sistema debe poder determinar qué intervalos de octetos adaptados a medios representan un MDE (o un objeto de datos similar) para empaquetar y enviar el MDE al planificador con el etiquetado de tiempo apropiado.
[0087] Un ejemplo de definición de un MDE es un intervalo de octetos adaptados a medios de medios que son significativos para un códec de recepción de medios. Debido a la estructura de trama de un códec, un MDE puede tener, o no, múltiples muestras en el uso de BMMF ISO de la muestra de términos. Un trama de audio en Codificación de Audio Avanzada de Alta Eficacia (HE-AAC) (ISO/IEC JTC1/SC29/WG11/N7016 (11 de enero de 2005)), que contiene múltiples muestras de audio, es, en sí misma, una sola muestra en un contexto BMFF ISO. Una muestra BMFF ISO en un contexto HEVC puede ser una sola trama de datos de vídeo. Un MDE puede incluir una o varias muestras BMFF ISO. Esta posibilidad existe debido a la interdependencia entre tramas de vídeo sucesivas. Hay un MDE más pequeño posible, pero por conveniencia u otros propósitos, estos MDE atómicos, es decir, los MDE más pequeños posibles, se pueden agregar en un MDE más grande. Los MDE, por lo general, no se superponen.
[0088] Los elementos del sistema 180 de la FIG. 5 que pueden percatarse primero los MDE son el codificador de medios 184, el segmentador 186 y el emisor 188. Las entidades funcionales de la FIG. 5 son conceptuales. Esta construcción lógica en cascada es por conveniencia a la hora de considerar el sistema y no es necesaria. Las funciones podrían integrarse funcionalmente en una sola entidad o, posiblemente, subdividirse entre unidades adicionales o alternativas de una manera diferente. Una ubicación lógica de la formación de MDE está dentro del alcance del codificador de medios 184, el segmentador 186 o la sección de entrada del emisor 188.
[0089] El alcance y la definición de un MDE se definen de acuerdo con el tipo de medio que se maneja. Por ejemplo, el audio puede empaquetarse en segmentos separados o multiplexarse dentro de segmentos, es decir, archivos/objetos BMFF ISO. MPEG DASH (NORMA INTERNACIONAL ISO/IEC 23009-1 Segunda edición 01/05/2014 "Information Technology-Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formats"), por ejemplo, define segmentos multiplexados y no multiplexados. Esto es simplemente un aspecto de la configuración. Como se muestra arriba en la FIG. 5, puede haber una función de configuración de sistema que proporciona configuración a las diversas funciones.
[0090] Ejemplos de algunos aspectos potencialmente configurados incluyen:
• Para DASH
o Duración de segmento
o Composición de segmento, es decir, tipos de medios contenidos en un objeto de medios específico
o Cadencia de tipo de segmento, por ejemplo, un segmento de medios específico contiene un punto de acceso de flujo (SAP) o no
• Para un codificador de vídeo
o Duración de GoP (La asignación específica de nombres de códec varía para dichas estructuras)
o Tipos de GoP, por ejemplo, abierto o cerrado
o Cadencia de tipo de trama, por ejemplo, I, B, B, P, B, B, P...
o Velocidad de trama, resolución, progresivo frente a entrelazado, etc.
o Límites de MDE mediante concordancia de patrones o desde estructuras de medios permitidas, por ejemplo
■ La trama de audio es una muestra atómica MDE e BMFF ISO
■ Una trama I individual (IDR) es un MDE atómico
■ Los grupos de tramas de vídeo son MDE atómicos, como se muestra en la Figura 3
o Tal determinación puede ser tomada o conocida en el codificador o determinada por el segmentador
• Para un codificador de audio
o Frecuencia de muestreo
o Selección de herramientas de codificación
o Detalles de la construcción de tramas de audio de acuerdo con el códec especificado
[0091] En la medida en que estos aspectos sean configuraciones estáticas, las definiciones de MDE asociadas se pueden proporcionar como definiciones estáticas, es decir, la configuración del codificador es conocida por el segmentador y/o el emisor, ya que es un conjunto configurado estático de ajustes. Suponiendo que el vídeo ejecuta una sola cadencia definida de tipos de tramas de vídeo, los límites de MDE pueden estar definidos por la configuración. Véase la FIG. 7 a continuación para un ejemplo de una cadencia de vídeo específica y sus MDE atómicos. Cabe destacar que esta figura muestra el orden de visualización de las tramas de vídeo.
[0092] La FIG. 6 es un diagrama conceptual que ilustra un ejemplo de composición de alto nivel de MDE.
[0093] La FIG. 7 es un diagrama conceptual que ilustra un ejemplo de cadencia tipo trama y MDE definidos correspondientes. En particular, la FIG. 7 ilustra las tramas de vídeo 250-296. Las distintas tramas de vídeo se etiquetan como I, P o B, para representar si los tramas se intrapredicen (I), se intrapredicen unidireccionalmente (P) o se interpredicen bidireccionalmente (B).
[0094] Las tramas de vídeo representadas en la FIG. 7 se ilustran en orden de visualización. Si la figura estuviera dibujada en orden de entrega, las agrupaciones de tramas aparecerían como intervalos de octetos contiguos en el flujo de origen del codificador de vídeo y dentro del contenedor BMFF ISO, es decir, un segmento de medios para DASH.
[0095] La identificación de los límites de MDE para tal cadencia definida se puede lograr por medio de tablas que, por ejemplo, definen las N primeras tramas de vídeo de GoP como MDE 1, las M siguientes tramas como MDE 2, etc., o la cadencia específica de los tipos de trama, por ejemplo concordancia de patrones, que se reconoce en la sintaxis de códec. El uso del procedimiento de tablas es simple y conveniente, si la cadencia de los tipos de trama es estática en cada segmento. Esto es potencialmente un procedimiento conveniente para el tipo de medio de audio para el que puede haber un número fijo de tramas de códec de audio por MDE y por códec. (Esto es también un ejemplo de una regla trivial). Estas tablas que pueden contener una descripción explícita de un patrón o reglas pueden expresarse como XML. La FIG. 7 muestra que algunos MDE atómicos pueden agregarse para formar un MDE más grande. Esto puede determinarse por medio de reglas, concordancia de patrones o una combinación de ambas cosas. Estos procedimientos pueden implementarse dentro del codificador de medios y transmitirse como descripción explícita al segmentador y al emisor, por ejemplo, ROUTE o MMT.
[0096] Como se mencionó antes brevemente, la tabla de configuración puede formarse de acuerdo con una regla. La lógica de dicha regla puede permitir que el funcionamiento de la función de identificación de MDE (intervalo de octetos adaptados a medios) sea adaptativo. Esto es conveniente, por ejemplo, si un segmento (objeto BMFF ISO) está multiplexado, es decir, contiene varios tipos de medios. La función de identificación de MDE del segmentador puede analizar sintácticamente, por ejemplo, subtítulos, audio y vídeo. Además, la cadencia de, por ejemplo, los tipos de tramas de vídeo puede ser adaptativa.
[0097] Ejemplos de aspectos adaptativos del vídeo desde una perspectiva de MDE incluyen:
• Cadencia del tipo de trama de vídeo para habilitar GoP abiertos y cerrados en una secuencia de segmentos
• Recuento de tramas de vídeo y cadencia de tipos por segmento o período
o Por ejemplo, anuncios de 24 fps y contenido de 30 fps intercalados
o Tal cambio en la velocidad de trama puede provocar un cambio en la cadencia del tipo de trama de vídeo y, como consecuencia, en la cadencia de MDE.
[0098] Se describen técnicas para admitir la identificación de MDE dentro de segmentos, es decir, intervalos de octetos adaptados a medios que son contextualmente relevantes para un códec de medios asociado para admitir un protocolo adaptado a intervalo de octetos, por ejemplo ROUTE o MMT.
[0099] Ejemplos de técnicas para admitir dicha definición de MDE, es decir, intervalos de octetos adaptados a códec de medios, pueden incluir:
• Procedimientos tabulares que describen secuencias específicas, tales como:
o Tipo de trama de vídeo
o Secuencias de tipos de tramas de vídeo
o Número de, por ejemplo, tramas de vídeo o audio
o Combinaciones de estructuras descritas
o Coincidencia de patrones de una secuencia específica de, por ejemplo, tipos de tramas de vídeo o Estos procedimientos implementados en un codificador de medios, segmentador o emisor
• Detección basada en MDE basado en reglas
o Por ejemplo, una configuración específica de un códec HEVC puede permitir estas construcciones lógicas de secuencias de tipo de trama:
■ Una secuencia de inicio de trama (MDE) satisface este primer conjunto de condiciones.
■ Una secuencia de final de trama (MDE) satisface un segundo conjunto de condiciones.
■ Una secuencia de tipos de tramas satisface un tercer conjunto de condiciones.
• Los procedimientos de patrones y reglas descritos se pueden combinar, por ejemplo:
o Este patrón se descubre
o entonces, esta regla debe aplicarse
• Un codificador de medios puede tener una librería de modos operativos definidos con construcciones de MDE específicas.
o El codificador de medios comunica dicho modo operativo en tiempo real con los medios codificados que se pasan al segmentador
• Consúltese el Apéndice A para ver un ejemplo de lógica basada en reglas de archivo o XML y lógica basada en patrones.
[0100] Cada MDE puede definirse con un tiempo de transmisión más temprano y/o más tardío. Esto beneficia al planificador, cuya tarea es asignar medios a las ranuras de entrega, por ejemplo, tramas FEC específicas en ATSC 3.0 en la capa física. Estos atributos más tempranos y más tardíos pueden estar limitados por diferentes aspectos, tales como:
• Tiempo de transmisión más temprano: Eso es literalmente el instante en que se puede irradiar el primer bit de un MDE (o segmento) dado. Este bit irradiado más temprano incluye todo el protocolo de encapsulación relacionado.
• Tiempo de transmisión más tardío: Esto es literalmente el último instante en el que va a irradiarse el último bit de un MDE (o segmento). Este último bit incluye todo el protocolo de encapsulación relacionado.
[0101] El tiempo de transmisión más temprano puede estar limitado por la configuración del sistema. Por ejemplo, la cadencia de tramas de capa física podría tener tramas que comiencen en límites de segundos completos del tiempo de capa física ATSC (48b TAI segundos, 10b ms o, posiblemente, otra fracción de segundo). Esta cadencia de tramas de capa física puede estar, o no, directamente relacionada con la(s) duración(es) del segmento de medios. Un período dado de un programa, por ejemplo, podría tener que entregarse en su totalidad antes del final del segundo completo que precede a un anuncio que es un anuncio de reemplazo. El anuncio de reemplazo de cola, por ejemplo, no comenzará a entregarse hasta que comience el siguiente segundo completo. Para tiempos fuera de los límites del período, el tiempo de transmisión más temprano podría ser, por ejemplo, un segundo completo anterior.
[0102] El tiempo de transmisión más tardío puede estar relacionado con el tiempo de descodificación del último medio descodificado contenido dentro de un MDE etiquetado. El etiquetado aplicado a la entrega a nivel de segmento de medios puede ser determinado por la línea de tiempo de disponibilidad de segmento/DASH nominal. El tiempo de transmisión más tardío puede ser coherente con el cumplimiento del límite de tiempo de entrega del segmento. El requisito de tiempo de transmisión más tardío para el último MDE (intervalo de octetos adaptado a medios) de un segmento puede ser el mismo que el del segmento completado.
[0103] La FIG. 8 es un diagrama conceptual que representa una vista simple del tiempo de sistema. Es decir, la FIG. 8 representa una vista de nivel superior del tiempo de sistema. Este es el caso de la reproducción a nivel de segmento o la reproducción basada en intervalo de octetos. Una diferencia en relación con la reproducción de MDE es que el retardo del receptor estático puede ser notablemente más corto que para la reproducción de segmentos. El tiempo de reloj de estación se puede entregar al receptor por medio de la capa física y el protocolo de soporte. El tiempo de reloj de receptor en cualquier instante, después de la sincronización, es el tiempo actual de reloj de estación menos el tiempo actual de vuelo de señal desde el transmisor dominante al receptor.
[0104] La FIG. 9 es un diagrama de bloques que representa el sistema 300, que representa una infraestructura de transmisión configurada con una relación de tiempo. Es decir, la FIG. 9 proporciona una representación conceptual de cómo los retardos de tiempo pueden afectar el proceso de transmisión del sistema 300. En este ejemplo, el sistema 300 incluye un búfer de medios de duración GoP 306, un codificador de medios 308, un segmentador 310, un control de velocidad 304, una unidad de gestión de sistema 302, un emisor 312, un planificador 314 y un excitador/amplificador 316.
[0105] En este ejemplo, el búfer de medios de duración de GoP 306 almacena (es decir, guarda temporalmente) datos de medios sin procesar que se van a codificar. El codificador de medios 308 recupera datos de medios a codificar desde el búfer de medios de duración de GoP 306, codifica los datos de medios, encapsula los datos de medios codificados en forma de unidad NAL y entrega las unidades NAL 320 al segmentador 310. Debe entenderse que los datos de medios codificados también incluyen MDE, por ejemplo, como se muestra en la FIG. 7. Además, como se explicó anteriormente, cada uno de los m De puede tener requisitos de tiempo de transmisión, tales como requisitos de tiempo de transmisión más temprana y/o más tardía.
[0106] El segmentador 310 recibe las unidades NAL 320 desde el codificador de medios 308 y encapsula uno o más MDE (es decir, una o más de las unidades NAL) en segmentos respectivos. De nuevo, los segmentos pueden corresponder a archivos que pueden entregarse de forma independiente asociados a URL respectivos, donde cada URL puede identificar de manera única el segmento correspondiente. Los MDE pueden corresponder a intervalos de octetos respectivos de los segmentos. Además, el segmentador 310 puede determinar los requisitos de tiempo de transmisión para cada uno de los MDE y pasar al emisor 312 tanto los requisitos de tiempo de transmisión 322 como los MDE (en forma de intervalos de octetos de los segmentos) 324.
[0107] El emisor 312 puede funcionar de acuerdo con un protocolo de entrega basado en archivos, tal como ROUTE. Por tanto, el emisor 312 puede encapsular partes respectivas de los segmentos (por ejemplo, los MDE) en respectivas unidades de entrega basadas en red 328, tales como paquetes o tramas, al planificador 314 para su transmisión. Además, el emisor 312 proporciona los requisitos de tiempo de transmisión 326 al planificador 314, de manera que el planificador 314 puede entregar las unidades de entrega basadas en red a un dispositivo cliente (no mostrado en la FIG. 9) de acuerdo con los requisitos de tiempo de transmisión. Más en particular, el planificador 314 forma una descripción de banda base de los eventos de entrega de datos (DDE) de capa física 330 y pasa la descripción de la banda base de los DDE de capa física 330 al excitador/amplificador 316. Después, el excitador/amplificador 316 transmite datos en la capa física a, por ejemplo, el dispositivo cliente.
[0108] La FIG. 9 también representa diversos retardos introducidos por el sistema 300 al enviar datos de medios a un dispositivo cliente. Por ejemplo, el tiempo que transcurre entre que los datos de medios se almacenan en un búfer y los datos de medios se planifican para su transmisión se denomina retardo de duración de análisis 332. El retardo de duración de análisis incluye, en particular, el retardo de una sola pasada para una muestra específica 334, que es el tiempo entre que el codificador de medios 308 codifica la muestra y encapsula la muestra en una unidad NAL y proporciona la unidad NAL al segmentador 310, como se muestra en la FIG. 9. Además, el tiempo entre tener datos planificados para su transmisión y los datos que se transmiten realmente se denomina retardo de transmisor y STL 336.
[0109] Definir el tiempo para los datos de medios es una cuestión de considerar cuánto tiempo antes del tiempo de irradiación tienen que estar funcionando los diversos bloques funcionales de la infraestructura de transmisión del sistema 300 y cuánto tiempo después de la recepción los medios serán entregados al descodificador o descodificadores de medios. En consecuencia, este análisis se divide en antes de la irradiación y después de la recepción. ¿Por qué es esencial el tiempo de irradiación real? Para lograr un cambio síncrono potencial entre los flujos de origen para una aplicación, tal como la inserción de anuncios personalizados. El tiempo real que limita la transmisión de medios puede verse limitado. El tiempo entregado al receptor se sincroniza con el tiempo de irradiación de la función de arranque de la capa física. Debe entenderse y controlarse el lapso de tiempo en que un período específico está presente en la capa física. Un MDE o segmento de medios está etiquetado con un intervalo de tiempo durante el cual se le permite irradiar, por lo que todos los procesos antes de la emisión real están desplazados en el tiempo por un retardo constante asociado a un bloque o función específicos. La FIG. 9 representa una organización plausible de dominios de tiempo dentro de la infraestructura de transmisión. Esta división no es un requisito, es simplemente conveniente desde una perspectiva conceptual. A continuación se muestra una lista de algunos posibles dominios de tiempo y sus duraciones plausibles.
[0110] Retardo de transmisor y de enlace de transmisor de estudio (STL) 336: El retardo definido en estos bloques es lo suficientemente largo como para que el transmisor pueda empezar a emitir una trama de capa física determinada que acaba de empezar a entregarse al STL, una vez transcurrido este período. Este retardo incluye nominalmente al menos una duración de trama de capa física, una duración de intercalador y el retardo de transmisión más largo en la red de distribución SFN. Se podría considerar la ejecución de este retardo más corto, por ejemplo, en cada subtrama. La admisión de subtramas puede provocar, posiblemente, un aumento de la velocidad máxima en el enlace de transmisor de estudio, es decir, el enlace de transmisor de estudio debe mantener el rendimiento máximo permitido de la capa física durante al menos una duración de subtrama. La restricción en una implementación de trama completa es la asignación de velocidad máxima permitida medida sobre una base de trama completa, que podría ser menor que por subtrama, aunque podría ser la misma si todos los PLP activos tienen la misma capacidad.
[0111] Retardo de duración de análisis 332: Una de las tareas del planificador 314 es asignar medios a la capa física de tal manera que cumpla con sus límites de tiempo definidos y cumpla con las limitaciones de capacidad según las definiciones actuales de PLP de capa física. Para lograr esto, el planificador 314 debería analizar al menos la duración más larga de una trama de capa física de medios. El planificador 314 podría fallar en última instancia si no planifica correctamente al menos un tiempo de trama de capa física de medios codificados por tiempo de trama de capa física transcurrido. Esta es una tarea acumulativa. Una trama de capa física con menos de su duración de tiempo de medios puede desfasarse con una trama de capa física que representa más tiempo de medios.
[0112] La duración de una trama de capa física puede ser más corta que la duración de segmento de medios o de GoP más larga. En este caso, el límite está relacionado con al menos la duración de segmento de medios o la duración de GoP más larga si el GoP está compuesto por múltiples segmentos de medios. El planificador 314 puede garantizar que el segmento de medios/GoP de mayor duración se planifique correctamente. El planificador 314 puede generar además al menos un segundo de segmento de medios/GoP codificado por segundo de medios. Como se describe aquí, el retardo de duración de análisis 332 no es constante, ya que el planificador 314 tiene la flexibilidad de tiempo de irradiación más tardío - tiempo de irradiación más temprano en el tiempo de irradiación real.
[0113] Retardo de una sola pasada 334: Si los medios de entrada se transmitieran directamente al codificador de medios 308 y al segmentador 310, habría un retardo de descodificación estáti
desde la entrada de una primera trama de un GoP hasta el tiempo de descodificación de la primera trama descodificada, como se describe en el primer segmento resultante. Esta es una construcción conceptual.
[0114] Puede darse el caso de que el codificador de medios 308 (que puede representar múltiples codificadores) pueda producir con gran probabilidad más de un tiempo de medios de contenido codificado por tiempo de segmento de medios. Es probable que las limitaciones reales estén definidas por el número de "pasadas" que utiliza el esquema de codificación. En este contexto, una "pasada" es una instancia de una codificación de medios. Si el codificador de medios 308 pudiera cumplir con todos los objetivos en una pasada de codificación, entonces el requisito sería al menos una duración de segmento de medios por tiempo de segmento de medios transcurrido. Es bastante difícil obtener el tamaño de datos deseado en la primera pasada, por lo que un planificador puede intentar limitar las pasadas a una codificación de dos pasadas. En la codificación de dos pasadas, una primera pasada puede proporcionar una calibración sobre la complejidad de los datos de medios que se van a codificar, y una segunda pasada puede usarse para ajustar las decisiones tomadas durante la primera pasada para cumplir con la capacidad de la capa física. Si la pasada de codificación inicial da como resultado tamaños de datos que son sustancialmente diferentes del tamaño de datos final deseado/requerido, entonces se puede realizar una tercera pasada u otro ajuste en la velocidad de datos. Cabe señalar que el planificador tiene que funcionar con el tamaño real de los datos que se entregarán en la capa física, incluida toda la encapsulación.
[0115] Suponiendo que los medios se transmiten al codificador de medios 308 en tiempo real, y que se trata de un esquema de codificación de múltiples pasadas, se requiere potencialmente un retardo de GoP completo para capturar los medios de transmisión en tiempo real por delante del codificador o codificadores de medios. Los tiempos de descodificación proporcionados con los medios codificados en el receptor deben reflejar todo el retardo de la infraestructura y el receptor. Se espera que estos se basen en la reproducción de segmentos de medios. Los tiempos de MDE se pueden calcular desde el punto de inicio de RAP m De en relación con lo que habría ocurrido para la reproducción a nivel de segmento.
[0116] La FIG. 10 es un diagrama conceptual que ilustra múltiples segmentos por GoP con una ubicación de RAP escalonado. Un tiempo de segmento de RAP escalonado como se ilustra en la FIG. 10 (es decir, múltiples duraciones de análisis por GoP) pueden reducir el tiempo de captura mínimo requerido antes de la planificación de medios y, por lo tanto, una latencia general más baja. Esto tiene beneficios de multiplexación estadísticos algo limitados porque, como se ilustra, la velocidad de datos para una trama de capa física dada está dominada por un solo tamaño de datos de segmento RAP. El etiquetado de tiempo de los medios se captura con los medios.
[0117] Como se describió anteriormente, el retardo de transmisión, o el retardo hasta la irradiación, se puede expresar como:
Duración de retardo de análisis - Retardo de un sola pasada hasta muestra específica Retardo de transmisor y de STL
(Tiempo de trama Profundidad de intercalador Distribución de SFN)
[0118] La FIG. 11 es un diagrama conceptual que ilustra un retardo mínimo para descodificar tiempo para la reproducción de medios. Es decir, la FIG. 11 representa los retardos mínimos que afectan a los tiempos de descodificación de medios para la reproducción de segmentos de medios y de MDE. Una diferencia entre los segmentos de medios y la reproducción de MDE es que el tiempo de inicio de la reproducción de MDE en el retardo a nivel de segmento debe considerar el retardo de apilamiento más largo más un retardo de presentación sugerido, mientras que la reproducción a nivel de MDE es el retardo real de la configuración estática del dispositivo individual más un retardo para garantizar que el llenado del búfer ROUTE sea suficiente. El valor total de retardo MDE puede ser menor que un tiempo de segmento.
[0119] El retardo total de descodificación de segmento de extremo a extremo puede expresarse como:
Duración de retardo de análisis - Retardo de un sola pasada hasta muestra específica Retardo de transmisor y de STL
(Tiempo de trama Profundidad de intercalador Distribución de SFN) Tiempo de vuelo Retardo hasta tiempo de inicio de disponibilidad MPD@RetardoPresentaciónSugerido Retardo dentro del segmento hasta muestra específica
[0120] El retardo total de descodificación de MDE de extremo a extremo puede expresarse como:
Duración de retardo de análisis - Retardo de un sola pasada hasta muestra específica Retardo de transmisor y de STL
(Tiempo de trama Profundidad de intercalador Distribución de SFN) Tiempo de vuelo Retardo de llegada en receptor ROUTE o MMT similar Tiempo de demora de intervalo de octetos de transmisión en continuo Retardo dentro de segmento hasta muestra específica
[0121] En lo que antecede se han analizado determinados detalles de procedimientos de metadatos de tiempo para la planificación. Aquí se analizan más detalles acerca de los procedimientos de metadatos de tiempo para la planificación. La generación de metadatos de tiempo para el/los MDE puede basarse en un punto de anclaje definido por el último tiempo de transmisión requerido debido al inicio de un segmento. El tiempo más tardío requerido para un MDE puede ser lineal en el orden del primer tiempo de descodificación de cada MDE respectivo después del inicio de segmento. El tiempo más tardío puede estar limitado por el tiempo de descodificación de la muestra actual a descodificar en el MDE, en relación con la primera muestra descodificada del segmento, que también es el primer MDE descodificado del segmento. Este tipo de procedimiento es lineal en tiempo de descodificación, que es solo un enfoque para definir los metadatos del tiempo de transmisión más tardío.
[0122] Hay aspectos adicionales a considerar, por ejemplo, posibles componentes de medios de carga frontal, tales como audio y subtítulos. Dado que estos componentes de medios son pequeños en relación con el vídeo, pero es posible que la presentación completa no se reproduzca sin ellos, posiblemente sea más simple enviarlos antes del RAP de vídeo, pero después de objetos de metadatos posiblemente requeridos, tales como MPD e IS. Esto es, en general, un procedimiento que se puede usar para garantizar que todos los pequeños objetos de datos requeridos se entreguen primero.
[0123] La FIG. 12 es un diagrama conceptual que ilustra una sincronización de capa física opcional y metadatos relacionados. La relación de las tramas de la capa física con el T-RAP es un aspecto relevante con respecto a la transmisión más temprana. Por ejemplo, considérese el ejemplo de la FIG. 12, que muestra el tiempo más temprano de libertad de adelantarse al inicio de la trama física nominal. Esto puede afectar el tiempo de cambio de canal, a menos que haya una secuencia completa de metadatos de inicio en todas las capas.
[0124] El diseño de una capa física puede ser capaz, o no, de representar la sincronización con precisión en los límites de GoP como se muestra arriba. La definición de posición de sincronización puede estar limitada a otras ubicaciones por la numerología de la capa física. Un procedimiento viable es utilizar una ubicación cercana a la duración de GoP. Cerca podría ser, por ejemplo, el próxima instante de tiempo disponible, es decir, antes del límite nominal de tráfico previo que lleva la transformación o después. La escala de tiempo para una transformación mínima puede estar en la escala de 1 ms, mientras que el máximo puede estar en el rango de 10 ms.
[0125] La función de planificación puede considerar nominalmente un bloque de tiempo fijo, posiblemente relacionado con la duración de GoP de medios o la duración de segmento, como se describió anteriormente. Para un esquema de duración de GoP más eficiente, es posible que se puedan planificar todos los medios y que quede disponible alguna capacidad significativa en (N) para su posible uso en el siguiente intervalo de análisis (N+1). En tal condición, el planificador puede intentar llenar esta capacidad en (N) con medios del siguiente intervalo de análisis (N+1). Esto se puede habilitar mediante los metadatos de tiempo, lo que permite la transmisión en un intervalo anterior por medio del parámetro más temprano. Una vez que se conoce la porción completa del intervalo de procesamiento, el componente de capa física puede insertar un elemento de sincronización de trama opcional, proporcionado con el propósito de permitir la adquisición de servicios de medios antes de lo que sería posible con la formación periódica y cuasifija de tramas, por ejemplo, arranque y preámbulo de ATSC 3.0.
[0126] La FIG. 13 representa un ejemplo de un procedimiento que incluye una secuencia de etapas correspondientes a eventos potenciales de sistema para permitir la adquisición de servicios para múltiples capas de datos de medios. Es decir, la FIG. 13 es un diagrama de flujo que ilustra una secuencia de ejemplo de eventos de adquisición. El procedimiento de la FIG. 13 puede realizarse mediante diversos dispositivos y sistemas mostrados en el presente documento, tales como el dispositivo de preparación de contenido 20 y el dispositivo de origen 60 de la FIG. 1, el sistema 180 de la FIG. 5 o el sistema 300 de la FIG. 9. Para propósitos de ejemplo y de explicación, el procedimiento de la FIG. 13 se explica con respecto al sistema 180 de la FIG. 5.
[0127] El sistema 180 entrega una secuencia de datos que permite el inicio de un servicio lineal basado en aplicaciones o lineal (350). La FIG. 13 representa una secuencia típica de eventos en un receptor y el orden de entrega del sistema (180) de metadatos relacionados, otros objetos y archivos de medios relacionados con un inicio típico de recepción de servicio. Este inicio de servicio se inicia típicamente (350) mediante la entrada del número de canal, la entrada de tecla de subida/bajada de canal o la selección de guía de un servicio. La adquisición de la capa física se inicia mediante la recepción de un patrón de arranque o sincronización de sistema (352). Los metadatos de sistema relacionados con la capa física y la adquisición de metadatos de sistema adicionales se logran mediante la recepción de metadatos de descripción de capa física similar o preámbulo (354). Tras la identificación de la ubicación de los PLP deseados u otros flujos de paquetes de la capa física en la forma de onda, se reciben flujos de paquetes deseados que contienen ALP, otro protocolo de encapsulación similar que contiene un mapa (referencia cruzada) de diversos ID de flujo de paquetes (ID PLP) con respecto a un IP contenido u otros ID o direcciones de flujo de paquetes similares (356). El preámbulo o similar (354) contiene una bandera que identifica la presencia de metadatos de sistema (LLS) que identifica detalles de servicio como el tiempo del sistema, composición del servicio (SLT), posible información de alerta (AEAT) (358). El SLT disponible en los LLS (358) contiene la ubicación de los detalles por servicio en el SLS (360). Los PLP que llevan el servicio también pueden contener una aplicación que puede incluir una aplicación de tiempo de ejecución (362), que puede permitir que el servicio de televisión funcione en una interfaz basada en navegador. Si está presente, la aplicación puede iniciarse antes o después del inicio del servicio. Una vez que se completan estas etapas, desencadenadas por la recepción de datos relacionados, puede iniciarse la reproducción de medios a partir de la recepción y descodificación de un IS (364) y el segmento de medios relacionado (366). Entonces puede comenzar un servicio lineal basado en aplicaciones o lineal (368).
[0128] El retardo de descodificación de extremo a extremo del/de los MDE es un tiempo estático anterior a la descodificación a nivel de segmento. Este desfase estático se puede lograr por medio de los metadatos existentes en la MPD o una reescritura de la MPD que cambia el valor de los metadatos para permitir la reproducción MPD de los MDE. El valor del desfase se puede determinar a partir de la primera reproducción de RAP por medio de MDE en relación con el tiempo en el que se reproduciría el primer RAP desde el nivel de segmento.
[0129] Las características relacionadas con la planificación de un MDE pueden incluir:
• Organización temporal de tipos de medios y metadatos para minimizar el tiempo de adquisición.
o Proporcionar tipos de datos de medios más pequeños con tiempos más tempranos o más tardíos para garantizar la entrega completa y como una simplificación relativa al intento de intercalación con otros medios a través de muchos objetos planificados más pequeños. Este procedimiento da como resultado una mayor flexibilidad en la planificación, es decir, algunos objetos más grandes con más latitud de tiempo en lugar de muchos objetos más pequeños con requisitos estrictos. Una mayor flexibilidad de planificación da como resultado generalmente resultados superiores en lo que respecta a la eficacia global.
o Si se desea un rendimiento más robusto para el audio y metadatos esenciales, estos se pueden planificar juntos en una canalización de capa física más robusta.
o En caso de que se desee una intercalación específica de tipos de medios en una canalización de entrega común, el uso de un segmento multiplexado puede ser más sencillo de implementar. Las muestras dentro del objeto de medios multiplexados se proporcionan en el orden de entrega/descodificación.
• Procedimientos para preservar una rápida adquisición por medio de ubicaciones de sincronización de capa física opcionales.
o Reconocimiento de entrega de T-RAP antes de la ubicación nominal, es decir, sincronización de capa física nominal de cola o intervalo de análisis nominal relacionado.
o Adaptación basada en el ciclo de planificación actual habiendo cumplido todas las solicitudes de entrega, es decir, si se han cumplido todas las solicitudes de datos con las últimas en el período de capa física de trama nominal.
• Medios para adaptar una duración de tiempo no exacta de trama de capa física a un intervalo de análisis alineado con GoP de medios utilizando la regla de que el transmisor debe comenzar en un segundo completo y ms conocidos. (El modo de sincronización siempre se ejecutará en segundos y milisegundos pares por definición). El modo de símbolo siempre mantendrá un número entero de tiempo transcurrido de símbolos a partir de un segundo y milisegundo de tiempo ATSC. (Las velocidades de símbolo se pueden cambiar entre valores predefinidos especificados en o determinados a partir de la información de configuración).
o Asignación de sincronización de tramas a la ubicación de símbolo disponible más cercana en el tiempo que sigue la posición nominal relativa al intervalo de análisis.
o Asignación de sincronización de tramas a la ubicación disponible más cercana en un símbolo por delante de la posición de intervalo de análisis nominal.
o Cualquier otro esquema basado en la sincronización de capa física basada en reglas relativo a un intervalo de análisis definido.
o Intervalo de análisis definido vinculado a un GoP de medios o estructura similar.
• Posible procedimiento de baja latencia basado en intervalos de análisis basados en duraciones de segmento en lugar de los GoP.
o Gestión de velocidad principal basada en segmentos RAP.
o Ajuste de segmentos no RAP de cola para compensar una PSNR fallida u otra métrica de calidad.
[0130] Esta divulgación describe de forma genérica diversas técnicas, que pueden usarse solas o en cualquier combinación, para identificar las ubicaciones de los MDE, intervalos de octetos adaptados a medios, en protocolos de transporte de archivos, tales como ROUTE o MMT. Estas técnicas pueden basarse en la descripción explícita y la concordancia de patrones válidos o la determinación de patrones válidos mediante una o más reglas. Estas técnicas pueden combinarse. No hay restricción en el orden de combinación. Asimismo, esta divulgación también describe aspectos de tiempo como antecedentes para el análisis de técnicas para organizar la sincronización de capa física y otros aspectos de entrega. Estas técnicas pueden permitir una adquisición rápida en sistemas con ubicaciones de sincronización variables o inexactas en relación con un intervalo de análisis relacionado con medios.
[0131] La Fig. 14 es un diagrama de flujo que ilustra la invención reivindicada. El procedimiento de la FIG. 14 se explica como realizado por una unidad de envío de protocolo basado en archivos, tal como el emisor 188 de la FIG. 5 o el emisor 312 de la FIG. 9. Con propósitos explicativos, el procedimiento de la FIG. 14 se explica con respecto al emisor 312 de la FIG. 9, aunque debe entenderse que otras unidades pueden configurarse para realizar este procedimiento u otro similar. Como se analiza anteriormente, el emisor 312 representa un ejemplo de una unidad de envío de protocolo basado en archivos, por ejemplo, una unidad que envía datos de acuerdo con el protocolo ROUTE o el protocolo FLUTE, u otros protocolos de transmisión basados en archivos.
[0132] Inicialmente, en el ejemplo de la FIG. 14, el emisor 312 recibe uno o más segmentos que incluyen uno o más MDE (380). Por ejemplo, los MDE pueden corresponder a intervalos de octetos entregables de los segmentos. A continuación, el emisor 312 determina las ubicaciones de MDE (382). En general, el emisor 312 no recibe información explícita que señalice las ubicaciones de los MDE, sino que utiliza una o más de las técnicas de esta divulgación para procesar datos de los segmentos para determinar las ubicaciones de los MDE. Por ejemplo, el emisor 312 puede realizar técnicas de concordancia de patrones o reglas que definan cómo se pueden identificar los MDE, como se analizó anteriormente. El emisor 312, en consecuencia, puede usar las técnicas de concordancia de patrones, reglas u otras técnicas similares para identificar MDE dentro de los segmentos.
[0133] El emisor 312 puede determinar además los requisitos de tiempo de transmisión para los MDE (384). Por ejemplo, el emisor 312 puede analizar datos de un archivo de manifiesto correspondiente a los segmentos y determinar los requisitos de tiempo de transmisión a partir del archivo de manifiesto. El archivo de manifiesto puede comprender, por ejemplo, un MPD de acuerdo con DASH. Los requisitos de tiempo de transmisión pueden representar el tiempo de transmisión más temprano y/o el tiempo de transmisión más tardío para uno o más de los MDE, como se analizó anteriormente.
[0134] En última instancia, el emisor 312 puede proporcionar los MDE y datos que representan los requisitos de tiempo de transmisión para los MDE a una unidad de envío de capa física (386), tal como el planificador 314 y el excitador/amplificador 316. De esta manera, el planificador 314 puede planificar la transmisión de los MDE de acuerdo con los requisitos de tiempo de transmisión, de modo que el excitador/amplificador 316 transmita datos de los MDE no antes del tiempo de transmisión más temprano y/o no más tarde del tiempo de transmisión más tardío.
[0135] De esta manera, el procedimiento de la FIG. 14 representa un ejemplo de un procedimiento que incluye, mediante una unidad de envío de protocolo basado en archivos de un dispositivo de origen, recibir un flujo de datos que comprende segmentos de datos de medios desde un segmentador del dispositivo de origen que forma los segmentos, comprendiendo cada uno de los segmentos un respectivo archivo recuperable individualmente asociado a un único localizador de recursos uniforme (URL) o identificador de recursos uniforme (URI), determinar ubicaciones de los eventos de entrega de medios (MDE) en el flujo de datos de medios, donde los MDE incluyen datos para al menos una parte de uno de los segmentos, determinar uno o más requisitos de tiempo de transmisión para los MDE que representan los momentos en los que los MDE van a enviarse a un dispositivo cliente, y proporcionar los MDE y datos que representan los requisitos de tiempo de transmisión a una unidad de envío de capa física del dispositivo de origen de acuerdo con ranuras de entrega disponibles para la unidad de envío de capa física.
[0136] En uno o más ejemplos, las funciones descritas se pueden implementar en hardware, software, firmware o en cualquier combinación de los mismos. Si se implementan en software, las funciones pueden almacenarse en, o transmitirse por, un medio legible por ordenador como una o más instrucciones o código, y ejecutarse mediante una unidad de procesamiento basada en hardware. Los medios legibles por ordenador pueden incluir medios de almacenamiento legibles por ordenador que correspondan a un medio tangible, tales como medios de almacenamiento de datos, o medios de comunicación que incluyan cualquier medio que facilite la transferencia de un programa informático de un lugar a otro, por ejemplo, de acuerdo con un protocolo de comunicación. De esta manera, los medios legibles por ordenador pueden corresponder, en general, a (1) medios de almacenamiento tangibles legibles por ordenador que sean no transitorios o a (2) un medio de comunicación tal como una señal o una onda portadora. Los medios de almacenamiento de datos pueden ser cualquier medio disponible al que se puede acceder mediante 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.
[0137] A modo de ejemplo, y no de limitación, dichos medios de almacenamiento legibles por ordenador pueden comprender RAM, r Om , EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, memoria flash o cualquier otro medio que se pueda usar para almacenar el código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. Además, 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 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 incluidos 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 tangibles no transitorios. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen habitualmente datos magnéticamente y otros discos reproducen datos ópticamente con láseres. Las combinaciones de lo anterior también se deben incluir dentro del alcance de los medios legibles por ordenador.
[0138] 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 integrados o discretos equivalentes. Por consiguiente, el término "procesador", como se usa en el presente documento, se puede referir a cualquiera de las estructuras anteriores 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 de software dedicados configurados para la codificación y la descodificación, o incorporarse en un códec combinado.
Además, las técnicas se podrían implementar por completo en uno o más circuitos o elementos lógicos.
[0139] Las técnicas de esta divulgación se pueden implementar en una amplia variedad de dispositivos o aparatos, incluidos un teléfono inalámbrico, un circuito integrado (IC) o un conjunto de IC (por ejemplo, un conjunto de chips). En esta divulgación se describen diversos componentes, módulos o unidades para destacar aspectos funcionales de dispositivos configurados para realizar las técnicas divulgadas, pero 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 incluyen uno o más procesadores descritos anteriormente, junto con software y/o firmware adecuados.
[0140] Se han descrito diversos ejemplos. Estos y otros ejemplos están dentro del alcance de las siguientes reivindicaciones.

Claims (14)

REIVINDICACIONES
1. Un procedimiento (1400) de transporte de datos de medios, comprendiendo el procedimiento, mediante una unidad de envío de protocolo basado en archivos de un dispositivo de origen:
recibir (380) un flujo de datos que comprende segmentos de datos de medios desde un segmentador del dispositivo de origen que forma los segmentos, comprendiendo cada uno de los segmentos un respectivo archivo que puede recuperarse de forma individual asociado a un localizador de recursos uniforme, URL, o un identificador de recursos uniforme, URI, únicos;
determinar (382) ubicaciones de eventos de entrega de medios, MDE, en el flujo de datos de medios, donde los MDE incluyen datos para al menos una parte de uno de los segmentos;
determinar (384) uno o más requisitos de tiempo de transmisión para los MDE que representan momentos en los que los MDE van a enviarse a un dispositivo cliente; y
proporcionar (386) los MDE y los datos que representan los requisitos de tiempo de transmisión a una unidad de envío de capa física del dispositivo de origen de acuerdo con ranuras de entrega disponibles para la unidad de envío de capa física.
2. El procedimiento de la reivindicación 1, en el que determinar las ubicaciones de los MDE comprende determinar las ubicaciones de los MDE usando concordancia de patrones.
3. El procedimiento de la reivindicación 2, en el que los datos de medios comprenden datos de vídeo y en el que determinar las ubicaciones de los MDE usando concordancia de patrones comprende:
obtener datos que definen una cadencia para tramas de vídeo del flujo, donde la cadencia definida representa un orden en el que se envían los tipos de las tramas de vídeo, donde los tipos de las tramas de vídeo incluyen tramas de vídeo intrapredichas y tramas de vídeo interpredichas; y
determinar al menos algunos de los MDE en base a la cadencia definida, de modo que los MDE estén entre respectivos límites de tramas de vídeo.
4. El procedimiento de la reivindicación 2, en el que los datos de medios comprenden datos de audio y en el que determinar las ubicaciones de los MDE usando concordancia de patrones comprende:
determinar un número fijo de tramas de audio del flujo a incluir en cada uno de los MDE; y
determinar al menos algunos de los MDE para que cada uno incluya el número fijo de tramas de audio del flujo.
5. El procedimiento de la reivindicación 1, en el que determinar las ubicaciones de los MDE comprende determinar las ubicaciones de los MDE usando reglas, que comprende:
recibir datos que representan una o más reglas que definen una o más tramas de audio, tramas de vídeo e instancias de texto temporizado;
determinar ubicaciones de al menos una trama de audio, una trama de vídeo o una instancia de texto temporizado en base a las reglas; y
determinar los MDE en base a las ubicaciones de la al menos una trama de audio, trama de vídeo o instancia de texto temporizado.
6. El procedimiento de la reivindicación 1, en el que determinar las ubicaciones de los MDE comprende determinar las ubicaciones de los MDE en base a información de temporización para la sincronización de capa física de la unidad de envío de capa física.
7. El procedimiento de la reivindicación 1, en el que determinar las ubicaciones de los MDE comprende analizar una pista de indicaciones que incluye metadatos representativos de ubicaciones de datos reproducibles dentro del flujo.
8. El procedimiento de la reivindicación 1, en el que determinar los requisitos de tiempo de transmisión comprende determinar un tiempo de transmisión más temprano para uno de los MDE en base a una configuración de sistema para el dispositivo de origen.
9. El procedimiento de la reivindicación 1, en el que determinar los requisitos de tiempo de transmisión comprende determinar un tiempo de transmisión más tardío para uno de los MDE en base a un tiempo de disponibilidad de segmento para un segmento para el cual se incluyen datos en el uno de los MDE, comprendiendo además el procedimiento determinar un tiempo de disponibilidad de segmento a partir de un archivo de manifiesto para el flujo de datos.
10. Un dispositivo de origen (300) para transportar datos de medios, comprendiendo el dispositivo de origen: un segmentador (310) configurado para formar un flujo de datos que comprende segmentos de datos de medios, comprendiendo cada uno de los segmentos un respectivo archivo que puede recuperarse de forma individual asociado a un localizador de recursos uniforme, URL, o un identificador de recursos uniforme, URI, únicos;
una unidad de envío de capa física (314) configurada para entregar eventos de entrega de medios, MDE, a un dispositivo cliente de acuerdo con requisitos de tiempo de transmisión para los MDE, donde los MDE incluyen datos para al menos una parte de uno de los segmentos, donde la unidad de envío de capa física está configurada con ranuras de entrega disponibles para recibir los datos que van a entregarse; y una unidad de envío de protocolo basada en archivos (312) configurada para:
recibir el flujo de datos que comprende los segmentos de datos de medios desde el segmentador; determinar ubicaciones de los MDE en el flujo de datos de medios;
determinar uno o más de los requisitos de tiempo de transmisión para los MDE que representan los momentos en los que los MDE van a enviarse al dispositivo cliente; y
proporcionar los MDE y datos que representan los requisitos de tiempo de transmisión a la unidad de envío de la capa física de acuerdo con las ranuras de entrega disponibles para la unidad de envío de capa física.
11. El dispositivo de origen de la reivindicación 10, en el que la unidad de envío de protocolo basado en archivos está configurada para determinar las ubicaciones de los MDE usando concordancia de patrones.
12. El dispositivo de origen de la reivindicación 11, en el que los datos de medios comprenden datos de vídeo, y en el que para determinar las ubicaciones de los MDE usando concordancia de patrones, la unidad de envío de protocolo basado en archivos está configurada para:
obtener datos que definen una cadencia para tramas de vídeo del flujo, donde la cadencia definida representa un orden en el que se envían los tipos de las tramas de vídeo, donde los tipos de las tramas de vídeo incluyen tramas de vídeo intrapredichas y tramas de vídeo interpredichas; y
determinar al menos algunos de los MDE en base a la cadencia definida, de modo que los MDE estén entre respectivos límites de tramas de vídeo.
13. El dispositivo de origen de la reivindicación 11, en el que los datos de medios comprenden datos de audio, y en el que para determinar las ubicaciones de los MDE usando concordancia de patrones, la unidad de envío de protocolo basado en archivos está configurada para:
determinar un número fijo de tramas de audio del flujo a incluir en cada uno de los MDE; y determinar al menos algunos de los MDE para que cada uno incluya el número fijo de tramas de audio del flujo.
14. Un medio de almacenamiento legible por ordenador que tiene almacenadas en el mismo instrucciones que, cuando se ejecutan, hacen que una unidad de envío de protocolo basado en archivos de un dispositivo de origen:
reciba un flujo de datos que comprende segmentos de datos de medios desde un segmentador del dispositivo de origen que forma los segmentos, comprendiendo cada uno de los segmentos un respectivo archivo que puede recuperarse de forma individual asociado a un localizador de recursos uniforme, URL, o un identificador de recursos uniforme, URI, únicos;
determine ubicaciones de eventos de entrega de medios (MDE) en el flujo de datos de medios, donde los MDE incluyen datos para al menos una parte de uno de los segmentos;
determine uno o más requisitos de tiempo de transmisión para los MDE que representan momentos en los que los MDE van a enviarse a un dispositivo cliente; y
proporcione los MDE y los datos que representan los requisitos de tiempo de transmisión a una unidad de envío de capa física del dispositivo de origen de acuerdo con ranuras de entrega disponibles para la unidad de envío de capa física.
ES17701389T 2016-01-08 2017-01-06 Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios Active ES2864645T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662276674P 2016-01-08 2016-01-08
US15/399,381 US10666961B2 (en) 2016-01-08 2017-01-05 Determining media delivery event locations for media transport
PCT/US2017/012551 WO2017120482A1 (en) 2016-01-08 2017-01-06 Determining media delivery event locations for media transport

Publications (1)

Publication Number Publication Date
ES2864645T3 true ES2864645T3 (es) 2021-10-14

Family

ID=57882176

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17701389T Active ES2864645T3 (es) 2016-01-08 2017-01-06 Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios

Country Status (20)

Country Link
US (1) US10666961B2 (es)
EP (1) EP3400712B1 (es)
JP (1) JP6893930B2 (es)
KR (1) KR20180101371A (es)
CN (1) CN108432261B (es)
AU (1) AU2017205187B2 (es)
BR (1) BR112018013750A2 (es)
CA (1) CA3007318C (es)
CL (1) CL2018001833A1 (es)
CO (1) CO2018006980A2 (es)
ES (1) ES2864645T3 (es)
HK (1) HK1257973A1 (es)
HU (1) HUE052430T2 (es)
MX (1) MX2018008372A (es)
MY (1) MY192795A (es)
RU (1) RU2718170C2 (es)
SA (1) SA518391872B1 (es)
SG (1) SG11201804448QA (es)
TW (1) TWI740878B (es)
WO (1) WO2017120482A1 (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10129358B2 (en) * 2016-01-15 2018-11-13 Verizon Digital Media Services Inc. Partitioned serialized caching and delivery of large files
WO2017152178A1 (en) * 2016-03-04 2017-09-08 Bladelogic, Inc. Provisioning of containers for virtualized applications
US11122331B2 (en) * 2016-06-30 2021-09-14 Sony Semiconductor Solutions Corporation Receiving device, transmitting device, and data processing method
US10863247B2 (en) * 2016-07-20 2020-12-08 Saturn Licensing Llc Receiving device and data processing method
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US11412312B2 (en) * 2016-09-28 2022-08-09 Idomoo Ltd System and method for generating customizable encapsulated media files
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
US10904313B2 (en) * 2017-06-20 2021-01-26 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses, methods, computer programs, and computer program products for live uplink adaptive streaming
US11146608B2 (en) * 2017-07-20 2021-10-12 Disney Enterprises, Inc. Frame-accurate video seeking via web browsers
US10750220B2 (en) * 2018-04-06 2020-08-18 Enensys Technologies Method for generating a STL stream, local adapter and corresponding computer program
CN108737845B (zh) * 2018-05-22 2019-09-10 北京百度网讯科技有限公司 直播处理方法、装置、设备以及存储介质
US10652849B2 (en) * 2018-07-16 2020-05-12 Sinclair Broadcast Group, Inc. Using broadcast physical layer for one-way time transfer of universal coordinated time to receivers
CN109471736A (zh) * 2018-09-14 2019-03-15 叮联信息技术有限公司 事件信息不间断随机传递及实时共享方法
CN115460184A (zh) 2018-09-17 2022-12-09 谷歌有限责任公司 用于传递无清单流媒体内容的方法、系统和介质
KR102124194B1 (ko) * 2018-12-19 2020-06-23 포디리플레이코리아 주식회사 영상분석을 위한 다채널 영상 전송 시스템 및 이의 제어 방법
US10700798B1 (en) * 2019-03-01 2020-06-30 GM Global Technology Operations LLC System and method to receive and deliver audio content
US20210185381A1 (en) * 2019-12-11 2021-06-17 Sony Corporation Reducing latency during service change and improving robustness in advanced television systems committee (atsc) 3.0 system
CN113141514B (zh) * 2020-01-17 2022-07-22 北京达佳互联信息技术有限公司 媒体流传输方法、系统、装置、设备及存储介质
EP4162695A4 (en) * 2020-06-09 2023-08-02 Telefonaktiebolaget LM ERICSSON (PUBL) PROVISION OF SEMANTIC INFORMATION WITH ENCODED IMAGE DATA
RU203858U1 (ru) * 2020-08-05 2021-04-23 Общество с ограниченной ответственностью "Витрина ТВ" Устройство отображения и воспроизведения аудиовизуального контента
CN114598756B (zh) * 2020-12-01 2024-03-12 深圳Tcl数字技术有限公司 一种alp数据包的处理方法、存储介质及电子设备
US11882170B2 (en) * 2021-04-19 2024-01-23 Tencent America LLC Extended W3C media extensions for processing dash and CMAF inband events

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4392880B2 (ja) * 1998-06-29 2010-01-06 キヤノン株式会社 認証装置及びその制御方法並びに記憶媒体
US7146429B2 (en) * 2001-03-16 2006-12-05 The Aerospace Corporation Cooperative adaptive web caching routing and forwarding web content data requesting method
JP2007213772A (ja) * 2006-01-11 2007-08-23 Sony Corp 記録転送プログラム、記録転送装置及び記録転送方法
US20080037956A1 (en) 2006-06-30 2008-02-14 Scientific-Atlanta, Inc. Systems and Methods of Generating Encapsulated MPEG Program Streams
JP2008257592A (ja) * 2007-04-06 2008-10-23 Iwate Broadcasting Co Ltd クライアント端末、コンテンツ再生方法及びコンテンツ再生プログラム
JP4427567B2 (ja) * 2007-07-03 2010-03-10 株式会社東芝 無線通信装置及び無線通信方法
US8200810B2 (en) 2007-12-13 2012-06-12 Highwinds Holdings, Inc. Content delivery network
CN101222509B (zh) * 2008-01-22 2011-10-26 中兴通讯股份有限公司 一种点对点网络的数据保护传输方法
CN101616009B (zh) * 2008-06-27 2011-07-06 中国移动通信集团公司 数据业务的传输方法及其设备
CN102308547B (zh) 2008-12-31 2014-11-19 苹果公司 通过非流化协议流化多媒体数据的方法
US9036092B2 (en) * 2013-06-24 2015-05-19 Broadcom Corporation Video channel change system
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9032451B2 (en) 2011-09-01 2015-05-12 The Directv Group, Inc. Method and system for using a second screen device for interacting with a set top box to enhance a user experience
US9591361B2 (en) 2011-09-07 2017-03-07 Qualcomm Incorporated Streaming of multimedia data from multiple sources
CN102769509B (zh) 2012-06-07 2015-10-21 华为技术有限公司 一种物理层信号的发送方法、装置及系统
GB2506911B (en) * 2012-10-12 2015-12-09 Canon Kk Method and correponding device for streaming video data
WO2014113486A1 (en) 2013-01-15 2014-07-24 Futurewei Technologies, Inc. Using quality information for adaptive streaming of media content
EP2988519A4 (en) 2013-04-16 2017-01-11 LG Electronics Inc. Broadcasting transmission device, broadcasting reception device, operating method of broadcasting transmission device and operating method of broadcasting reception device
CN104283849A (zh) * 2013-07-04 2015-01-14 深圳市天趣网络科技有限公司 弹窗数据推送、展示方法及装置、系统
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
CN105100015B (zh) 2014-05-16 2018-07-03 林琳 一种采集互联网访问数据的方法及装置
WO2015178690A1 (ko) 2014-05-21 2015-11-26 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
WO2016129973A1 (ko) 2015-02-15 2016-08-18 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Also Published As

Publication number Publication date
CL2018001833A1 (es) 2018-10-12
JP6893930B2 (ja) 2021-06-23
KR20180101371A (ko) 2018-09-12
RU2018124449A (ru) 2020-02-10
AU2017205187A1 (en) 2018-06-21
HUE052430T2 (hu) 2021-04-28
AU2017205187B2 (en) 2020-09-10
CA3007318C (en) 2023-08-15
SA518391872B1 (ar) 2022-01-24
MX2018008372A (es) 2018-09-21
RU2018124449A3 (es) 2020-02-10
EP3400712B1 (en) 2020-12-23
CN108432261B (zh) 2021-01-05
RU2718170C2 (ru) 2020-03-30
TW201725911A (zh) 2017-07-16
TWI740878B (zh) 2021-10-01
MY192795A (en) 2022-09-09
HK1257973A1 (zh) 2019-11-01
WO2017120482A1 (en) 2017-07-13
EP3400712A1 (en) 2018-11-14
CN108432261A (zh) 2018-08-21
CA3007318A1 (en) 2017-07-13
JP2019506059A (ja) 2019-02-28
BR112018013750A2 (pt) 2018-12-11
US10666961B2 (en) 2020-05-26
SG11201804448QA (en) 2018-07-30
US20170201761A1 (en) 2017-07-13
CO2018006980A2 (es) 2018-07-19

Similar Documents

Publication Publication Date Title
ES2864645T3 (es) Determinación de ubicaciones de eventos de entrega de medios para el transporte de medios
ES2848116T3 (es) Transmisión basada en formato de archivo con formatos DASH basados en LCT
ES2767288T3 (es) Transmisión en continuo de vídeo de baja latencia
ES2784605T3 (es) Entrega de middleware de métricas de QOE del cliente dash
ES2788901T3 (es) Procesamiento de contenido multiperiodo continuo
ES2710702T3 (es) Temporización en vivo para la transmisión continua dinámica adaptativa sobre el HTTP (DASH)
US9591361B2 (en) Streaming of multimedia data from multiple sources
ES2764224T3 (es) Robusto funcionamiento en vivo de DASH
US20180316740A1 (en) Deadline signaling for streaming of media data
ES2818622T3 (es) Entradas de muestra y acceso aleatorio
KR20170089863A (ko) 멀티미디어 및 파일 전송을 위한 전송 인터페이스
ES2821382T3 (es) Entradas de muestra y acceso aleatorio
US20170331666A1 (en) Real-time control interface for broadcast object streaming
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
BR112017027511B1 (pt) Distribuição de middleware de métricas de qoe de cliente dash